2.3 CESAM Systems Architecture Pyramid

2.3.1 The three Key Questions to Ask

As discussed in the previous section, any system can be analyzed from an operational, functional and constructional perspective. In order to achieve such analyzes in practice, one must simply remember that one shall just ask three simple questions¹ to cover these different architectural visions:

Key operational question: WHY does the system exist?²
Key functional question: WHAT is doing the system?³
Key constructional question: HOW is formed the system?⁴

One usually summarizes these different questions in the CESAM Systems Architecture Pyramid, which is a simple graphical way to represent a system, presented in Figure 27 below. Such a pyramidal representation intends just to recall that details – and thus clarification of the system model – will permanently increase when moving from the operational to the constructional vision.
Note that the key point is of course the order in which these three core questions are asked during a system design process. The systems architecting consists indeed in following the previous order, i.e. passing from the first question (“Why?”), to the second one (“What?”) up to the third one (“How?”), in that exact order. Be however careful not to manage successively, that is to say one after the other, these three types of analyses which should largely overlap in practice. At some point, it is indeed just impossible to reason operationally without any vision of the concrete solution that will answer to the operational architecture⁵. This typically leads to manage coarse grain functional and constructional analyses during the operational analysis. In the same way, it is not possible to reason functionally without any idea of the components that may implement the functional architecture. This obliges to manage middle grain constructional analyses during the functional analysis. As a consequence, good systems architecting practice is clearly to manage in parallel the three architectural analyses at the same time, but not at the same grain of analysis.

The CESAM systems architecture pyramid figure

Figure 27 – The CESAM systems architecture pyramid

Organizing the systems architecting process in that way will allow passing from technical-oriented to value-oriented system design strategies. In most of classical system design strategies, the technical components are indeed usually the starting point and it is only at the end of the development phase that one begins to look how the developed system fits to its stakeholders needs. Such an approach is a product-push strategy from a marketing perspective and it may work well as soon as one is making incremental improvements on existing products in stable markets.
Unfortunately industry must nowadays more & more manage many technological ruptures within unstable environments. In that case, just pushing new products will have a high probability to fail. To increase success, one must thus invert the design logic in order to put stakeholders and their needs as a starting point to the product development. Systems architecting shall thus just be seen as the key methodological tool to implement such a need-pull strategy.

2.3.2 The Last Question that shall not be Forgotten

The three previous questions are however not the only ones that one should ask in the context of complex systems design & development. The last fourth key question, unfortunately often forgotten in real systems contexts, refers to the product/project duality as introduced in section 1.1. It simply consists in asking which person – in other terms “Who?” – is the project counterpart of the different product elements described in the three architectural visions of the product, that is to say:

WHO owns each architectural element of the system?

This question can then be declined according to the three architectural visions as follows:

Operational perspective: who are the stakeholders of the system?
Functional perspective: who is in charge of the functions of the system?
Constructional perspective: who is responsible of the components of the system?

Asking these different questions is clearly fundamental from a systems architecting perspective. First it is just impossible to capture the right needs without deeply interacting with the stakeholders of the system of interest, which requires identifying them as early as possible, thus leading to question 4.1. Secondly, we may recall that the robustness of a system design is directly correlated to the fact that all transverse functions are managed, i.e. under the responsibility of somebody within the project, which immediately motivates question 4.2. Third one cannot imagine influencing the design of a system without involving all functional & constructional responsibles, which again obliges knowing them well, which can be achieved through questions 4.2 and 4.3. In this matter, we shall also recall that the role of a systems architect is usually to manage a complex socio-dynamics implying all these different actors, which cannot be done without perfectly understanding their personal motivations, their synergies and their antagonisms with respect to a given system design & development project. We are here again in the “who” sphere and not in a technical issue.

Alignment of the project system architecture with the product system architecture figure

Figure 28 – Alignment of the project system architecture with the product system architecture

Note finally that the “WHO” question is also crucial in the construction of the project organization. A good project architecture indeed results from the mapping of all architectural elements of a given product system into the project system, that is to say onto people, where they shall be put under a single responsibility. This project/product alignment principle is indeed crucial to be sure that all operational, functional and constructional elements of a product system are taken in charge by somebody within the project system, which obviously a sine qua non condition for the completeness of any engineering analysis, but also to guarantee that no product architectural perimeter has two project responsibles which would mechanically lead to many engineering conflicts⁶. Figure 28 illustrates this alignment principle on the electronic toothbrush example: the boxes appearing on the project system side are for instance modeling project teams that correspond there to the first levels of decompositions of the different views which are provided on the product system side.

2.3 CESAM Systems Architecture Pyramid