1.2 The Complexity Threshold
At this stage, it is now time to explain more precisely what “systems complexity” is and how it is connected with systems architecting. An element of answer is provided by the Constructive Systems Engineering Cost Model (COSYSMO; see for instance [79] or [84]). This cost model – which extends to general industrial systems a classical model well known for information systems since the 1980’s1That is to say the Construction Cost Model (COCOMO) developed by Barry Boehm in 1981 (see [1], [19] or [83]). This other model expresses the effort for constructing an information system (in men-months) in terms of function points, which was aimed to be an intrinsic complexity measure of an information system, independent of the programming language. – is based on an integration complexity measure of a product system2In this matter, note also that the notion of “complex system” cannot be formally defined. One can however define the notion of “complexity” for a system, as introduced in this section. This complexity definition will then allow discussing whether a given system is of low, medium or high complexity – but not whether it is complex or not, which is a typical false debate for us, even if many people like to discuss on the difference between complicated and complex, which is irrelevant from a purely scientific perspective which can only deal with measured complexity – or eliciting the connection between engineering effort and complexity as provided by the COSYSMO model that we presented here. that recursively measures3The exact complexity measure provided by COSYSMO is more complicated than that. However the approximation that we are making here, for the sake of simplicity, is totally valid. the number of external & internal product interfaces within a given industrial system.
The COSYSMO cost model connects then the effort of engineering, expressed in men-months, required developing a given product system (denoted Effort in the below equation) to this intrinsic measure of complexity (denoted Complexity in the below equation), by the following relationship4Such a model is a statistical model, constructed on the basis of the analysis of several real engineering projects.:
Effort = A x Complexity1+B,
Equation 1 – Relationship between engineering effort and systems complexity according to COSYSMO
where, on one hand, A is a constant, depending on the size and performance5A is 1.0 by default, but multiplicatively grows depending on product or project parameters such as number of critical algorithms, requirements and operational scenarios to manage, requirements and architecture understanding, expected level of service, migration and technological risks, project team experience, stakeholders cohesion, etc. of the project system, and where, on the other hand, B is a statistic scale factor only related to the product system, than can move from 0.05 for simple systems up to 0.5 for large systems.
The key issue to point out here is the non-linear nature of Equation 1 which induces a largely nonintuitive relation between integration complexity and engineering effort, and thus system delivery delay which is directly connected to such an effort6 Typical relation is Delay = 2.5 x Effort1/3, where Delay and Effort and respectively expressed in months and men-months. We refer to the appendix of [70] for a rational explanation of that apparently empirical law discovered by Boehm [19].. It is indeed important to see that integration complexity is proportional to the square N2 in the number N of components of a given system7When a system has N components, the number of its internal interfaces is indeed N2/2 on the average.. As a direct consequence, the engineering effort is then proportional to N3 , where N stands again for the number of component of the underlying system, when a large size system is involved, due to the 1.5 exponent in Equation 1 in this situation. In more familiar terms, this means that the engineering effort is multiplied by 8 (resp. 1,000) if the number of components of a system is multiplied by 2 (resp. 10), with a project team who would be able to easily absorb the increasing of complexity8This probably never occurs, which means that the engineering effort increasing will be probably much more that the simple impact of the single complexity parameter, due to the A factor in Equation 1 that will probably also heavily evolve in such complex situations. .
As a result of that complexity laws, the engineering effort in a system development project will be quickly too important, when complexity grows, for being anymore handled by a single person. In other terms, there will be always a cognitive rupture moment where complexity is too high to be any longer efficiently individually mastered by a systems architect or engineer. This rupture point is of course difficult to formally define and it depends on the system maturity of a given industry9The system maturity of an industry may evolve among time due to its industrial cycles (see Case study 1). , but as far as we could regularly see in practice, it can always pragmatically be observed when complex systems designers began to express strong cognitive difficulties10 Typical verbatims in such complexity situations are: “it is impossible to take a reasoned decision”, “we have the feeling of not mastering anymore anything”, “we are spending all our time to understand our problems and then there is not more time to solve them”, “we are fighting against a more and more increasing pressure of our environment”, “cost and delays are exploding and we cannot do anything to avoid it”….
Figure 11 – Project effort and integration complexity relationship
The consequence of this situation is that we can now distinguish two types of engineering, depending whether the complexity of a given system lies before or after the complexity rupture zone that we pointed out (see Figure 11). The first type of engineering, working perfectly well for low complexity systems, is just what we will here call “classical engineering”: it is usually based, on one hand, on waterfall design project approaches, induced by a separation of engineering organizations by domain specialties, and, on the other hand, on implicit systems models where key technical knowledge only lies in the brains of a limited number of technical experts.
Such engineering unfortunately do not work anymore when the systems complexity threshold that we pointed out, is crossed. One arrives then in a domain where transversal collaboration becomes key in order to complete individual expertise (which is of course still mandatory) and where explicit systems models are now mandatory due the fact that it will be basically impossible to handle implicitly the complexity one is facing. In other words, one enters in “systems engineering” which is the engineering approach dedicated to integrative complexity mastering, that we will discuss more in details in the two next sections.
System Maturity Cycles: the European Space Industry Case
The European space industry is a sector were systems complexity is well mastered, due to a very early introduction of systems engineering that goes back to the 1960’s when Europe decided to construct its own spatial capability. Systems engineering was then chosen as a key tool to reach this objective. It took afterwards two to three decades to totally master this practice which is today completely integrated within all engineering processes.
In the 1990’s, the failure of the very first Ariane 5 launch (cf. Appendix B for more details on that case) lead however to a deep evolution of the systems engineering processes. The issue was to better integrate and monitor the emergence of critical real-time embedded software with its difficult associated safety issues. A new industrial cycle began when these difficulties were mastered, which quite interestingly is finishing nowadays due to the growing pressure of the new low-cost competitors like SpaceX or Blue Origin.
The European space industry indeed totally reshaped with the creation – announced in June 2016 – of a new company – Airbus Safran Launchers – that integrates vertically two key players. It is too early to tell how will probably evolve again systems engineering in that context, but there is no doubt that this practice will play a key role in the success of the new challenges that the European space industry will have to face in the near future.
Case study 1 – System maturity cycles: the European space industry case
As a matter of fact, one shall finally also notice that integration complexity is increasing in most areas due to the impact of many new technological paradigms. The replacement of analogical control by numerical control or the new electrical architecture are for instance deep trends, which are regularly creating new software, electronical or electrical interfaces between components within numerous industrial systems, hence by the same way, mechanically increasing the integration complexity of the corresponding systems. Most of industries will thus cross the complexity threshold along the lifecycle of their products and thus be obliged to deal with systems engineering and architecting, if they want to be able to efficiently face this challenge.
NEXT PAGETABLE OF CONTENTS
References
[1] Abts C., Boehm B., Brown W. A., Chulani S, Clark B.K., Horowitz E., Madachy R., Reifer D.J., Steece B., Software Cost Estimation with COCOMO II (with CD-ROM), Englewood Cliffs, Prentice-Hall, 2000
[19] Boehm B., Software Engineering Economics, Englewood Cliffs, Prentice-Hall, 1981
[79] Valerdi R., The Constructive Systems Engineering Cost Model (COSYSMO), Quantifying the Costs of Systems Engineering Effort in Complex Systems, VDM Verlag Dr. Muller, 2008
[83] Wikipedia, COCOMO, https://en.wikipedia.org/wiki/COCOMO
[84] Wikipedia, COSYSMO, https://en.wikipedia.org/wiki/COSYSMO