Chapter 8 – Conclusion

8.1 A first Journey in Systems Architecting

This pocket guide intends to offer to the reader a first journey through systems architecting and we hope that it was appreciated. We thus explored the following topics as provided in Table 11.

However one shall notice that our pocket guide does of course not cover the full domain of systems architecting. We only focus on the fundamentals that every systems architect – even junior – shall know. Thus we put the stress on system modelling, since one just cannot do any systems architecting activity in practice without models. Models do indeed form the language of systems architecting: they can be used to analyze a problem, to describe a system, to elaborate a common vision, to communicate on a solution … The internal coherence of a system model – that leads to permanent crossed checking between the various diagrams we introduced – is also a very powerful tool for the systems architect in order to be confident in the robustness of an architecture.

8.2 The other Key Systems Architecting Topics

We did not discussed in this pocket guide, that was just intended to be an introduction to this huge domain¹ Systems architecting is a continent to explore, to rephrase an expression due to Marcel Paul Schützenberger, one of the seminal fathers of modern computer science (personal communication). , of many other systems architecting topics – summarized in Table 12 below, that could be addressed by all people who wants to specialize in systems architecting. Among them, we may cite a first group of three important topics – even if usually not the ones to learn on a first step – that should also be part of the common knowledge of any senior systems architect, that is to say:

• verification & validation (how to guarantee that a real system satisfies to its needs & requirements and to its descriptions?),
• project architecture (how to optimally structure a development project, taking into account the constraints coming from systems architecture?),
• collaborative architecture (how to organize efficiently the collaborative between the internal and the external actors of a development project?).

In a second group, we may also distinguish the following three quite specialized – and technically much more difficult – topics that may be typically reserved for expert systems architects:

• safety (how to integrate dysfunctional analyses within a system architecture?²The question is absolutely not to become a safefy specialist, which is a totally different type of expertise, but to be able to efficiently manage the interface between systems architecture and safety. ),
• system family architecture (how to architecture a full family of systems?),
• system of systems architecture (how to architecture a system of systems?).

Note finally that there also some other classical topics such as needs capture techniques, advanced functional architecture, systems architecture simulation, interface architecture or design to X³ X can mean cost (design to cost), value (design to value), maintainability (design to maintainability), etc techniques, that could also be placed in that second group.

8.3 How to Develop a Systems Architecting Leadership?

Mastering the techniques contained in this pocket guide would clearly be a first necessary important step for any systems architect. However systems architecting cannot and shall not be reduced to systems modeling. The core of systems architecting indeed consists in helping system development teams to make rational & shared optimal choices in complex environment. As a consequence, the main difficulty of systems architecting is not to master modelling in its own, which by the way is not easy. The main difficulty of systems architecting is indeed to be able to create a common vision – involving all project actors – around the system in development with the help of system models.
This last point can only be approached through concrete development projects with real experiences of consensus building. Understanding the “theory” is clearly not enough as soon as one is dealing with human relationships issues which are in fact at the core of systems architecting practice. One shall indeed understand that one cannot manage a convergence protocol, in order to create a shared vision among project actors on a given topic, in the same way than a technical study or a prototype development. When dealing with people, mistakes or bugs are typically forbidden⁴Telling to someone to do something, then sometimes after to do something else, then again after to do something again
different, will probably never work …: contrarily to a purely technical problem, human issues shall always be managed with great care. All the complexity of the systems architect job is therefore to be able to manage convergence protocols – with their inherent socio-dynamic difficulties – in complex technical environments⁵The mix between socio-dynamics and technique is of course the core difficulty of systems architecting in practice.

To progress in systems architecting, the systems architect shall thus clearly develop its non-technical competency (consensus creation, workshop animation, meeting facilitation, etc.), but which has to be applied in technical complex contexts. In this matter, practice is absolutely fundamental. One can just not achieve developing leadership in systems architecting without confronting the complexity of real development situations. In this matter, one may note that CESAMES is offering dedicated 6 to 10 month on-the-job trainings in systems architecting. Such trainings are especially devoted to that leadership construction through the concrete application of a full systems architecting process on a real system and the achievement of a complete systems architecture specification file (we refer to the corresponding item in the training section on our website: www.cesames.net).

8.4 Towards a New Systems Architecture Modelling Language

Last, but not least, we would like to point out that the different diagrams we introduced in this pocket guide were all constructed on the basis of a SysML syntax (see for instance [34]) in order both to avoid disorienting the reader and to let him/her able to use standard modeling tools to practically apply the material he/she will found in this pocket guide. However one can easily see by reading this pocket guide that such syntax is not perfectly adapted to the needs of systems architecting, due to the differences and/or discrepancies that exist between the different views. The diagrams used to statically specify missions, functions are components together with their interactions are for instance not homogeneous, which is clearly absurd⁶Other typical issues are also coming from the fact that, in most modelling languages, environment’s objects do not have the same type that system’s objects. This is just a terribly bad choice since it prevents to make use of the natural recursion brought by a system hierarchy., thus leading to lots of easily avoidable – with a good modelling language – technical difficulties while modelling systems. We would thus like to launch a call to the systems engineering community for creating a architecture-oriented system modelling language with a sound mathematical-based semantics such as the one provided by the CESAM framework within this pocket guide.

TABLE OF CONTENTS

REFERENCES

[34] Friedenthal S., Moore A.C., Steiner R., A Practical Guide to SysML : the Systems Modeling Language, Morgan Kaufmann OMG Press, 2012