A short while ago I wrote about using ArchiMate to model processes instead of the (agreed, vastly superiour) BPMN language. What I did was change the visuals on ArchiMate elements to support this and I also did a few things that are not (strictly) ArchiMate 2.1 compliant. But it is practical if your demands do not require the power of a real process modelling language such as BPMN.
I created those views by creating a special profile for BiZZdesign Architect (which allows for quite some under-the-hood tinkering and messing about). I’ve now created an update to the official Mastering ArchiMate profile for BiZZdesign Architect version 4.7 to support this alongside the standard viewpoints in a single model. Which means you can have views that looks like this:
which is ArchiMate in the Mastering ArchiMate colour scheme. Note that it uses the Business Activity element which is not standard ArchiMate but an extension available in BiZZdesign Architect (a leftover from the pre-TOG days of ArchiMate). But in the same model I can now have the following view (of the same structure):
The above is not strictly legal in ArchiMate 2.1 (mainly because of the Nesting used), but good architects are pragmatists, right? I’ve also added a few trigger relations to the set of allowed relations in my standard profile. The approach (including what is non-standard) is explained in the previous post and in the manual of the Mastering ArchiMate that is part of the tool support package.
Follow this link to get the Mastering ArchiMate tool support package.
PS. I’ll be giving the opening EA keynote for the Enterprise Architecture Conference Europe 2016 on 14 June 2016 in London. I’d love to discuss EA with you. So: meet me there?
R&A IT Strategy & Architecture 
Hi,
Can I play to “What’s wrong” with first picture? I see here that “Data Entry” business process is composed of “Start” and “End” business event, which is not allowed in ArchiMate…
Should I conclude that BIZZdesign Architect is not really compliant with standard?
LikeLike
BiZZdesign does not perfectly implement the standard. But this relation is not that terrible.
Some of the non-standard elements (and relations?) might be considered extensions (which ArchiMate allows), such as the OR-Junction and the AND-Junction. There are also relations in BiZZdesign Architect which I cannot explain at all, such as Application Component Accesses Application Interface.
Might I refer to page 33 of a well-known ArchiMate book? This is part of the Basics section where a few common pitfalls are mentioned.
Pitfall 3: Trusting your tool blindly.
LikeLike
“Some of the non-standard elements (and relations?) might be considered extensions”
I would say not in this case. Business Activity (BA) can easily be seen as a specialization of Business Process (BP) and thus all relationships allowed for BP can also apply to BA. But the language extension mecanism doesn’t permit to add new allowed relationships, it is more the way arround (“Specialized concepts inherit the properties of their “parent” concepts, but additional restrictions with respect to their use may apply. For example, some of the relationships that apply to the “parent” concept need not be allowed for the specialization.” – http://pubs.opengroup.org/architecture/archimate2-doc/chap09.html#_Toc371945251)
So, unless we consider that these are specializations of associations with a graphical notation that “looks like” composition and access, this is just not ArchiMate compliant.
For the fun, I’d be happy to see how this ends up when exported to the ArchiMate Open Exchange format and imported in a strictly compatible tool like, er Archi 😉
LikeLike
That stuff from chapter 9 is inconsistent anyway. Because what is done there is not a specialisation but the reverse. Business Process, Business Function and Business Activity are children of an introduced more abstract entity. The same might happen here if you follow that example. Make Business Event a specialisation of that more abstract entity and bingo! you can have this composition.
LikeLike
On LinkedIn, the following comment was made: “[these] models do not follow the ArchiMate Notation because ArchiMate do not have gateways like BPMN”, and I am replying here to keep the arguments in one place.
First, there is much here that is not perfect ArchiMate (e.g. the Nesting) and it is certainly not perfect BPMN. BPMN Gateways are a lot richer than the ArchiMate Junction. Having said that, the ‘gateways’ modeled here as Junctions is perfect ArchiMate. The actual elements are the AND-Junction and OR-Junction. These are valid extensions to ArchiMate (ArchiMate Standard 2.1 Section 9.2 even shows them as examples). Secondly, ArchiMate is a language that doesn’t prescribe any visual form of relation or element. It is in its foundation a modelling language, not a visualisation language. It is perfect ArchiMate to use different visualisations for elements and relations, e.g. see Section 8.4.1 The Introductory Viewpoint where most relations look like a simple line and Network looks like a cloud. ArchiMate’s section on Notation (A.1) is ‘Informative’, not ‘prescriptive’.
LikeLike
I very much applaud your creativity to use Archimate beyond its purpose. I only find it a bit ironic that you use a tool that already supports the BPMN-notation and is able to connect BPMN models to Archimate process concepts.
LikeLike
The support for the linkage provided by that tool is not perfect (even kludgy here and there). Besides, I’m not using this way myself, at this point in time.
LikeLike
An interesting and informative exercise.
I am perfectly happy with Archimate’s ability to indicate that a process exists, what it’s production inputs are, and what purpose it serves.
There is an ontological line, I do not want to cross, between variant (specific) and invariant (categorical) causality.
Personally I might even like Archimate better if a process was simply (and only) a relationship that some elements could have with each other.
LikeLike