User:YoavShapira/Principles of system architecture: Difference between revisions
YoavShapira (talk | contribs) |
YoavShapira (talk | contribs) No edit summary |
||
Line 114: | Line 114: | ||
# Descriptive version: a good system architect is one who is both educated and experienced in the role. |
# Descriptive version: a good system architect is one who is both educated and experienced in the role. |
||
# Inspired by the ancient Chinese proverb: ""I hear and I forget, I see and I remember, I do and I understand." |
# 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 === |
|||
# Decisions are almost always based on uncertain information and almost always depend on fugure things happening, future technologies, future values... |
|||
# Accordingly, these decisions are best made using appropriately weighted systemic uncertainty measures. |
|||
# Inspired by Thomas Speller, an MIT PhD student as of [[2005]], during a discussion for MIT's ESD.34 System Architecture course. |
Revision as of 00:47, 30 October 2005
Introduction
This page describes the theoretical principles of System Architecture (SA). System Architecture can be defined in several ways, including:
- The composite of the design architectures for products and their life cycle processes. From IEEE 1220-1998 as found at their glossary.
- 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.
- 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.
- 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.
- 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: What Is Good Architecture?
- A good architecture is one that meets the needs of the customers 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.
Principle 2: Robust Functionality Drives Essential Complexity
- Essential complexity is that which is essential to deliver functionality before gratuitous complexity slips in,
- Functionality drives complexity in any given concept,
- But “Functionality” is often defined as a surrogate for a much broader set of functions for which the product will actually be used.
- Therefore, it is the (often implicit) robust functionality which drives essential complexity
Principle 3: Every System Is Made Up of Subsystems
- Every system is made up of subsystems.
- Alternatively, every system can be viewed as a part of another system, up to the whole universe.
- The interfaces between subsystems are a place of key leverage for the architect.
- 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
- All design processes can and should involve iteration.
- Many systems are too complex, and many architects are not competent enough, to do a perfect job on the first pass.
- Many data points only become available later in the architecture or design process.
- 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
- The optimal architecture or design for a given subsystem may result in sub-optimal global functionality of the bigger system.
- Therefore, the architect must be cognizant of the global system when optimizing and designing subsystems.
Principle 6: Omnipresent Risk
- Every system has risks associated with it.
- Risks can rarely be completely eliminated, but they can be noted and accommodated in the architecture.
- 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
- An architecture that satisfies the architect but not the customer is useless.
- The customer should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture.
- 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
- The architect should strive to think holistically about the system, its components, its usage contexts, and other relevant systems.
- Holistic thinking is important in coming up with the best possible architecture.
- If the architect does not think holistically, he or she may miss important factors that should influence the system architecture.
Principle 9: Modularity
- 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
- The architect should strive to adhere to the KISS principle, "keep it simple, stupid."
- The system architecture should be as simple as possible without conflicting with other design principles.
- Architectures that are more complex than necessary will result in sub-optimal systems.
Principle 11: Identity
- Everything that exists have a specific set of characteristics or identity that describe what it is.
- 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.
- 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
- 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.
- 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 ;)
- 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.
- 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 13: Develop a common language for your team
- 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.
- 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.
- 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
- The quality of a system architecture depends largely on the inputs provided to the architect.
- 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.
- 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.
- 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.
- Inspired by the corresponding computer science principle.
Principle 15: Between the Idea and Reality Falls a Shadow
- The idea may seem so simple but the reality in life and the execution of it is very complex and never really goes as planned.
- 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 will prove more problematic than anticipated.
- The difference between espoused ideas and the action of people often do not align. This proves the same when I have had people 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. I was inspired by this principle during my classic strategic war studies and have always remembered Clausewitz, On War, when he said, “The gap between principles and actual events cannot always be bridged by a succession of logical thought.” Consistently, after the very long and deliberate mission and decision analysis methods we used, ie succession of logical thought, the plan never survived much past the first few minutes of movement. Just like the plan to make money in business is to, buy cheap and sell high, is simple and well know, the ability to actually achieve that reality is much more difficult. The same is true for the principles of war, just because they are well known implementing them successfully in the real world is very difficult.
Principle 16: Must Do To Learn
- No class or homework is sufficient for one to become a good system architect.
- 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.
- 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.
- 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.
- Descriptive version: a good system architect is one who is both educated and experienced in the role.
- 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
- Decisions are almost always based on uncertain information and almost always depend on fugure things happening, future technologies, future values...
- Accordingly, these decisions are best made using appropriately weighted systemic uncertainty measures.
- Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for MIT's ESD.34 System Architecture course.