Modelling processes in ArchiMate

ArchiMate is not a process modelling language. It has only limited support for process modelling. That is why I personally prefer to combine BPMN with ArchiMate, but that is not trivial (as explained here and here). In the book there is a proposed way to link these and my configuration for one of the tools supports that synchronisation. But, if you forego the richness and niceties of a real process modelling language, you might do something that is close enough for most organisations, even if it is technically not 100% valid ArchiMate.

My esteemed colleague Jos Knoops has set this up. The problem he ran into with the original synchronisation was that it was impossible (in the tool we use) to create an integrated published architecture. Switching from ArchiMate views to BPMN views was not possible. So, given that his business users have no real use for all the richness and niceties of BPMN (they just want swim lanes, risk/controls, RACI, etc.) he decided that he could serve their needs fully in ArchiMate, thus enabling a simple but good enough way for process documentation and an integrated publication.

To see what kind of information the business users like, it is something like this (the example is The Flower Shop from one of my open letters to TOG about improving the standard):

Complete Florist Process.jpeg

If we would like to do something like this in ArchiMate, how would that look? Well, to make matters more interesting, let’s include a process where one step is done automated, in other words: by a system.

Suppose we have a data entry process. A clerk enters data in a program, if the data leads to some sort of serious exception, the clerk is signalled, e.g. via the user interface. The process description says he must then inform his Boss. In the meantime, the program calculates some sort of values and sends this result to the Boss who checks the warning.

I have modelled this in ArchiMate as follows (basing myself on Jos’ choices) and in the Mastering ArchiMate colouring scheme:EntryProcess.jpeg

For those acquainted with processes modelled in swim lanes, this is directly understood. We see a process, in which we see three ‘lanes’, for which I have used (as customary in swim lane modelling, but certainly not by definition) the performers of the activities.

You might think this is not ArchiMate. You would be right, but not by definition for the reason you think.

  • If you think the Start and End elements are not ArchiMate, you are mistaken. These are Business Events. I have just given them a different appearance so they look like elements from BPMN. ArchiMate officially does not tell you how the elements should look, even if it comes with a ‘standard notation’.
  • If you think the Business Activity elements are not ArchiMate, you are only partly right. They were part of pre-TOG ArchiMate and dropped when TOG published ArchiMate 1.0, but they have been in the standard since, as examples of how you can extend the standard. Slightly problematic examples, but I won’t get into that here and now. See Section 9.2 of the standard.
  • If you think the ‘gateways’ are not ArchiMate, you are not right in a combination of both of the previous points, because these are ArchiMate Junctions. I have used the extension of Junctions into an Or-Junction and an And-Junction and given these the look of BPMN’s gateways.

Without replacing the Business Activities with Business Processes, in slightly more ordinary ArchiMate visualisation, this would look like this:EntryProcess-ArchiMateLikeView.jpeg

Note that using Junctions is currently a trick to send Triggers and Flows between the different layers (business, application, infrastructure) in ArchiMate, something you normally cannot do. You cannot model a Flow from Business Process to Application Function, but you can model a Flow from Business Process to Junction and then from Junction to Application Function. It’s one of those funny weird spots in ArchiMate. ArchiMate is far from a perfect lingo, but it is practical. Just as we humans tend to be far from perfect but more of the ‘practical’ persuasion. I feel a philosophy reference coming up, but lets not do that this time. People might get bored.

Anyway, as I said, I like BPMN and having it synchronised with ArchiMate in the way I described in the book. But tool support is far from perfect and this is a lot simpler and we stay within a single modelling language.

Which leaves us with the question: “What then, in the first ArchiMate view above, the one that shows the lanes so nicely, is not valid ArchiMate? Agreed, it is a small issue. Let’s turn that into a “What’s wrong with this picture” question. For previous ArchiMate puzzles, see here, here and here.

12 comments

  1. This is not a good way to model ! Take the following steps:

    Step 1: Define your Actors and Roles in ARCHIMATE

    Step 2: Define your Pools and Lanes in BPMN without description

    Step 3: Select each Pool and Lane and do a ‘ Instance Classifier (the way in EA12)) and then select from the ARCHIMATE Actors and Roles the correct one. You will see that the name of the Actor / Role appears on the Pool . Lane. The same for Applications, please Model applications in BPMN as a Black Box.

    Sinc.
    Christian Gijsels

    Like

    1. I think, Christian, that your reply is tool-specific (Sparx?). Sparx has its own interpretation of things, I have been told, and not always 100% ArchiMate compliant. I don’t know the tool myself so I can’t comment.

      But as your instructions may work for Sparx, but they won’t for Archi, BiZZdesign Architect or any of the other tools around.

      Like

      1. This is indeed true, that is why I wrote (the way in EA12).
        This way-of-warking allows you also to redefine Role in UML from ARCHIMATE, trully amazing feature in EA12. But I am sure that every tool has his own way.
        But to use ARCHIMATE symbols in BPMN is not a good practice.
        With this way-of-working you can create End-to-End models where Names or Roles / Applications / Data can get the Notation specific look, but with a unique name, only defined once and because we work Top-Down, you can best use the ARCHIMATE symbols for the unique name definition.

        Sinc.
        Christian Gijsels

        Like

    2. Christian, I think you missed the point here. The goal was to model in pure ArchiMate in a way that makes it similar to BPMN. This is something that I had to do several times when trying to model things that had to be read and understood by people used to BPMN.

      Re Sparx, I don’t want to start a (big) discussion on tools, but I’m using a rather old version (8) and I find ArchiMate implementation not really useable (no metamodel enforced, so any relation can be used with any couple of elements). I hope this has been fixed on newer versions.

      Regards,

      JB

      Like

      1. Sorry JB, I’m using pretty much the most recent version and although they’ve fixed some things from the version you’re using, it still doesn’t deal with many things correctly (including the metamodel issues). There are extensions you can get these days that I think might do a better job, but I think it’s a fundamental flaw in Sparx that it doesn’t enforce metamodel rules at all really.

        Michael

        Like

  2. Hi Gerben,

    I believe the the main issue lies with the “swim lanes” and what the elements placed there imply. Archimate only allows elements that are aggregated, composed or assigned to be displayed the way that view shows them. That would mean that ‘warning by clerk’ is related to the Boss element by one of these three relationships which it cannot be because the ‘warning to clerk’ element is a business object which can only be connected via an access relationship.

    The same logic applies to the junctions and (I think) the encompassing process.

    I like the diagram though and it proves the point I think that some times the rules need to be stretched to communicate what you need to communicate.

    Michael

    Like

    1. Well spotted, Michael. And indeed the encompassing process too, because one could nest an Assignment from Role to Process, but not the other way around.

      Strictly adhering to syntax doesn’t always lead to ‘common sense semantics’ and the same is apparently true for ‘common sense visualisation’.

      Like

  3. I don’t pretend to be an Archi expert but I do prefer it as a modelling tool – I’ve been a little frustrated with the lack of direct cross functional flowchart support and caught this article.

    Really interesting approach in changing the representation of an entity on one specific archimate view to suit the view itself. I couldn’t figure out a way to do that in the tool…Am am missing something simple?

    Are you suggesting that in terms of lanes these could be mapped to business roles or actors (events, processes, objects representing the activities) but then jumping between architectures perhaps also application services as lanes with business events & processes as the activities in the lanes?

    Like

    1. The view has been done in BiZZdesign Architect in a special profile I created. You cannot set such per-view, though I suspect that I could make a Viewpoint that is like Total View that does this change. Hmm, interesting idea. Currently, it is a system wide setting.

      I would show Business Roles, Business Actors or Application Components as Lanes. This is in line with the ArchiMate-BPMN mapping I developed in the book. The relation between ArchiMate services and BPMN is difficult and I would in this case just model Business Services as being Realised by the overall Business Process.

      Like

  4. I believe that the usage of the Application Function to modelize the Calculation activity is not optimal. Indeed, in the ArchiMate Specification (section 6.1), they use a Business Process assigned to the Application Component to modelize that the Business Process is automated.

    Like

    1. You are quite right that it is Application Component Assigned-To Business Process in ArchiMate. This is all not perfect ArchiMate (e.g. the nesting) but this aspect is there: The Application Component is modelled as a Lane and as such represents a performer of the process (though nested in the wrong way).

      The whole ArchiMate-BPMN mapping story is part of the book. Note that to make a flow diagram of sorts, you need placeholders for the activities/tasks in the process. The Application Component may perform several of these and using it to represent all is problematic in many ways.

      Like

Leave a comment