Modeling of the system and value chains in architecture

The work of the architect is based on the construction of models which make it possible to produce (in an automated way in an ideal vision) an exhaustive, coherent and unambiguous system architecture documentation.

Among the main pitfalls:

• Consider models only as communication and alignment tools and do not base architectural decisions on the exploitation of models,
• Do not set up traceability links between the models,
• Failing to explain the links between engineering models and architectural models,
• Not focusing enough on the form: an illegible diagram cannot be communicated and is therefore difficult to use,
• Not using models to highlight value chains and communicate them to stakeholders.

Here are some good practices to consider:

• Proceed step by step in the implementation of model-driven engineering: first we formalize, then we share the models, we build architectures, we reuse architectures, we use them for simulation, then for specify etc,
• Set up an architecture plan per project that instantiates the toolbox and the level of depth expected for each box (however, criteria must be given, for example, to model novelty),
• Attach the risk and value aspect to the models in order to have a shared global vision and use the models to highlight the perimeters on which to work (particularly relevant in a company with a strong history),
• Have an end-to-end modeling approach – from development to test (e.g. formalization of scenarios with a test perspective (traceability)), while taking into account the time allocated,
• Communicate by always using the same models (so as not to lose people) and adapt the level of detail to the audience (so you need several levels for each model),
• Do not hesitate to add images or other to make the modeling more understandable and better communicate,
• See a clear objective per model and a unique message per diagram: you have to know why you model. Feel free to create a second schema if you need to send a second message,
• Information must be accessible without the tools being an obstacle,
• Think carefully about the life cycle of the models created and in particular clearly define the way to manage them in configuration,
• Throw away diagrams when they are no longer useful (stop maintaining them).

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

“ We use our architectural models to validate security analyses,
“ We have set up a 150% model which is instantiated by project according to the context and the objectives to be achieved,
“ Our modeling tools: Visio, Draw IO, Enterprise Architect, Capella, Rhapsody, Tom Sawyer (“simple” automatic layout of connection to other tools).