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.

An important aspect of the Enlightenment (from 1600 onward) was the concept that science and technology would usher in a new age of prosperity, peace and happiness. This philosophical revolution in the West was also strongly associated with the concept of the individual, as expressed in the United States Declaration of Independence:

"We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness. — That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, — That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness."

In classical times in Egypt and Greece, the prosperity of society was greatly dependent on slavery: cheap labour. It enabled the city states to devote more resources to philosophical, artistic, and military advancements. It is estimated that 30-40% of the labour force in Ancient Greece consisted of slaves!

In a way the robotisation of modern society is creating a new class of "slaves": worker entities without intrinsic rights (although in ancient times the level of rights of slaves varied considerably), never complaining, able to work around the clock as long as they are properly maintained.

But an important element in the equation is not often discussed: who actually owns the value of these assets? In ancient times you were able to buy a slave or obtain one through some other means (indenture, as a punishment, conquest etc.). The slave would then be your asset. In our times we see a different ownership model. Robots (as a generic term for machines that perform labour in the broadest sense) are owned by a very small set of corporations, to be "leased out" to organisations or individuals. In other words: the actual value of the asset is reaped by those few real owners. The rest of us can only pay-for-use, and are completely dependent on the actual owners as to the price they charge for use.

It is very easy to understand that this construct is not sustainable. It is already clearly demonstrating that it results in a growing inequality in wealth. This has been demonstrated historically to lead to instability and eventually revolutions.

Elon Musk told the US–Saudi Investment Forum that advanced AI and humanoid robots will make human work “optional” within 10–20 years, end poverty, and make money “irrelevant,” predicting a major societal shift driven by automation.

Quotes like the one above are commonly heard from the parties expected to profit most from these technological developments. History teaches us that things usually do not develop in this manner. A brief period of wealth concentration is followed by a destructive upheaval resulting in a slight (and temporary!) redistribution of wealth. An example is the French revolution.

In France just before the Revolution of 1789, the proportion of national wealth held by the top 10 percent was about 90 percent, and the fraction possessed by the top 1 percent was as much as 60 percent.  After the Revolution, the proportion held by the top 10 percent fell slightly due to the redistribution of land belonging to the aristocracy and clergy in favour of the bourgeoisie (a little over 9 percent). - Thomas Piketty

Might we say that the seeming luxury of these robotic "slaves" has a rippling effect in making ourselves into slaves?

A sustainable model will need to be created, with the actual ownership of automated support in the hands of the people that use that support, with actual value (as in marketability).

Estimated reading time: 5 minutes

Why Building Blocks?

When embarking on any change effort, in the context of enterprise architecture usually referred to as a business transformation, partitioning the effort is essential for a successful, controlled result. This article tries to explain how to identify those parts: the building blocks that comprise the change.

The partitioning is not only necessary in the solution space (say, a new business process, or the implementation of a new IT system), but also on the strategic level. And both need to be aligned for a successful result.

What are Building Blocks?

The concept of a building block is neatly defined in TOGAF® as:

• Building blocks have generic characteristics as follows:
  • A building block is a package of functionality defined to meet the business needs across an organization
  • A building block normally has a type that corresponds to the metamodel (such as actor, business service, application, or data entity)
  • A building block has a defined boundary and is generally recognizable as "a thing" by domain experts
  • A building block may interoperate with other, inter-dependent building blocks.
• A good building block has the following characteristics:
  • — It considers implementation and usage, and evolves to exploit technology and standards
  • — It may be assembled from other building blocks
  • — It may be a subassembly of other building blocks
  • — Ideally a building block is re-usable and replaceable, and well specified

TOGAF 10^th Edition: TOGAF Standard — Architecture Content

A Building Block is an element that is used to "bridge the gap": we are here, we want to get there, and this component is (part of) what we need to find ourselves "there".

To partition the building block specification, usually two levels of abstraction are used:

1. The Architecture Building Block (ABB)
   The focus is on the architectural requirements here. The level of specification avoids specific tools or technology. Again, from the TOGAF Standard:
   • Fundamental functionality and attributes: semantic, unambiguous, including security
   • capability and manageability
   • Interfaces: chosen set, supplied
   • Interoperability and relationship with other building blocks
   • Dependent building blocks with required functionality and named user interfaces
   • Map to business/organisational entities and policies
2. The Solution Building Block (SBB)
   The focus here is more on the specific guidelines for the actual solution.
   • Define what products and components will implement the functionality
   • Define the implementation
   • Fulfil business requirements
   • Are product or vendor-aware

How to model building blocks in ArchiMate®?

ArchiMate provides a lot of concepts to model the enterprise architecture continuum, but has not specifically defined a concept for a building block.

The following article contains some examples on how to model building blocks in ArchiMate:

• Using ArchiMate to Visualize the TOGAF Enterprise Continuum

However no comprehensive solution or template was presented. Which is not a problem in itself, it just illustrates that modelling building blocks is possible with ArchiMate, but that different approaches can be used, depending on the context of your specific architecture.

Within the Dutch Ministry of Defence our team has defined the following template or metamodel for building blocks, both the ABB (Architecture Building Block) and the SBB (Solution Building Block). Additionally there is also an element called a Realisation Building Block (RBB) which contains the detailed solution as it is implemented within specific tooling. We will not explain that element further.

You can click on the image for an enlarged view.

Some remarks on the view:

• Elements with bold border are considered mandatory in a view based on this viewpoint
• Elements in a bold red border box: at least one element of the types included in the box are mandatory in a view based on this viewpoint

We decided to slightly deviate from the TOGAF specification in that we defined services to be part of the ABBs, and interfaces to be part of the SBBs. This is not a real deviation, because the term "interface" in the TOGAF definition does not correspond 1-1 to the term in ArchiMate.

• The service specifies the kind of questions I can ask the building block, and the format of the answer I receive (if applicable — a request to do something might not require an answer).
• The interface specifies the actual place where I can ask the question, for example a web service URL.

All elements in the building block definition can be neatly found in this metamodel:

• ABB
  • Fundamental functionality and attributes: semantic, unambiguous, including security: The Architecture Requirement
  • Interfaces: chosen set, supplied: Services (provided) on all layers
  • Interoperability and relationship with other building blocks: Services (consumed) on all layers, which will be the services provided by the other building blocks
  • Map to business/organisational entities and policies: the Role (ABB) and the Standard
• SBB
  • Interfaces: the channels through which the ABB services can be accessed (both the provided and consumed interfaces)

Further work

Obviously the proposed viewpoint is not meant to be final and complete. But we found that for most of our needs the elements sufficiently describe the building block components in our landscape.

Some elements were omitted. We could for example have added processes on the different layers. One of the reasons they are not here is the guideline to model top-level processes in ArchiMate with Functions (see Procesconcepten in NORA - article in Dutch).

An important subject is the strategic alignment. For this please read a separate article, which explains the viewpoint Strategic Planning. That viewpoint deals with the alignment of Building Blocks with Capabilities and Value Streams. Partitioning should not just be with Building Blocks. Actually the start of partitioning should be capability-based, with the building blocks a realisation of the capabilities. In other words: the actual building block boundaries are derived from or based on capabilities. More about that in the article I mentioned.

Attributions

Thanks to my colleagues in the architecture team with the Dutch Ministry of Defence (MoD): Wouter Paul Trienekens, Niels Doeleman, Emiel van Meurs, Herman Meijer and others.

Related articles

• The ArchiMate metamodel
• Business-centred ArchiMate
• The Business-IT Fallacy
• Round instead of square
• Kantelen met enterprise architectuur

Introduction

This article explains an ArchiMate® viewpoint, the Strategic Planning viewpoint which has been made by our team within the Dutch Ministry of Defence. We have found this viewpoint to be particularly effective in partitioning the transformation effort (which as you might understand is substantial within the context of Defence!).

Strategic alignment is often overlooked. It usually focusses on strategic views such as a Capability Map, but often leaves it at that. We then miss how these strategic landscapes are actually trickling down into the actual solutions.

Or we dive into possible solutions, usually taking too little or no effort to really understand what the problem is and what approach to take.

Capability-based planning

A central tenet of our approach is not specific for Defence, but becoming quite the standard in business architecture. As you may recall, TOGAF specifies a stratified approach to modelling regarding the content of the architecture repository, specifically the part called the Architecture Landscape. The architecture repository of the Dutch Ministry of Defence and most of the enterprise repositories I have worked with in my career have a similar structure:

1. Strategic architectures
   Architectural descriptions for organisation-wide things, expecting to be generic to any part of the enterprise. One of the descriptions is the Capability Map.
2. Segment architectures
   Descriptions specific for the different main components of the enterprise. An example segment within the MoD would be the Navy. The term "domain" can be viewed as a synonym.
3. Capability architectures
   This is where we describe the various capabilities (within the MoD termed "enterprise capabilities" to distinguish them from the military and NATO capabilities, which we decided to label "operational capabilities") and how they are realised by services and underlying business, software and technology. This approach partitions the solutions landscape according to the capabilities defined in the Capability Map mentioned above.
   

Today the accreditation process for our BPM training came back positively: as of December 2025 reflektis is an officially accredited training provider!

Our BPM training started off in 2012 with DHL Express as one of our first customers in The Netherlands. By now we have helped hundreds of people in applying BPMN. The training has been delivered through Skillsoft/Global Knowledge and for the completely online version through reflektis (in Dutch and English).

Interested in learning BPMN from the expert?

Visit https://academy.reflektis.nl/bpmn for our online training offering!

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.

De NORA (Nederlandse Overheids Referentie Architectuur) definieert een aantal concepten over processen. In dit artikel wil ik ingaan op de definities van:

• Ketenproces
• Bedrijfsproces
• Werkproces (Deelproces)

NORA definieert de concepten correct, maar summier, en ik kom in de praktijk tegen dat hierdoor veel voorkomende fouten gemaakt worden. In dit artikel kom je te weten hoe je ketenprocessen, bedrijfsprocessen en werkprocessen moet modelleren conform NORA, in ArchiMate en BPMN.

Definities

Allereerst is het belangrijk om je te realiseren dat de termen zijn gedefinieerd in NORA 2.0, maar (deels) zijn losgelaten in de latere versie 3 (2014). Daar is een belangrijke reden voor, namelijk dat de definities te rigide waren. Hierover volgt straks uitleg. Binnen allerlei overheidsorganisaties zijn de definities echter omarmd en gebruikt in de procesarchitecturen (zoals in de GEMMA), en is het van belang dat we helder definieren wat we hiermee bedoelen en hoe we hiermee om moeten gaan. In mijn werk bij UWV, Belastingdienst en Defensie kom ik dezelfde worsteling tegen.

We zullen bovenstaand generiek procesmodel gebruiken als kapstok voor de uitleg:

Ketenproces analyse

Diagram 1 laat een generiek voorbeeld zien van een top-level bedrijfsproces. Het feit dat het een ketenproces betreft is in dit diagram direct te zien, omdat één stap in het proces (Werkproces 3b) geheel uitbesteed is aan een ketenpartner (Ketenpartner, de black-box pool waarmee een response/request message flow interactie is te zien).

Dit hoeft niet altijd een activiteit in een top-level diagram te zijn: wanneer een processtap of handeling is uitbesteed is er nog steeds sprake van een ketenproces: een deel van het proces, op welk procesniveau dan ook, wordt onder regie van de eigen organisatie uitbesteed aan een ketenpartner.

Wat is nu het verschil met een "gewone" partner, bijvoorbeeld een betalingsprocesstap die uitbesteed wordt aan een payment provider?

De payment provider zal ook gemodelleerd worden met een black-box pool, maar is geen ketenpartner. In BPMN termen is de payment provider een "gewone" collaboration. Er zullen ook message flow interacties zijn tussen de black-box pool van collaborator en de eigen white-box pool. Alleen heeft de eigen organisatie op geen enkele wijze een afhankelijkheid met de interne opbouw en ontwerp van het proces van de black box pool. De payment provider stelt een service interface ter beschikking van alle gebruikers (waar wij er één van zijn) en wij moeten ons conformeren aan die interface om van de diensten van de payment provider gebruik te kunnen en mogen maken. De message flow interacties vinden plaats vanuit onze "eigen" activiteiten met message send/receive elementen (tasks of events).

Bij een ketenpartner ziet het er iets anders uit. We modelleren wel een "lokale" placeholder voor de uitbestede activiteit. Omdat wij de regie hebben (wij zijn de proceseigenaar), zijn wij in staat aan die lokale placeholder allerlei eisen te stellen. We kunnen bijvoorbeeld uitspraken doen over hoe de activiteit wordt getriggerd (inkomende sequence flow) en hetzelfde voor de uitgaande sequence flow(s). We kunnen als wij dat willen de interne structuur van het (extern uitgevoerde) proces beschrijven. Wij gedragen ons als eigenaar van de uitbestede activiteit, en de afhankelijkheid is dus veel groter dan bij een "gewone" collaboration. De activiteit Werkproces 3b is dus eigenlijk "onze" activiteit. Omdat er iets bijzonders mee is maak ik gebruik van een grijstint van het blokje maar dit heeft geen betekenis en is een persoonlijke voorkeur (je ziet ook een blauwe black-box pool, hierover meer hieronder).

Samenvattend: om recht te doen aan de strakkere afhankelijkheid van een stap die onder onze eigen regie wordt uitgevoerd door een externe organisatie, stel ik voor gebruik te maken van een lokale placeholder met message flow connecties naar de externe organisatie.

Ik wil het diagram nog wat meer exploreren.

Alleen werkprocessen op top-niveau?

We zien dat alle activiteiten op één na subprocessen zijn (het plusje in de activiteit). Hieronder zal ik de inhoud van die subprocessen laten zien. Er is echter (als voorbeeld) één activiteit opgenomen die geen subproces is maar een gewone (Abstract) Task: Processtap 4. Dit kan een simpele handeling zijn van bijvoorbeeld maar 1 stap. Het komt voor in dit procesniveau, en omdat een handeling in de bovenstaand definities is gekoppeld aan een rol binnen een afdeling/team is die informatie hier ook getoond: de rol Rol 02 binnen Afdeling 2.

Je kunt er ook voor kiezen op het top-niveau alleen werkprocessen te willen laten zien. Dan staat je niet veel anders te doen dan Processtap 4 een subactiviteit te maken van een Werkproces 4 dat je op het top-niveau toont. Beide zijn mogelijk.

Laten we door het proces lopen.

Walk-through

Het proces wordt getriggerd door een Externe trigger (black-box pool, bijvoorbeeld een Klant). Dit is in het merendeel van de bedrijfsprocessen zo. Het inkomende verzoek wordt aangeduid met Bedrijfsobject 1, de message payload van de triggerende message flow. Een voorbeeld van een dergelijk object zou een Order kunnen zijn. We zeggen dan dat het bedrijfsproces in zijn geheel de "Order" representeerd. Bedrijfsprocessen hebben meestal een bedrijfsobject dat het proces representeert.

Vervolgens wordt door Afdeling 1 een proces uitgevoerd die wordt aangeduid met Werkproces 1. We zien dat dit een subproces is, en we zien dat er een uitgaande en inkomende message flow is (resp. request/response) met een externe black-box pool. Deze pool is hier blauw getint, wat een persoonlijke conventie is (geinspireerd door ArchiMate, waarin applicatie objecten blauw zijn). Ik adviseer applicatie koppelingen te modelleren met black-box koppelingen. Waarom?

• Applicaties zijn encapsulated (als het goed is - service componenten die tegenwoordig in plaats van applicaties ontwikkeld worden zijn dat per definitie), dus onafhankelijk van de buitenwereld.
• Applicaties worden gebruikt in een proces via een of andere API. Dit is perfect te mappen op het concept message flow, zeker wanneer er een asynchrone communicatie plaatsvindt (over (a-) synchroon later meer).
• De gebruiker van een applicatie heeft geen enkele dependency met de interne structuur van de applicatie.

We duiken straks dieper in wat er gebeurd binnen Werkproces 1. Ik ben er dus geen voorstander van om de applicatie als een Lane in het proces op te nemen, maar adviseer dit te modelleren als een externe black-box pool.

We zien dat op Werkproces 1 een XOR Gateway volgt. Daaruit kunnen wij afleiden dat het subproces Werkproces 1 twee end states heeft waarvan er één het label Fout heeft (labeling conventie van Gateways). Hieronder gaan we dit procesniveau expliciet beschrijven, voor nu lopen we nog even door het proces op dit top-niveau.

Als er een Fout end state is in Werkproces 1, moet nog een kleine handeling verricht wordt door Rol 02 in Processtap 4, waarna het proces eindigt in de state End state fout. Daarmee eindigt het proces (er zijn geen tokens meer in het proces).

Als er geen fout end state is, wordt Werkproces 2 uitgevoerd, waarvan we de binnenkant hieronder nader beschrijven. Na deze stap, komen we bij een splitsing (Parallelle Gateway) die ervoor zorgt dat Werkproces 3a en 3b parallel worden uitgevoerd. Werkproces 3b is de lokale placeholder voor werk dat in werkelijkheid uitgevoerd wordt door Ketenpartner. We gaan hieronder inzoomen op de stappen in dit subproces.

Nadat Werkproces 3b is afgerond volgt er een gateway: we zien hier al dat Werkproces 3b twee end states heeft waarvan er één het label Afgerond heeft. Wordt dit bevestigd (happy flow, de yes-gate wordt getriggerd) dan word gewacht in de merging parallelle gateway totdat Werkproces 3a klaar is. Zodra dat het geval is worden beide tokens gemerged en gaat het proces verder naar End state correct en het proces eindigt. Wanneer Werkproces 3a eerder klaar is dan Werkproces 3b wacht de merging gateway totdat Werkproces 3b klaar is, merged de tokens en gaat dan eveneens naar End state correct.

Wanneer Werkproces 3b echter niet in de end state Afgerond eindigt, wordt een foutmelding gestuurd naar de Externe trigger, en komt het proces in een Terminate end state fout. Dit moet een Terminate zijn (en niet bijvoorbeeld een Message Send End State) omdat er parallelliteit in het proces zit: Werkproces 3a zou nog niet klaar kunnen zijn. De Terminate End Event zorgt ervoor dat Werkproces 3a, mocht die nog bezig zijn, wordt afgebroken, en het gehele proces eindigt in End state fout.

Tot zover het top-level proces. Laten we nu inzoomen op de subprocessen.

Werkproces 1

In dit subproces zien we twee sublanes binnen de lane Afdeling 1, die van Uitvoerder (die Processtap 1.1 uitvoert) en die van Goedkeurder die Processtap 1.2 uitvoert. Ik ga verder niet in op dit subproces, en zoom meteen in op Processtap 1.2.

In dit procesniveau zien we één voorbeeld van de twee manieren waarop applicatiekoppelingen gemodelleerd kunnen worden in procesmodellen, namelijk door een Service Task te gebruiken. Handeling 3 is de stap die uitgevoerd wordt door Applicatie 1. We zien de message flow interacties vanuit die service task. Merk op dat het gebruik van een Service Task impliceert dat de interactie synchroon plaatsvindt, en dat de message flows suggereren dat die asynchroon plaatsvindt. We zien de laatste tijd dat er een conventie ontstaat om asynchrone service interacties toch te modelleren met een service task en message flows, wanneer de request/response cyclus zeer kort (nano/millisecondes) is. Voor een voorbeeld van asynchrone interacties zie hieronder bij Werkproces 3b.

Ten overvloede: in dit subproces staan (nog) niet sublanes die de subrollen/personen binnen de rol Goedkeurder beschrijven (bijvoorbeeld om aan te geven dat Handeling 1 gedaan wordt door Junior Goedkeurder).

Merk ook op dat alle message flow interacties vanaf het laagste niveau (in dit geval Handeling 3) omhoog propageren tot op het top-niveau.

Werkproces 3b

In dit subproces is weliswaar geen sprake van een applicatiekoppeling maar met een externe ketenpartner, maar merk op dat het koppelingspatroon hetzelfde is.

We zien dat wij in dit proces niets doen, alles wordt via asynchrone message flows gedelegeerd naar Ketenpartner. We zien ook een time-out op het proces staan, een standaard onderdeel van elke externe delegatie.

We zien ook een ander pattern: de send is een task, en de receive is een event. Hierdoor kunnen wij bijvoorbeeld een loop zetten op de send, of een boundary.