User:YoavShapira/Principles of system architecture

This article lists several principles of system architecture. For each principle, a short description is provided, along with longer normative and descriptive explanations, and in some cases an example.

Principle 1: What Is Good Architecture?

1. 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 ilities by allowing for maintenance, evolution, further development, embedding, etc. as the customer requires.
2. Really good architectures are also elegant (intellectually clean of unnecessary complexities or 'exceptions'), can direct a builder to cost-effective structures that can be completed within a reasonable time frame, conceptually pleasing to all stakeholders (especially the user), and provide some special advantage (such as a competitive advantage) or utility to the customer.

Principle 2: 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 3: Every System Consists of Subsystems

1. Every system consists 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 4: 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 5: 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 6: 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 7: 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 8: 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 9: 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 10: KISS

1. The architect should strive to adhere to the KISS principle, "keep it simple, stupid." There are

Principle 11: 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 12: 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 pri

Principle 13: 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 needs 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 14: Garbage In, Garbage Out

1. The quality of a system architecture depends largely on the inputs provided to the architect.
2. The architect is particularly responsible for ensuring high-fidelity inputs. For example, the architect must identify legitimate sources for user (and sponsor) needs appropriately (e.g., as distinguished from user— or sponsor— wants or wishes; or, sponsor constraints), and obtain user needs from them, rather than from uncertified personnel, or other indirect or secondary sources.
3. If low-fidelity, noisy, inaccurate, or otherwise low-quality upstream data is provided to the architect, the system may suffer from a sub-optimal architecture.
4. Good inter-personal communications, cross-checking, and other data gathering and verification approaches (e.g., the use of prototypes) can and should be used to ascertain the quality of data being used to design the system architecture.

See also GIGO.

Principle 15: Between the Idea and Reality Falls a Shadow

1. The ability of state an idea simply does not neccessarily or frequently lead to simplicity in execution of said idea.
2. The architecture concept or design may seem simple or logically flow on paper, but often times in reality the challenges of cultures, technology interfaces and other real world issues prove more problematic than anticipated.
3. The difference between espoused ideas and the action of people often do not align. This is exemplified when individuals brief plans and everything sounds great but the environment in which the plan will be executed is not considered in the planning process. This generally results in significant problems and plan changes. An example of this is the difficulty of successfully implementing the business principle of buying cheaply and selling dearly to amass great fortune.

Principle 16: Must Do To Learn

1. No class or homework is sufficient for one to become a good system architect.
2. A well-designed course, such as MIT's ESD.34 System Architecture offering, teaches the important concepts, provides examples, and most of all, attempts to instill in the student a way of thinking appropriately about systems and system architecture.
3. However, such courses are no substitute for real experience. The only way to become a good system architect is to serve in this role on multiple projects, preferably (at least initially) working under the guidance of more experience architects.
4. Prescriptive version: to be a good system architect, one must have been properly educated and had experience in the system architect role on at least one significant real-life projct.
5. Descriptive version: a good system architect is one who is both educated and experienced in the role.
6. Inspired by the ancient Chinese proverb: ""I hear and I forget, I see and I remember, I do and I understand."

Principle 17: Systemic Uncertainty

1. Decisions are almost always based on uncertain information and almost always depend on future things happening, future technologies, future values...
2. Accordingly, these decisions are best made using appropriately weighted systemic uncertainty measures.
3. Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for MIT's ESD.34 System Architecture course.

Principle 18: Standardized Process Improvement

1. A process should be standardized before it's improved, for maximum effect. If a process is not standardized the benefit from improvement will be reduced.
2. Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for MIT's ESD.34 System Architecture course.

Principle 19: Early Defect Elimination

1. Defects should be identified and eliminated as early as possible in the product development process.
2. The later you are in the process, the more expensive and/or difficult it is to fix defects appropriately.
3. Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for MIT's ESD.34 System Architecture course.

Principle 20: Value is Identified Outside

1. Most often, customers judge the value of a product, system, or service by looking at its external interfaces and their function and form. They frequently treat the product/system as a black box for their use and for their value.
2. The architect should keep this mind, and maximize the perceived value of the system by focusing on its external interfaces, external form, and externally-delivered function. Of course, the architect must also keep the internal modules and sub-systems in mind.
3. Inspired by the common proverb "Don't judge a book by its cover" which unfortunately many people do -- that's why the proverb is a proverb ;)

See also

• Systems architecture / Systems architect
• Software architecture / Software architect
• Hardware architecture / Hardware architect
• Systems engineering / Systems engineer
• Software engineering / Software engineer
• Requirements analysis / Requirements engineer
• Systems design
• DODAF
• FEAF
• MODAF
• TOGAF
• Zachman framework