User:YoavShapira/Principles of system architecture

Introduction

This page describes the theoretical principles of System Architecture (SA). System Architecture can be defined in several ways, including:

1. The composite of the design architectures for products and their life cycle processes. From IEEE 1220-1998 as found at their glossary.
2. A representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and human interaction with these components. From the Carnegie Mellon University's Software Engineering Institute as found at its glossary.
3. An allocated arrangement of physical elements which provides the design solution for a consumer product or life-cycle process intended to satisfy the requirements of the functional architecture and the requirements baseline. From The Human Engineering Home Page's Glossary.
4. The architecture of a system in terms of its logical (eg, functional) and physical (component) architecture. Contrast with business architecture and software architecture. From Donald Firesmith's Glossary.
5. A description of the design and contents of a computer system. If documented, it may include information such as a detailed inventory of current hardware, software and networking capabilities; a description of long-range plans and priorities for future purchases, and a plan for upgrading and/or replacing dated equipment and software. From The National Center for Education Statistics glossary.

The original motivation for creating this page was an assignment by Professor Edward Crawley of MIT, for his class titled System Architecture and taught in 2005. However, we recognize the general applicability and interest of this material: equivalent classes are taught at numerous schools, and we invite everyone to provide feedback and add principles from their own experience or creation.

List of Principles

Principle: underlying and long enduring fundamentals that are always (or almost always) valid.

For each pricinple, a short description is provided, along with longer normative and descriptive explanations, and hopefully an example.

Principle 1: Robust Functionality Drives Essential Complexity

1. Essential complexity is that which is essential to deliver functionality before gratuitous complexity slips in,
2. Functionality drives complexity in any given concept,
3. But “Functionality” is often defined as a surrogate for a much broader set of functions for which the product will actually be used.
4. Therefore, it is the (often implicit) robust functionality which drives essential complexity

Principle 2: Every System Is Made Up of Subsystems

1. Every system is made up of subsystems.
2. Alternatively, every system can be viewed as a part of another system, up to the whole universe.
3. The interfaces between subsystems are a place of key leverage for the architect.
4. Therefore, the architect should spend a significant chunk of his/her efforts on designing and clearly specifying these interfaces.

Principle 3: All Design Processes Should Involve Iteration

1. All design processes can and should involve iteration.
2. Many systems are too complex, and many architects are not competent enough, to do a perfect job on the first pass.
3. Many data points only become available later in the architecture or design process.
4. Therefore, every architecture design process should involve iteration: the process should be designed to be conducted over and over again until a satisfactory solution is reached.

Principle 4: Local versus Global Optimality

1. The optimal architecture or design for a given subsystem may result in sub-optimal global functionality of the bigger system.
2. Therefore, the architect must be cognizant of the global system when optimizing and designing subsystems.

Principle 5: Omnipresent Risk

1. Every system has risks associated with it.
2. Risks can rarely be completely eliminated, but they can be noted and accommodated in the architecture.
3. A well-designed architecture is robust to these risks, can continue to function if they materialize.

Principle 6: The Customer is the Judge of Quality

1. An architecture that satisfies the architect but not the customer is useless.
2. The customer should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture.
3. While the architect may attempt to educate the customer to their mutual benefit, in cases of difference of opinion it is the customer's opinion that matters.

Principle 7: Holistic Thinking

1. The architect should strive to think holistically about the system, its components, its usage contexts, and other relevant systems.
2. Holistic thinking is important in coming up with the best possible architecture.
3. If the architect does not think holistically, he or she may miss important factors that should influence the system architecture.

Principle 8: Modularity

1. One of the architect's roles is to ensure the best modularization of the system architecture, so as to allow for all the benefits of modularity: easier testing, easier accommodation of new requirements at the component level, and easier accommodation of new components at the system level.

Principle 9: KISS

1. The architect should strive to adhere to the KISS principle, "keep it simple, stupid."
2. The system architecture should be as simple as possible without conflicting with other design principles.
3. Architectures that are more complex than necessary will result in sub-optimal systems.

Principle 10: Identity

1. Everything that exists have a specific set of characteristics or identity that describe what it is.
2. A system's identity is based on the identities of its constituent parts and how they interact together. In other words, an entity is more than the sum of its parts.
3. Because system features are parts of a system identity, system designers need to understand the decompositions and the inner interactions of these parts in a system.

Principle 11: Conceptual Brilliance Doesn't Blind the Laws of Physics

1. A system architecture may be elegant, but the architect must not become so enamored with his or her work so as to lose track of the basic governing laws of the usage context in which the system operates.
2. Most of the time, the laws of physics must be obeyed: perhaps if the system is to be operated in a complete vacuum in outer space, some may be relaxed, but not all ;)
3. Therefore, the architect and other stakeholders must not be blinded by the beauty (in their eyes) of their creation, and always review features with a pragrmatic and detail-oriented eye as well.
4. The inspiration for this principle comes from the 1996 Woodruff Distinguished Lecture, delivered by Norman R. Augustine, at the time the Chairman and Chief Executive Officer of Lockheed Martin Corporation.

Principle 12: Develop a common language for your team

1. Not only is the job of the architect to drive ambiguity out of the system by defining the boundaries of the system, to creating the concept of the system, by allocating functionality and defining interfaces and abstractions, but the architect need to be able to communicate these goals completely and clearly in the deliverables. Moreover, a common language is needed for continuous communication among team members throughout the developmental process. It is the architect’s job to define the language of the system.
2. The architect must not allow ambiguity to creep back into the system through difficulties in communication. The architect must create a basic method of communication, so that all team members can communicate clearly and accurately.
3. On any given project, an architect has the responsibility of getting everyone on the same page so that they can speak about their system in common terms. One example from industry is the use of UML in many projects. UML provides a common language for teams to communicate about designs.

Principle 13: Garbage In, Garbage Out

1. The quality of a system architecture depends largely on the inputs provided to the architect.
2. The architect is partially responsible for ensuring high-fidelity inputs. For example, the architect should identify sources for user needs appropriately, and obtain user needs from them, rather than through other indirect or secondary sources.
3. If low-fidelity, noisy, inaccurate, or otherwise low-quality upstream data is provided to the architect, the system will suffer with a sub-optimal architecture.
4. Communications, cross-checking, and other data gathering and verification approaches can and should be used to ascertain the quality of data being used to design the system architecture.
5. Inspired by the corresponding computer science principle.