7. Architectuur

Verschillende architectuurstijlen op een rij

Het is inmiddels ronduit bekend dat niet alleen Thomas de taarten van Aleksandra erg lekker vindt. Er zijn een hoop andere afnemers. Aleksandra is blij dat ze nu volledig zelfstandig is en op niemand meer een beroep hoeft te doen. Sterker nog: ze heeft al een aantal medewerkers in dienst. Sommige ook uit Oekraïne, andere gewoon uit de regio. Één heeft zelfs een bakkerijtje in Amsterdam geopend dat vanuit Zaandam beleverd wordt.

Het wordt tijd voor de volgende stap. Aleksandra’s Bakery wordt omgedoopt tot The Bakery Group:

Nu is een logo maken best leuk, maar er moet nog veel meer gebeuren. Inmiddels zijn er al behoorlijk wat systemen. Ze gebruikt AFAS voor de resource planning en financiën, ze heeft een relatiebeheersysteem, een website en een cloud-applicatie voor de recepten. Systemen die moeten meegroeien met de grootte van de bakkerij. En al die systemen moeten ook nog eens goed met elkaar en met de systemen van de leveranciers geïntegreerd worden.

Langzaamaan ontstaat er een succesvolle bakkerij met een professionele werkwijze.

Volop concentratie

De bakkerij

Nog steeds is de input “ingrediënten” en de output “taarten”, alleen nu niet voor één buurman, maar voor duizenden ‘buren’… Voordat de taarten van de lopende band rollen, dient er eerst wel een bakkerij te staan. Er moest een pand worden gehuurd en een lening worden afgesloten om machines te kunnen kopen.

Aleksandra heeft een architect in de arm genomen. Met hem spreekt ze over het gebouw, de indeling van de bakkerij, de machines die de taarten produceren, een docking platform voor vrachtwagens en het kantoor. Daarnaast wil ze graag een relaxruimte en een keukentje met gezond eten. Het kan niet elke dag feest zijn.

Een grote droom, een grote investering. Zowel Aleksandra als de architect die ze heeft ingehuurd willen een optimaal resultaat. Maar het budget en de uiteindelijke efficiëntie mogen niet uit het oog worden verloren. Onderaan de streep dient er nog wat verdiend te worden.

De architect

De rol van een architect is om de wensen van de klant, de bouwers en de materialen bij elkaar te brengen. De orde van architecten geeft aan:

“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.”

Grote data-integratieprojecten hebben dezelfde voorwaarden om succesvol te kunnen zijn. Hiervoor zijn requirements, ontwerp en architectuur van groot belang. Je kunt namelijk integratiesoftware-componenten kopen, maar dit garandeert nog niet dat deze voldoen aan de eisen en wensen van de organisatie. Als deze zaken niet op orde zijn, eerder het tegenovergestelde…

Requirements

Een integratiearchitect is verantwoordelijk voor de integratielaag. Deze laag bestaat enerzijds uit het integratieplatform (de fabriek), anderzijds uit de integraties zelf (de producten die van de band rollen). Voor dit laatste worden soms solution-architecten ingezet die zich richten op het verwezenlijken van een specifieke oplossing. De integratiearchitect werkt ook nauw samen met de enterprise-architect, die weer organisatiebreed kijkt. In kleinere organisaties kan dit één en dezelfde persoon zijn.

De basismaterialen waarover een integratiearchitect beschikt zijn de softwarecomponenten (de machines), zoals een broker of een API Management Platform. Op dit niveau spreken we nog over tools en frameworks. Zodra deze tools en frameworks geïnstalleerd zijn en op elkaar zijn afgestemd spreken we over een integratieplatform; de fabriek staat.

De allereerste stap bij het opzetten van een integratieplatform is het in kaart brengen van de eisen en wensen van de organisatie, ook wel het opstellen van business requirements genoemd. Soms wordt hier de hulp ingeroepen van een derde partij die leveranciers- en technologie-onafhankelijk advies geeft.

De consultant

The Bakery Group groeit steeds verder door. Er worden taarten door heel Nederland geleverd. Het bedrijf wordt langzaamaan een geduchte concurrent van Multivlaai. Er zijn binnen de organisatie inmiddels al een hoop applicaties in gebruik. Een HR- en administratiesysteem. En natuurlijk een productie-, transport- en magazijnsysteem. De meesten zijn al met elkaar verbonden via een aantal point-to-point integraties.

Er wordt binnen het IT management de wens geuit voor een echt integratieplatform. Ondertussen wordt door het MT al met verschillende afkortingen uit hoofdstuk 4 “De belangrijkste integratiecomponenten” gestrooid. Maar echt een integratielaag realiseren blijkt lastig. Besloten wordt een externe integratieconsultant in te huren die het bedrijf adviseert over de implementatie.

Voorbeeld: checklist integratieplatform

Het allereerste wat de consultant doet als hij bij de Bakery Group binnen loopt, is de bedrijfsdoelen helder krijgen en de bijhorende eisen en wensen voor de integratielaag in kaart brengen. Een niet-uitputtende lijst van vragen die hij/zij stelt is:

Bedrijfsprocessen

• Is er een lijst met bedrijfsprocessen?
• Is er een lijst met (gewenste) integraties?
• Hoe relateren de integraties met de bedrijfsprocessen?

Datastromen

• Welke informatiestromen zijn er nu tussen de verschillende systemen? Is er een architectuurplaat?
• Welke informatiestromen zijn gewenst (bijvoorbeeld master data / administratie)?
• Is er documentatie van deze stromen beschikbaar?
• Wat zijn de architectuurrichtlijnen?
• Welke architectuurstijlen zijn er binnen IT in gebruik (EAI/SOA/Microservices)?
• Is er een diagram van de infrastructuur en het netwerk?
• Welke aanbevelingen zijn er met betrekking tot het netwerk / de infrastructuur?
• Zijn er al integraties?
• Welke middleware software wordt er nu gebruikt?

Per integratie

• Wat is de eenheid van data per integratie (bericht types als artikel of factuur)?
• Welke applicaties zijn de bron?
• Welke applicaties zijn het doel?
• Is er sprake van een push- of pull-mechanisme?
• Is de integratie Batch (Scheduled) of Event Driven (Real-time)?
• Bevat de integratie synchrone of asynchrone communicatie?
• Welke protocollen worden er gebruikt?
• Welke dataformats (XML, JSON) worden er gebruikt?
• Welke transformaties zijn er? (Data mapping, Canoniek datamodel)

Technische kennis

• Welke kennis over integratie is er aanwezig?
• Welke kennis is er gewenst?
• Hoe ziet de invulling van begeleiding er uit?
• Per betrokken IT medewerker: wat is je rol/verantwoordelijkheid van het systeem (wat versta je onder integratie)?

Robuustheid

• Hoe moet deze data worden beveiligd of worden geautoriseerd?
• Hoe gevoelig is het systeem voor bijvoorbeeld uitval?
• Hoe kan worden omgegaan met autorisaties en wijzigingen hierop?
• Kan er een vorm van single-sign on worden gebruikt?
• Is er nagedacht over exception handling / logging?
• Is er nagedacht over monitoring / alerting / beheer?
• Is er nagedacht over Tracking & Tracing van data berichten?
• Is er nagedacht over testen?
• Is er nagedacht over Continuous Delivery (Release/Deployment)?

Performance

• Wat is het aantal berichten nu en in de toekomst?
• Welke hardware/Cloud/OS wordt er gebruikt?
• Welke softwareapplicaties worden er gebruikt?
• Wat zijn de specificaties van het systeem?
• Is er een OTAP-straat?
• Wat zijn de beschikbaarheidseisen?
• Wat zijn de performance-eisen (real time/near real time)?

Architectuur Roadmap

Op basis van de vragen uit de lijst zoomt een consultant eerst in op de huidige integraties en de middleware-oplossingen die nu in gebruik zijn. Daarna gaat hij specifiek de eisen en wensen in kaart brengen. Vervolgens zoomt hij weer uit. Vanuit dit plaatje wordt de gewenste situatie geschetst. Tenslotte bepaalt hij samen met de organisatie de route van de oude naar de nieuwe situatie. Het resultaat is de architectuur-roadmap.

Zoals al aangegeven zijn er bij het opstellen van de roadmap een hoop vragen waarover nagedacht kan worden. Niet elke vraag hoeft echter tot in detail te worden uitgewerkt. Een integratielaag, bestaande uit een platform en integraties, leent zich goed om stapsgewijs op te bouwen. Je hoeft niet direct naar level 10, maar je kunt als organisatie telkens een nieuw level vrij spelen. “Integration Maturity” wordt dit ook wel genoemd.

Punten die de integration maturity kunnen verhogen zijn verbetering van schaalbaarheid, ofwel de hoeveelheid data die het platform kan verwerken. De ondersteunde integratiepatronen. Een mix van technische en functionele componenten die samen een compleet platform vormen. Het opstellen van richtlijnen en standaarden voor het inrichten van deze componenten. Het steeds eenvoudiger maken van wie de integraties kan maken.

Get Raymond Meester’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Hieronder is een voorbeeld van zo’n model:

Telkens als er verbeteringen op het platform zijn gerealiseerd kan de focus worden verlegd naar de integraties zelf. Bij het realiseren van integraties is het daarbij handig het volgende in het achterhoofd te houden:

• de basis architectuuruitgangspunten
• de data staat centraal, niet de applicaties
• de communicatie staat centraal, niet de technologie

Voorbeeld: checklist integraties

Om een data interface goed te kunnen implementeren is het vaak handig ook per integratie nog een checklist te gebruiken. Daarbij ligt de focus op de data en op de versturende (producer) en ontvangende (consumer) partij van de data:

• Hoe heet het systeem? Een systeem kan overigens elk soort softwarecomponent zijn, zoals een applicatie, een database of data warehouse, een server, een API enzovoorts.
• Wat is de functie van het systeem? Hierbij gaat het om de business functie die het vervult.
• Wat is de rol van het systeem? (producer of consumer)?
• Wie is de contactpersoon (naam, email, telefoonnummer)?
• Waar komt de data vandaan/gaat naartoe?
• Stuurt de producer de data actief op (push) of dient hij opgehaald te worden (pull)? Of is er sprake van interactie?
• Dient er toegang te worden verleend?
• Welk protocol wordt voor integratie gebruikt (HTTP, FTP)?
• Welk data format wordt gebruikt (CSV, XML)?
• Is er een validatieschema voor het data format?

Design

De basis voor de producten van The Bakery Group is het recept. Verschillende recepten kunnen aan de hand van de klantwensen allerlei verschillende taarten opleveren. In data integratie is er geen vast recept. Wel wordt er meestal uitgegaan van een ontwerp. Op basis van analyse, architectuuruitgangspunten en best practices wordt dit ontwerp opgesteld.

Een goed design volgt een aantal vaste elementen, zodat het ontwerp tegelijkertijd de documentatie vormt. Een herhaalrecept dus. Een typisch ontwerp van een data-integratie bevat:

1. Bericht: functionele beschrijving van het bericht, inclusief een voorbeeldbericht
2. Producer: beschrijving van de producers en protocollen die zij gebruiken; connectiviteit van één of meerdere bronapplicaties
3. Proces: de processtappen voor de verwerking van het bericht; daarnaast ook wel de software-modules/containers die de verwerking uitvoeren
4. Consumer: beschrijving van de doelapplicaties (consumers) en de protocollen die ze gebruiken

Sommige ontwerpers gebruiken vooral tekst of een spreadsheet in het ontwerp, andere gebruiken vooral diagrammen. Meestal is het een mix van beide.

Architectuurstijlen

“The world gets more and more connected” is een uitdrukking die je tegenwoordig veel hoort. De vragen “hoe is deze wereld verbonden?” en “hoe om te gaan met steeds meer verbindingen?” zijn architectuurvragen. Er zijn verschillende stijlen ontwikkeld als antwoord op deze vragen. Voordat we ingaan op deze architectuurstijlen gaan we eerst terug in de tijd.

1700 jaar oude monolith (Bolivia)

Monolithisch

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

Al voor deze ontwikkelingen plaatsvonden waren er allerlei grote computers ontstaan, de zogenoemde mainframe-applicaties. Vaak op basis van een monolithische architectuur. Dat betekent dat alle functionaliteit in één geheel wordt geïmplementeerd. Dit kon ook vaak niet anders. Er waren nog geen standaardapplicaties of containers beschikbaar, dus bouwden bedrijven alles in één grote mainframe-applicatie. De data werd vaak ingevoerd via een command line user interface (terminal) dan wel via een import/export data-interface.

Monolithische architectuur

In de jaren tachtig en negentig ontstonden er standaardapplicaties. Denk aan administratieve of magazijnsoftware. Deze software hoefde niet per se meer op een mainframe te draaien, maar kon op een Unix-server draaien en het internet gebruiken om data uit wisselen.

Zo kochten bedrijven steeds meer externe applicaties in. 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 point-to-point koppelingen vormden een brug tussen de applicaties.

In veel gevallen waren deze applicaties bijna nog net zo monolithisch als de mainframe-systemen.

EAI

Met steeds meer applicaties ontstond 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 als aparte IT-laag.

Zoals er veel verkeersmiddelen zijn (boot, vliegtuig, auto en vrachtwagen) en infrastructuur (wegen, spoorlijnen en vliegvelden) om logistieke vraagstukken op te lossen, zo ontstonden er ook voor data-integratie concepten en oplossingen. Data die niet door rechtstreekse bruggen, maar door transport en infrastructurele componenten met elkaar wordt verbonden.

EAI (Enterprise Application Integration) is een concept waarbij point-to-point koppelingen vervangen zijn 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. Thus, for ten applications to be fully integrated point-to-point, 10 × 9/2 = 45 point-to-point connections are needed. (https://www.brainspire.com/services/internal-software-integration)

EAI zorgt dat iedere applicatie van de juiste data wordt voorzien. De data van elke applicatie zijn zo consistent met elkaar. Tussen de applicaties hoeft niet niet telkens een aparte directe interface te worden gebouwd. Alle datastromen lopen via middleware. Door middleware is het voor ieder duidelijk hoe de datastromen lopen. Toch is implementatie lastig omdat je centrale projectmanagement en coördinatie van alle data-integratie moet bewerkstelligen. Ook leidt deze stijl tot het rondsturen van veel kopieën van data.

SOA

Na het jaar 2000 zie je een steeds verdergaande opsplitsing van applicaties in services (webservices). De reden hierachter is simpel, het mainframe en later de grote standaard ERP-applicaties zijn lastig te onderhouden en te wijzigen. In de architectuurstijl SOA, service-orientated architecture, draait zoals de naam al zegt alles om services.

Services zijn software-modules die zoveel mogelijk onafhankelijk en los van andere software staan. Omdat ze meestal beschikbaar zijn via netwerken, zoals het internet, spreekt men meestal over webservices. Elke webservice heeft een definitie van hoe de data interface moet worden aangeroepen. In tegenstelling tot EAI gaat het niet om het synchroniseren van data, maar meer om het opvragen en verwerken daarvan.

Opzet van een SOA Service met het SOAP protocol

Door kleinere modules te gebruiken kunnen IT en de organisatie makkelijker evalueren. Daarbij moet specifieke functionaliteit eenvoudig te wijzigen zijn zonder veel afhankelijkheden van andere software. Dit staat meestal te boek als “loosely coupled”, de software-onderdelen zijn losjes met elkaar gekoppeld. Uiteraard communiceren alle services wel met elkaar. Elk service dient een gestandaardiseerde manier van interfacing te hebben. De interfaces dienen overzichtelijk, herbruikbaar en schaalbaar te zijn.

Vaak is de uitleg over SOA nogal technisch. Laten we daarom van onze analogie met de banketbakkerij uitgaan:

Aleksandra heeft verschillende banketbakkers in dienst. In SOA ga je ervan uit dat die bakkers niet collegiaal zijn. Aleksandra laat ze daarom alleen het hoognodige communiceren en geeft elke banketbakker een eigen rol. Één bakker maakt het deeg, één maakt het beslag, één maakt de taarten en de laatste doet de versiering.

Aleksandra zegt de deegmaker niet alleen dat hij deeg moet maken, maar ook precies waar hij het moet neer zetten. Ditzelfde geldt voor de maker van het beslag enzovoorts. De taartmaker neemt het deeg en beslag als input voor de taart en zet de gemaakte taarten ergens neer. De laatste bakker krijgt de hele taart en versiert hem voordat hij hem in de vitrine legt.

De verschillende bakkers doen dus vooral hun eigen ding. Ze zijn alleen in zoverre van elkaar afhankelijk dat er een vast overgangsmoment is. In dit voorbeeld zie je dat elke banketbakker zijn eigen taak heeft met een duidelijke procedure die aangeeft waar hij de input vandaan haalt en waar hij de output moet neerzetten.

Een service in SOA werkt op dezelfde wijze. Het is een op zichzelf staande module met een duidelijke ingaande en uitgaande interface. Voordeel van het concept is dat je een service kan hergebruiken. Net als je het deeg ook kan hergebruiken voor gebak of cake bijvoorbeeld. Je hoeft alleen te weten waar het deeg staat.

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

Microservices

Het werken met services kan echter nog fijnmaziger (en nog complexer). Je zou de bakkers in SOA nog ambachtelijk kunnen noemen. In een lopende band zou je specifieke taken door mensen en robots op microniveau kunnen laten uitvoeren. Zo’n fabriek is natuurlijk uiterst complex, maar levert wel als voordeel vaste kwaliteit met een hoge output.

Voor software is het verder verfijnen van services in microservices vooral de schaalbaarheid en flexibiliteit een voordeel.

Microservices borduren voort op de SOA architectuurstijl. Het maakt daarbij uitdrukkelijk niet gebruik van een ESB laag, maar gaat uit van standaard netwerkprotocollen (HTTPS) die door middel van (REST) API’s met elkaar communiceren. De onderliggende technologie (programmeertaal/database) is gericht op de functie van de applicatie, technologie trends 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 slechts één of enkele business-functies. Het doel is net als bij SOA dat zo’n 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 microservice beperkte business-functionaliteit bevat, zijn er al snel veel microservices nodig. De installatie, versiebeheer en registratie van nieuwe en gewijzigde services evenals afhankelijkheden tussen services kan hierdoor zeer complex worden.

Andere architectuurstijlen

Hieronder nog enkele andere stijlen:

• Remote calls: Server-clients waarbij applicaties veelal zonder middleware elkaars functies, procedures of objecten aanroepen.
• RPC (Remote Procedure Calls). Aanroep van procedures. In een RPC stijl wordt de procedure gestart doordat een client een request message naar een server stuurt. De server voert de procedure uit. Na afhandeling van de procedure stuurt de server een reply terug.
• 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 (Object Management Group).
• MFT (Managed File Transfer): Het overzetten (transfer) en synchroniseren van databestanden. Richt zich met name op veiligheid, betrouwbaarheid en grote volumes van bestanden. Vaak zijn applicaties zelf voor import/export van de bestanden verantwoordelijk.
• SCS (Self Contained Systems): Een architectuurstijl met de nadruk op de functionele Separation-of-Concerns. Alle applicaties in het applicatielandschap zijn op zich staande webapplicaties die zowel de business logica, de data en de user interface bevatten. Elke van deze webapplicatie heeft zijn eigen business functie. De data-uitwisseling tussen die applicaties loopt zoveel mogelijk asynchroon.
• EDA (Event Driven Architecture): Architectuur stijl die uitgaat van events (gebeurtenissen). An event-driven system bestaat uit event emitters (ook wel agents), event consumers (ook wel sinks) en event channels. Emitters/Agents detecteren een gebeurtenis (een toestand verandert) en verzamelen de juiste data. De event consumers krijgen het resultaat en moeten eventueel een reactie op de input geven. De event channels zorgen voor de interface tussen emitter en consumer.
• Reactive: Event-Driven architectuurstijl die van responsieve applicaties uit gaat. Als er een wijziging 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. Veel principes van deze stijl zijn vastgelegd in het Reactive manifest.

De praktijk

Zelden wordt een applicatielandschap opgebouwd vanuit een leeg blad. Vaak is het ongeveer zo gegaan: in de jaren 70 en 80 werden eerst de administratieve en primaire processen geautomatiseerd. Er was nog geen standaardsoftware voorhanden, dus werden er op mainframes grote monolieten ontwikkeld.

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 werden 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 tenslotte verschillende architectuurstijlen met verschillende type applicaties in het landschap. Hoe het applicatielandschap er precies uit ziet, is grofweg afhankelijk van:

1. het aantal jaren dat een bedrijf bestaat
2. de grootte 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 klein en de processen zijn 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 of hypes. Soms omdat het nieuwe beter is, soms omdat het oude niet meer onderhoudbaar is (technical debt). Zie bijvoorbeeld het volgende verhaal vanuit 15 jaar ervaring met software. In dit verhaal gaat het over hoe het applicatielandschap groeit tot er allerlei (onbeheersbare) technologieën en architecturen worden gebruikt.

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

Architectuurstijl vs technologie

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

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

Het 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 het mee evalueren van het applicatielandschap met de business. Welke stijl er ook wordt gekozen, het is altijd een uitdaging om complexiteit van een organisatie te implementeren in één technisch geheel en het overzicht van de datastromen te bewaren.

De roadmap

Met behulp van de software componenten, eisen en wensen en architectuurstijlen kan een schets van het integratieplatform 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 worden.

Bij The Bakery Groep richten ze zich bijvoorbeeld eerst op standaardtaarten, zoals appel- en slagroomtaarten. Later moet ook vlaaien, gebak en bruidstaarten mogelijk zijn.

Zo kan men zich bij integratie eerst richten op integraties met legacy-systemen en later bijvoorbeeld op API’s. Gaan we eerst voor een ESB of direct voor een iPaaS? Als de verschillende bouwstenen die eerst gelegd worden bekend zijn, kan gestart worden met de verwerving van deze bouwstenen.

Meestal bouwen de bouwstenen voort op andere. Je bouwt eerst een deel van de fabriek, leert hier van en gaat door. Uiteraard is één van de voordelen van softwarebouwstenen dat deze flexibeler zijn dan bakstenen. Een nadeel is wel dat soms niet helder is hoeveel werk de implementatie kost en wat het oplevert.

De laatste fase is op basis van de eisen en wensen van een specifieke bouwsteen een product opstellen. Bijvoorbeeld waar een broker of een gateway aan moet voldoen. Daarna kan de selectie en verwerving (eventueel via een aanbesteding) plaatsvinden. Dit dient zorgvuldig te gebeuren, omdat deze producten rustig meer dan 10 jaar gebruikt 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.

8. Cloud Integratie

Inhoudsopgave: