Participate in our next event !
CESAM Community regularly organizes events. Our next event will be the Complex Systems Design & Management (CSD&M) conference in December 2022.
CSD&M Paris 2022
For any system S, environment architecture has two core deliverables:
These two deliverables are presented more in details below.
Let S be a system and let Env(S) be its reference environment (see section 2.1).
The stakeholder hierarchy diagram of S is then a hierarchical exhaustive representation of all stakeholders – or equivalently all external systems to S – that belong to Env(S), a stakeholder H1 being under another stakeholder H2 in this stakeholder hierarchy if and only if H1 is contained in H2 (simply viewed here as sets), meaning that H1 is a special case of H2 or equivalently that H2 is more abstract that H1. The project system is for instance a typical stakeholder, associated with any engineered system that hierarchically abstract – in the above meaning – an engineering team, the supply chain, an industrialization team, a plant and the delivery logistics. The engineering team may then be recursively hierarchically decomposed into a project management team, a systems architecture team, different specialty engineering teams and a verification & validation team. The same type of recursive decomposition applies of course for all other first order stakeholders.
Figure 40 below also provides an illustrative partial example of stakeholder hierarchy diagram for an electronic toothbrush, a stakeholder or equivalently an external system being – classically – represented here by a graphic depicting a person1This is just a representation which may typically model any hardware, software or “humanware” system as soon as they are part of the reference environment of the considered system., when the inclusion or abstraction relationships on which this hierarchy relies are – also quite classically – represented by arrows.
Figure 40 – Example of a stakeholder hierarchy diagram for an electronic toothbrush
When dealing with the stakeholder hierarchy diagram, the main standard difficulty is to find the “good” abstractions. One shall indeed avoid to have too much stakeholders of first level, but also too many levels of abstractions if one wants to be able to efficiently use such a view. The 7x7x7 rule provides a simple trick to use in order to organize optimally this diagram. This ergonomic principle indeed claims that a human being can only holistically understand a maximum number of more or less 35027 multiplied by 7, multiplied again by 7 makes 343 data, as far as they were hierarchically clustered into 7 main groups of data, each of them again decomposed into 7 subgroups, each of them finally containing 7 elementary data. The 7x7x7 principle is therefore a precious tool for organizing a stakeholder hierarchy diagram: the limitations of the human brain indeed oblige to respect it for constructing such a diagram, as soon as one wants to easily read and communicate with these diagrams. As a consequence, a typical “good” stakeholder hierarchy diagram have no more than 7 high level stakeholders, each of them decomposed in around 7 medium level stakeholders, refining finally into 7 low level stakeholders. Note of course that the number 7 shall just be taken as an order of magnitude. Obtaining up to 10-12 high level stakeholders in a stakeholder hierarchy diagram would typically not be a heresy: however one must probably not go further without at least checking whether this number is justified. Finally one shall not hesitate to construct additional stakeholder hierarchy diagrams for refining such an analysis as soon as all relevant stakeholders are not captured.
Let again S be a system and Env(S) be its reference environment (see section 2.1). The environment diagram of S is then a representation of:
Figure 41 that follows gives an example of environment diagram, here associated with an electronical toothbrush, taking here the same representation for stakeholders of Env(S) than in the stakeholder hierarchy diagram, when the system S is modeled by a box.
Figure 41 – Example of an environment diagram for an electronic toothbrush
A classical way of organizing an environment diagram for a given system S consists in respectively positioning the following stakeholders, i.e. external systems, in the four quadrants of the diagram:
These key input, output, constraining and resource systems associated with S within the environment diagram will be respectively denoted below by I(S), O(S), C(S) and R(S). Note that the environment diagram of Figure 41 is for instance typically organized in such a way. This mode of representation is useful since it equips such a diagram with a natural semantics. One may indeed automatically read the mission of the considered system on an environment diagram organized in such a way using the following pattern:
Table 9 – Pattern of mission statement of a system
In a similar way, functional analysis is also naturally oriented by such a representation mode. The core functions of a system S are indeed then the functions that are connecting the input systems I(S) to the output systems O(S), when the piloting and the support functions of S are the functions that are mainly exchanging with respectively the constraining systems C(S) and the resource systems R(S).
The environment diagram is thus a very important diagram which induces structuring architectural orientations for a system. It can also be used for monitoring the first systems architecting activities. A good environment architecture shall indeed fundamentally always be balanced: the number of lower level stakeholders or of needs per high level stakeholder shall typically be more or less the same. Any difference of balance in these numbers shall therefore necessarily puzzle the good systems architect who must question it, even if there is a rational explanation to it. As we can see, the environment diagram is a very rich diagram and a precious tool for the systems architect!