{"id":25891,"date":"2021-07-07T16:24:17","date_gmt":"2021-07-07T14:24:17","guid":{"rendered":"https:\/\/cesam.community\/2021\/07\/07\/3-2-the-key-deliverables-of-environment-architecture\/"},"modified":"2022-11-15T12:24:15","modified_gmt":"2022-11-15T11:24:15","slug":"3-2-the-key-deliverables-of-environment-architecture","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/07\/07\/3-2-the-key-deliverables-of-environment-architecture\/","title":{"rendered":"3.2 The key Deliverables of Environment Architecture"},"content":{"rendered":"

3.2 The key Deliverables of Environment Architecture<\/h2>

For any system S, environment architecture has two core deliverables:<\/p>\n

    \n
  1. the stakeholder hierarchy diagram<\/em> that hierarchizes all stakeholders associated with S \u2013 or equivalently external systems \u2013 according to an abstraction hierarchy (see below),<\/li>\n
  2. the environment diagram<\/em> that describes the exchanges existing between S and its first level stakeholders \u2013 or equivalently external systems \u2013 with respect to the above hierarchy.<\/li>\n<\/ol>\n

    These two deliverables are presented more in details below.<\/p>\n<\/div>

    3.2.1 Stakeholder Hierarchy Diagram<\/h3>

    Let S be a system and let Env(S) be its reference environment (see section 2.1).<\/p>\n

    The stakeholder hierarchy diagram<\/em> of S is then a hierarchical exhaustive representation of all stakeholders \u2013 or equivalently all external systems to S \u2013 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 \u2013 in the above meaning \u2013 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.
    \nFigure 40 below also provides an illustrative partial example of stakeholder hierarchy diagram for an electronic toothbrush, a stakeholder or equivalently an external system being \u2013 classically \u2013 represented here by a graphic depicting a person1<\/a><\/sup>This is just a representation which may typically model any hardware, software or \u201chumanware\u201d system as soon as they are part of the reference environment of the considered system.<\/span>, when the inclusion or abstraction relationships on which this hierarchy relies are \u2013 also quite classically \u2013 represented by arrows.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25482″ img_size=\u00a0\u00bb450×249″ alignment=\u00a0\u00bbcenter\u00a0\u00bb]

    Figure 40 \u2013 Example of a stakeholder hierarchy diagram for an electronic toothbrush <\/span><\/strong><\/p>\n<\/div>

    When dealing with the stakeholder hierarchy diagram, the main standard difficulty is to find the \u201cgood\u201d 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 3502<\/a><\/sup>7 multiplied by 7, multiplied again by 7 makes 343<\/span> 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 \u201cgood\u201d 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.<\/p>\n<\/div>

    3.2.2 Environment Diagram<\/h3>

    Let again S be a system and Env(S) be its reference environment (see section 2.1). The environment diagram<\/em> of S is then a representation of:<\/p>\n