3.2 The key Deliverables of Environment Architecture

3.2 The key Deliverables of Environment Architecture

For any system S, environment architecture has two core deliverables:

1. the stakeholder hierarchy diagram that hierarchizes all stakeholders associated with S – or equivalently external systems – according to an abstraction hierarchy (see below),
2. the environment diagram that describes the exchanges existing between S and its first level stakeholders – or equivalently external systems – with respect to the above hierarchy.

These two deliverables are presented more in details below.

3.2.1 Stakeholder Hierarchy Diagram

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 person¹This 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 350²7 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.

3.2.2 Environment Diagram

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:

• the system S and all the high level stakeholders – or equivalently external systems to S – in the meaning of the stakeholder hierarchy introduced in the previous paragraph,
• all flows exchanged between the system and its stakeholders, that is to say between S and the external systems of its reference environment.

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:

• in the left hand-side of the diagram: key input systems of S,
• in the right-hand side of the diagram: key output systems of S,
• in the top of the diagram: key constraining systems with respect to S,
• in the bottom of the diagram: key resource systems with respect to S.

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!

TABLE OF CONTENTS