I like ArchiMate, but, being an Enterprise Architect (and thus rather pigheaded), I have my criticisms. In this post, I’ll be discussing what I would call a ‘Problem Area’ of ArchiMate: Business Role.
Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF) for more information.
Problem 1: structure versus behaviour
As I wrote at the end of a previous post, ArchiMate’s definition of Role raises my eyebrows: “A business role is defined as a named specific behavior of a business actor participating in a particular context.”. While the role is the performer of the Business Function and its position in ArchiMate’s scheme of things is structural but its definition is behavioural. And, apparently as a side-effect, the Assigned-To relation gets ‘Fulfilled-By’ next to ‘Performed-By’ in its definition: an actor fulfills a role.
There is an Assigned-To relation from Actor to Role and from Role to Process/Function. But the first Assigned-To means fulfills and the second means performs. They do not really share the same meaning, thus two meanings have been glued together into in a single definition.
There is an alternative. What if we want to be clear that Role is structural? The definition of a Role then could be something along the lines of: “A business role is defined as a structure performing specific behavior in a particular context”. Actor could then become a specialization of Role: “An actor is a human form of a business role”. It looks like this:
This, however is obviously problematic. We know actors fulfill multiple roles in an organization. So, if we use Realization we get multiple inheritance, possible, but not my favourite. It is however also natural to see an actor in an organization as aggregating the multiple roles he/she fulfills:
The end result of this is a clear structural definition of role I would like to see in ArchiMate 3.0 and one that maps GOFBF.
Problem 2: Automated Business Behaviour
There is a second weirdness related to Role. If we model automated business processes in ArchiMate, it looks like this:
The Business Function (or process) uses the application and to model that the application is also the one performing the business function, a kind of short cut Assigned-To relation is drawn between Application Component and Business Function (or process). But we now have a business layer where we do have behaviour, but no role to perform it. That does not seem right. And the application component also sort of uses itself, which also sandpapers my ‘modeling nerves’. Besides, in ArchiMate there are two relation types that can go from layer to layer in a natural way: Realization and Used-By. It would in my opinion be cleaner if Assigned-To would be internal to a layer.
So, what if we want a real Role that performs the Business Function in the case of an automated process? We have to think then how this role comes to be. Combining this problem with the earlier suggestion of Actor as an aggregation of Role, there is the following solution: let the Application Component realize the ‘robotic actor’.
Here we see the Application Component that realizes a ‘Robotic Actor’ which aggregates Role(s). The behaviour of the application realizes the behaviour of the Business Function.
Imagine the following scenario in a company: to save money, we replace the customer telephone assistance (partly) by an automated menu where your customer gets the well known choices as “choose 1 for being disconnected, choose 2 for being put on indefinite hold with muzak, etc.”. What we in fact have done is replace the agent that our customers interact with (our human operator) with a (very dumb) robot. In fact, providing customers with self-service web sites does not make them users of your systems (as is often thought), it can also be seen as making them interact with robots of your creation. As you are responsible for what those robots do, and thus as you can never ‘blame the user’ of doing something wrong here, the robot picture is more realistic than the user picture (and besides, if your customers become actors inside your organization, all kinds of complexities appear in your architecture, think for instance your auditing, access control, authentication, etc.). Automation of customer interaction is rather new, so it is not so strange it was not immediately recognized as robotics.
Here is the final suggestion for ArchiMate’s 3.0 metamodel:
We have removed the double meaning of Assigned-To (and its cause). And we have introduced a Robotic Actor which is realized by an Application Component (and the business behaviour is realized likewise by the Application Function). Only Realization and Used-By now go from layer to layer in the metamodel. And here is how it would look in an actual model with both automated and user-performed business behaviour:
On the left an ‘automated process’, on the right the standard ‘human performed process uses application’ (without the application interface drawn). Both with the structure/behaviour removed from Role.
All of this would lead to the following definitions:
- Business Role: A business role is defined as an structural object performing specific behavior in a particular context;
- Actor: A business actor is defined as an organizational entity capable of (actively) performing business behavior. An actor may aggregate multiple business roles;
- Robotic Actor: A robotic actor is defined as an automaton, realized by an application component, capable of (actively) performing business behavior;
Problem 3: Roles assigned to processes
There is a third problem related to Role. Try to imagine a concrete (singleton, not a collaboration) role in your organization that is not assigned to a business function at all (or old-style: part of a GOFBF). There is no such thing, is there? Every singleton role that happens in your organization should be assigned to (part of) a business function. A role is in fact a kind of basic ‘behavioural resource’ of your organization and as such almost by (ArchiMate) definition something assigned to a Business (sub)Function. Through that assignment to a Business Function it is assigned to the internal process of that function. See a previous post.
We we therefore might wonder why in ArchiMate you can assign Roles other than collaborations (of roles assigned to functions) to Business Processes at all. After all, can you have real roles in an organization that are not assigned to a business function? Is your picture of the company complete if you have such roles?
So, I can choose not to directly connect singleton Business Roles to my Business Processes, only Collaborations (which aggregate the singleton Business Roles that perform the Business Functions that are used by the Business Processes). This can be done within standard ArchiMate:
Note, I am not writing about the internal processes of a business function (not shown here), but of the processes of your organization that realize products and services.