SYSTEM ARCHITECTURE PRINCIPLES

Principle#1: Principle of Good Architecture

Tag Line: A good architecture optimally meets needs of all its stakeholders in an elegant manner.

Re/ference Quote:/[‘’]

./[“.//.Samatvam Yoga uchhyat/[e” – Bhagvad Gita   Translation: Equanimity/ Balance is essence of unity (in Lifp/[=e). (http://www.asitis.com/2/48.html)

(Edward Crawley, 2004)

Descriptive Version of Principle:

A good architecture is one that assigns function to form according to a well thought through concept such that it optimally and elegantly maximizes benefits to all the stakeholders while minimizing the cost. (Wen Feng)

Prescriptive Version of Principle:

An architect should take a holistic approach to balance the needs of all the important stakeholders while ensuring that the system is easy to build. To make the system easy to build the architect must modularize it and explicitly state the intent, goals and function and form.

 He must also specify appropriate interfaces to make system testable and scalable to evolving needs.

Discussion:

Consider an architect for construction of a house. A good architect first holistically considers the context in which the house is built and then proceeds to identify the needs of the person living in the house. He also holistically considers the needs of city municipal authorities and other stakeholders like banks who lend money to the house user. Then he specifies the architectural design that is easily comprehensible to the mason and construction worker. He specifies the optimal materials to minimize the cost. He ensures some extra space is left around house for future expansion. He also budgets for stronger foundation to ensure that a new floor can be constructed (flexibility).

 

 

Principle#2:  Principle of Simplicity

Tag Line: Architecture shall not be any more complex than it is necessary to meet the architectural objectives.

Reference:
“Simplicity is about subtracting the obvious and adding the meaningful.”
― John Maeda, The Laws of Simplicity: Design, Technology, Business, Life (http://quotevadis.com/post/5865779503/adding-the-meaningful)

 Introduce complicatedness to reduce complexity. – Victor Tang

Descriptive Version of Principle: An architect’s primary task is to drive out complexity from the system design process. Hence systems architected well are essentially simple in their expression and predictable in their emergence.

Prescriptive Version of Principle: An architect should eliminate all unnecessary interfaces and subsystems while organizing the remaining subsystem to hide complexity from the user (beneficiary).

Discussion:

There is a lot of discussion in philosophy, science and engineering that directs one to keep things simple. The maxim of simplicity also applies to architecture. However it very difficult to follow the principle because simplicity is a vague term that differs from system to system and situation to situation. Hence as a process, an architect must define the Minimal Viable System. This can be done by benchmarking it against the simplest system that meets the architectural goals. One can also perform a clean slate architectural design of the system that is not encumbered by issues of legacy, history and organizational competencies. Once such an architectural blue print is developed, any subsequent architectural changes to the simplest system, driven by competing stakeholder demands or upstream and downstream influences can be controlled and justified.

Principle#3: Principle of Modularity

Tag Line:

A system that is architected well lends itself to optimal level of decomposition.

Reference Quote:

"any large computation should be split up into a collection of small, nearly independent, specialized sub processes." (http://en.wikipedia.org/wiki/Modularity)

(Katja Ho¨ ltta¨ -Otto)

Descriptive Version of Principle:

In architect’s role is to partition the system to the optimal granularity to enable development of efficient design while maintaining simplicity as mentioned in Principle #2.

Prescriptive Version of Principle:

An architect must partition the system such that each subsystem or module has a definite independent function. An architect must increase the cohesiveness of entities in a module while reducing the interaction with the entities outside the module.

Discussion:

“A module is commonly defined as an independent chunk that is highly coupled within, but only loosely

coupled to the rest of the system.” (Katja Ho¨ ltta¨ -Otto). An architect must make a tradeoff between the increases in complexity of interfaces that comes along with increase modularity versus the reduction in complexity resulting from better understanding of the subsystems. A tightly coupled integral architecture is generally more efficient in performance as compared to a modular architecture. However a modular architecture is in general more scalable, flexible, resilient and testable. Modular architecture also increases commonality and product variety . Despite it being sound architectural principle it is surprising that systems in nature are largely NOT modular.

Principle#4: Principle of Scalability

Tagline:  System scalability is an architectural choice and not an accident!

Reference Quote:

Sun Tzu - Managing a big army is in principle the same as managing a small one: it is a matter of organization. Directing a large army is the same as directing a small troop: it is a matter of strict and impartial command. (http://www.chinavista.com/experience/warart/epotential.html)

Descriptive Version of Principle:

An architect must take a lifecycle view of the system and ensure that the system can scale appropriately to the varying demands by building appropriate interfaces at system boundaries.

Prescriptive Version of Principle:

An architect should build the system interfaces not only to interact with a whole product system or other systems but also with itself.

Discussion:

Generally most natural systems are effectively scalable. They achieve this by cloning. Cloning is achieved by two steps. First step involves repeated instantiation of the same system and the second step involves interfacing of the clone with the parent system. Since systems in general have long periods of existence, a system architect must understand that the system will be subject to variable demands in its life time. Hence it is important that the system can scale up or down based on demand. Certain architectural constructs like bus are more scalable than others like ring or hub and spoke.

Principle#5: Principle of Frugality

Tag Line: A well architected system is good enough not perfect.

Reference Quote:

 “The way to wealth is as plain as the way to market. It depends chiefly on two words, industry and frugality: that is, waste neither time nor money, but make the best use of both. Without industry and frugality nothing will do, and with them everything.” 
― Benjamin Franklin (http://www.goodreads.com/quotes/tag/frugality)

Descriptive Version of Principle:

An architect has to ensure that system is frugal in terms of its resource utilization by building in efficient structures and interfaces. This is in consonance with the duty of architect to maximize benefit while minimizing the cost.

Prescriptive Version of Principle:

An architect must first envision a most constraining context and whole product system and then begin the process of architecting. This ensures the system is most frugal in terms of resource utilization.

Discussion:

As the population of world increases, the pressures on resources, both natural and man-made , are increasing. These pressures lead to issues of resource contentions and increasing costs. Organizations and individuals are therefore trying to seek greater efficiency in the operation of systems like buildings and cars. A frugal design tries to minimize waste by making efficiency a priority, early in the architecture development phase. TATA Nano which is a car that sells for $2000 at the same time giving 55 miles per gallon is an example of frugal design. The architect here designed a light weight body from inexpensive but reliable materials.

Principle#6: Principle of Reliability

Tag Line: Potential emergence of malfunction dictates the architecture of the system.

Reference Quote:

 “You are only as strong as your weakest link.” - Unkown

Descriptive Version of Principle:

An architect must envision the failure scenarios and build in redundancy to ensure that the overall system availability and probability of failure on demand are within acceptable limits.

Prescriptive Version of Principle:

An architect must characterize the risk of the system by taking the product of likelihood of malfunction and severity of malfunction for each of the subsystems and build in necessary redundancy based on system requirements.

Discussion:

Issues like BP oil spill and Bhopal gas tragedy can cause enormous damage to life and property. These events occur because the architecture did not include the right levels of redundancy for each of the involved subsystem leading to single points of failures. In my prior role as a safety engineer, I always began by performing a process hazard analysis and then defining the system requirements. This ensured that the system was architected to meet the risk profile of the failure.  Also using tools like FMEA (Failure Mode Effects Analysis) one can identify the single points of failure and build in necessary redundancy.

Principle#7: Principle of Architecture Malfunction Detectability

Tag Line: A wisely architected system tells the owner (beneficiary) what is wrong, when it is wrong.

Reference Quote:

“The primary duty of an exception handler is to get the error out of the lap of the programmer and into the surprised face of the user. Provided you keep this cardinal rule in mind, you can’t go far wrong.”

        — Verity Stob (http://www.cs.uky.edu/~keen/115/quotes)

Descriptive Version of Principle:

An architect must establish a concrete strategy for system enhance the detectability of system malfunction evolving an alarm rationalization strategy.

Prescriptive Version of Principle:

An architect must design appropriate flags for system malfunction for residual risk of the system after architecting the system for reliability as in Principle #6.

Discussion:

In FMEA one of the levers to reduce the risk is to increase the detectability of the system malfunction. An architect has to consider an appropriate alarm rationalization strategy especially for safety critical systems. When an alarm will be annunciated and what is the required operator response should be characterized early in the architecture document so that the design process in controlled to give the expected outcomes. In my prior work we classified alarms to different levels of severity and announced the high severity alarms in a prominent manner so that the operator could take appropriate mitigation strategies. We also provided a clear document that instructed operator the correct mitigation procedure.

 

Principle#8: Principle of System Hierarchy

Tag Line: An architect must enable the team to manage complexity by reducing the consideration set.

Reference Quote:

“Hierarchies are celestial. In hell all are equal.” 
― Nicolás Gómez Dávila

Descriptive Version of Principle:

–Architect must ensure that the architecture is stable and easy to build and upgrade. Hence when a system is partitioned into multiple layers, ensuring that all the subsystems in a hierarchical level evolve/change at same rate (clock speed), helps in managing complexity of architectural evolution .

 Prescriptive Version of Principle:

– An architect must ensure that all subsystems in a hierarchical level have comparable clock speeds.

Discussion

•Architectural upgrades are expensive and complex activities. Hence an architect should always strive to develop a stable architecture that lasts for a long time. It is easier to perform an upgrade to just one layer or hierarchical level in the architecture at any given point in time.

•One way to achieve this is to first classify the subsystems that evolve at the same rate  and then group them into a hierarchical level.  It is also beneficial to layer in such a manner that the slowly evolving subsystems are at lower levels of hierarchy while quickly changing subsystems are at higher level of hierarchy. (Fine)

Example: Consider the hierarchy in OSI model. The elements or subsystems of physical layer evolve at a slower pace compared to subsystems of application layer. Almost all subsystems in physical layer evolve every decade while the application layer subsystems change every year.

Reference:

Discussions with Shakeel Rajwani

 

 

Principle#9: Principle of Architectural Flexibility

Tag Line: Architecture should enable systems to respond well to changing context.

Reference Quote:

Flaw of Averages: Plans based on average conditions are wrong on average (Sam Savage).

Inspired by course on Real options for product design by Professor Richard de Neufville

Descriptive Version of Principle:

–      “The essential role of the architect is to ensure that the  architecture enables the system to flexibly scale up or down based on system usage/ demand.”

Prescriptive Version of Principle:

“Architect should create interfaces in such a manner that a repeated instantiation of the system can extend the system capacity”

Discussion:

Architecting is an upstream activity. A lot of information about the system, its operation and usage patterns are unknown at the time of architecting. In such a scenario an architect might be tempted to develop the architecture based on average usage patter of a similar system. However a clever architect would take the distribution of load on the system and build flexibility to the architecture to scale up or down based on demand. To understand the degree of flexibility and the cost of incorporating flexibility the architect can use the theories of real options.

An example is for flexible architecture is cloud computing. If you are a website and are not aware of traffic to your server. Then you could architect the system on Amazon Elastic cloud 2, so that you can scale up or down the server capacity based on demand. If you had a local server, such a system architecture might not have been equally.

Principle#10: Principle of System Resilience

Tag Line:
A well architected system is not the one that never fails but one that heals itself after it is damaged.

Reference Quote:

 “The oak fought the wind and was broken, the willow bent when it must and survived.”
― Robert Jordan, The Fires of Heaven (http://www.goodreads.com/quotes/tag/resilience)

Descriptive Version of Principle:

An architect help construct a system that is resilient to shocks from the external environments by evaluating the acceptable system down time and evolving the reconstruction or repair strategy.

Prescriptive Version of Principle:

An architect shall begin by evaluating the acceptable system down time and then evolve a strategy that either builds in redundancy or maintains an appropriate level of inventory of easily replaceable spare parts to make the system resilient to external shocks.

Discussion:

Systems are subjected shocks from external environment. It is impossible or expensive to build a system that will withstand all the shocks.  Instead it is better to develop a system architecture that can be either enable system be functional in a degraded mode and allow for quick bounce back. Human body and many other systems in nature have a resilient architecture. When subjected to shock or injury the body functions in a degraded manner but soon rebuilds itself and gets back to normal operation. This is similar to graceful degradation that is propounded by authors like Olivier L. de Weck. (Weck)

Bibliography

Edward Crawley, O. d. (2004). The Influence of Architecture in Engineering Systems. Monograph, 1st Engineering Systems Symposium.

(n.d.). Clockspeed : Winning Industry Control in the Age of Temporary Advantage –. In C. Fine.

http://en.wikipedia.org/wiki/Modularity. (n.d.).

http://quotevadis.com/post/5865779503/adding-the-meaningful. (n.d.).

http://www.asitis.com/2/48.html. (n.d.).

http://www.chinavista.com/experience/warart/epotential.html. (n.d.).

http://www.cs.uky.edu/~keen/115/quotes. (n.d.).

http://www.goodreads.com/quotes/tag/frugality. (n.d.).

http://www.goodreads.com/quotes/tag/resilience. (n.d.).

Katja Ho¨ ltta¨ -Otto, O. d. (n.d.). Degree of Modularity in Engineering Systems and Products with Technical and Business Constraints. CONCURRENT ENGINEERING: Research and Applications.

Weck, O. L. (n.d.). Modeling Methods and Conceptual Design Principles for Reconfigurable Systems.

Wen Feng, E. C. (n.d.). Understanding the Impacts of Indirect Stakeholder Relationships – Stakeholder Value Network Analysis and Its Application to Large Engineering Projects.