ArchiMate is fantastic and connecting different layers of architecture together, and BPMN is fantastic at modelling process – This article demonstrates my approach to marrying the two languages.
Playing To The Strengths
As I mentioned in my article Architecture Languages, Standards, And Frameworks, BPMN strengths lay in creating process detail – and whilst it’s possible to create processes equally as detailed in ArchiMate, generally speaking those processes tend to require more views, and do not look nearly as tidy without a significant amount of effort.
A question I am often asked is which modelling language should be used, and to what level of detail? Both Languages have pros and cons.
For that reason I tend to model the process and its connection to the rest of the architecture in ArchiMate and leave the details in the BPMN model.
The order you do this very much depends on the level of understanding you have of the process. Some people prefer to do the detailed process and then fit it into the context of the organisation and others prefer to do the general overview and then detail out the process later. As part of my standard approach to creating high level designs I normally create the ArchiMate process overview before the BPMN one.
The ArchiMate Process Overview
In ArchiMate, my overview generally looks something like this:
I start with the actual process in the middle. I have found many architects can have a challenging time fully defining a process; its easier to understand what you need from a process and what your expected inputs and outputs to process are, and who needs to be involved, than it is to understand all the minutiae. So the key elements here:
- Business Process – I normally start with one process – with a name suffixed with the word “process”, because its just easier that way to be clear when talking in conversation to other people.
- Business Actor / Role – I prefer to use roles rather than actors, because it helps with abstraction and re-usability of the process; it’s important to understand the differentiation – actors are assigned to performing roles. Sometimes I might use both or a mixture of two if i have good reason.
- Business Events – In the ArchiMate specification it says that events denote state change in an organisation – The way I am using events here is to denote the events that cause the process to start running, and the outputs of the process The direction of the trigger relationships tell us which are which.
In the view above (fig. 1) we can see that our process serves the “My Software Service” – its good to put a process into the context of either a service or a function within the overview. Of course I can just take one or several elements from such a view and include them in other views as needed:
In figure 2, you can see a support process as part of a layered view; in this case we are connecting a process also into the application layer, you can see how if we had a process overview of Support Process our understanding if it work be better. We may have included some elements that would appear on a process overview; but not probably not all of them – this is a judgement call – when creating a view, I am telling a story, and I use whichever elements are relevant to that story. Of course the story of a process overview, is “this is the process from end to end, and this is how it all works”. Its views like the one above where we are able to use the process in the context of other architecture in a repository – that make modelling the process in ArchiMate worthwhile.
Creating a BPMN model
Going to the next level of detail, if we did a BPMN view for Figure 1, we may have created a process that could end up looking like this:
A couple of key things to note
- The swim lanes in figure 3, match the roles in Figure 1; of course, if figure 1 had actors, they would be here too; I need to understand easily how the detailed process in BPMN connects not only into the process overview in ArchiMate, but the rest of the model.
- Its really important to give the process in ArchiMate the same name as the process in BPMN so later its easy to search and find it.
- We match up the events with same names in BPMN as ArchiMate, It makes sense. I think of them a little like being interfaces into the process.
- I deliberately didn’t make the BPMN more complex – Its one of those languages that you can get started with easy, and there’s a few things you can do with gateways, and events, and a lot more possibilities than I show on my example. As I have probably said, I am a great believer in keeping it simple – and the 80-20 rule – you can get 80% of the work done in 20% of the time. Of course encourage architects to learn the standards properly and fully utilize them, but the elements i use in figure 3 cover most of my needs – and I would rather not have architects engaged in hour long discussions over what kind of gateway to use, when it is evident from just leaving the gateway empty and seeing it in the context of the view. I have found in the past, after getting comfortable with the basics, most good architects like to explore these modelling languages and will start to figure these things out themselves.
Why Am I Calling It A Process Overview?
So the elements shown in Figure 1 – could be considered to make up a standard process view like is showing in the ArchiMate 3 manual. I consider the process overview to be a specialization of that – because I am asking for specific elements, in a specific configuration – I tend not to want to clutter the view. I also do not limit this kind of model to the business layer – I could just as easily apply exactly the same concept in the application layer, an application process would be triggered by application events, and may serve application functions – Actors & roles would be replaced by other active elements in the application layer – typically the application component.
How Do You Practically Do This With Tools?
Typically I am using BiZZdesign’s Enterprise Studio (BES), which makes it easy, because the model allow me to create models in either ArchiMate or BPMN. I normally connect those view via hyperlinks – both on navigation pages, and in documentation. Enterprise studio also supports cross model relations – so I can link the navigation of one object directly to another and state the type of relationship; so for example, I could create a relationship on my Software Acquisition Process in ArchiMate to show it is refined in my BPMN model; a number of cross model relationship types exist. I could also tweak the meta-model to give me better options, but I haven’t done that.
Enterprise studio has some new compliance functionality – I did a quick video on it (with some notes in another blog) –
If I was using Archi & Visio, I would create a custom property on the element in the Archi Model and link it to the Visio file in a shared space. All of the modelling tools out there support hyperlinking in one way or another. Another option would be to link from the actual views rather than the specific process elements – but I don’t do that.
Summing It Up…
Of course we don’t actually need to do produce both BPMN and Archimate in all cases, but I do like to leverage the benefits of both together.
The approach I have presented today has a few advantages:
- The ArchiMate view is quick and easy to get started with when you don’t have all your process detail.
- BPMN is easy for process developers and other people to develop the detail in parallel. This is important if you work in an organization where process is developed separately from architecture.
- Following some of the rules I presented will make it really easy to understand ArchiMate in the context of the more detailed view – because the inputs and outputs align.
- Having naming aligned, and hyperlinks in place helps you find things – the alternative to this is to have disconnected processes.
I personally believe that not aligning your BPMN models with your ArchiMate ones, is effectively disconnecting process from architecture. But of course, Let me know what you think.