Extract from the white paper: The role of the architect – The Cercle CESAM

The architect assesses the compliance of the architecture with the priority needs that he must first identify as such. Compliance is then established, initially, with respect to the state of the art and then with respect to the constituents (2nd stage once the needs have been defined via the first architectural drafts).
The results of this assessment and the first compliance feedback are consolidated by establishing a compliance matrix providing an overall view of what is compliant, non-compliant or partially compliant.


Assessing the compliance of an architecture with priority needs or value is a process that must be initiated very early in the development cycle with the identification of value-bearing needs for the customer and the implementation of the compliance matrix defining the elements expected at the different phases (justification, elementary tests, global tests.).


Among the main pitfalls:

  • Poor exchanges between engineering strata and poor consideration of potentially reported
  • Liar poker policy vs contracts and financial constraints (or to get the contract).
  • The upstream team does not use minimum requirements engineering (no upstream tag) in order to give a factual matrix.
  • All needs come first.
  • Lack of clearly defined requirements.

Here are some good practices to consider:

  • Identify priority needs (KDD, key design drivers) with issuing stakeholders.
  • Capitalize on the state of the art and have a management of this state of the art (updated by R&T in particular) to know at any time what we are capable of.
  • Have a good management of multi-layer engineering margins.
  • Have a factual statement of the coverage of the technical proposal which is taken into account with the associated level of performance.
  • Element contributing to the T of the QCDT during the phase transition.
  • Very early in the development cycle, have a preliminary mapping of the Key Driver. Parameters (main indicators) on the different layers of analysis (need, system, subsystem, etc.) allowing a preliminary assessment of the feasibility and conformity to needs. Establish a traceability link between these KDPs.

We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:

With us, the prioritization of value is done by the teams in charge of writing the black box. The response is done by the architecture in the form of a batch with a logical division which represents the integration chain.

Contractual constraints stronger than non-compliance alerts from sub-systems and customer notified too late of non-compliance, program canceled late and financial and image losses at the end.

Development of a pre-sizing model to link operational KDPs, KDP systems and KDP subsystems. Development of a diverted DSM matrix -> “KDP Structure Matrix” to ensure a traceability link of KDPs and analyze the impacts of non-compliance with certain parameters.

All needs come first. With us, it is very difficult to have the analysis of the value as justification. The magic phrase “The market will never accept” is very often used.

This post is also available in pdf format.DOWNLOAD
Any comments?

Your comments will be considered by the members of the Cercle at the next monthly meeting.