ArchiMate, BPMN and UML together

The question about “the remaining role of UML now that ArchiMate has arrived” generated an interesting discussion on ArchiMate LinkedIn group. Adrian Champbell‘s first comment was:

Archimate was deliberately designed to be mappable to BPMN and UML, but not to replace them. Not parallel universes but complementary ones.

Archimate is for modelling at an Enterprise Architecture level of detail and not at the Solution Architecture and Software development level of detail. BPMN and UML have much more detail in them than ArchiMate.
Conversely neither BPMN or UML can replace ArchiMate either.

I agree with Adrian. Actually, I find the idea of an EA notation set comprising ArchiMate, BPMN and UML quite appealing. They are complimentary, although having some representation types that could be redundant in a unified method.  I use here ‘representation type’ to avoid ‘model’, which means different things in UML and ArchiMate. There are other fundamental differences, but we don’t have to deal with all of them. The three notations can co-exist quite well as they are. Especially when supported by a repository-based tool with separated content and presentation space. It seems that what is needed in a wide variety of use cases is already there, or if not, an extension could take care of it. The rationale behind such a combination of ArchiMate, BPMN and UML  is to have a relatively small number of notations that could satisfy most stakeholders and comply with some common modelling rules. Finding a good way to integrate these three languages could bring a lot of benefits. Coming to one universal notation turned out to be a difficult task, maintaining a dozen is neither efficient nor effective and then having several kept separated, used per project, could bring little benefit for the enterprise in the long run. Then how about these three only, and well integrated?

There are two basic questions. How to make them play together? How to add what is missing?

To make them play together

we need some mechanisms and some rules. We need mechanisms for transclusion, elaboration/navigation and transformation. We also need rules to avoid redundancies and ambiguities.

Transclusion or a similar mechanism is needed to manage separated content and presentation space. This should enable some unit of behaviour, for example, maintained in the content space, to participate as a task in a BPMN diagram, as a process in ArchiMate view and as an activity in UML Activity Diagram.

An elaboration/navigation mechanism is needed to link, for example, a process in ArchiMate with its BPMN elaboration and data object with its elaboration as UML Class Diagram.

Transformations could be handy in cases where we need to generate a UML Sequence Diagram from BPMN Collaboration Diagram. Such a demand may arise when at some point, we need special message capabilities like create and destroy and/or we need to see when objects are active and when passive which would be a bit of a challenge for a pool to show.

Modelling rules, along with method restrictions, should be used to avoid redundancies and ambiguities. The diagram below shows some overlapping areas. It should be clear, for example (area 1), when a process should be represented as ArchiMate process view, when as a BPMN process diagram or UML Activity Diagram, if ever. It seems natural to expect ArchiMate process view to be used for more conceptual representation and then each process to be elaborated as BPMN process or collaboration Diagram (Area 2). A similar convention could be applied to data structures in area (3). In many cases, UML Class Diagrams are used without specifying attributes and methods. Probably in those, an ArchiMate data view should be more appropriate as then the same data objects could easily be reused in coherence views to show relations with a service for example.

The main idea behind BPMN is to bring processes easily to process engines for execution. As smooth as possible. How the recently released BPMN2 is another question. I’m not going to discuss it here. Just want to draw your attention to area (5). There are some cases where it would make sense to elaborate a Service Task from a BPMN diagram to a UML (component) diagram.

To add what is missing

we need some extensions. I mentioned a few things missing in a whole-of-enterprise EA in my previous post. Most of those should clearly extend ArchiMate, assuming we confine to this trilingual framework. What I see as the most ‘urgent’ need is for a motivation extension. So far, there is one good attempt to satisfy it. Still, a lot to improve, but the first step is made.

Another extension could meet the demand for a loose sticky-notes type of modelling. This proved to have a lot of benefits, bringing people together and stimulating creativity and innovation being just a few of them. There are already some good methods for that as the Business Model Canvas. It would be even better to have the freedom for brainstorming and collaboration and then some way to transform ideas into a more rigorous model. I find the whiteboard in ARIS Align a very good example. There, in a collaboration (social media like) environment,  sticky-notes from the whiteboard could be dragged and dropped as tasks in a method-restricted area for business process modelling. How about a similar thing with business models done using business model canvas? Just drag the sticky-note and place it in ArchiMate ‘area’ to create an object. A sticky-note from Value Proposition building block would probably be transformed into Business Service or Product in ArchiMate. Well, as it so often happens, a notations talk easily slips into a tools-and-features talk. Not good, but now that we are here, let’s mention another feature. A toolset supporting integrated use of these three notations should always have a way to support an author-specified notation. Alternatively, some abstract diagrams, like context-space maps or the one above, should be done outside.

In an environment not allowing a fourth notation, an extension of ArchiMate might be needed to model Value Stream Maps and other lean and Six Sigma diagrams. Such an idea probably sounds heretical to most of the practitioners of these methods. I find it rather nice.

BPMN and UML (especially) have good extension mechanisms. Currently, I see more need for reduction than extension there.


We represent aspects of (or decisions about) reality to help us improve it. The bottom box in the diagram is labelled ‘realization’. I didn’t want to call it execution or automation. Our subsequent decisions could be realised with or without IT. That brings us to the fourth arrow on the right side. Some decisions represented in ArchiMate could be realised as changes in enterprise reality with no use of IT. Others can make use of IT or affect IT but without any need to go through BPMN or UML.

These were just a few thoughts on the idea of EA notation set comprising ArchiMate, BPMN and UML. Only user experience could show if and how that works. There are companies using ArchiMate and UML together, the latter to support Solution Architecture modelling. Others use BPMN and UML. Maybe there are some that have already experienced or probably standardised on the three.

4 thoughts on “ArchiMate, BPMN and UML together

  1. “Another extension could meet the demand for a loose sticky-notes type of modelling…There, in a collaboration (social media like) environment, sticky-notes from the whiteboard could be dragged and dropped as tasks in a method-restricted area for business process modelling. How about a similar thing with business models done using business model canvas? Just drag the sticky-note and place it in ArchiMate ‘area’ to create an object. A sticky-note from Value Proposition building block would probably be transformed to Business Service or Product in ArchiMate.”

    Yes, I’m working on this in Archi. Next stage is to work on transforming the stickies to ArchiMate entities. I like your idea!


  2. I’ve been thinking about something along these lines for a while.

    I think it can be realised if you build in on top of a repository that is built around object and relation identifiers to which arbitrary attributes can be added. Yes, a triple store is what I have in mind, but is doesn’t need to be one of those. In the repository, any entity and relation can have attributes – such as classifications – from all three modeling languages, just one language, or maybe even none at all (as in the sketch view). Each of those modelling language is in effect an ontology, which already supplies some of the rules, and more could be added to regulate the meaning and behaviour of an entity that has a status in more than one language.

    You’d have to be very careful to not overconstrain such a thing though. It’s probably best to try to get the UI to enforce only loose couplings between the languages.

  3. @Phil
    Archi is a very good tool. I’m looking forward to see this feature released. And talking about ‘brainstormin’ and DnD-features, when I use Xmind I sometimes wish I could drag and drop to Archi. May be that looks possible because of the similar Eclipse interface :)

    Now as we have BPMN meta-model released, we have all three meta-models and that would make such a task much easier.

    How do you imagine loose coupling between the languages?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.