Architectuur

Niet alleen Safwan vindt de taarten van Anneke erg lekker. Ook buurman Frans en de oude meneer Roos lusten ze graag. "Hier zit business in", denkt Anneke. Ze trekt de stoute schoenen aan en begint een eigen banketbakkerij: The Bakery Group.

Uiteraard is er nog van alles nodig. Eerst aanmelden bij de kamer van koophandel. Dan een pand met werkruimte, spatels en pannen, ingrediënten enzovoorts. Anneke komt er als snel achter dat dit andere koek is. Er moet een assortiment vast worden gesteld. Er moeten grotere hoeveelheden op tijd klaar zijn. De hulp die ze heeft ingehuurd moet worden instrueert.

Ze besluit om eens planmatig te werk te gaan om de vaste kwaliteit voor haar bestaande fans te kunnen bieden. Ook wil ze nieuwe klanten trekken. Kortom het inrichten van de banketbakkerij en het vaststellen van de processen. Langzaamaan ontstaat er een succesvolle bakkerij met een professionele werkwijze.

De fabriek

Nog steeds is de output "taarten", maar nu niet één voor de buurman, maar duizenden. Voordat ze van de lopende band rollen, dient er eerst een fabriek te zijn. Er moet een stuk grond gekocht worden, er zal met een architect gepraat worden over het gebouw en de indeling van de fabriekshal, de machines die de taarten produceren, een docking platform van vrachtwagen en een kantoor. Daarnaast wil Anneke een relaxruimte en een kantine met gezond eten. Het kan niet elke dag feest zijn.

Een grote droom, een grote investering. Zowel Anneke als de architect die ze heeft ingehuurd willen een optimaal resultaat. Maar het budget en de uiteindelijke efficiëntie mag niet uit het oog worden verloren. De rol van architect is de wensen van de klant, de bouwers en de materialen bij elkaar te brengen. De orde van architecten geeft:

"In de praktijk is de rol van de architect niet beperkt tot het opmaken van plannen, nodig voor het aanvragen van de vergunning, en het controleren van de uitgevoerde werken. Ze omvat ook de praktische begeleiding doorheen het bouwproces op basis van de specifiek overeengekomen architectenopdracht.

De architect is uw vertrouwenspersoon die uw wensen omzet in werkelijkheid. Hij staat u bij in de keuze van bouwmaterialen en kan u helpen bij het opvragen en vergelijken van offertes, daarbij rekening houdend met de vakbekwaamheid en referenties van de uitvoerders en uw financiële slagkracht."

Grote data integratie projecten hebben dezelfde voorwaarden om succesvol te zijn. Hiervoor zijn requirements, projecten en architectuur van belang. Je kunt namelijk integratie software componenten kopen, maar dit garandeert nog niet dat het voldoet aan de eisen en wensen van de klant. Als deze zaken niet op orde zijn, eerder het tegenovergestelde...

Een integratiearchitect is verantwoordelijk voor de integratielaag. Deze laag bestaat enerzijds uit het integratieplatform (de fabriek), als de integraties (de lopende band die integraties opleveren). Voor laatste worden soms ook solutionarchitecten die zich richten op het verwezenlijke van de specifieke oplossing. De integratiearchitect werkt hierbij nauw samen met de entprise architect die organisatiebreed kijkt.

De basismaterialen waarover een integratiearchitect beschikt zijn de softwarecomponent, zoals brokers en ESB, beschreven in hoofdstuk 3. Op dit niveau spreek we nog of tools en frameworks. Zodra deze tools en frameworks op elkaar zijn afgestemd en geinstalleerd dan spreken we over een integratieplatform de fabriek staat.

Requirements

De allereerst stap die een integratie doorloopt is de eisen en wensen van de organisatie in kaart te brengen. In dit kader spreken ook wel van business requirments. Soms wordt hier de hulp ingeroepen van een 'objectieve' derde partij die leveranciers- en technologie onafhankelijk advies geeft. Bij integratie onderscheidt men meestal tussen de implementatie van integratie software (het platform) en data integraties gebouwd bovenop dit platform. Belangrijk bij beide is de verwachtingen van de klant helder krijgen. Handig is het om met checklist te werken. Hierdoor wordt niet alleen niets vergeten, maar geeft het ook inzicht in de complexiteit.

Voorbeeld Checklist implementatie

Huidige situatie:

• Welke informatiestromen zijn er nu tussen de verschillende systemen (diagram?)
  • Is er een diagram van de infrastructuur en netwerk?
  • Welke aanbevelingen zijn er met betrekking tot het netwerk / infrastructuur?
  • Welke informatiestromen zijn gewenst (bijvoorbeeld masterdata / studenten registratie)?
  • Is er documentatie beschikbaar?
  • Welke software wordt er nu gebruikt.
• Architectuur richtlijnen
  • Stijl (EAI/SOA/Microservices)
  • Push/pull
  • Batch/Scheduled of Event-Driven/Real-time
  • Synchrone of asynchrone communicatie
  • Standaard van gebruikte protocollen
  • Standaard voor gebruikte data formaat
  • Canoniek datamodel
• Bedrijfsprocessen
  • Welke processen zijn er?
  • Hoe zijn / kunnen deze worden geautomatiseerd?
  • Welke inzichten zijn gewenst met betrekking tot tracking / tracing?
• Integratie omgeving
  • Koppelingen
  • Analyse van het aantal / complexiteit
  • Type transformaties
  • Technische implementatie en verbeteringen (eventueel introductie van een Canonical formaat)
  • Toekomstige koppelingen
• Technische Kennis
  • Welke kennis is aanwezig?
  • Welke kennis is gewenst?
  • Hoe ziet de invulling van begeleiding er uit
  • Voorstel voor kennis verbetering

Nieuwe situatie:

• Wat is je rol/verantwoordelijkheid van het systeem (wat versta je onder integratie)?

  • Hoe moet deze data worden beveiligd of worden geautoriseerd?
  • Hoe wordt er met beveiliging omgegaan?
  • Welke security mogelijkheden biedt het systeem?
  • Hoe gevoelig is het systeem?
  • Hoe kan worden omgegaan met autorisaties en wijzigingen hierop?
  • Kan er een vorm van single-sign on worden gebruikt?

• Is het wenselijk een BI / Datawarehouse systeem te hebben, hoe moet dit worden ontsloten

• Wat zijn de aantal berichten nu en toekomst

• Welke hardware/Cloud?

• Wat zijn de specificaties van het systeem?

  • Hardware
  • Software
  • OTAP
  • Availability

• Performance eisen (real time/near real time)

  • Exception handling / logging
  • Monitoring / beheer
  • Testing
  • Continuous Delivery (Release/Deployment)

• Wat is de gewenste situatie/roadmap voor de implementatie?

• Wat is het verwacht eindproduct vanuit de business/klant?  

Checklist data integratie

Bij integraties is het handig het volgende in het achterhoofd te houden:

• Data staat centraal en niet applicaties.
• Er zijn minstens 2 partijen betrokken.

Om een data interface goed te implementeren is vaak handig een checklist te gebruik voor de versturende (producer) en ontvangende (consumer) van de data:

Producer

• Zijn er één of meerdere systemen die bron van data zijn (de producers)
• Hoe heet het systeem? (applicatie, datawarehouse, server, url)
• Wat is de functie van het systeem?
• Wie is het contact persoon voor de bron (naam, email, telefoonnummer)?
• Waar komt de data vandaan?
  • Stuurt de producer deze actief op (push) of dient het opgehaald te worden (pull)?
  • Dient er toegang te worden verleend?
• Welke protocol wordt voor integratie gebruikt (HTTP, FTP)?
• Wat voor data format wordt gebruikt (CSV, XML)
• Is er een validatie schema voor het data format?

Consumer

• Zijn er één of meerdere systemen die doel van data zijn (de producers)
• Hoe heet het systeem? (applicatie, datawarehouse, server, url)
• Wat is de functie van het systeem?
• Wie is het contact persoon voor de doel (naam, email, telefoonnummer)?
• Waar komt de data vandaan/gaat het naartoe?
  • Stuurt de producer deze actief op (push) of dient het opgehaald te worden (pull)
  • Dient er toegang te worden verleend?
• Welke protocol wordt voor integratie gebruikt (HTTP, FTP)?
• Wat voor data format wordt gebruikt (CSV, XML)
• Is er een validatie schema voor het data format?

Design

Op basis van de requirement vanuit de checklist kan er een ontwerp van de data interface gemaakt worden. Een goed design volgt een aantal vaste elementen, zodat het ontwerp tegelijkertijd de documentatie vormt. In basis staat hier een bericht centraal.

1. Bericht: Functionele beschrijving van het bericht
2. Producer: Beschrijving van de producers en protocollen die zij gebruiken. Connectiviteit van één of meerdere bronapplicatie.
3. Proces: De processtappen voor de verwerking van het bericht. Daarnaast ook wel software modules/containers/groepen de verwerking doorvoeren.
4. Consumer: Beschrijving van de doelapplicaties (consumers) en de protocollen die ze gebruiken.

Sommige gebruik tekst of een spreadsheet, andere gebruiken diagrammen voor het ontwerp.

Architectuur

"The world is (more and more) connected." is een uitdrukking die tegenwoordig vaak voorbij komt. De vragen "hoe deze wereld verbonden is" en "hoe om te gaan met steeds meer verbindingen", zijn architectuur vragen. Er zijn verschillende stijlen ontwikkelt als antwoord op deze vragen. Voordat we overgaan op de verschillende architectuurstijlen gaan we eerst terug in de tijd.

Gegevensoverdracht heeft al vroeg in de ontwikkeling van computers plaatsgevonden. Al in het begin van de jaren 60 onderzochten wetenschappers manier om computers met elkaar te laten communiceren. Het meest in het oogspringende project was ARPANET, waar het internet met email (1971) en FTP (1973) uit zijn voortgekomen. De ontwikkelingen richtten zich echter nog erg op netwerken. Andere ontwikkelingen waren opkomst besturingssystemen (Unix, DoS, OS400), databases (Oracle) en programmeertalen.

Monolithisch

De technologieën die in de jaren 60/70 ontwikkelt werden, vormden de basis voor het bouwen van mainframe applicaties. Veelal op basis van een monolithische architectuur. Dat wil zeggen dat alle functionaliteit in één geheel wordt geïmplementeerd. Dit kon ook vaak niet anders. Er waren nog geen standaardapplicaties beschikbaar of containers, dus bouwden bedrijven alles in één grote mainframeapplicatie. Data werd vaak via een command line user interface dan wel via data import/export voor zien.

In de jaren negentig begonnen op bepaalde gebieden standaardapplicaties te ontstaan. Zo kochten bedrijven steeds meer externe applicaties. Niet alleen meer applicaties, maar ook meerdere protocollen en programmeertalen doken op. Met behulp van database links, scripting en adapters werden de meeste applicaties rechtstreeks aan elkaar gekoppeld. Deze vormden een brug tussen de applicaties.

Monolithische architectuur wil zoveel dat zoveel mogelijk componenten bij elkaar worden geplaatst. Zolang er één code base is dit een uniforme wijze om je functionaliteit te bundelen. Zoals in het voorbeeld zie je dat het als snel meerdere monolithische applicaties zijn die data via direct koppelingen met elkaar uitwisselen.

EAI

Met steeds meer applicaties ontstaat er een applicatielandschap. Voor organisaties is het van belang dat de verschillende applicaties in het landschap als één geheel werken. Hierin zie je een belangrijke stap naar data integratie. Data die niet door rechtstreekse bruggen, maar door transport en infrastructurele componenten met elkaar wordt verbonden. Zoals er veel verkeersmiddelen (boot, vliegtuig, auto, vrachtwagen) en infrastructuur (wegen, spoorlijnen, vliegvelden) zo ontstonden er ook voor data integratie concepten en oplossingen.

EAI (Enterprise application integration) is een concept waarbij point-to-point koppelingen vervangen worden door middleware. Allereerst beperk je daarmee het aantal mogelijke koppelingen:

If integration is applied without following a structured EAI approach, point-to-point connections grow across an organization. Dependencies are added on an impromptu basis, resulting in a complex structure that is difficult to maintain. This is commonly referred to as spaghetti, an allusion to the programming equivalent of spaghetti code. For example:

The number of connections needed to have fully meshed point-to-point connections, with n points, is given by ( n 2 ) = n ( n − 1 ) 2 {\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}} {\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}} (see binomial coefficient). Thus, for ten applications to be fully integrated point-to-point, 10 × 9 2 = 45 {\displaystyle {\tfrac {10\times 9}{2}}=45} {\displaystyle {\tfrac {10\times 9}{2}}=45} point-to-point connections are needed.

EAI zorgt dat iedere applicatie van de juiste data wordt voorzien. De data is zo consistent en er hoeft niet telkens een aparte interface wordt opgesteld. Door middleware is het duidelijk hoe de data loopt. Toch is implementatie lastig omdat je centrale project management en coördinatie van alle data integratie moet doen. Ook leidt deze stijl tot het rondsturen van veel kopieën van je data.

SOA

Na het jaar 2000 zie je een steeds verder gaande opsplitsing van applicaties in services (webservices/microservices), tot zelfs modules die slechts één functionaliteit of business rule uitvoeren. De reden hierachter is simpel, de mainframe en later grote standaard ERP applicaties zijn lastig te onderhouden en te wijzigingen. Door kleinere modules kunnen IT en de organisatie makkelijker evalueren. Daarbij moet specifieke functionaliteit kunnen wijzigen. De interfaces dienen overzichtelijk, herbruikbaar en schaalbaar zijn.

In de architectuurstijl SOA, service-orientated architecture, draait zoals de naam als zegt alles om services. Services, zijn software modules, die zoveel mogelijk onafhankelijk en los staan andere software. Omdat ze meestal beschikbaar zijn via netwerken, zoals internet, spreekt men meestal over web services. Elke web service heeft een definitie van de data interface hoe deze moet worden aangeroepen. In tegenstelling tot EAI gaat het niet om het synchroniseren van data, maar meer om het opvragen en verwerken van data.

Vaak zijn de uitleggen over SOA nogal technisch. Laten we daarom van ons analogie met de banketbakkerij uitgaan:

Anneke heeft verschillende banketbakkers in dienst. In SOA, ga je er van dat die bakkers niet collegiaal zijn. Anneke laat ze daarom alleen het hoog nodige communiceren en geeft elke banketbakker een eigen rol. Eén bakker maakt het deeg, één bakker maakt het beslag, één bakker maakt taarten en de laatste maakt de versiering. Anneke geeft tegen de deegmaker aan dat hij deeg moet maken en ergens neer zetten, de beslag maker doet dit ook. De taartmaker neemt dit als input voor de taart en zet deze ergens neer. De laatste bakker krijgt de hele taart en versiert deze alvorens deze in de vitrine te leggen.

In het voorbeeld zie je dat de elke banketbakker zijn eigen taak heeft met een duidelijke procedure waar het de input vandaan haalt en de output moet neerzetten. Een service in SOA werkt op dezelfde wijze. Het is een op zich zelf staande module met een duidelijke ingaande en uitgaande interface. Voordeel van het concept is dat je service kan herbruiken. Net als je het deeg ook kan herbruiken voor gebak of cake bijvoorbeeld. Je hoeft alleen te weten waar de deeg staat.

Om de service te implementeren en te managen wordt vaak een ESB laag gemaakt waar de services kunnen communiceren en op elkaar afgestemd worden. Amazon AWS (Amazon Web Services) zijn een bekende implementatie van dit principe. Toch zijn er ook veel implementaties mislukt, omdat niet het hele applicatielandschap hier op aan sloot en het beheren van veel services snel complex werden.

Microservices

Microservices borduurt voort op de SOA architectuurstijl. Het maakt daarbij expliciet niet gebruik van een ESB laag, maar gaat uit van standaard netwerkprotocollen (HTTP) die door middel van (REST) API met elkaar communiceren. De onderliggende technologie (programmeertaal/database) is gericht op de functie van de applicatie, technologietrends en kennis en wensen van het implementatieteam. Om de API's te beheren wordt vaak van een gateway of management tooling gebruik gemaakt.

Elke microservice heeft 1 of enkele business functies. Doel is net als bij SOA dat deze module onderhoudbaar en testbaar is. Elke module kan (meestal in een container) zelfstandig deployed worden. Veelal is de nieuwe microservice daarna via een service registry beschikbaar voor gebruik.

Doordat elke microservices beperkte business functionaliteit bevat, zijn er al snel veel microservices nodig. De deployment, versiebeheer en registratie van nieuwe en gewijzigde services alsmede afhankelijkheden tussen services kan hierom zeer complex worden.

Andere architectuurstijlen

• Remote calls Server-clients waarbij applicaties elkaar veelal zonder middleware elkaars functies, procedures of objecten aanroepen.
• RPC (Remote Procedure Calls). Aanroep van procedures.
• CORBA (Common Object Request Broker Architecture). Een standaard voor data integratie tussen gedistribueerde systemen. De client roept hier objecten aan bij een remote server (in plaats van procedures). De CORBA standaard is gedefinieerd door OMG.
• MFT (Managed File Transfer): Managed File Transfer: Het overzetten (transfer) en synchroniseren van databestanden. Richt zich met name op veiligheid en betrouwbaar, als grote volumes. Vaak zijn applicaties zelf voor import/export.
• SCS (Self Contained Systems): Een architectstijl met de nadruk op Seperate-of-Concerns. Hierbij zijn alle systemen in het landschap op zich staande webapplicaties die logica, data en UI bevatten, maar niet delen met andere webapplicaties. De datauitwisseling gebeurd zoveel mogelijk asynchroon.
• EDA (Event Driven Architecture) Architectuur stijl die uitgaat van events (gebeurtenissen). An event-driven system gaat uit van event emitters (ook wel agents), event consumers (ook wel sinks) en event channels. Emitters/Agents detecteren een gebeurtenis (een toestand veranderd) en verzamelen de juiste data. De event consumer krijgt het resultaat en moet eventueel een reactie op de input geven. De event channels zorgen voor de interface tussen emitter en consumer.
• Reactive: Event-Driven Stijl die van responsieve applicaties uit gaat. Als er een wijzing in een applicatie is dan start er een dataflow. Deze dataflow kan weer een andere starten. Alle dataflows (ook wel event streams) verwerken data asynchroon. Reactive manifest

De praktijk

Zelden wordt een applicatielandschap opgebouwd vanuit een leeg blad. Veelal is het ongeveer zo gegaan: In de jaren 70 en 80 werden eerst de administratieve en primaire processen geautomatiseerd. Er was nog geen standaard software voorhanden, dus werden er op mainframes grote monolithen ontwikkelt. In de jaren negentig kwamen er standaardapplicaties op de markt. Applicaties werden een 'commodity'. Het werd dus goedkoper om deze applicaties aan te schaffen als aanvulling op het centrale maatwerk systeem. Tussen de systemen werden rechtstreekse koppelingen gemaakt, vervolgens werd er steeds meer gespecialiseerde middleware producten aangeschaft. Met behulp van de middleware werden de databases van de applicaties gesynchroniseerd (EAI).

Rond 2005 begonnen bedrijven met het loskoppelen van applicaties met behulp van ESB in een SOA stijl. Door snellere veranderingen in de markt en het centraal stellen van het internet zijn ze ten slotte API’s op basis van microservices in gaan zetten. Het totale applicatielandschap bevat ten slotte verschillende architectuurstijlen met verschillende type applicaties in het landschap.

Hoe het applicatie landschap er precies uit ziet, is grofweg afhankelijk van:

1. Het aantal jaren dat een bedrijf ontstaat
2. De grote van het bedrijf
3. De complexiteit van de processen
4. De snelheid van de veranderingen in de markt
5. De architectuurfunctie

Het kan goed zijn dat een startup die net is ontstaan alleen gebruik maakt van Microservices zonder enige vorm van middleware. Het bedrijf is te klein en de processen te eenvoudig. Vaak speelt architectuur hier nog geen grote rol. Zodra het bedrijf groeit zullen er meer applicaties bij komen. De huidige applicaties worden verbouwd en aangevuld met standaardapplicaties en nieuwe technieken. Net als het bedrijf, gaat ook IT mee in nieuwe trends in hypes. Soms omdat het nieuwe beter is, soms omdat het oude niet meer te onderhouden is (technical debt). Zie bijvoorbeeld het volgende verhaal vanuit 15 jaar ervaring met software.

Dat is de praktijk: een mix tussen verschillende architectuurstijlen. De oorzaak is dat steeds een andere stijl geïmplementeerd is, verschillende technologieën en use cases. De praktijk is dan een combinatie tussen architectuurstijlen, on premisse/cloud, push/pull, synchroon/asynchoon enzovoorts.

Veelal zie je dat bepaalde architectuurstijlen worden geassocieerd met bepaalde data formaten, technologieën en protocollen. In onderstaande overzicht zie je de architectuurstijlen waarmee ze geassocieerd worden:

	Monolithic	EAI	SOA	Microservices
Time period	Until mid 90’s	Until 2005	Until 2015	Until now
Data format	ASCII/CSV	CSV/XML	XML	JSON
Middleware	Adapter	Broker	ESB	API gateway
Protocol	FTP	JMS	SOAP	REST
Version control	None	CVS	SVN	GIT
Runtime	Mainframe	Server	VM	Docker

Het is echter goed om de techniek van de architectuurstijl te scheiden. Ook op een mainframe kunnen microservices draaien en een monolith kan gemaakt worden met REST API’s draaiend in een Docker container. In de praktijk zie je dat deze associaties verwarrend werken met name om dat er in de organisatie verschillende stijlen en technieken door elkaar heen worden gebruikt. Soms is dit alleen bekend bij architecten, maar zijn veel andere in de organisatie hier onbewust van.

Belangrijkste is de architectuurstijlen en technieken optimaal in te zetten voor de organisatiedoeleinden. Doordat deze steeds sneller wisselen, is er een tendens naar architectuurstijlen die expliciet rekening houden met meeevalueren van het applicatielandschap met de business. Welke stijl er ook wordt gekozen, het is altijd een uitdaging om complexiteit te implementeren in het geheel en het overzicht te bewaren.

De roadmap

Met behulp van de software componenten, eisen en wensen en architectuurstijlen kan een schets van het inegratieplatform worden gemaakt. Dit is dus als ware de schets van de fabriek. De roadmap is de weg naar die fabriek toe. Het kan best zijn dat die weg lang is, d.w.z. delen van de fabriek moeten al operationeel zijn, terwijl andere delen later toegevoegd. Bij de Backery Groep richten ze zich bijvoorbeeld eerst op standaardtaarten, zoals appel- en slagroomtaarten. Later moet ook vlaaien, gebaks en bruidstaarten mogelijk zijn.

Zo kan bij integratie zich eerst richten op integraties met legacy systemen en later met API's. Gaan we eerst voor een ESB of voor een iPaas? Als de verschillende bouwstenen en welke eerst gelegd wordt bekend zijn dan gestart worden met de verwerving van deze bouwstenen. Meestal bouwen deze voor op de andere. Je bouwt eerst een deel van de fabriek, leert hier van een gaat door. Uiteraard is één van de voordelen van software bouwstenen dat deze flexibeler zijn. Een nadeel is wel dat soms niet helder is hoeveel werk de implementatie kost en wat het oplevert.

Het is dus aan de hand van de grote van de fabriek voor mensen helder. Een werkplaats voor het maken van accu's voor de aftermarket is eenvoudiger dan een Gigafactory voor duizenden Tesla's. Dit is soms onduidelijk bij software. De roadmap, de detailtekeningen en milestones voor het opleveren van het integratieplatform zijn belangrijk om met de gebruikersorganisatie en andere stakeholders regelmatig te bespreken.

De laatste fase is nog op de requirements van de specifieke bouwsteen. Daarna kan de selectie en verwerving (eventueel via een aanbesteding) plaatsvinden. Dit dient zorgvuldig te gebeuren, omdat deze producten rustig meer dan 10 jaar geberuikt worden. Hulp van derde partijen bij de selectie en ook het uitvoeren van een Proof-Of-Concept met de top 2/3 producten is voor grote organisaties vaak wenselijk.

Governance

De klant en aannemer willen uiteraard op toe zien dat de fabriek en het produceren in de fabriek aan de verwachtingen voldoet. Hier is een stuk governance voor nodig. Bij integratie gaat het om de volgende drie zaken:

1. Principes

Architectuurprincipes zijn richtinggevende uitspraken die aangeven wat wenselijk is. Een architectuurprincipe kan worden gezien als een beleidsuitspraak die specifiek betrekking heeft op de inrichting van organisatie, processen en informatievoorziening. Bij integratie is het bijvoorbeeld vaak een principe van open standaarden (denk aan HTTP of OpenAPI) gebruik te maken. Een andere bekend princip is de van "ontkoppeling". Applicaties worden niet op elkaar aangepast (tightly-coupled), maar maken gebruik van berichten en middleware voor uitwisseling van gegevens.

Een bekende lijst met zijn de NORA principes (https://www.noraonline.nl/wiki/Principes). Dit zijn principes van de overheid voor referentiearchitectuur. Ook buiten de overheid wordt vaak hier van gebruik gemaakt.

2. Richtlijnen

Aan de hand van richtlijnen (in het Engels meestal guidelines) wordt de implementatie gestuurd. Het zorgt dat je een vaste kwaliteit uitdraagt en ook bewust van bent als je hiervan afwijkt. In de bouw is bijvoorbeeld de richtlijn om de bouwstenen verzet neer te leggen, alle muren zijn dan niet alleen stevig, ze zien er ook hetzelfde uit.

Richtlijnen bij integraties richten zich vaak op vragen als:

1. Welke patterns horen op de integratielaag en welke niet? Bijvoorbeeld routing is onderdeel van de integratielaag, maar berekeningen niet.
2. Wat is de naamgeving van integraties?
3. Wat zijn de richtlijnen voor security?
4. Wat zijn de richtlijnen voor protocollen?
5. Wat zijn de richtlijnen voor data formats?

Een richtlijn bij integratie kan bijvoorbeeld zijn "API-first", dat wil zeggen je bij een nieuwe applicatie over verwerving prefereer je deze manier van integreren boven bij FTP. Goede richtlijnen zorgen er voor dat vragen beantwoord, kunnen worden met behulp van een beslisboom. In de praktijk zie je bij integraties vaak een druk op de richtlijnen, omdat van integratie wordt verwacht dat zij de "lijm" in de organisatie vormen. Het actief naleven van richtlijnen levert echt veel voordelen bij de schaalbaar- en onderhoudbaarheid van de omgeving.

3. Standaarden

Een standaard is een set van regels die beschrijven hoe mensen materialen, producten, diensten, technologieën, taken, processen en systemen dienen te ontwikkelen en beheren. In sommige gevallen zijn deze verplicht. Bijvoorbeeld als de uitwisseling volgens een specifiek EDI-standaard moet lopen of de authenticatie via OAuth of SAML. Als het niet volgens deze standaarden loopt dan mag het niet geïmplementeerd worden. In andere geval kan een bepaalde standaard alleen een richtlijnen zijn. Bijvoorbeeld dat Json/XML geprefereerd wordt boven ASCII en CSV. Ook hier geldt vaak dat buiten security er wordt verwacht dat de integratielaag relatief flexibel om gaat met verschillende standaarden.

Fases

Een integratie omgeving opbouwen gaat grofweg in drie fases. Daarin worden telkens dezelfde stappen doorlopen.

Implementatiefase

De implementatiefase kenmerkt zich door introductie, vervanging of vernieuwing van het integratieplatform. Integratieplatformen ondersteunen meestal meerdere architectuurstijlen. De eerste stap is vaak te bepalen welke architectuurstijl je kiest. Vaak zie je later dat er meerdere door elkaar lopen, maar dat zou zeker niet het uitgangspunt moeten te zijn. Uiteraard is dit een requirement die aanbod komt bij de aanschaf bij het integratieplatform.

De tweede stap is inrichting van het platform. Bij cloud (iPaas) is deze stap al gedaan, maar bij on premisse zal het systeem geïnstalleerd en geconfigureerd moeten worden. In deze stap ben je nog niet met de daadwerkelijke integratie bezig, maar met de fundamenten om data interfaces te draaien. Je kan het vergelijken met een metrotunnel. Eerst moet de tunnel er zelf komen. De tunnel moet geboord worden en de wanden moeten gestut worden.

In de volgende fase ga je de daadwerkelijke rails leggen waar de metro over gaat rijden. In deze fase gaat het om de data die je over het platform laten lopen. Als je de data berichten heb vastgesteld die bij de implementatie van belang zijn, ga je ontwerp per data bericht maken. Elk data bericht is een aparte metrolijn. Elk station zou je als een aparte stap kunnen beschouwen die kunnen technische stap of een functionele stap zijn. Als alle stappen en wat in de stappen gebeurd compleet zijn dan is het ontwerp van de data interface af.

Het hangt er een beetje van de werkwijze af, maar je kan het ontwerp van alle data interfaces van te voren vastleggen. Meestal wordt tegenwoordig een meer agile benadering gekozen, waarbij eerst een eenvoudig interface wordt opgezet, het ontwerp wordt aangepast en er steeds weer een schakel aan toe wordt gevoegd.

Je komt nu in de bouwfase. Hoe te bouwen is sterk afhankelijk van het integratieplatform. Het ene platform levert grafische tools, andere gaan van programmeren uit. Zodra het platform opgebouwd is zal in de testfase eerst gekeken worden of berichten van A naar B komen. Dit noemen we unit of technische testen. Vervolgens zal end-to-end ketentesten gedaan worden, waarbij gekeken wordt of de data gebruikt kan worden als informatie door de business. In sommige gevallen is er nog acceptatiefase door de eindgebruikers. De laatste fase is die van in productiename. Alle stappen van de OTAP-straat zijn doorlopen.

Uitbreidingsfase

De uitbreidingsfase bouwt de interfaces op het platform verder uit. Net als een extra aftakking naar een andere wijk of een nieuw metrostation, komt er een aftakking naar een nieuw aangeschaft systeem. Zolang het applicatielandschap evalueert, evalueert het integratie platform mee. Dit kunnen nieuwe applicaties of data berichten zijn.

Bij elke uitbreiding zullen dezelfde stappen worden doorlopen. Dus ook bij een aanpassing aan een bestaande interface wordt er ontworpen, gebouwd, getest, geaccepteerd en in productie genomen. En net als in metrosysteem, vormen aanpassingen in een productieomgeving meer voorzichtigheid. Vaak ligt een metrosysteem in de nacht nog stil, maar integratiesysteem verwerken doorgaans 24/7 data.

Uitfaseringsfase

De laatste fase is als het integratieplatform niet meer gebruikt wordt. Het kan zijn dat er nieuwe integratiecomponenten worden ingezet, een nieuwe architectuurstijl of een ander platform. Vaak zie dat er per databericht over wordt geschakeld.

next