| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

FrontPage

This version was saved 18 years, 7 months ago View current version     Page history
Saved by PBworks
on February 26, 2006 at 2:30:57 am
 

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. An architecture is the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales about the overall structure (i.e., essential elements and their relationships) and associated characteristics and behavior. From OPEN Process Framework (OPF) Repository.
  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. If the principle is inspired by a person, a thing, or a quote, that attribution should be given and/or explained.

 

There is no one perfect way to phrase a principle: wording is significant, but the spirit of the principle is more important.

 

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 other expansions of this acronym, and in fact this principle has its own page.

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.

4. This principle is also known as Occam's Razor.

 

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 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

 

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 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 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.

 

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

 

* Principles of system architecture

* 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

* Electrical engineering

* Electronics engineering

* DODAF

* FEAF

* MODAF

* TOGAF

* Zachman framework

 

This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)

Comments (0)

You don't have permission to comment on this page.