ArchiMate is an open standard for modeling Enterprise Architecture. It can be used in many ways. One of these is a good Current State Architecture description: your current landscape of business and IT, coherently modeled with enough detail to be usable for analysis. At the business layer however, there is generally need for more precise and detailed description of what is going on than what ArchiMate can offer. Here, we enter the domain of Business Process Modeling.
(If you come to this page from the BPMN world and you are not acquainted with ArchiMate, I suggest reading the book Mastering ArchiMate).
Warning: thinking in progress.
When you want to model your business processes, there is only really one open standard with reasonable tool support to go for: BPMN (Business Process Modeling Notation, or Business Process Model and Notation the BPMN home page gives both expansions), currently at version 2.
But BPMN, even if it is the only standard around which has reasonable tool support, is not automatically perfect for documenting your existing processes. Here is what BPMN Top Expert Bruce Silver wrote about BPMN recently:
The spec heavily overweights (probably by 10:1) executable BPMN over its much more common use, non-executable
Having studied the standard, I must agree. So we are stuck with a standard that is very detailed and technical (500 pages with class diagrams, XML schema and all), based on a detailed underlying formal class model for all its elements (true to the software engineering background of its parent organization, the Object Management Group, also the father of the widely used UML standard for software engineering) and above all focused on processes that are executable by work flow engines. The support from technology vendors like IBM, Tibco and Oracle will have something to do with that. Still, it still does show its ‘work flow charts’ heritage and is usable for human process modeling as well.
Given that UML is a widely used standard and BPMN is the only real alternative in town for process modeling, it is not so strange that The Open Group, owner of ArchiMate, has decided to start to look into linking ArchiMate to Business Models in BPMN on the one hand and to IT-models in UML on the other hand. ArchiMate, of course, does not have a strong engineering background, like UML and BPMN and is more a language designed pragmatically and not so much formally. So, interesting times ahead:
(Not quite what is happening, because TOG’s ArchiMate Forum has decided to link up with OMG’s UML and BPMN standards, but both are competing standards organizations. Thanks to Mark Douwe Wierda for providing the materials for this image.)
Anyway, here are some important differences I can initially see if you want to set up a link that can be maintained largely automatically (this is a must, otherwise it is not maintainable) and where the details of ArchiMate Business Processes can be found in BPMN models:
- ArchiMate has the (pragmatic) derived relations that enable you to create shortcuts and summary views and it has abstract/high-level use of its concepts, whereas the UML and BPMN worlds are rather like software engineering: strict and detailed. Example: BPMN is very strict: you can assign a resourceRole to an activity and a resource to a resourceRole. You cannot assign a resource to an activity directly. ArchiMate’s derived relations, on the other hand, allow for instance a direct assignment from Business Actor to Business Process, bypassing Business Role.
- Functional decompositions of ArchiMate are difficult to model in BPMN. E.g. BPMN doesn’t know about functional decompositions of the business (even if Pools and Lanes are sometimes used for those, but that is not so much BPMN as well as pragmatic use of the freedoms of BPMN. Actually, BPMN is at least used in an ambiguous way, because on the one hand the Lanes are often used to depict roles (mostly graphically), but separately roles (resourceRole) are also classes that can be assigned to Activities.
- The Service Orientation of ArchiMate is difficult to model in BPMN. Take for instance a Manual Task where the role performing it uses an application to look something up. BPMN’s definition of Manual Task (doesn’t use any application) and User Task (must be scheduled by a scheduling system) doesn’t leave any room for this normal business pattern. If you really model it in BPMN, you need to set up a very fine grained description where the ‘provisioning of information’ is a Service Task performed by an application (in its own Lane or even Pool) and your user’s Activity needs to be broken up in very small steps to make this work. Even if it might be logically correct, there is no way I can explain or sell this nuts-and-bolts extremely detailed engineering-like thinking to the poor business users who have to sign off on the correctness of the descriptions of their own processes.
- BPMN’s Pools and Lanes are troublesome. In the spec it is made clear that Pools are meant for Participants (which are real elements in BPMN). Lanes are just a way to (freely) categorize activities, though they’re normally used for dividing up the performers of the process (actors/roles, systems). But when something is a Participant is not clear. The spec suggests companies, i.e. (legal) parties. But OMG’s own BPMN 2.0 By Example document (Figure 6.4 page 11) then shows a company’s internal process modeled as a BPMN Collaboration between Pools, while it also models it as a single Pool (Figure 6.1 page 8). Those two solutions cannot exist side by side in the same BPMN model, so what is it to be? If you want to link models up, you must choose.
- Furthermore, the idea of Gateways to model sequence flow is of course very nice, but presents us with other problems (especially with complex gateways), which I plan to write about at a later stage.
So, that sets the stage from something I have been looking at for the last couple of weeks. And the goal is to set this link up in a pragmatic and workable way within the next couple of weeks. It will be impossible, I think, to set up a generic link between both languages, especially with all their linguistic freedoms (yes, even BPMN has these). A workable link requires choosing your modeling patterns on both sides with care. (Hence I guess a working group trying to link both at the linguistic level will have a tall order, if it is possible at all.)
The solution needs to be:
- Usable and intuitive from the business user’s perspective. They should not get buried in modeling complexities;
- Not too labor intensive to model by Enterprise Architects and Business Process Modelers alike;
- (Semi-)Automatically linkable to a detailed Current State Architecture ArchiMate model;
- Correct from the spec standpoint of BPMN and ArchiMate (and if not 100%, than as correct as possible).
I’ll keep you posted.