Understanding Organization Decomposition Diagrams and Role Mapping in Enterprise Architecture
The article explains how organization decomposition diagrams illustrate the links between participants, roles, and locations, define responsibilities, show information flows, and map goals to stakeholders using UML/BPMN and Archimate models, providing a comprehensive view of enterprise structure and governance.
Organization decomposition diagrams describe the connections among participants, roles, and locations within an organizational hierarchy, presenting the command chain of owners and decision‑makers and allowing goals to be intuitively linked to stakeholders.
These diagrams also define participant responsibilities and illustrate how participants relate to each other or to organizational units, revealing hierarchical relationships, communication paths, and accountability.
By visualising the main information flows between key participants, the diagrams highlight tasks and responsibilities, showing who receives, processes, or sends specific information and thereby clarifying element responsibilities.
They are further used to define the various roles that participants assume.
Location, Role and Participant
An example shows a headquarters in Paris with branch offices in Nantes, Toulouse, and Lyon; organizational units are assigned to these locations, most services reside in Paris, the IT department is in Toulouse, and each branch has a sales department. Geographic location of a role is usually implied through responsibility links.
UML/BPMN EAP Profile
Internal actor: an actor belonging to the enterprise.
Headquarters location: the deployment location of enterprise elements (organizational units, hardware, participants, etc.) defined geographically.
Site location: similar to headquarters but for branch sites.
Organizational unit: a unit that decomposes the enterprise, e.g., a department.
Localization link: a link that localises an enterprise element to a specific location.
Archimate
Definition of Roles and Responsibilities
The diagram shows roles and their responsibilities, providing a clear view of enterprise functions and stakeholder interactions.
Actors can represent individuals or groups (e.g., a board), each with specific duties and decision‑making authority.
External participants illustrate how they relate to the organization.
Responsibility links describing hierarchical responsibilities.
Communication links indicating who communicates with whom.
Composition links showing composite actors.
Internal and external actors.
Major Information Flows Within the Enterprise
Figure 3 depicts primary information flows exchanged between actors and/or organizational units, focusing on flows from external participants to internal units.
Elements used include actors, business units, and information flows (e.g., tickets, orders).
Roles Assumed by Participants
Figure 4 illustrates how participants assume roles to perform tasks, modeling the expected function of each actor.
Elements involved: actors, roles, and assumed dependency relationships.
Internal actor: an actor belonging to the enterprise.
External actor: an actor outside the enterprise.
Internal role: role played by an internal participant.
External role: role played by an external participant.
Detailed Role Model for a Sales Director
Figure 5 provides a detailed hierarchical model focusing on a single participant, showing goals, responsibilities, business processes, location, assumed roles, used application components, interactions with other participants, and access rights.
Goal: a business objective.
Internal actor.
Headquarters location.
Organizational unit (e.g., department).
Business macro‑process.
Composition link: role composed of other roles.
Responsibility link: hierarchical responsibility between roles/participants and organizational units.
Owner link.
Assignment link: assigns goals to elements such as participants or processes.
Localization link.
These models, combined with UML/BPMN and Archimate representations, provide a comprehensive framework for mapping organizational structure, responsibilities, and information flows.
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.