Representing organizational structures, roles, responsibilities, and linking this model with the process model, could be a mess, especially if your Architecture model should integrate perspectives modeled according to different standards.
I expose here some ideas that we are putting in practice across our Enterprise Architecture projects, in my current Company.
The topic of model mapping is hot: you can find a lot of interesting toughts in the blogs of Gerben Weirda. At the same time, the OMG is working on a UML profile for Archimate.
I will start with Archimate, and the basic elements from the Business Layer: Actor and Role.
The following picture, shows a suggested extension:
The Role is specialized, leading to four different stereotypes:
- Organizational role: a role that is specific of an organizational unit, eg. Director (role) of IT (unit).
- Functional role: a role that is specific of a function or authority assigned to a person, eg. Sales Representative.
- Process role: a role that has a meaning in the context of one or more processes, eg. “Purchasing requester”, “credit approver”
- Partner role: a role of an external partner in a collaboration, eg. Customer, Bank, Tax agency.
At the same time, the Actor element is specialized:
- Organization unit: an element of the organization which may be aggregated at an higher level, or may aggregate lower level units. The dependency may follow several patterns: hierarchical, matrix.
- Human Business Actor: a single, identified person.
- External partner: a person or organization external from our business.
The diagram shows the main relationships among elements. The “Process role” may be assigned to a human actor, another functional or organizational role. Anyhow, it is meaningful only n he context of execution of a single instance of one or more processes,
Why do we need those extensions? Well, mainly for ease of communication with some stakeholders. It is common wisdom that complexity in the metamodel leads to obscure resulting models (for the eyes of non-professional stakeholders). But in this case, I think that a little bit of specialization is useful:
- specialization of user roles helps the overall classification of them, and provide some guidance also for junior analysts and people outside the Architecture practice.
- Specialization of business actors helps avoiding the potential ambiguity deriving from the fact that a branch, an office, a bank, or a receptionist are all modeled with the same element.
In the following posts, I will describe how we have translated this profile in UML, and how we have linked the Business Layer with the relevant elements of BPMN models.