1.6 How to Analyze a Systems Architect Profile ?

1.6 How to Analyze a Systems Architect Profile ?

To conclude this chapter, we will briefly present the key characteristics of an (ideal) systems architect profile. Such profiles are indeed quite rare and always difficult to find as a matter of fact. Having some clues on that still poorly explored topic may thus be helpful for any engineering organization that would like to increase its systems architecting capability.
With CESAM framework, systems architecting skills are indeed analyzed from the following three completely different perspectives, as described in Figure 17:

• Dimension 1 – business & technical skills, referring here first to standard capability such as scientific education, analysis capability and business orientation, but also to a multi-area knowledge, both from a product and engineering domain perspective;
• Dimension 2 – soft skills, that is say leadership, communication and facilitation ability (key for being able to create consensus within stakeholders), curiosity & open-mindedness, together with a strong customer orientation (key for analyzing correctly a systemic environment);
• Dimension 3 – architectural skills, with first of all abstraction and synthesis ability, modeling & needs capture capability, systems architecting main processes mastering and integration, verification, validation, qualification knowledge.

A good systems architect must indeed have a well-balanced profile with respect to all these three dimensions. This gives the key clue on how to identify systems architects. One shall indeed measure the maturity of a future systems architect on the previous three axes and check that this maturity is high in all of these axes, typically by analyzing concrete realizations done by the candidate, in order to ensure good systems architecting capability within somebody.
One may also pay attention to the following three unfortunately quite common anti-profiles that should not be confused with systems architect profiles. The first anti-profile is the technical expert profile, which refer to somebody who is excellent with respect to dimension 1, but much more poorly the other ones. A good systems architect was probably very good in several technical domains, but is clearly not anymore a technical expert, in the usual meaning of that term. The second anti-profile is the manager one who mainly developed in dimension 2. Good technical managers are usually very bad systems architects due to the fact that they have a project-oriented, and not a product-oriented vision. Thus do never take a managerial profile for a systems architecting mission, it will not work! The last anti-profile is a bit vicious since it corresponds to somebody who would have a good level in dimension 3, but not in the others, that is to say typically with poor soft skills. We are here referring to a methodologist profile, in other terms to somebody who knows very well all systems architecting and engineering methods, but without having the ability of creating consensus among them¹Systems architecting is never a “behind the door” process. This does not mean that solitary design work is not necessary… An architectural work must always identify the needs of the stakeholders and the constraints of the involved engineering domains. This requires a huge presence on the field! A good architecture is indeed always an architecture shared by all stakeholders, both external and internal: thus a permanent alignment of all concerned contributors shall be ensured.. A good systems architect has clearly strong methodological capability, but he/she shall never be confused with a methodologist²Systems architecting is indeed not a quality process, taken here in a purely normative meaning. This does not mean that quality is not fundamental in Systems Architecture, on the contrary… Its effectiveness is thus not measured by the syntactic realization of deliverables, but by the intrinsic quality of the proposed architectural choices (which can often only be validated through pear reviews). The production of documentation is also not its main objective: an architectural work must remain smart and produce the « minimal effective » quantity of technical documentation which is required. (and vice-versa).

Figure 17 – Ideal profile of an ideal systems architect 

Last but not least, do also not confuse systems architecting with systems modeling. Modeling is a tool for the systems architect, but never an end in itself. A systems architect shall master systems modeling, but more importantly he shall know why and how, and thus when, to model something. We refer to Appendix C for some good practices in that matter.

TABLE OF CONTENTS