0.3 CESAM: a Collaboration-oriented Architecting Framework
CESAM is however not only a mathematically sound system modeling framework, specifically focused on complex integrated systems. It is also an architecting framework which means that it is intended to efficiently support all the design decisions that a systems architect needs to regularly take during a complex system prototyping or development project. We must recall in this matter that modeling is not an end in itself1Which most systems modelers do unfortunately forget!, but just a tool for architecting which is the key design process addressed by the CESAM framework. Architecting here means finding a solution that fulfills a series of external needs and constraints. It can be seen as an optimization process which has to construct and select the “best” system among a series of possibilities. Choice is thus intrinsic to that activity. Being able to make the “good” choices in a rational way is thus always key in any system design project. This is exactly the purpose of the CESAM framework which provides to the working systems architect a number of systemic views as a support to collaborative architectural decisions.
It is indeed important to remember that a technical system does never exist alone and that it cannot be designed independently of the people who are engineering it. A “good“ systems architecture is in particular always an architecture that all stakeholders do share. The first job of any systems architect (by applying the core principles of systems architecting to the engineering system to whom he/she belongs) shall thus always be to understand and to identify the organizational architecture in which a given system development takes place: the technical architecture of the system under design is indeed highly correlated to that organizational architecture (we refer to section 1.1 for more details on this important topic). This explains why a systems architect must manage the two following types of activities which are of very different nature:
- On one hand, technical activities fundamentally centered on the definition of high level global system models, making explicit interfaces between all components of a system,
- On the second hand, facilitation activities centered on the construction of convergence on these models, creating a common vision between all stakeholders of the system.
Figure 6 illustrates these two kinds of systems architecting activities which all rely on system models. The initial version (initial version 0) of the system architecture presented in that figure is the result of a technical activity, when the second version (shared version 1) is the result of a facilitation activity. It is thus quite interesting to see the differences between these two system views: this illustrates the value brought by facilitation which is crucial for collaboratively constructing robust systems.
Figure 6 – Using models to converge on the same vision of a system
System models are thus key for ensuring a collaboration of quality which is mandatory in the context of complex integrated systems development (as we will see more in details in section 1.5). In these matters, the basic tool for managing collaboration and creating architectural convergence is the collaborative systems architecture workshop. We will now quickly sketch its mode of operation in order to better understand the “human” dimension of systems architecting.
The principle of such a workshop is quite simple since it consists “merely” in putting in the same place all stakeholders2This means that these stakeholders were comprehensively and correctly identified, which in itself is a difficult exercise with multiple traps. Moreover, it can also easily be understood that it is difficult to carry out convergence with 150 people! The effective implementation of a collaborative workshop also presupposes that we previously achieved an organizational architecture analysis, which sufficiently abstracted the “field” of a given system architecture by only identifying a limited number (typically no more than 15) of top level players, truly representative of the entire organizational scope of the target system, with whom we shall manage the required convergence work. that must convergence on a given architectural solution and submitting then them a first version of the intended system architecture. This is indeed key to obtain stable systems architectures. The groundwork for a collaborative systems architecture workshop is then to discuss and collaboratively modify the proposed system architecture, so that the final architecture, as resulting from such a process3To carry out such a work in practice, a simple way to proceed is typically to make visible the system model to share by printing the various architectural views on large A0 posters. One can then easily collectively discuss and change an initial system architecture by directly annotating these architectural diagrams (cf. Figure 7 for an illustration of this method). Note that the systems architect must manage that “live” modification process in order to permanently guarantee that the proposed changes have the consent of all participants and do not lead to sub-optimality at system level., becomes a collective asset.
This method naturally leads to shared visions which are usually deeply engaging all involved actors. Note that the systems architect has a key role in this process since he/she must always ensure that the system architecture, on which all stakeholders converge, remains a satisfactory response with respect to all needs it shall take into account. However this modus operandi assumes a key prerequisite, that is to say that all stakeholders of the workshop have a common systemic representation language. In other terms, the meaning of all system descriptions shall be the same for all participants, which is usually not the case. It is therefore highly recommended to start a collaborative systems architecture workshop by sharing with the participants the semantics of each of systemic representation that will be used4This is again one of the important use and purpose of CESAM framework..
Once established these core bases, the work of convergence towards a shared architecture can be attacked, starting with a collective analysis of the proposed initial architecture. We then often see in practice that the first problems which occur are again syntactical problems, due to the fact that the vocabulary that is used to describe the elements of an architecture is not necessarily shared among its stakeholders! To solve this other recurrent issue, it can for instance be helpful to also share with all participants a glossary of key technical terms, in order to be sure that these terms have exactly the same meaning for everybody.
Figure 7 – Initial and final models as managed during a collaborative systems architecture workshop
Once these barriers are removed, we can consider that we have a solid base to attack the technical activities, strictly speaking. The work consists then in discussing the proposed system architecture and modifying it collectively, if necessary (see Figure 7), so that the final architecture resulting from the exchanges is shared by all at the workshop’s end. Note that it is also mandatory to have an arbitration mechanism which will handle all the disagreement points, if any, for decision-making (in which case, a new loop with stakeholders may be needed to explain them the definitive choices).
As one can see here, the systems architecting technical process shall always be deeply integrated into a “human” engineering process without which no shared and no “humanely” robust systems architectures would emerge (which by the way is often a sine qua non condition for them to also be technically robust).
NEXT PAGE