1.5 The key Role of Systems Architects

1.5 The key Role of Systems Architects

Systems architecting would of course not exist without the right key people, i.e. systems architects, to support the architectural process! The systems architect shall indeed fundamentally be the core responsible of the systems integration issues. He/she shall thus ensure that the interfaces of the subsystems of the target system under design are reasonably robust for the purpose of the system development project¹And possibly beyond, but this is another issue, namely that of the reusability of reference systems architectures and of product lines design, we will not discuss here., or in other terms that they will not be questioned (or as little as possible) by the technical managers in charge of the different subsystems.

To achieve such objectives, it is necessary to play on a different dimension than the purely technical one. A key problem within system design is indeed that it is usually not enough to have the “best” possible system architecture for that it is automatically picked up and used by everybody. The global optimum, typically with respect to quality, cost, delay and performance criteria, for an integrated system is indeed never²This is true as soon as the system has not a linear behavior with respect to its entries, which is never the case for complex systems. This result can be traced back to Richard Bellman in the 50s (see [13]). the union of the local optima of each of subsystems that compose it: the consequence is that each subsystem shall necessary individually be sub-optimal with respect to these criteria, if one wants to reach global optimality at system level.

This fact is unfortunately not easy to accept for the subsystems responsible who will not design their sub-systems with a global vision, as can have the architect of the whole system³The difficulty of understanding the importance of system architecting comes from this situation. Engineers usually deal with technically homogeneous subsystems of a given system (i.e. the “boxes” of Figure 16) which are clearly visible to all. On the other side, the systems architect takes care of the system interfaces (that is to say the “arrows” in Figure 16) that nobody sees because they are strictly speaking not material. The architecture work is thus done somewhere in the invisible. It is thus difficult to detect for the uninitiated, while fundamental since it fixes the framework in which to do engineering (a bad architectural framework can typically only lead to a “bad” system). . To solve this “human” problem, which is intrinsic to the design of integrated systems, one must put stakeholder alignment mechanisms at the heart of any system architecting process. These alignment activities shall in particular ensure that the structuring systems architectural choices will always be shared by their stakeholders. Systemically speaking, such mechanisms will indeed guarantee that the technical interfaces of the product system will always be discussed and accepted at the “human” interfaces to which they are allocated within the project system (see Figure 16).

Figure 16 – The key role of the systems architect 

This quick analysis therefore shows that a systems architect must always be fundamentally capable of converging actors on the architectural choices which he/she is responsible. This convergence work – which is a substantial and essential part of the systems architect job⁴And that makes a good “systems” architect a kind of 6 feet sheep… – is however not simple at all. It indeed requires mastering, among purely technical competency, a set of completely different soft skills that could be qualified of “human” architecting and engineering since they are highly involving the “human” dimension of the project system. At that level, the systems architect shall for instance typically have the following key capability⁵Which are typically pre-requisites to achieve the success of any actors’ convergence in a systems architecting context..

• Identifying all stakeholders of a given system architecture: it looks as an apparently simple activity, but it is often terribly difficult to achieve in practice since it requires confronting the complex and changing reality of engineering organizations. Ensuring the completeness and validity of a particular organizational analysis is indeed never easy. It is notably more than classical to forget key players within a given engineering scope and to identify erroneously others⁶This can be for instance achieved by badly analysing the role of somebody in a given organization.. Moreover, organizations are often changing rapidly. Making a stakeholders mapping should thus always be constantly update if one wants to keep pace with reality.

• Aligning these stakeholders on a same architectural solution: this is a real “facilitation” skill in the best sense of the term since such a work requires a real difficult technical and human know-how. A systems architect will only succeed to achieve stakeholders’ convergence on given architectural choices if he plays consistently on both the technical side, that he/she should of course perfectly control to be credible, and the human level, in order to secure strong consensus that will withstand the test of time.

TABLE OF CONTENTS

References

[13] Bellman R.E., Dynamic Programming, Princeton University Press, 1957