Een serie posts over Schiphol IT-architectuur en over hoe wij, Schiphol IT-architecten, meehelpen Schiphol te verduurzamen. Geregeld zal ik hier artikelen, interviews en inzichten plaatsen over onze IT-architectuur en hoe deze doorwerkt in activiteiten van de luchthaven.

Eerst een stuk over mijn eigen specialiteit, de architectuur van het samenwerken van applicaties, ook wel integratie genoemd. Bij Schiphol gebruiken we de archimate als hulpmiddel voor deze architectuurmodellering. En voor het modelleren van integratiearchitectuur ontwikkelden we ook nog eens specifiek beleid. Van dit integratiebeleid laat ik je het centrale thema, dat draait om het concept van services, zien.

In het verleden heb ik een aantal keer geschreven over integratiearchitectuur en hoe je integratiearchitectuur kunt modelleren met behulp van archimate. Deze vorige posts vormen de basis voor het hierboven genoemde integratiebeleid én deze post.

In de loop der jaren ontwierp ik integraties vaak met behulp van MS-Viso of PowerPoint. Hieronder zie je één van de oudste en ook meest typische platen die ik kon terugvinden. Het is een subset van high-level weergaven van orderintegraties:

Deze visualisatie bevat twee integratiestromen die de applicatie "online ordermodule" bedient.

Deze integratievisualisatie wilde ik transformeren naar een archimatemodel. Hiermee toon ik dan aan dat Archimate geen Visio is. Tegelijkertijd kon ik je laten zien hoe wij bij Schiphol integraties modelleren met archimate. Maar terwijl ik aan deze transformatie werkte, werd ik gehinderd door een fout in onze modelleringsmethodiek. Gelukkig vond ik, terwijl ik iets met water deed (zie afbeelding 2), een perfecte oplossing die niet alleen het probleem oploste, maar dat ook nog eens prachtig en elegant deed.

En ik noemde de oplossing: de Integratie-Service-Hiërarchie.

Zelfs de oude manier hierboven om een integratie weer te geven, blijkt afhankelijk van een bepaalde hiërarchie. Als ik de CreateOrder-flow iets anders teken dan krijg je het volgende:

Nu groepeert de abstracte "orderservice" de integratie tussen OOM en OMS. De Order-Service bestaat op zijn beurt weer uit (is samengesteld uit) drie integratieservices. Hoewel we nu technische informatie over het onderliggende communicatieprotocol missen, kunnen we nog steeds begrijpen waaruit de orderservice bestaat. Het punt dat ik wil maken, dat je bij het gebruik van Archimate anders moet denken. Je moet de neiging weerstaan om alleen aan stromen tussen artefacten te denken en alleen deze te tekenen.
Het lijkt mij beter om eerst na te denken over de aard van de relaties die je moet weergeven.

In dit stuk zal ik:

1. Je de Integratie-Service-Hiërarchie laten zien

2. Uitleggen wat elke service in deze hiërarchie doet

3. Waarom elke service in deze hiërarchie op zijn positie staat

4. Hoe de hiërarchie past in een e2e-integratie

5. Waarvoor je deze hiërarchie kunt gebruiken

Maar voordat we ingaan op de Integratie-Service-Hiërarchie, moeten we eerst kijken naar hoe we integraties in het applicatielandschap (collaboration view) modelleren. Voorheen tekenden we hier bij Schiphol per integratie, alleen de (gegevens)stromen tussen applicaties. Maar we wilden meer informatie over integraties kunnen modelleren dus besloten we om aan elke flow een applicatie-service te koppelen. Dit maakte het mogelijk om nette applicatielandschappen te tekenen enerzijds en daarnaast ook integraties te kunnen groeperen en daarmee te zoeken/vinden en fijnmaziger te modelleren.

Het gaat dus om de relatie tussen de flow van het Employee Data-object tussen de twee getoonde applicaties en de "Integrating Employee" integratieservice in bovenstaande afbeelding. Deze koppelings-relatie kan je én een “schone” collaboration-view he

De relatie tussen de "Integrating Employee" integratieservice in bovenstaande afbeelding en de specifieke stroom van het Employee Data-object tussen de twee getoonde applicaties maakt het dus mogelijk om collaboration views te koppelen

En het is deze "Integrating Employee"-applicatieservice die ook bovenaan de Integratie-Service-Hiërarchie staat.

De hiërarchie van integratie kan worden gezien als een soort piramide. Bovenaan, verlicht het oog van de piramide de specifieke integratieservice(1). Ook bij problemen met een bepaalde integratie staat deze specifieke integratieservice in de schijnwerpers.

Direct onder het oog staan de integratieservices die de samenwerking orkestreren.

En aan de basis van de servicespiramide staan de integratieservices die het echte werk doen. Alleen aan deze koppelen we één of meer realiserende functies.

In mijn volgende post rond ik eindelijk de transformatie van Visio naar archimate af. Dan laat ik ook alle voordelen van een compleet integratieoplossingsontwerp in archimate zien. Maar om je een alvast een blik te gunnen op het eindresultaat; de Integratie-Service-Hiërarchie moet passen tussen de integrerende applicaties, de bij de integratie betrokken applicatiefuncties en de bijbehorende Data-Objecten.

Gebruik alleen de benodigde services van de Integratie-Service-Hiërarchie hoeven. Dus sommige (4 en/of 8) kan je weglaten en sommige (2&3 en/of 6&7) kan je combineren tot één:

Zoals je in het bovenstaande voorbeeld kunt zien, bevat deze Integratie-Service-Hiërarchie niet alle services (1 tot en met 9), maar alleen de services vereist voor deze specifieke architectuur. Modeleer alleen services die informatie bieden voor verdere implementatie en operationeel gebruik of architectuurwijziging.

Bijvoorbeeld, met de Exposing Integration Service (9) laat je zien dat het om een loosly-couped integratie gaat. De realiserende functie eronder toont het integratiepatroon (db, bestand, bericht, gebeurtenis, api) en de assigned applicatie toont welk specifiek integratieplatform we hiervoor gebruiken.

Voor operationeel gebruik; Bij een probleem is met een bepaalde integratie, biedt deze weergave een startpunt tijdens incidenttoewijzing. Je kunt duidelijk zien dat op dit toepassingsniveau drie (en niet één!) partijen verantwoordelijk zijn voor het operationele welzijn van een integratie. Je kunt dus beginnen met contact opnemen met de verantwoordelijke partijen voor service 6, 8 en 2 en informeren (niet toewijzen) over het probleem.

Voor architectuurwijziging, wanneer je bijvoorbeeld de providerapplicatie vervangt, geeft deze weergave de specifieke providing integratieservice(6) die behouden moet blijven. Was je consistent bij het beheren van de leverende integraties, dan kan je gemakkelijk een tabel maken met te migreren integraties en hun specificaties.