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.
R&A IT Strategy & Architecture 
Very interesting article, thank you for sharing this with us. I do have some doubts on how you tackle the second problem, automating business behavior. Almost a year ago I wrote an article discussing this topic. You can find it at this location: http://blog.bavoderidder.com/?p=270
I would be very interested in your opinion on this article and the comments made by some people.
LikeLike
Thank you for your comment.
The way I tackle the second problem is of course not valid ArchiMate as ArchiMate is now. What I wrote under #2 is currently not the way it can be done in ArchiMate (so doubt is very much deserved), but an alternative I would suggest for a future ArchiMate 3.0 discussion. As you have read, I agree with you that the ‘circularity’ of the current way to model automated business processes in ArchiMate is not very pleasing. Hence my alternative.
(Answering here as I had trouble logging in to comment at your blog)
Having read your post, if I am doing this within ArchiMate 1.0, I would probably be closest to Bill’s view (in terms of objects versus class and having multiple services). And if I want to group different implementations of the ‘same’ service I would probably use aggregation as the abstraction du jour. Your view “I tend to define services based on the “need” of the consumer and use interfaces to model how the consumer interacts with the actual realization to serve the consumer’s “need”.” takes business services as something that is a ‘resource’ for the consumer. That is of course as valid a way to look at it as many others, but I would still keep the separation in tact, because such grouping creates dependencies that are not really there in your reality: your model has a dependency (derived relation) between the simple web application and the phone business interface. If you model it with an aggregation of two services as Bill suggests, you do not have the possibility of the derived relation from simple web app to phone business interface as you cannot travel the aggregation/composition in that direction.
I would suggest adding the app function and app service (that have to exist as you have an app component) into your view #4 and then ask yourself: what process uses that app service that is provided by your simple web app? And try to draw the consumer’s business process. What is he using? The business service or the application service of the simple web app?
Finally, I prefer not to make customers users of my systems. If the customers triggers a bug in the simple web app, which business actor is to blame/responsible? The customer? I think not. Thinking about my app as a robot that represents me (bugs and all) makes it clear that the actor to blame for the problem is part of my organization and not of the customer’s. I need an actor in my architecture. That is why I would prefer the option to let your simple web app realize a ‘robotic actor’. Imagine one step further in a few years: your simple app in a robot body at the entrance of your company. The customer talks to your robot. Is he using your app or is he interacting with an ‘employee’? Why do people get so irritated by ‘phone menu’ applications? Because they do not see themselves as using an app, but as interacting with you at business level. And that interaction often stinks.
Personally, I also have a ‘rule of thumb’ to have only one ‘realizer’ for a service. A process can realize multiple services, but when you model one service being realized by multiple processes, you are modeling something that cannot be the case in reality. The same is true at the app level, where an app function can realize multiple app services, but a single service must be realized by a single app function. You can do it with ‘combination services’ assigned to ‘application interaction’, but most of the time I prefer the less abstract approach.
Triggered by your example: I am wondering if it would be possible to have ‘phone’ as infrastructure service in your model and ‘conversation’ as business interface. That would probably require a direct link between infrastructure and business layer without anything in between and I think that is something one cannot do in ArchiMate 1.0 as we need something at the app level and what is that in that case?
LikeLike