Basic Terms & Principles

• Components are uniquely identifiable, non-trivial, nearly independent devices, individuals, organizations, organisms, elements, building blocks, parts, or sub-assemblies that may be collected together to cooperate or to serve a common purpose.
• Architectural components have externally visible properties but their internal details are hidden.
• Components exhibit behaviors.
• Behavior is the set of processes that fulfill a specific function or purpose.
• It is the range of actions and mannerisms exhibited by components in conjunction with themselves or their environment.
• It is the response to various stimuli or inputs, whether internal or external.
• Structure: arrangement or pattern of interlinkage of components; organization of a system; the form; the “shape” of a system.
• Structure is a fundamental, tangible or intangible notion referring to the recognition, observation, nature, and permanence of patterns and linkages of components. This notion may be tangible, such as a built structure, or an attribute, such as the structure of society.
• Connectivity refers to the state of being linked or joined together so as to enable some form of exchange. Connectivity is a basic form of structure.
• For power grids, the basic elements of exchange are:
  • energy
  • money
  • control/access
  • information
  • services
  • value
• Relationships are the means by which two entities are affiliated; they consist of collections of component behaviors.
• Architectural relationships consist of two classes of behaviors:
  • Interactions: Mutual or reciprocal influences
    • conversation
    • transaction
    • closed loop (feedback) control
  • Transfers: Conveyances from one entity to another
    • transmission, broadcast, narrowcast
    • grants or takings
    • open loop command and control
• A system is a set of allied or interdependent elements forming an integrated whole.
  • A system has components: it contains parts that are directly or indirectly related to each other
  • A system has structure: its components are linked by connectivity and relationships
  • A system has behavior: it exhibits processes that fulfill its function or purpose and respond to stimuli 
  • A system has qualities: a set of characteristics as seen by the users of the system (solution domain)
  • A system has properties: a set of characteristics as seen by the developers and operators of a system (problem domain)

• A system architecture is the conceptual model that defines the components, structure, behavior, qualities, properties, and essential limits of a system. An architecture description is a formal representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system. System architectures are written, composed or specified.

• Design is a different activity altogether.

Core Architecture Principles

• A good architecture is one that meets the needs of the stakeholders (especially the users) to their satisfaction, does not violate established principles of system architecture, and takes into account the relevant qualities and properties as the customer requires.
• Good architectures have conceptual integrity (intellectually clean of unnecessary complexities or 'exceptions,' similar problems are solved in similar ways, etc.), can direct a builder to cost-effective structures that can be completed within a reasonable time frame, are conceptually pleasing to all stakeholders (especially the users), and provide some special advantage (such as a competitive advantage) or usefulness to the customer.
• Conceptual integrity is best achieved by a small cohesive team of like-minded architects. Architecture should be the product of a single architect or small team with an identified leader.
• Essential functionality drives complexity, not architectural “elegance.”
• Architectural structures should have formal bases where possible to minimize ad hoc configurations with unknown properties.
• Architecture should feature a small number of interaction patterns (should do the same things in the same way throughout).
• Architecture should not depend on a particular commercial product or tool.
• Architecture should produce enforceable key constraints.
• The architect must be cognizant of the global system when optimizing subsystems.
• Stakeholders should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture.
• Architecture must be consumable (i.e. understandable) by the users. Architecture should be documented with agreed-upon notation that stakeholders can understand.
• Each component should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality. Components should be coupled only through explicit structure, avoiding hidden coupling where possible.
• Architectures should define interfaces, not vice versa.
• The system architect is not a generalist, but rather a specialist in managing complexity.

Seven Architecture Maxims

1. Architectures are abstractions. Know when to stop detailing - that is the design engineer’s job.
2. Architecture development is more than just a matter of tabulating use cases and then drawing a block diagram or a cloud illustration. It requires an understanding of the problem environment, relevant emerging trends, and the systemic issues that provide a top down view to complement the bottom up view that comes from use cases. Systemic issues cut across many use cases and are often not directly discernible from consideration of a set of unitary use cases only – this is where reference models come into play.
3. The problem decomposition that works best for human comprehension is almost always not the best for efficient implementation. The logical decomposition will look quite orthogonal, whereas the efficient implementation design will often seem oblique.
4. An architecture that looks neat and elegant is probably not real. Real architectures tend to be messy and inelegant to some degree, especially when there are significant legacy elements. Strong architectures can minimize but not eliminate the messiness.
5. Recognize that system architecture as a discipline is part science and part artistry. Don’t get carried away with the artistry part. One person’s work of art is another person’s kitchen sink stain.
6. System architecture should define organization, but all too often it is the other way around. Absent a rigorous foundation and framework, the structure of a product or system will tend to mirror the structure of the organization that produced it.
7. System architecture development is not a committee function.