Architecture: System Metaphor

Architecture is abstraction until it is expressed in concrete artifacts: design specifications and maquettes.
System Metaphor and Concept bring all structural and functional elements (Utilitas and Firmitas addressing System Quality Attributes) together.

A system metaphor is a story that everyone - clients, programmers, and managers - can tell about how the system works.
A concept is a semantic unity that every element – a method, a visual element (control, screen, page and form), class and object, module and component, process and system – inherits when it is defined and implemented.

We seek a system metaphor for several reasons:
     - Common Vision: To enable everyone to agree on how the system works. The metaphor suggests the key structure of how the problem and the solution are perceived. This can make it easier to understand what the system is, as well as what it could be.
     - Shared Vocabulary: The metaphor helps suggest a common system of names for objects and the relationships between them. This can become a jargon in the best sense: a powerful, specialized, shorthand vocabulary for experts. Naming something helps to acquire power over it.
     - Generativity: The analogies of a metaphor can suggest new ideas about the system (both problems and solutions). For example, the metaphor of "Customer service is an assembly line" suggests the idea of a problem being handed from group to group to be worked on, but it also raises the question, "What happens when the problem gets to the end of the line?" This can bring out important issues that might otherwise lurk and fester.
     - Architecture: The metaphor shapes the system by identifying key objects and processes, and suggesting aspects of their interfaces. The metaphor supports the static and dynamic object models of the system.

A System Metaphor selection is driven by similarities in the business domain and a metaphoric domain in processing System Subject. The metaphor is some analogy that is recognizable by everyone on the business domain.
For example, the Chrysler accounting system used the "Assembly Conveyer" Metaphor.
Similarly, a Case Management might use the "Postal Service" as a System Metaphor.

There are two main products of the System Metaphor defining process:
- System Subject, and
- System Process.

System Subject is an abstract entity that the system is planned to operate with and on. System Subject is the reason why the system is needed. If System Subject is removed, the system loses its meaning. System Subject is an entity that is recognized by any element of the system regardless of the location of the element.
     Example 1: the System Subject of the "Building" Metaphor is "Person" (an individual).
     Example 2: the "Letter" is the System Subjects of the "Postal Service" Metaphor.

System Process is an abstract logical flow that operates on an instance of the System Subject during its entire life cycle
     Example 1: the System Process of the "Building" Metaphor is a flow of steps to accommodated and procure an instance of the "Person" System Subject while inside the Building after Person enters Building and until Person exits Building.
     Example 2: writing, enclosing, securing, mailing, sorting, delivering, recognizing content, responding, forwarding response back through the mail chain are steps of the logical process flow of the System Process of the "Postal Service" Metaphor.

Both System Subject and System Process allow to define System Quality Attributes and to identify the points of their applicability as well as metrics (expectation limits). Defining System Process is important for two reasons:
1. It defines how System Subject is conceptually processed by the system, and
2. It defines how, which and when the system attributes are applied to System Subject during processing.

These reasons form two parts of the System Process.
First one defines how System Object "travels" in the system.
Second one defines what the system needs to do to allow (or restrict) System Object to "traverse".
These two parts of the System Process allow to identify system rules, expectations and metrics – known as System Quality Attributes, their indicators and criteria.

Conclusion:

1. We create a System Metaphor to "extract" primary products and attributes of a Concept:
     a. System Subject, and
     b. System Process.

2. We create a Concept to:
     a. design quality attributes in all elements on the system level,
     b. delegate quality attributes to all elements on the system level,
      and, for each attribute, establish
          1. Metrics,
          2. Test Scenarios;
     and during design
     c. bring functionality and structure together.

3. Without System Metaphor it is hard to identify System Subject and System Process, and hence it is difficult to identify concrete system qualities, attributes, and metrics.
Thus, In such situation one commonly resorts to using only:
     a. generic system requirements that "normally" are applied (such as "security", "performance" that typically are utilized by other systems), and
     b. ambiguous metrics (such as generic performance measurement indicators specified as "system must have a good performance", or "system must respond within two seconds").
     Same is applicable to any quality attribute.
     This results in "designing" defects into the system right from the beginning.

Example of Applying Design Concepts

In order to achieve the required levels (limits) of System Quality Attributes, we should apply architectural concepts that will be translated into technical maquettes forming a system prototype.

Quality Attributes	Examples of Applicable Design Concepts
Utilitas
Business Provision	System Metaphor, System Subject, System Process, System Metadata
Utilization Security	System Metaphor, System Subject, Principle of Least Knowledge
Performance and Efficiency	System Metaphor, System Process, Single Responsibility, Single Design Point
System Recovery	System Metaphor, System Process, Principle of Least Knowledge
Learnability and Memorability	System Metaphor, Industry Patterns, Standards and Clichés
Usage Satisfaction	System Metaphor, Consistency
Firmitas
Modifiability	System Metaphor, System Process, Single Responsibility, Single Design Point
Requirements Tolerance and Estimate Predictability	System Metaphor, System Process, Single Responsibility, Single Design Point
Extensibility	System Metaphor, System Process, Loose Coupling, Published Interfaces, System Metadata
Maintainability	System Metaphor, System Process, Single Responsibility, Single Design Point, Technology Transparency, System Metadata
Portability	System Metaphor, Published Interfaces, Plug-In/Out and Switch-It-On/Off, Technology Transparency
Reusability	System Metaphor, System Process, System Metaphor, System Subject, Technology Transparency
Integrability	System Metaphor, System Subject, System Process, Plug-In/Out and Switch-It-On/Off, Loose Coupling, Technology Transparency
Scalability	System Process, Loose Coupling, Single Responsibility
Testability	System Metaphor, System Process, Published Interfaces, Industry Patterns, Standards and Clichés

System Metaphor: Business Case

OpenFrame System Metaphor is Business Case (further herein referred to as BizCase). Business Case herein is not viewed as one in project management domain.

From a software system viewpoint, a Business Case is a set of business atomic information processed as a unit. This takes roots from the UML Use Case notion.
Note: We can think of BizCase as of Business Entity. However, Entity is more abstract, requires another metaphor to describe it (such as "Customer is an Entity"), and therefore should not be acquired as a System Metaphor. There is another problem with Entity-based metaphors and systems. If Letter can be considered as Entity in the Postal Service, then do we define Address as Letter’s attribute or also entity? If, even hypothetically, Letter can be sent to many addresses and Address can be used to send many letters to, then Address is not a Letter’s attribute. However, how can Address be a Business Entity if it does not participate in postal business process as a subject? It is only a reference, an instruction for the Postal Service, similar to a database connection.

BizCase, as a representation of a visual set of information, is more suitable for a System Metaphor.
Both Letter and Address (as well as anything else) can be represented as BizCase. And, what’s more interesting, BizCase can be at the same time an attribute of other BizCases. This is a conceptual point of our System Metaphor that BizCase supports both hierarchical and relational structures. (Hierarchical means "objectal" in technical language, that is, related to objects). BizCase is not a participant of a business process. It rather controls business process flow. Because BizCase always represents a Client requesting certain actions or processing of business information.

Business Process (Abstract)

We define a business process as a continuous and systematic action, operation, or series of changes taking place in a definite manner and directed to some end.
A business process is a way that any organizational body performs specific, meaningful action to reach an established objective, such as revenue for profit organizations, or social purpose or governance for non-profit organizations. A business process typically is a cyclic course of actions repeating on and on. For example, a post office receives revenue from its business by accepting a letter, processing it (stamping, forwarding, and delivering), and charging money for those services. Because the process does not end after the letter has been delivered but rather repeats again for other letters, we can say it has the cyclic nature of repeating itself.

The business process can be ongoing. That is, the same sender can stay within the process of sending letters further on, visiting the post office from time to time not for sending letters or parcels but for purchase of stamps or bubble mailers. This would not be considered the same postal procedures as sending a letter but for us it will be the same business process of that postal office reaching its objective of receiving revenue. Being the same the business process repeats itself for each sender and recipient. The business process would end when the sender exited it, for instance, moving to another city or having passed away. In both cases, the sender would not be able to continue utilizing the postal services of that office and, therefore, would not be able to participate in its business process.

In the definition of the business process given above we must stress the expression "series of changes". The point here is that a business process can and does consist of a series of sub-processes. It is similar a Use Case that includes smaller Use Cases, speaking in UML.

In the business process of serving a sender, the post office undertakes specific sub-processes, such as: accepting a letter, verifying letter’s attributes such as the address correctness and the right postage applied, stamping the letter to certify those attributes, forwarding the letter to the recipient’s post office, and so forth.

Each sub-process ends when a certain change has occurred. For example, a postal business process may include a sub-process of retrieving a letter from a mail deposit box. The process of forwarding a letter starts when a letter (as the process participant) enters it (the process). The process may also comprise sub-processes. This is when a letter changes its status. When a letter changes its status from "Retrieved" to "Accepted", the sub-process of retrieval ends, and the process of attribute verification starts. When the verification sub-process ends satisfying all requirements for correct delivery and collecting a fee, the status of the letter changes to "Verified". Thus, we are talking about transitions of process subject from one status to another during the subject’s lifetime. Business process subject begins its lifetime when it enters the business process and lives in the process until it exits it.

Business Process Subject: BizCase (Abstract)

A BizCase is a distinctive, self-contained and independent business unit that is a part of the business domain and - as being its part – participates in the business process flow.

In other words, a BizCase is a logical instance of data visually presented to a user and requiring a specific business decision or action.
One BizCase can be represented by one business data view (page, screen, or form). It is obvious that the same business view cannot be used for different BizCases. If a view can be re-used for several business tasks or actions performed upon a BizCase data.
Sometimes a BizCase can be presented by more than one view. However, we need to underline that it is done primarily for two reasons:
     - separation of a view by logical blocks or steps (such as a wizard-like screen flow); or
     - partitioning of a large view into smaller sub-views.
Often these reasons are combined. Separation and partitioning of a view is implemented primarily for usability scenarios rather than for design purposes.

An empty BizCase has no importance from a business viewpoint. Each Business Case instance has information important to the business in question. Such information is represented by business case attributes containing data values. The data values are of interest and importance to the user of the business case.

In order to describe attributes of BizCase (such as info, data state, status, etc) we need to use a metaphor comparison to explain terminology we are going to apply. Basically, this is why we have chosen a metaphor for our system in the first place.

Example of System Metaphor

Below we show simplified and schematic use of "Postal Service" System Metaphor the way it might be applied to a system and the process of identifying and defining System Quality Attributes.

As it is specified above, during establishing the System Metaphor we:
     - define a quality attribute,
     - determine a point of its applicability,
     - establish requirements and metrics,
     - set rules for System Subject and constraints for System Process;
     - produce test scenarios,
     - identify risks and potential problems.

The following diagram is, of course, simplified but it shows usefulness of creating a System Metaphor to discover a profound analogy to familiar elements.


Using unfamiliar elements has a risk of not discovering all aspects required by the business domain until the system is actually tried and tested. For example, further evaluation of the Performance as a System Quality Attribute on the system level would reveal that actual delivery by ground may depend on road’s (a communication channel) conditions such as "throughput" and "surface" that may impact of speed of delivery. Another factor in this scenario may be a fleet of aging delivery trucks.

» Back To Steps to Create True Software Architecure

---