Proposal, justification and choice of competing architectures

The selection of an architecture among several competing architectures is done according to a selection process which must be justified based on criteria, chosen according to the principles of system engineering, criteria according to which the architecture can be evaluated based upon its strengths and his weaknesses.

Among the main pitfalls:

• There are not enough candidate solutions. It is often induced by too many constraints: lack of time, means and sometimes imagination (we are already happy to have a solution that meets the needs).
• In fast iterative processes (including AGILE processes), it is sometimes difficult to position the identification of candidate architectures and justifications in the cycle. We tend to present the solution obtained.
• Absence of justification capitalized at design time, which leads to retro-engineering a posteriori, or the loss of information and difficulties in providing justifications during an audit, an impact analysis, or developments later.
• Insufficient black box analysis, which leads to bias in the selection of criteria, stakeholders, etc.
• Not anticipating the variability of needs in the evaluation of candidate architectures.
• Poor choice of selection criteria between competing architectures: poor consideration of non-functional ones (scalability, resilience, etc.), difference criteria, etc.
• Disregard the architecture of the data model which is key on certain types of systems.
• Involvement of too few stakeholders or over-representation of certain stakeholders (marketing, customer, etc.).
• No “factualization” of the criteria: the evaluation is no longer objective.

Here are some good practices to consider:

• Plan this phase in the development process: impose, for example, a technical review regularly dedicated to this subject (once a month for example), or a criterion for the milestones of the project, or even a questioning every x sprints.
• Adjust the effort to the level of the risk and the associated problem according to the subjects.
• Bring out disruptive architectures by organizing creativity and innovation workshops.
• Implement good knowledge management (including old systems, technology watch and patents, etc.).
• Model and describe the different alternatives to help present them, validate them, and make informed choices.
• Communicate through architectural diagrams to use them as support for speech.
• Use processes for positioning architectures in relation to each other: Pugh matrix, risk/value analysis, effort/benefit, DSM matrix, etc.
• Use of software tools to quickly explore many architectures.
• Create a prototype for cases where the risk incurred justifies it (this is the principle of the POC).
• For developments, it is interesting to compare with the status quo to challenge the contribution of value.
• For the data model (of information systems), distinguish and link the conceptual model to the implementation model (e.g. a complete conceptual model – in the mathematical sense – can give a complex and costly implementation model).

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

“ We include the identification of options and not a single architecture in the design process.
“ We systematically ask ourselves the question of the issue linked to design. This is what motivates our choice of alternatives.
“ We use a Novelty Ranking that rates the risk we take based on the number of deployments of the solution