1.4 The Value of Systems Architecting

Chapter 1 – Why Architecting Systems?

1.4 The Value of Systems Architecting

To complete our discussion on systems architecting, let us now focus on the value brought by this discipline, which was in particular quite well analyzed by Honour in [41]. The key point to understand is that the systems engineering approach in which systems architecting takes place, mainly consists in redistributing the engineering effort towards upstream phases of the project, in a “definition” phase, in order anticipating design risks as early as possible within a systems development project.

Figure 14 below, extracted from [41], perfectly illustrates this paradigm, where more time is initially spent better understanding the system to develop and thus reducing the project risks in the future, compared to a traditional design. Such an approach strongly relies on systems architecting since the “definition” phase will typically contain a strong part dedicated to the construction of a systems architecture file that will allow to analyze the system under design in all its dimensions1Typically such as environment, lifecycle, use cases, operational scenarios needs, functional modes, functions, functional dynamics, functional requirements, configurations, components, constructional requirements, constructional dynamics, critical events, dysfonctional modes and behaviors, verification & validation., the other part being devoted to the project planning. In that perspective, systems architecting can thus be seen as a risk management good practice in complex systems development contexts.

Systems Architecting as a risk management practice figure

Figure 14 – Systems Architecting as a risk management practice 2This figure was reproduced from [41].

Many evidences support this point of view (see for instance again [41] for many concrete examples). Among them, we will consider a quite interesting one which comes from NASA. In 1992, the financial controlling office of NASA indeed analyzed 32 major spatial programs conducted during between 1970 and 1990, comparing the final budget overrun with the budget ratio which was allocated to the initial “definition” phase, upstream the Preliminary Design Review (PDR), which does especially include the initial systems architecting analyses, as discussed above. The finding of that financial analysis was quite clear: budget overrun was indeed statistically inversely proportional to the budget dedicated to the definition phase. More precisely, it could be seen that budgets more or less always at least double when the definition phase is weak and that the optimal ratio to dedicate to the definition phase seems to be around 15 % of the global budget (see Figure 15 below). Consequently, this probably means that, to cover optimally product & project risks, a complex systems manager should allocate around 5 % of its global budget to systems architecting, strictly speaking, with another 10 % being reserved for project-oriented initiation and preparation activities.

One can thus understand that systems architecting is a key tool for mastering systems design and development projects in the respect of their quality, cost, delay and performance constraints (QCDP), as soon as one deals with complex systems produced by the integration of many technical systems (hardware & software) and human systems (people & organizations). We shall finally recall some key principles3 That one shall always have in mind during a systems design & development project. provided by systems architecting that allow achieving this objective:

  • Provide simple, global, integrated and shared visions of a system: “to be simple” and capture completely all dimensions of a given problem in complex environments, which does not mean “to be simplistic”, is always very difficult…
  • First, think about needs and not about solutions: this last point being unfortunately the common rule in most of systems development projects. One shall thus remember that the “customers” of a system project shall fundamentally feed the systems architecting process.
  • Sort out all “spaghettis” in a system design: in order to avoid mixing everything (objectives, functions, technical constraints, etc.) and confusing ourselves while confusing others which are also again very common bad practices in too many complex systems contexts.
NASA statistics supporting the importance of the definition phase figure

Figure 15 – NASA statistics supporting the importance of the definition phase4This figure was reproduced from [41] where it was traced back to [37].

NEXT PAGE

TABLE OF CONTENTS

References

[37] Gruhl W., Lessons Learned, Cost/Schedule Assessment Guide, Internal presentation, NASA Comptroller’s office, 1992

[41] Honour E.C., Understanding the value of systems engineering, INCOSE 2014 International Symposium, Vol. 14, 1207–1222, Toulouse, June 20-24, 2014, France, INCOSE, 2004; accessible at
http://www.seintelligence.fr/content/images/2015/12/ValueSE-INCOSE04.pdf