This activity aims to:
1. Specify system behaviors in the form of a functional architecture by identifying and prioritizing internal system functions, defining, and synthesizing existing functional interfaces between these functions through both a functional interaction diagram and a Function Breakdown Structure (or FBS). Finally, the operating modes of the system are defined.
2. Allocate the internal functions of the system to the components through a logical then physical architecture by first identifying the components that implement the internal functions using an allocation matrix, then prioritizing these components and defining finally their interfaces via an interaction diagram.
3. Implement an iterative convergence and justification protocol for stakeholders and subsystem teams by creating and evolving architecture views. The objective is to get all the stakeholders to adhere to
the same vision of the architecture of the system in order to secure its definition and to have any compromises validated. The system architect is responsible for arbitrating and must ensure
convergence, but he is not necessarily the one who makes the implementation choices. These activities should not be seen as sequential but should be carried out in parallel. All dysfunctional aspects must be taken into account.
The architect carries out a white box analysis which allows him to identify the functions covering the needs and uses identified and prioritized while apprehending the future couplings between the components. It starts by thinking as much as possible independent of the technology used at the component level, then it drives the implementation choices. He is the guarantor of multi-business convergence on the necessary compromises to be found.
Among the main pitfalls:
- Encroachment on business domains. The architect must be the link between the different professions and disciplines and must allow arbitration thanks to a global vision. The technical responsibility must be borne by the architect, but it is sometimes difficult to have the businesses accept them (e.g. the software businesses who work from dedicated views which take over),
- Failure to successfully iterate with subsystems in the architecture phase. This can generate additional costs and rework downstream. This is often due to a lack of time (they see the interest but have not automated the activity in their process) or a lack of visible added value on their part (especially when the integration issues are not history on these layers),
- Believing and letting people believe that the implementation of architectural practices is an all or nothing approach, with no possible latitude on its implementation,
- Confusing logic/physics with software/hardware,
- See the architect as the guarantor of a functional and non-dysfunctional architecture.
Here are some good practices to consider:
- Integrate architectural practices step by step and gradually increase in ambition. Make a first project in POC mode then generalize,
- Organize the levels of abstraction of the diagrams by respecting the rule of 7x7x7,
- Adapt its practices to the complexity of the product and the maturity of the company. We must always keep in mind that the implementation of the architecture must create value,
- Take into account both the static and temporal dimension of the architecture,
- Demonstrate value layer by layer. We start by increasing the maturity of the system level before tackling the subsystem level and so on. Demonstrating value by example to the strata below is a catalyst and highlights the changes needed sooner,
- Map the architecture activities on the deliverables in order to make the link between the activities and the multi-business deliverables,
- Practice active listening via the regular organization (frequency to be adapted to the context) of multi-business meetings to discuss architectures. Architecture deliverables can be used as support for discussion and meeting minutes. This can also be done informally,
- If the word function is used, it must be associated with the adjective “internal” or “external” in order to clearly specify what we are talking about,
- Dysfunctional variants of use cases must be analyzed.
We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:
“ We have set up a set of system reviews which specify the levels of maturity of the architectures expected at the milestones and articulate the work between system and subsystems. The architect also participates in subsystem reviews (which must take into account system requirements).
“ We have established work rituals of 2 or 3 hours per week to distribute the architectural work between the strata and facilitate multi-business convergence.
“ The software teams initially felt disturbed and worried by the implementation of a functional architecture. We included them earlier in the definition of “white box” functions so that they feel more comfortable and less in danger.
Your comments will be considered by the members of the Cercle at the next monthly meeting.