Wanneer je kijkt naar hoe je integratie organiseert, loop je tegen verschillende aspecten van integratie aan.
In dit blog worden ze toegelicht: de integratieketen, de integratie-opbouw, de integratiepatronen en (de)centraliseren.
Het doel is vooral om bewustzijn van deze aspecten te creëren en welke afwegingen je kunt maken. Hóe je je integratie uiteindelijk het beste organiseert, hangt af van de keuzes die je maakt en de context van je eigen organisatie.
De integratieketen
Waar ben je binnen ‘integratie’ voor verantwoordelijk wanneer je de complete eind-tot-eind integratieketen aanschouwt:
Tussen de twee applicaties die door een integratie worden verbonden zitten vele, meestal infrastructuur-gerelateerde, componenten. Dan kan het gaan om zaken als een proxy, een firewall, wellicht nog andere security-gerelateerde componenten.
Wat hiervan wordt allemaal door het integratieteam uitgevoerd en beheerd, en wat niet? Een projectmanager die een nieuwe integratie nodig heeft ziet het liefst een ‘one stop shop’ voor alles. Aan de andere kant is infrastructuur vaak een vak apart en wordt dan ook door een andere afdeling gedaan.
Ben je de ‘one stop shop’ (en ga je bijvoorbeeld ook ontwerpgesprekken op detailniveau met de applicatieteams voeren, en alle infrastructuurcomponenten aanvragen of realiseren) of lever je puur de integratie op basis van duidelijke specificaties en houd je je verre van de rest? Wat je ook kiest, wees helder over wat je wel of niet doet, en wees hier consequent in.
De integratie-opbouw
Om integratie te realiseren heb je vaak een hele ‘stack’ nodig:
Ook op deze dimensie moeten keuzes worden gemaakt over verantwoordelijkheden en beheer. Over hoeveel lagen/teams/organisatieonderdelen wordt de ‘stack’ opgesplitst? En wie is er eigenaar van en gaat bijvoorbeeld over strategische keuzes? Wie is er verantwoordelijk voor het inrichten? En voor het beheer? Wie is er verantwoordelijk voor de overkoepelende integratie-architectuur? Wie voor de technische inrichting van het integratieplatform en de bouwblokken? Wie neemt strategische besluiten over het integratieplatform? Hoe lopen de lijnen bij een incident in een onderliggende laag?
Het voordeel van meerdere lagen kan zijn dat je per laag minder specialistische kennis nodig hebt. Aan de andere kant zorgen meer lagen weer voor een grotere complexiteit – zeker wanneer er zich een prio 1 incident voordoet: weet iedereen elkaar dan snel genoeg te vinden? En wat zijn de beheerafspraken voor iedere laag? Het is lastig 24×7 support leveren op een integratie wanneer er ‘lager’ in de stack géén 24×7 support beschikbaar is.
De integratiepatronen
Vaak is er behoefte aan meerdere integratiepatronen. Op basis van de integratievereisten zal als onderdeel van een integratie-architectuur een keuze worden gemaakt voor één of meerdere platformen/tools/merken om deze integratiepatronen te faciliteren.
Vervolgens zal een keuze moeten worden gemaakt of ieder platform een eigen development en beheerteam krijgt, of dat er meerdere platformen binnen één team worden belegd. Zo kan gebrek aan schaalgrootte aanleiding zijn om niet voor ieder platform een eigen team in te richten. Zeker wanneer 24×7 beheer nodig is, kan het aantal mensen dat je nodig hebt snel oplopen. En ook bij gecombineerde integraties (integraties waarbij meerdere integratieplatformen nodig zijn) kan het ook handig zijn om iedereen in één team te hebben zitten.
(De)centraliseren
Er zijn de afgelopen jaren allerlei bewegingen geweest: alles centraal trekken, platformen centraal maar features decentraal, werken met een competence center, center of excellence of een center of enablement.
Wat handig of haalbaar is, kan per integratieplatform (patroon) verschillen. Zo laat een Enterprise Service Bus zich minder makkelijk decentraliseren (hoge complexiteit, specifieke diepe skills), terwijl een minder complex API management platform zich juist wél makkelijk laat decentraliseren. Maar het hangt ook af van de overall organisatiestructuur en –cultuur (en de ambities van de organisatie).
Conclusie
Al met al spelen er 4 dimensies mee in dit model:
En er is niet één oplossing. Het hangt af van de gekozen (of beoogde) organisatiestructuur en -cultuur, gekozen integratiepatronen/platformen, de beschikbare integratieskills binnen de organisatie, etc. En je hoeft niet één model voor alle integraties te kiezen. Maak in ieder geval je keuzes bewust, communiceer er helder over en houd je aan je eigen regels.
Bij ilionx hebben we de expertise in huis om je met dit soort vraagstukken verder te helpen. Wij doen bij diverse klanten het support van hun integraties en vaak pakken we ook een bredere verantwoordelijkheid. Zo kunnen onze experts per geval bepalen wat de beste manier is om een integratie-omgeving in te richten, interfaces te realiseren en support te doen.
Training ‘360° blik op integratie’
Ook geven we regelmatig de tweedaagse training ‘360° blik op integratie’ om je meer inzicht te geven in de wereld van integratie. In deze training behandelen we diverse aspecten van integratie, zowel organisatorisch als licht-technisch, zodat je weloverwogen keuzes kunt maken over je integraties.
