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.

Intro

TOGAF defines its process or method in something called the ADM: the Architecture Development Method.

It is usually represented by the illustration below, with the familiar arrangement of circles around Requirements Management, which has come to be the iconic representation of TOGAF.

Waterfall mindset

The Open Group itself is clear on the ADM in that it is not necessarily a waterfall-like process (although it can be executed in such a fashion). It is supposed to be iterative and incremental, as any process nowadays should be.

The ADM is iterative, over the whole process, between phases, and within phases (see Part III, 18. Applying Iteration to the ADM)

(from The TOGAF^® Standard, Version 9.2, chapter 4.2.1)

The picture does not really help in conveying that message, since:

1. The circles are named "phases"
2. They are sequentially numbered (letters A to H)
3. The A to H phases are linked with directional arrows suggesting a flow from A to H
4. The description of the various inputs and outputs of the phases further emphasises the sequential dependency between phases (output of one is input for the next)

Mixed perspectives

ADM "phases" are quite heterogeneous.

1. Phases B to D are the actual architecture development phases, realising architectures in the different architecture domains, Business, Software and Infrastructure.
2. E and F are quite different since they focus on planning.
3. G is an altogether different beast again, since it focusses on governance, especially in relation to running implementation or solution projects. As long as implementation projects are running that are an outcome of planning in one TOGAF ADM cycle this phase is active.
4. And then there is phase H which is the least sequential of all, since it is a continuous monitoring and analysing activity with everything to do with change, inside and outside of the organisation.

Of course there is the central "phase", Requirements Management, somehow positioned as the linking pin between all the other. In my experience this is completely fine since all work impacts requirements and vice-versa. Positioning the Requirements activities in this way is a helpful aid to maintain a focussed mindset.

Superfluous ADM phases

Two phases are somewhat problematic in my view, and those are Preliminary and Architecture Vision. They further emphasise a waterfall interpretation of the ADM.

The Preliminary phase is not actually part of the process — it instead is there as a placeholder to prepare for the process. Why include it in the ADM at all? Of course we need to do some stuff before a TOGAF cycle, iteration, or sprint for that matter, can start. But it is only confusing to include it as if it is a step or phase.

The Architecture Vision phase is the same. In a waterfall interpretation of TOGAF, sometimes referred to as "comprehensive" this phase may make sense, but again this pushes our understanding in the waterfall direction. If we interpret the various ADM "phases" as disciplines, workflows, or EA capabilities (this last has my preference), these can (and will!) be executed in parallel in whatever fashion. This will make Architecture Vision a superfluous phase altogether. It will be just some work done in some time period across different disciplines, later to be extended, to lay the groundwork resulting in a formal approval for a TOGAF cycle by the sponsoring organisation. It is then just a comprehensive ADM cycle.

A new representation

All in all this leads to the following illustration of what I believe the TOGAF ADM could be pictured in, mitigating issues I mentioned related to the waterfall suggestion of the traditional representation. By the way, this representation of the TOGAF ADM is 100% compliant to TOGAF (TOGAF is meant to be tailored/customised), it is just a different visualisation that might be more helpful.

This illustrates nicely that we have

• one triangle: three disciplines focussing on the architecture domains (Business, Information Systems, and Technology),
• and another triangle: three disciplines that are less about architecture content but more about the link with the rest of the organisation, while still maintaining the central role of the third aspect:
• requirements management.

Architecture Development

If we see the three disciplines: Business, Information Systems, and Technology, as disciplines or workflows, we can mitigate a fundamental issue with TOGAF, namely the BDAT-stack (Business-Data-Application-Technology). A few remarks in this context.

Information should be more prominently included in the Business Architecture discipline (as one of the four cornerstones of Business Architecture: Capabilities, Value Streams, Information and Organisation, as defined by the Business Architecture Guild).

It seems the Open Group already embraced this approach, and my expectation is that we will see this take form in the next release of the TOGAF standard. The 9.2 version of the standard has taken steps to include these in the Content Metamodel and the artefacts to be produced in the Business Architecture phase: Business Capability Map, Value Stream Map and Organisation Map. Information as a cornerstone Business Architecture concept is not really positioned well in the 9.2 version of the standard. It is summarily discussed in the Business Model Diagram and really should be given more depth.

The Business Architecture part of TOGAF is under intense development and The Open Group now even provides a credential specifically focussed on Business Architecture: https://www.opengroup.org/certifications/togaf-business-architecture-level1

The Information Systems Architecture should no longer be separated into Application/Data. In fact both terms (Application and Data) are outdated. Data is meaningless without context, and that is precisely what we add in the concept of Information as defined in the Business Architecture as mentioned above. This discipline is about realising automated, smart, and evolving systems on the software level (as opposed to the Technology Architecture discipline that thinks about how to run all that on platforms, physical or virtual).

The Information Systems Architecture should put more focus on "mirroring" the business. As you can read in many articles on this site (for example The Mirrored World) this approach is crucial in gaining alignment with the real world. We have recently seen a "rediscovery" of this concept (although I have been writing about this since 1995) in the form of the concept of Digital Twins. Recently picked up by Gartner this is getting quite a lot of attention lately.

Trend No. 5: Digital Twin

Within three to five years, billions of things will be represented by digital twins, a dynamic software model of a physical thing or system. Using physics data on how the components of a thing operate and respond to the environment as well as data provided by sensors in the physical world, a digital twin can be used to analyze and simulate real world conditions, responds to changes, improve operations and add value. Digital twins function as proxies for the combination of skilled individuals (e.g., technicians) and traditional monitoring devices and controls (e.g., pressure gauges). Their proliferation will require a cultural change, as those who understand the maintenance of real-world things collaborate with data scientists and IT professionals.  Digital twins of physical assets combined with digital representations of facilities and environments as well as people, businesses and processes will enable an increasingly detailed digital representation of the real world for simulation, analysis and control.

(from Gartner)

The parallel execution implies that it is meaningless to do "just" software architecture. To align it with business it needs to be developed in sync with the business domains, and the business architecture in the center (see my article Business-Centred ArchiMate, or The Live Domain). I believe that this will help in mitigating the Business-IT divide.

Planning

Planning is done all over the place. To define it as a separate capability means that we can use it

1. to plan TOGAF cycles or iterations
2. to plan projects (agile or waterfall)
3. to plan doing architecture.

The difference between Opportunities and Solutions (diverging and focussing on exploring all possible approaches) and Migration Planning (converging and finalising the approach) is not clear in the current standard, and is also less applicable in more agile approaches to architecture, so why not bundle these into one?

Parallel execution

Requirements Management will remain positioned as it was.

Since we now have less of a suggestion of sequentiality, and we no longer have the need to talk about iterations of the ADM since it will be requirements that drive the amount of attention needed from any ADM discipline, and activities in any discipline can be executed in parallel with any other discipline.

Over time the execution of the disciplines can be visualised as follows (example, also showing a more or less constant resource utilisation):

This is partly inspired by how the Rational Unified Process (RUP) talked about disciplines:

Summary

To summarise, I would like to change the ADM visualisation as shown above, and change the following:

1. No longer use the term "phases" but change to "disciplines" or "architecture capabilities".
2. Merge Migration Planning and Opportunities and Solutions to "Planning", which includes planning of the TOGAF ADM cycle itself.
3. Remove Preliminary and Architecture Vision and move the activities in those phases in the new structure.
4. We are then left with the following disciplines:
   1. Business Architecture
   2. Information Systems Architecture
   3. Technology Architecture
   4. Planning
   5. Governance
   6. Change Management
   7. Requirements Management

Introduction

Most people I work with think of architecture governance as something imposed upon the populace from above. They see architects operating from a kind of control tower: architectural guidelines and rules, constantly fighting to uphold the norms they themselves concocted.

I do not think that will work in the long run.

For me, architecture governance works much better when it self-organises from the roots. For that, a simple model has been created that I would like to share with you. Let me know if you think this might work for you.

Enterprise Architecture Repository

As you may have surmised, I am not a great fan (or believer) in top-down architecture. But I do think there is a great advantage in having something called an Architecture Repository. However you structure this repository, my preference is to have only one repository containing all architectural but also all solution building blocks. Probably you will have some kind of document management system as well, but if you do, please use the architecture repository as the central index, and not the other way around.

Anyway, the structure of the Enterprise Architecture Repository is a subject on its own. My current focus is on the fact that architecture work is structured in a unified way, using some kind of metamodel that makes sense for your organisation, whether it is Zachman, ArchiMate or TOGAF or something else.

Decision Log

An essential part in the strategy I propose is a thing called the Decision Log. This is a part of the Enterprise Architecture Repository where architectural decisions that are taken in the course of doing work are recorded. Entries in this log are reviewed in a structured way:

1. Peer review by a team member (a person directly working with the person logging the decision).
2. Peer review by a randomly selected member of another team. Not completely random, but the intent is to introduce a certain element of randomness and stochasticity in the selection.
3. Review by an architectural role.
4. End review on a random selection base by the enterprise architect.

Architectural Decisions

Step 1. Awareness: See

Everyone in any organisation, both on the floor as in all management structures, does architecture (see Everyone's an Architect). The purpose of this first step is for all involved to realise:

1. What is architecture?
2. When do I make an architectural decision?

In order for that awareness to take form it is usually necessary to evangelise it: give presentations, tailored to the various audiences such as developers, sales people, managers. These presentations should not focus on IT alone. Architecture, especially from the perspective of Enterprise Architecture, involves all.

Step 2. Work with architecture: Do

As soon as people start to become aware of what architecture is and how it surfaces in their daily work, we are ready for the next step: what to do when I do something that touches on architecture?

As soon as that is the case you participate in a vital function of the organisation, called the Architecture Function. Just like for example in the human body, where we have functions like the circulatory function. This (architecture) function has always been there, it is just that now we want to work on making us aware of it and making it more explicit.

To make that possible you are asked for a specific behaviour. You do the same thing you did before, just slightly different. Below you will see a summary.

1. Is this decision I want/need to take an architecture decision (remember: in the previous step we worked on creating awareness of what this means). If yes, move on to step 2. If no, well just do your thing as you did before.
2. OK, we are dealing with an architectural decision. No need to panic, it sounds more … well, high-brow, than it is. We are going to document it. There is this thing called a Governance Log, within which lives another thing called a Decision Log. We document that we want to make an architectural decision: name, date, a short summary of the context.
3. Now that we have recorded the architectural decision or action in the Decision Log, we need to determine whether we actually can make the decision.
   Essential for a correct answer to this question is our own competence (architecture has to do with competence, experience, understanding, insight), and most importantly our ability to assess the level of our competence. Do we believe we can make the decision? Then by all means take it, and document the action in the Decision Log. Mark the decision as being taken. Now you should realise that you are responsible (subject-matter responsibility) for that decision!
   If we think we can not make the decision, for whatever reason, move on to 4.
4. The architectural decision is still waiting to be made, only you could not make it. Now's the time to confer with your peers in order to gain more information. Maybe in that process you realise you are able to make the decision. Again, do so as described earlier: document in the Decision Log. Your participation in the architecture function is done for now and you can remove your architecture hat. But it can be that you see that you, even with the input from your peers, are still not able to make the decision. You log that, and move on to 5.
5. You are not able to make the decision. That means the architect's hat on your head needs to find another head. That is what you need to do in this step. What is actually done in this step depends on the maturity of the architecture function in your organisation. It basically comes down to finding the most immediate responsible (subject-matter responsible role) person. Are you for example a developer in a scrum team, you may have a team member who is end-responsible for architectural stuff. This person now puts on the architect's hat and she begins again with 1.
6. Architectural decisions that could not be made all eventually end up with the enterprise architect. But she will deal with it the exact same way, except when she cannot make the decision as well the decision moves outside the architecture function and becomes the responsibility of the board.

The picture above shows the basic steps in making architectural decisions.

The picture above shows the basic escalation path. What exactly the "next level" is depends on the maturity of the architecture process.

In summary: in this step we learn to put on the architecture hat, and how to act as an architect.

Step 3. Establish the architecture function: Build

In this step we work on establishing roles and responsibilities related to the architecture function. This might lead to the job function of Architect, but that is not what it is really about. It is more about the realisation of explicit roles. As we saw in the previous step, all of us play the role of an architect from time to time: when we need to make a decision that is marked as an architectural decision.

Working with scrum for example, we can establish one person as the end-responsible person within the team for architectural decisions. This role will need to be established on the various levels of the organisation, distinguishing the various architecture domains:

1. Business
2. Information
3. Information Systems (software)
4. Technical or infrastructure
5. Security

Step 4. Improvement: Learn

This step basically entails doing what is described above, and learn from it. To help us do so however, we need to explicitly revisit what and how things were done. This is called the Architecture Retrospective (borrowed from scrum). This might lead to an escalation structure as shown in the next picture.

This picture schematically depicts people making decisions marked as architectural, and how they "flow" through the organisation. It shows that architecture, to a great extent, "emerges" from the teams. And how some of it needs to flow up so to say, to make sure that the decision is actually made by the best person for that decision. It also uses the RACI model to separate two "kinds" of responsibility (see RACI for Enterprise Architecture).

However, the process is quite a bit different from what is generally meant by "governance". I hope you, the reader, realise that there is even a fundamental difference. The process as depicted in this article is a grass-roots process. It empowers local decision-making, and the makers of those decisions. It leads to a continuous improvement process, where we know we can never make the best decision at any given moment in time, but we do know that the quality of those decisions will improve constantly. We do not create a process (as is often the case, alas) that runs down on itself, but we create a sustainable learning curve.

For example, the decisions are logged in the Decision Log. This log is reviewed by others. But the log is not meant to be used as an enforcement tool. It is the process in which it is used that should be central. This in itself is a subject for a separate article (read: Logging Architectural Decisions). Too often architecture is implemented top-down, creating an ever-growing distance between architects and developers (and we are not talking IT only here: any organisation develops itself in all its aspects). The spirit of this article and the process it describes is empowerment, agility, continuous learning and improvement.

Introduction

This article attempts to reconcile the ArchiMate modelling language with Business-Centred design principles, principles I strongly advocate.

ArchiMate as a language (or, as some would say, a grammar, since a rigid definition of its semantics does not exist) is very "traditional" in the sense that:

• it is very IT-centric
• it explicitly invites the modeller to use a data-centric world view
• it does not exploit the power of distributed systems (for example as it should be doing with microservices)
• it has a very familiar but also frightfully traditional layered structure
• it has never understood the real power of object-orientation

It is my conviction that it is not so much the language that determines the scalability and flexibility of your solutions. But if the language and its usually implicit assumptions about how the world is structured is all you know, it does. So what is important, if you want to reap the benefits of business-centred design and the scalability and flexibility it offers, is to look elsewhere. It is not in the ArchiMate and EA community where you should look, with a very few exceptions (such as Tom Graves and his ilk, usually seen as rogue architects). Maybe we really should expand on the PureArchi idea ?.

But having adopted this "rogue" world view, not much should prevent you to make models of your solutions using ArchiMate, models that do not distort your axioms too much.

Re-writing ArchiMate

From the standard

This is what the ArchiMate 2.1 standard has to say about Business Models (Chapter 3.2):

The active structure aspect at the business layer refers to the static structure of an organization, in terms of the entities that make up the organization and their relationships. The active entities are the subjects (e.g., business actors or business roles) that perform behavior such as business processes or functions (capabilities). Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on structure, which means that the inter-relationships of entities within an organization play an important role. To make this explicit, the concept of business collaboration has been introduced. Business collaborations have been inspired by collaborations as defined in the UML 2.0 standard , , although the UML collaborations apply to components in the application layer. Also, the ArchiMate business collaboration concept has a strong resemblance to the “community” concept as defined in the RM-ODP Enterprise Language , as well as to the “interaction point” concept, defined in Amber as the place where interactions occur.

The concept of business interfaces is introduced to explicitly model the (logical or physical) locations or channels where the services that a role offers to the environment can be accessed. The same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or through the Internet. In contrast to application modeling, it is uncommon in current business layer modeling approaches to recognize the business interface concept."

ArchiMate 2.1 specification, (Chapter 3.2)

The business-centred variant

Now the same text, attempted for a different architectural style: the business-centred one, taking advantage from so-called active objects.

The active structure at the business core refers to the dynamic elements of an organisation. The dynamic, active entities in the model are related to entities in the "real" world usually regarded as passive business objects. The active entities in the real world, the subjects that perform behaviour such as business processes or functions (capabilities) are modelled as passive. These are the actors in the real world, such as individual persons (e.g., customers or employees), but also groups of people (organisation units) and resources that have a permanent (or at least long-term) status within the organisations. These are all modelled as passive objects. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on behaviour, which means that the inter-relationships of active entities in the model play an important role. These relations reflect the collaborative behaviour of these entities. Examples are accounts, products, invoices, contracts. This collaborative behaviour is modelled in Business Collaborations.

For architectural descriptions to remain intelligible this strategy pays of when our models scale. Behaviour is related to that active structure element in our model which in the "real" world is that which a subject operates upon or works with. Everything related to responsibilities of subjects in the "real" world is allocated in the model to the active structure elements. For example a carpenter works with wood to create a chair. In the model the chair works with a carpenter to create itself. All behaviour needed to make chairs is allocated to the chair by assigning the chair to this behaviour. This makes our models simpler. A chair can only make chairs. A car can only make cars. An insurance product can only make insurance products. And sell insurance products.

All active structure elements in our models must be requested to perform the behaviour they are assigned to. This request is directed towards their interface. The service may be offered on a number of different interfaces. These interfaces are actively employed by the users (clients) of those interfaces: other active structure elements.

Simplified ArchiMate

In fact the three "columns" of traditional ArchiMate are sometimes too convoluted even for "traditional" architects. We could very well do without the "passive" column, certainly for enterprise architecture. But extended models using the traditional approach often run against a wall for actors and roles performing more and more complex behaviour.

The approach above can do the trick. It is also called the Active-Passive Pattern.

… or any Enterprise Architecture framework.

As you may know TOGAF puts Requirements Management in the centre of its ADM method:

As one might expect, since this aspect of enterprise architecture is so prominently placed, it will be given a lot of attention in the TOGAF standard, right? Not so. The number of pages dedicated to this phase in the ADM in the 9.1 version of TOGAF is 8 pages.

There are an additional number of pages dedicated to Integration Requirements Management, one aspect of Requirements Management, and there is considerable attention for stakeholder analysis and the motivational model, which to a large extend translates into requirements of course. But many of my students in the TOGAF trainings I give are left with a lack of clarity and tooling to tackle this supposedly important phase.

The problem with requirements management is the meagre metamodel entities associated with it in the TOGAF metamodel:

• Requirement
• Assumption
• Constraint
• Gap

In ArchiMate this has (as yet, keep in mind the ArchiMate metamodel is working hard to get in line with TOGAF) not yet improved much. Remember in the ArchiMate 1.0 standard the word non-functional did not appear at all, so we are getting there.

SABSA Business Attribute Profile

hings are improving however. Some organisations have adopted the SABSA Business Attribute Profile. In fact, the Open Group has adopted SABSA not only for security architecture, but also for requirements management, thus introducing a robust and proven process to develop architectures on solid requirements, aligned with business capabilities.

The 6x6 matrix usually developed in the application of the SABSA framework looks a lot like Zachman:

Within this framework, the Business Attributes Profile plays an important role. It is the basis for requirements gathering.

In general, I have found similar lists of quality attributes useful enough (for example the ISO/IEC 25010:2011 standard, one which I have used extensively since 1997, especially while working on software in the medical sector). But there is also a risk associated: only experience (should I even say wisdom?) will tell you which attributes are important and how to implement them. This should be strongly stakeholder-driven, so an important quality for enterprise architects is to be able to explain these attributes to the relevant stakeholders and take their input to formulate your quality attributes in a SMART way.

After all, you want your architecture to be requirements-driven. Right?

Referentiearchitecturen zijn belangrijk voor bedrijven, zij bieden houvast. Toch blijven veel mogelijkheden onbenut. Het veelal hoge abstractieniveau, zeggen...

Source: www.automatiseringgids.nl (complete artikel alleen voor abonnees)

Mooi dat dit artikel een aantal belangrijke "pijnpunten" van referentiearchitecturen aanstipt.

Een aantal wil ik er graag uitlichten. Te beginnen met de herkenbaarheid door de "business" (niet voor niets tussen aanhalingstekens vermoed ik, maar een definitie van wat dat precies is wordt niet gegeven). Veel modellen kijken eenzijdig naar de organisatie (een bepaald perspectief), waarbij het vaak bij één perspectief blijft (bijv. processen) en het gekozen perspectief niet expliciet benoemd wordt. Hierdoor worden ook de tekortkomingen (aspecten van het domein die eenvoudig door het gekozen perspectief niet zichtbaar zijn) niet expliciet en dreigt het gevaar dat de indruk ontstaat dat deze niet relevant zijn. Een criterium voor een geslaagde referentiearchitectuur, of moet ik zeggen een geslaagde business referentiearchitectuur, is dat de betrokken personen uit de business (soms met enige hulp) in staat zijn hun rol te herkennen in de modellen.

Ten tweede de afbeelding van applicatielandschappen op de bedrijfsfuncties. Het lijkt mij dat hier een "probleem" wordt benoemd dat er niet is. Wat is er mis met bedrijfsfuncties die heterogeen afbeelden op applicaties? Als de relaties duidelijk zijn kunnen deze modellen toch zonder problemen gebruikt worden voor procurement?

Ten derde de suggestie, rampzalig in mijn optiek, bepaalde kritische applicaties onderdeel te laten zijn van de referentiearchitectuur. Ik merk in mijn werk als enterprise architect ook dat de "business" vaak denkt in termen van deze applicaties, maar ik voel het zelf als mijn opdracht hen daar van af te begeleiden en meer te gaan denken in de daadwerkelijke knelpunten en behoeftes en minder in oplossingen.

Ten vierde de suggestie, eveneens rampzalig in mijn optiek, metamodellen en architectuurtheorie over te slaan. Het is evident dat we daarin niet dóór moeten slaan (en dat te vaak doen) maar de theoretische omlijsting van de keuze voor een bepaalde architectuurstijl, bijvoorbeeld Distributed Objects, is onontbeerlijk om de consequenties van deze keuzes inzichtelijk te maken en de juiste afwegingen te kunnen maken.

Tenslotte zijn er een aantal suggesties in de punten die aangereikt worden om meer pragmatiek te realiseren waar ik het zeker mee eens kan zijn. Bijvoorbeeld de "algemene architectuurwaarheden". Misschien moeten we die maar eens op een algemene wiki zetten zodat we het er niet meer over hoeven te hebben ;-)

Een belangrijke vind ik ook het gebruik van perspectieven. Voor de communicatie is het zeker niet zo moeilijk als sommigen het doen voorkomen om visualisaties te maken die wél kloppen maar toch leesbaar zijn door leken.

"As an enterprise architect, you might be tempted to strive for a canonical data model for your systems’ interfaces. That’s not a good idea."

Source: www.innoq.com (STEFAN TILKOV March 24, 2015)

In mijn werk als lead enterprise architect heb ik bij LeasePlan het concept van het canonical datamodel geïntroduceerd, met name om verwarring rondom de betekenis van concepten te verminderen. De kunst is, zoals Stefan in dit artikel ook zegt, een minimale benadering te gebruiken. Het compleet definiëren van de complete structuur van alle data die in de communicatie tussen alle services heen en weer gaat is inderdaad een anti-pattern.

Het artikel is alleszins een all-out de grond inboren van het concept maar geeft veeleer aan dat voor je het weet het er insluipt dat je teveel centraal gaat definiëren. Stefan geeft ook aan dat (wanneer je een CDM wilt gebruiken) er een aantal randvoorwaarden zijn om dat succesvol te doen.

Een aspect dat Stefan niet noemt is de relatie tussen de (potentiële) omvang van een CDM en het ontwerp van de services. Mijn voorkeur voor micro-services in combinatie met een sterk business-centrische benadering (de services zijn business services, en de technische services zijn extreem versimpeld) leidt tot een interessante constatering dat deze ontwerpstrategie als neveneffect heeft dat de hoeveelheid data die over de lijn gaat ook extreem kleiner wordt. Er ontstaan enkele "aggregatie" services die misschien data vanuit verschillende services concateneren, maar er is weinig of geen incentive om deze data in zijn totaal te canonicaliseren, omdat de context van de verschillende datagebieden niet overlapt.

De minimale benadering heeft te maken met het feit dat in een landschap van los gekoppelde services, de services zélf het merendeel van "data" (ik spreek liever van persistentie) managen. Zij zijn er zelf voor verantwoordelijk. Alleen de data die aangeleverd moet worden door de vragende service, zodat een ontvangende service zijn werk goed kan doen (en hier wordt data informatie: het heeft betekenis in de context van een service interactie) behoeft centrale management.

Conclusie: goed service-ontwerp leidt tot minder data om centraal te managen. Is dit een stelling waarmee men het eens kan zijn? Ik ben benieuwd wat de ervaringen zijn van CDM in combinatie met microservices.

Ik heb de ArchiXL referentie-architectuur weer een flinke update gegeven - gratis beschikbaar! http://t.co/ZkOUBWMQ5F #entarch
De ArchiXL referentie-architectuur is een generieke architectuur die kan worden gebruikt bij het opstellen van specifieke architecturen voor organisaties. De architectuur is opgesteld op basis van kennis en ervaringen van consultants van ArchiXL en zal worden bijgesteld op basis van nieuwe inzichten. Hij wordt gratis beschikbaar gesteld zodat anderen kunnen bouwen op de kennis van ArchiXL en feedback kunnen leveren. De architectuur beschrijft de inrichting van de organisatie en informatievoorziening op verschillende lagen, waarbij de nadruk ligt op de generieke inrichting; dat wat van toepassing is op iedere organisatie. Het biedt zowel een set van architectuurprincipes (richtinggevende uitspraken) als een set van modellen.

Source: www.referentiearchitectuur.nl

Referentie architecturen zijn een leerzame input voor de implementatie van de bedrijfseigen architectuur. De referentie architectuur van ArchiXL heeft herkenbare relaties met domein-specifieke referentie architecturen zoals NORA, CORA, HORA en anderen, hetgeen geen verrassing is als we weten dat dezelfde mensen bij deze standaarden betrokken zijn geweest.

De ArchiXL referentie architectuur is nogal IT-centrisch. Er is summiere aandacht voor enkele bedrijfsfuncties en -objecten. Herkenbaar in de structuur is de centrale rol van Principes, een terechte nadruk want de organisatie-specifieke architecturen ontberen dit vaak, of als er al sprake is van Principes, worden deze gaandeweg de verdere uitbouw van de architectuur steeds minder prominent, herkenbaar en terug te vinden in de architectuurkeuzes.

Vanuit de bedrijfsfuncties en/of bedrijfsobjecten een heldere relatie leggen met de bedrijfsprocessen die ondersteund worden door systemen en/of mensen wordt niet duidelijk geïllustreerd in dit referentiemodel. Ook zien wij geen plaats ingeruimd voor Value Chain modellen (die daar bijvoorbeeld voor gebruikt kunnen worden).

Het informatiemodel heeft geen plek in dit referentiemodel. Ik kan mij voorstellen dat organisaties (en architecten) die ermee worstelen hoe dit model een plaats te geven in hun werk hierbij niet echt geholpen worden door dit referentiemodel, maar daar wel (al is het summier) iets verwachten.

Er is ook geen informatie te vinden over de relatie met (business-) services, en service-oriëntatie in het algemeen (SOA).

Maar goed, daar is het een referentie-architectuur voor. Gebruikers (d.w.z. architecten) zullen zich over het algemeen ervan bewust zijn dat dit soort referentie architecturen niet een compleet beeld kunnen geven van alle onderdelen die in de loop van de tijd nodig zijn om organisaties daadwerkelijk te helpen optimale synergie te bereiken.