System Architecture Principle 5: Systems exhibit emergent behavior

Tagline: Systems exhibit emergent behavior.

Descriptive version: As the elements of a system are brought together and interact, processes (function) and other intrinsic properties will emerge.

Prescriptive version: An architect must pay as much if not more attention to the functions and the combination of functions as compared to the items of form.  It is the proper combination of these internal functions that will result in the external delivered functions that provide value to the beneficiaries.  These emergent functions will not simply be the some of the sub-functions.

Discussion: During (Crawley2010), it was stated ``Form by itself delivers no value''.  With this I somewhat agree and somewhat disagree.  It has been exhibited, by options like the iPhone, that some users will perceive higher benefit to a system when the system has an appealing `industrial design'.  This could be an argument for form providing value.  On the other hand, one could argue that the function of the device, the iPhone in this example, provides the base value and form provides additional perceived value.  With this argument the statement of ``form by itself delivers no value'' might be restated best as ``form provides additional value assuming that functional needs are satisfied''. 




Citation
E. Crawley. Esd.34 lecture 1, September 2010.

System Architecture Principle 4: Systems exist to solve a need

Tagline: Systems exist to solve a need (Shapira) (Crawley2010a).

Descriptive version: Systems exist because humans or organizations have a need and are willing to trade something of value for that need to be satisfied.

Prescriptive version: It is important for the system design / architect to understand the needs of the key stakeholders and design a system that satisfies those needs.  Further, the perceived benefit of the system must exceed the perceived cost to obtain and operate the system.

Discussion: In the end, systems are acquired by exchange of money or other things of value in return for the benefits of the system.  The system must provide perceived value that is greater than the perceived costs, the difference being the perceived relative benefit of the acquiring organization or person.  Note the relation to the perceptions of the acquiring person or organization; this very much is in line with the principle of good architecture, which it is in the eye of the beholder.

This model gives the architect to levers to pull in order to increase the relative perceive value.  The first is to focus on the external interfaces, external form, and external deliver function in order to increase perceived value.  The second is to manage the internal system design so as to decrease the system life cycle costs

Citations
Y. Shapira. Principles of system architecture. http://en.wikipedia.org/wiki/User:YoavShapira/Principles_of_system_architecture.

E. Crawley. Esd.34 lectures on value exchange model, 2010.

System Architecture Principle 3: What can go wrong will go wrong

Tagline: What can go wrong will go wrong.

Descriptive version: It is very rare for a system of greater than medium complexity to operate without failure. This applies to both the satisfying the intended needs and anticipating future needs.

Prescriptive version: Robust design, flexibility in design, and design for contingency and emergency operations are critical to the success of a system.

Discussion: The potential history of this ``law'' dates back to an 1877 meeting of the Institution of Civil Engineers (Holt1878):

It is found that anything that can go wrong at sea generally does go wrong sooner or later...

Various other written references to the law of turned up over time, including in the context of stage magic, mountaineering, and as a name for the second law of thermodynamics. The law has been attributed to Capt. Ed Murphy, and engineer from Wright Field Aircraft Lab (Bloch1977), and to an unnamed theoretical physicist (possibly from California Institute of Technology, aka "The Other Technical School"). While it is difficult to pinpoint its origins, the law quickly spread throughout various aerospace engineering cultures (Unknown), into the engineering and science communities, and eventually into popular culture.

In the context of systems architecture, it is important that one consider all possibilities in the design and implementation of the system. Tools and techniques to do this include the consideration for contingency and emergency operations, designs that are robust to variability in operating conditions, to consider flexibility in design so a system can accommodate future unanticipated needs and operating scenarios. This should also be expanded to include consideration of human factors; humans are unpredictable, messy system elements and all care must be taken in the design and operation of systems that require humans to execute any of the system functions.

Citations

A. Holt. Review of the progress of steam shipping during the last quarter of a century. Minutes of Proceedings of the Institution of Civil Engineers, LI:2{10, 1878.

A. Bloch. Murphy's Law, and Other Reasons Why Things Go WRONG. Methuen Paperbacks Ltd, 1977.

Unknown. http://www.catb.org/jargon/html/M/Murphys-Law.html.

System Architecture Principle 2: You can't do everything for everyone

Tagline: You can't do everything for everyone.

Descriptive version: A system of any size will have many stakeholders with many needs to be satisfied  it will be very difficult or very expensive to completely satisfy all of them.

Prescriptive version: An architect must make trades between which needs will be fully satisfied and those that will be partially satisfied or not satisfied at all.

Discussion: Projects of any significance will have multiple stakeholders each with multiple needs that must be satisfied . It is up to the architect to determine the most important stakeholders and needs that must be satisfied . Sometimes this means that needs that are very important to a stakeholder will not be satisfied . It is important for the architect to use high quality (low variability) information when making the decision as to the most important needs to satisfy and which should be partially satisfied or wholly considered out of project scope.

As a supplement to this principle, according to Ed Crawley: "Very many factors will in influence and act on the conception, design, implementation, and operation of a system."

(As a corollary to this principle, the stakeholder with the need that has the least importance will be the most vocal stakeholder, causing no end of grief for the architect.)

(My) Definition of Good Architecture

Tagline: Good architecture is in the eye of the beholder.

Descriptive version: Ultimately, architecture is a blend of art and science with a tendency to be more art than science. Like all art, good architecture is in the eye of the beholder; that is the judgment of what makes good art depends on the tastes and preferences of the person observing the art.

Prescriptive version: As an architect, one must understand all the stakeholders that will observe their work over its lifespan, and make an attempt to either create something that is "good" within their eyes or make a conscious decision not to appease that stakeholder. All of this must be done while satisfying the system requirements, working within the system and project constraints, and without violating the laws of physics.

(My) System architecture principles

I recently had cause to be explicit about the principles of systems architecture that I think are important.  These are very personal, meaning these have worked for me in the past when architecting a system.  I thought I would share them here, in a series of blog posts, for all the world to see.  These influence how I think about systems, how I design them, how I critically judge systems, and the guidelines I use to evolve an existing system.  I would welcome any feedback on your experiences and thoughts on architecture principles.

Principle 1:   (My) Definition of Good Architecture.
Principle 2:   You can't do everything for everyone.
Principle 3:   What can go wrong will go wrong.
Principle 4:   Systems exist to solve a need.
Principle 5:   Systems exhibit emergent behavior.
Principle 6:   System design drives life cycle costs.
Principle 7:   You can't escape the laws of physics.
Principle 8:   Beware of software.