Dynamic relationships in ArchiMate

ArchiMate is especially powerful because of its rich set of relationship types. These relationships are grouped/classified in 4 sets:

1. Structural
2. Dependency
3. Dynamic
4. Other (called "Special" by me)

The basic pattern in ArchiMate modelling is:

1. You identify the main components in your architecture landscape. Those (as a rule) will be Active Structures. They will mostly be Internal Active structures (such as Business Actors or Devices), and networks (neither external or internal).
2. You detail these main components or nodes using structural relationships.
3. You identify the cohesion between these components by determining how they are connected using dependency relationships (mainly Serving).

If you have done this properly, the result should be a graph of Active Structures connected with each other through Services/Interfaces. This ensures the primary architecture principle of high cohesion-loose coupling. Great work!

However!

We also have dynamic relationships. They also create relationships between elements. An example:

The "Accept Claim" process is performed by a Role: Customer Service Representative. That process triggers (a dynamic relationship) the Assign Claim process.

However, that process is performed by a different internal active structure: High-Risk Claims Adjudication.

I have an issue with this model. What is it?

Well, the issue is the direct triggering of the behaviour of another entity, bypassing the entire premise of ArchiMate, namely the encapsulation of behaviour with an external layer.

As you may remember, the behaviour of an Active Structure in ArchiMate is Internal, that is: not available directly from outside (= other entities besides the one that performs this behaviour). If you want that internal behaviour of another entity to be of service to you, the honourable way to do that would be to utilise the published external behaviours, also called Services:

This is the honourable way to trigger a behaviour:

1. I need to do something: Accept Claim
2. When that is done, I would like someone else to "take over": I request that by invoking a service called Assign Claim. Handover!
3. The assign claim service is realised by the Assign Claim business process of that other (internal active structure, so effectively invisible to me: loose coupling)

This is why I always explain that: no I do not have a fundamental issue with using dynamic relations, but please keep in mind that in a proper architecture those relations are best seen as a kind of shorthand:

The same applies to the Flow relationship: it is very impolite to directly flow into someone else's (internal) behaviour, but it can be useful to show the shorthand notation.

Especially for implementers (solution architects or developers) working with these ArchiMate models as input, this is an important aspect to be aware of.

The most common hurdle for participants is the information overload. Both the ArchiMate metamodel and all the ArchiMate concepts with their definitions may be overwhelming to absorb. There are only three days in which all this information is presented and explained, with limited time available for exercises. This is where some preparation is going to help you immensely.

Coming from the UML world, I have been an accredited ArchiMate® trainer for many years, as well as working with ArchiMate almost from the birth of the language in The Netherlands in my consultancy work. The language was intended to be as simple as possible, even to the extent that the ArchiMate community originally had the ambition that it would be simple enough to be used by "the business", i.e. non-architects or people that did not need specific training or experience to read or use the diagrams. However this was soon abandoned because in spite of the goal of simplicity (which in my opinion has been successfully achieved) there is of course a conflict of interest for the language to be complete enough for enterprise architecture as well as to serve as a complete-enough spec for the TOGAF Content Framework, which is from another standard from The Open Group.

• To start with: get the website with the official spec in your favourites: the online edition of the ArchiMate 3.2 Specification (please note that a web account for The Open Group is required to access this resource).
• Play with an ArchiMate tool. I suggest Archi: https://www.archimatetool.com. If you do, I urge you to make a donation - the devs are doing incredible work! Of course if your company already uses a tool, see if you are able to access that.
• Import or navigate example ArchiMate models:
  • https://pubs.opengroup.org/architecture/case-study-models/archisurance-html/
  • https://pubs.opengroup.org/architecture/case-study-models/archimetal-html/
• There is a nice concise introduction to ArchiMate: https://archimate-community.pages.opengroup.org/workgroups/archimate-101/

If you take a few hours to invest in researching these references, you will have created a set of "hooks" in your mind to better connect the information that you receive in the training.

Good luck!

Rob Vens

In mijn vorige post Procesconcepten in NORA heb ik geprobeerd wat licht te werpen op het modelleren van processen in BPMN, gebaseerd op de NORA definities van processen. Dat artikel is vooral bedoeld voor procesontwerpers en bedrijfsanalisten die voor (overheids-) organisaties in Nederland bezig zijn processen te beschrijven.

Dit artikel richt zich meer op enterprise/bedrijfsarchitecten. Ook daar zie ik veelal een worsteling om dit te doen in lijn met de NORA referentie architectuur, en om te begrijpen wat NORA precies bedoelde met het onderscheid tussen bedrijfsprocessen en werkprocessen. Dit komen we namelijk steeds weer tegen bij de verschillende afgeleide referentie architecturen zoals de GEMMA, de HORA enz.

Merk op dat in de nieuwste versie van de NORA, mede vanwege de vele misverstanden die rond deze concepten ontstonden, dit onderscheid is losgelaten.

Naarmate een volwassener architectuurdiscipline in die organisaties ontstaat moet het daar natuurlijk niet bij blijven. Vanuit enterprise- en bedrijfsarchitectuur beschrijven we immers ook processen. Hiervoor wordt merendeels ArchiMate, een modelleertaal voor enterprise architectuur, gebruikt.

Bedrijfsarchitectuur

Het vakgebied van bedrijfsarchitectuur is volwassen aan het worden. Het fundament daarvoor is voor een groot deel afkomstig van de Business Architecture Guild. Dit is een onafhankelijke organisatie waarvan het werk door de Open Group wordt geadopteerd in TOGAF (Phase B: Business Architecture). Dat weerspiegelt zich dan weer in ArchiMate omdat beide standaarden beheerd worden door de Open Group en in lijn zijn met elkaar. ArchiMate is een manier om het metamodel voor TOGAF te beschrijven. Er zijn andere manieren, maar wereldwijd en zeker in Nederland is ArchiMate de enige die ik tegenkom.

De vier pijlers van bedrijfsarchitectuur

Volgens het framework van de Guild zijn er vier pijlers waarop bedrijfsarchitectuur rust:

1. Capabilities
2. Value Streams
3. Information
4. Organisation

We zien hierin bedrijfsprocessen niet (direct) voorkomen. In dit artikel wil ik die relatie tussen bedrijfsprocessen en enterprise architectuur uitwerken. Ik focus hierbij op Capabilities en Value Streams, zodat je kunt zien op welke wijze bedrijfsprocessen deel uitmaken van de bedrijfsarchitectuur.

Ook wil ik laten zien hoe processen samenwerken met software, in het geval dat processen geheel of gedeeltelijk geautomatiseerd worden uitgevoerd.

Bedrijfsprocessen en Value Streams

Onderstaande metamodellen zijn voor versie 3.2 van ArchiMate

Bedrijfsprocessen hebben een directe relatie met de Value Streams die zij realiseren. In het classificatiemodel (door de Open Group metamodel genoemd) van ArchiMate is dit te zien. Eerst kijken we hoe ArchiMate Value Streams en Capabilities ziet. Zoals je ziet, zijn dit gedragselementen (behaviours) in de Strategische laag:

Bedrijfsprocessen zijn ook gedragselementen, maar dan in de bedrijfslaag (Business Process hieronder):

In het diagram hieronder zie je de relatie tussen die twee. Een Strategy Behavior Element kan een Capability of een Value Stream zijn (zie hierboven), en een Business Process is een Internal Behavior Element.

De relatie tussen een bedrijfsproces (Business Process) en een Value Stream is dus een realisatie relatie. Hieronder zie je een voorbeeld van hoe die aan elkaar verbonden kunnen worden. Eerst kijken we naar de relatie tussen Capabilities en Bedrijfsprocessen. Hier toon ik meteen ook de gerelateerde BPMN versie van het ArchiMate proces.

Een voorbeeld van een relatie tussen Value Streams en Bedrijfsprocessen. Ook dit is een Realisatie relatie. In BPMN is het vervolgens mogelijk het top-level proces verder hiërarchisch te decomponeren zover als nodig/zinvol is. Hiervoor adviseer ik de methode van Bruce Silver zoals hij die uitlegt in zijn boek Method & Style.

Repository

Idealiter zijn beide procesbeschrijvingen uitgewerkt in dezelfde architectuur repository. Deze wordt beschikbaar gesteld door een tool die zowel BPMN als ArchiMate moet ondersteunen (en bij voorkeur nog meerdere talen, met name UML). Ook helpt de tool bij het (hyper-) linken van beide modellen, zodat te zien is dat een proceselement in een ArchiMate view dezelfde is als een activiteit in een BPMN view.

Nu gaan we even weer terug naar het abstracte voorbeeld in ons voorgaande artikel Procesconcepten in NORA:

Hieronder zie je nu datzelfde procesmodel, maar nu in ArchiMate.

Enkele observaties

• Vanuit de enterprise architectuur willen wij voor elk bedrijfsproces zien welke dienst dat proces levert: de Dienst 1. Hierdoor kunnen wij in andere views laten zien wie de afnemers zijn van dat proces
• We willen ook vastleggen wie verantwoordelijk is voor het proces, en wie het proces uitvoert. Het onderscheid tussen Bedrijfsproces en Werkproces is juist daarvoor bedoeld: het bedrijfsproces heeft een uitvoeringsverantwoordelijke, het werkproces heeft een uitvoerder (een afdeling of een team). Dit kun je zien in de elementen Bedrijf en Afdeling 1, en de relaties (assignment) die het heeft met de proceselementen. Dit is gerelateerd aan de peiler Organisatie.
• Wij willen ook zicht hebben op de gebruikte applicaties. De eventuele gebruikte software komen we tegen bij de proces stap Geautomatiseerd proces, dat gebruik maakt van een Application Service genaamd Geautomatiseerd proces. Dit is een voorbeeld van een proces stap die geheel door software wordt uitgevoerd.
• Een proces stap waarbij een mens gebruik maakt van software is Proces stap 1.2, die van Application Service 1 gebruik maakt
• Wij adviseren om in top-level processen alleen activiteiten, exclusieve gateways (~XOR Junction in ArchiMate), parallelle gateways (XAND Junction in ArchiMate), en simpele events te gebruiken, dus geen meer esoterische BPMN concepten zoals event-based gateways en complexe event types.
• Vanuit de enterprise architectuur is het tenslotte essentieel te weten welke bedrijfsobjecten waar gebruikt worden. Dit is gerelateerd aan de pijler Informatie.

Concluderend hoop ik dat deze uitleg helderheid geeft over hoe processen gemodelleerd moeten worden, onder de paraplu van NORA. Zowel bij Belastingdienst als Defensie heb ik deze aanpak met succes mogen realiseren. Ervaringen uit de praktijk zijn cruciaal om de aanpak verder te vervolmaken, en om die reden wil ik de lezers uitnodigen op mijn artikelen te reageren en in dialoog te gaan.