The Actor, from Archimate, to UML, to BPMN – one

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:

Archimate extension roleactor

The Role is specialized, leading to four different stereotypes:

  1. Organizational role: a role that is specific of an organizational unit, eg. Director (role) of IT (unit).
  2. Functional role: a role that is specific of a function or authority assigned to a person, eg. Sales Representative.
  3. Process role: a role that has a meaning in the context of one or more processes, eg. “Purchasing requester”, “credit approver”
  4. 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:

  1. 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.
  2. Human Business Actor: a single, identified person.
  3. 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.

Advertisements

One Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s