10 Lessons learned

Waar loop je in de integratie praktijk tegen aan?

“Over een paar jaar zul je als integratie specialist geen werk meer hebben”, zei een projectmedewerker van iShare eens tegen mij. Het afsprakenstelsel iShare was net tijdens de IT & Logistiek beurs in Utrecht gelanceerd. Dit stelsel helpt bij de autorisatie en authenticatie tussen logistieke partijen.

Geen werk? Was dat maar waar! Het omgekeerde is het geval, met elk nieuw geintroduceerd protocol, standaard of technologie hebben integratie specialisten het weer een beetje drukker. Al is de oplossing nog zo geavanceerd, de werkelijkheid is meestal toch weerbarstiger. Dus ondanks alle standaardisatie, protocollen, data formaten en tooling, blijven vele integraties een uitdaging.

Veel van deze uitdagingen zijn door Igor Tkac, directeur van IGT Consulting in de series #IntegrationStories opgetekend. Hier een aantal van zijn observaties.

De Bermuda-driehoek

Laten we beginnen waar veel complexiteit vandaan komt. Bij integratie heb je om te beginnen altijd met minimaal twee systemen te maken. Die verschillen vaak niet alleen in technologie, maar zijn vaak ook door verschillende makers gemaakt en worden door verschillende afdelingen beheerd.

Daar bovenop wil de organisatie zijn eigen bedrijfsprocessen ondersteunen. Dit leidt tot een soort Bermuda driehoek:

Elk hoek heeft zijn eigen doeleinden en belangen. Data kan daar zomaar in verdwijnen…

Voornamelijk afstemming

Stel dat systeem A een HR applicatie is en systeem B, een app voor personeelswerving. Het eerste systeem heeft als functie een goede personeelsadministratie. De SaaS leverancier zorgt voor een applicatie waarmee meerdere bedrijven die functie kunnen vervullen. Systeem B zorgt weer voor alles rondom de functie “werving & selectie”. De leverancier van deze app richt alles naar die functie.

De organisatie gebruikt beide weer voor andere doeleinden. Iemand die door de organisatie geworven is (Systeem B), moet bijvoorbeeld automatisch in het HR systeem komen (Systeem A).

De praktijk laat zien dat het overbruggen van de verschillen tussen deze twee systemen een hoop overleg vereist. Een kandidaat is namelijk niet hetzelfde als een medewerker. Gekscherend wordt er wel het volgende aangehouden:

90% is overleg, de rest is het analyseren, bouwen, testen en deployen van integraties. Nu is dit geen wetenschap, maar het gevoel dat vele hebben die met integraties bezig zijn. Waar komt dat gevoel vandaan?

Laten we ons voorbeeld verder vervolgen.

“OK iedereen, er komt een project die de HR, Werving & Selectie en Finance ‘versaast’. We gaan dus ook nog het Finance systeem vervangen. Het huidige systeem is 26 jaar oud en voldoet niet meer aan de moderne wensen.”

De managers zijn enthousiast over de businessvoordelen, de architecten zijn ambitieus over de technische vernieuwing. Onderschat wordt vaak dat in die 26 jaar toch wel een hoop gebeurd is. Maatwerk componenten, scripts en integraties zijn er om heen gebouwd. Allerlei processen zijn in place en jaren van finetuning is achter de rug.

Ook wordt onderschat hoeveel integratiewerk er eigenlijk nodig is, als dit al heel specifiek gebudgetteerd wordt. Er is al met al slechts een vaag idee van wat ze in het project willen, maar ze hebben vanuit het project wel al een inschatting nodig voor het integratiegedeelte.

Het integratieteam:

➢Hoeveel interfaces zijn er nodig?
Project: “Dat is nog niet duidelijk.”

➢ Hoeveel systemen moeten worden geïntegreerd?
Project: “Dat is nog niet zeker, maar waarschijnlijk tussen de 3 en 8.”

➢ Welke architectuur willen we gebruiken?
Project: “Daarover zijn we nog in gesprek. We werken nog de visie uit”

… enzovoort.

Daarnaast brengt de architectuur ambitie (Event-Driven, API-driven, Cloud-First, Microservices) veel nieuwe elementen in die soms niet in verhouding staan met het project.

Idee is bijvoorbeeld om over te gaan naar een microservices architectuur. Na twee weken komen de technici erachter dat je 90% procent op deze nieuwe manier kan doen. Maar hoe zit het met die andere 10%?

Ook komt het team erachter dat de nieuwe technologie nog veel kinderziektes heeft en je extra tijd nodig hebt om er ‘omheen’ te programmeren. Daarnaast biedt de nieuwe microservices architectuur veel meer complexiteit.

Langzaam valt het developer team in de valkuilen van gedistribueerde systemen. En niet alleen brengt de nieuwe technologie extra complexiteit met zich mee, vaak blijft er genoeg legacy achter waarmee geïntegreerd moet worden.

Is er voldoende zicht op de legacy die schijnt in de reflectie van de nieuwe applicaties?

Wat er vaak het geval is dat binnen de nieuwe architectuur die bijvoorbeeld in de cloud draait, integreren relatief makkelijk gaat. Ook de legacysystemen laten zich makkelijk verbinden on premisse. Beide, cloud services met on premisse applicaties, verbinden is echter hel.

1. Lesson learned: Een balans tussen oud en nieuw

Als je vooruit wilt dan zijn er risico’s. Hoe meer nieuwe elementen, des te meer risico je zal moeten incalculeren. Het agile werk veronderstelt een goede mix te vinden tussen bewezen technologie en vernieuwing. Daarbij heb je zowel ervaren mensen nodig die wijzen op de beren op de weg, als vernieuwers die de kansen van nieuwe trends omarmen.

2. Lesson learned: Een koppelvlak tussen oud en nieuw

Misschien is nog niet helemaal duidelijk hoeveel koppelingen er precies komen, maar is het wel handig één koppelvlak te maken, waarmee zowel oude en nieuwe applicaties kunnen worden verbonden. Vaak is dit een broker of een gateway waarvan uit de cloud en on premisse mee kan worden verbonden. Beide kant zullen netwerktechnisch hier toegang tot moeten krijgen.

De mate van complexiteit

OK, het project begint al aardig op stoom te komen. Er is inmiddels een helder beeld van het aantal integraties. De enterprise architect heeft inmiddels een ‘praatplaat’ gemaakt, waarbij elke verbinding tussen middleware en applicaties één lijntje vormt. De solution of integratiearchitecten werken dit verder uit op basis van berichttypes en protocollen.

Dan komen de analisten in actie die de verschillende stappen van elk ‘lijntje’ in een diagram proberen weer te geven. Inmiddels is de integratie al een aardige lange keten geworden. Ten slotte gaan de developers aan de slag en blijken er nog een aantal spoken uit de kast komen en wat technische hobbels moeten worden overwonnen.

Oorspronkelijke plaatje:

De uiteindelijke integratie:

De man is een berichtje van A naar B

Maar dit gaat slechts over de integratiestappen die er bij komen kijken. In moderne integraties zijn er nog hele andere uitdagingen, namelijk:

1. Infrastructuur
2. Security
3. Netwerken

Een integratiespecialist lijkt tegenwoordig meer en meer tijd kwijt te zijn met de randvoorwaarden van de integratie. Veilige en stabiele verbindingen zijn inderdaad noodzakelijk, maar het heeft vanuit het integratieperpectief eigenlijk nul business meerwaarde.

Het proces voor toegang vragen, netwerk configuratie, firewall poorten, certificaten etc. kost een hoop tijd van het integratieteam. IT is een vrij breed begrip en veel gebruikers (soms zelfs programmeurs) realiseren zich één belangrijk feit niet:

➢ Door hoeveel (fysieke en virtuele) lagen hun gegevens moeten gaan, van toepassing A tot ze toepassing B bereiken.
➢ En op hoeveel plaatsen er ‘iets mis kan gaan’ tijdens deze reis.

Het onderstaande plaatje is al vereenvoudigd:

Er is bij middleware dus niet alleen veel werk op de applicatielaag (waar de waarde wordt geleverd), maar ook op de systeemlagen eronder. Daarnaast als de integraties eenmaal draaien zijn deze erg afhankelijk van deze lagen.

Igor Tkac merkt op:

Een ding dat me ongemakkelijk maakt is hoezeer het integratieteam afhankelijk is van een stabiele infrastructuur.

Misschien ben ik gewoon een naïeve ‘consument van AWS/Azure reclames’, maar ik hou echt van een idee om ons te concentreren op ons werk zonder angsten van:

➢ Volle schijfruimte
➢ Blackouts door ‘ongepland onderhoud’
➢ ‘Transparante’ backend-upgrades (waarbij we de toegangsrechten tot ons platform verliezen)
➢ ‘Aha-momenten’ zoals dat u uw cluster op 2 verschillende machines wilde hebben (omdat het allemaal op één machine was toegevoegd)
➢ U hebt een nieuwe DB nodig? — geef ons 3 weken

Ik begrijp dat het ‘bezitten’ van infrastructuur zeker zijn voordelen heeft:

➢ minder kans op “spionage
➢ juridische redenen
➢ er is al geld geïnvesteerd in ‘onze’ datacenters — dus waarom zouden we dat nog eens uitgeven?

Bedrijven die integratietools en -platforms leveren, brengen inmiddels nieuwe versies uit die meer ‘portable’ zijn — dus ik denk dat ik niet de enige ben met deze behoefte.

Lesson learned 3: Oog voor infrastructuur

Get Raymond Meester’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

De implementatie vraagt specifiek een strategie voor de infrastructuur en netwerklagen. Hoe kunnen issues snel getackeld worden? Vaak is het nodig specifieke resources van zowel het integratieteam als infrastructuur te hebben in een groot project? Nu het management nog zover zien te krijgen…

Lesson learned 4: Eenvoud

KISS (Keep-It-Simple-Stupid) zal een van de uitgangspunten van het project moeten zijn. Je bereikt dit door regelmatig te standaardiseren, refactoring en soms door “nee” te zeggen op de integratielaag. Leonardi da Vinci wist het al “eenvoud is de ultieme vorm van verfijning”.

Het team

Het projectbudget is er eindelijk door heen, tijd om het integratieteam samen te stellen. Maar hoe doe je dit? Het begint bij een mix van rollen (coördinerende rollen, technische rollen en test/beheerrollen) en een mix van werk (het ‘eigenlijke’ werk, opleiding en plezier).

Maar hoe vind je (jonge) mensen die gaan houden van data integratie? Er is geen rechtstreeks opleiding voor en vaak hebben IT’ers alleen zijdelings met integratie te maken gehad. In functie beschrijvingen wordt dan vaak gestrooid met allerlei afkortingen van protocollen en frameworks, maar minstens zo belangrijk is:

➢ Brede kennis van IT (je hebt immers met allerlei soorten technologiën te maken).
➢ Flexibel in het leren van nieuwe dingen.
➢ Goede communicatieve vaardigheden.
➢ Bereid zich te specialiseren op een zeer specifiek gebied.
➢ 50/50 balans tussen coderen en communicatie!

Igor Tkac vraagt zich in integration stories af:

Maar waarom zou iemand houden van een baan waar:

➣ hoe ‘onzichtbaarder’ je bent, hoe beter je bent.
➣ als er toch iets fout gaat dan ben jij de eerste die de schuld daarvan krijgt.

Hij geeft in het vervolg echter aan dat er ook een andere kant aan dit verhaal is, namelijk hoe je met mensen om gaat. Een integratie specialist is iemand die:

➣ graag naar anderen luistert
➣ voldoening haalt uit het helpen van anderen

Wat echt belangrijk is, is de passie om deel uit te maken van het “grotere geheel” waarbij je nooit stopt met het leren van nieuwe dingen en trends.

De grootste uitdaging

Het project gaat van start en dan heb je nog te maken met een brok communicatie. Eh, communicatie?

Ja, communicatie: De GROOTSTE integratie-uitdaging.

Igor beschrijft systeemintegratiewerk graag als ‘het lijmen van business en technologie’ of ‘bruggen bouwen tussen technologieën’. Toch voegt hij daar aan toe: “maar soms voelt het aan als het proberen te lijmen van water en vuur”. In de praktijk heb je niet alleen te maken met veel verschillende technieken, maar ook met allerlei partijen.

Het speelveld van integratie:

Het probleem is dat integratie er meer last van heeft als verschillende onderdelen meer in hun eigen bubbel zitten zonder oog voor de omgeving. Juiste communicatie en bereidheid tot luisteren van ALLE kanten is een 🔑 tot succes.

Lesson learned 5: Een evenwichtige skillset

Vaak is IT opgedeeld in de praters en regelaars aan de ene zijde en technici aan de andere zijde. Uiteraard heb je daar allerlei smaken in. Bij een integratie specialist is dit vrijwel altijd 50/50, waardoor de soft en hardskills in evenwicht moeten zijn.

Lesson learned 6: Luisteren is goud

Vaak hebben integratiespecialisten sterke ideeën over wat een goede integratie is. De sleutel ligt echter in het luisteren om oplossing te vinden die aan de eisen en wensen van de stakeholders voldoet.

De onvermijdelijke P1

Eindelijk gaan de verschillende integraties naar productie. Een standaard iets bij integratie is dat er over productie altijd andere data wordt gestuurd dan tijdens de testfase. Dus al test je nog zo goed, er zijn altijd gevallen die er door heen glippen. Belangrijk is om zulke incidenten snel te kunnen detecteren (monitoring), te analyseren en de oplossing te kunnen doorvoeren (wat vooral ligt aan CI/CD en goed change management).

Als er kort na de in productiename iets fout gaat dan is er vaak nog genoeg ondersteuning. Daarna is integratie een onzichtbare IT-component …tot het moment dat er echt iets misgaat 💥. Een integratie specialist zijn is soms een ondankbare rol.

Als je verantwoordelijk bent voor front-end applicaties heb je feedback van gebruikers. De back-end is gehuld in mysterie, maar gebruikers weten dat er ergens een plek vol met ‘computers’ is ⚙️ die alles verwerkt wat ze nodig hebben.
Maar middleware? Gaan gegevens niet via kabels?

Maar zelfs een klein probleem op de middleware en 💥 … de data komt niet door, applicaties vertonen fouten en de back-end loopt vast… Maanden van stilte zijn voorbij. Het integratie team komt uit de schaduw. Hoe beter je je werk doet, hoe onzichtbaarder je bent.

Zelfs als we ons best doen gebeurt het van tijd tot tijd — een P1 incident met een flinke productieverstoring. Zoals het integratieteam weet, zullen zij de eerste lijn van verdediging zijn (en soms ook van schuld). De volgende twee zinnen helpen de stemming dan aardig om zeep:

1️⃣ Ik heb het aan mijn kant gecontroleerd en alles ziet er OK uit!
2️⃣ Er hoeft geen actie te worden ondernomen aan onze kant.

De reden waarom mensen dit zeggen is dat ze bang zijn 😱.
Ze willen geen deel uitmaken van het probleem, want heel vaak als je iemand wil helpen om het probleem op te lossen wordt het zo gepresenteerd alsof hij / zij verantwoordelijk zijn voor dat probleem.

Resultaat:

➢ Geen vertrouwen tussen teams
➢ Trage reacties / langere tijd nodig voor herstel
➢ en het belangrijkste: onbekende hoofdoorzaak

Wat gebeurt er als de gegevens van systeem A systeem B niet bereiken? Twee keuzes:

a) Controleer of systeem A en B correct werken. ❎
b) Contacteer het integratie team en zeg hen dat de middleware niet werkt. ✅

Yep … ‘b’ is meestal de keuze. En hiervoor moet je al je integratieteamleden (vooral juniors) op voorbereiden. Hoe groter bedrijven zijn, hoe zwakker de communicatie is tussen verschillende IT-teams (die zich vaak aan de andere kant van de wereld bevinden).

Integratie als ‘lijm en brug’ is meestal degene met het beste overzicht van wat er gebeurt binnen het bedrijf vanuit een IT perspectief. Dit is tegelijkertijd ‘een zegen en een vloek’ die leidt tot de genoemde situatie.

Ja, het brengt integratie in slecht licht (wat frusterend kan zijn) maar het uiteindelijke doel is om het probleem ASAP op te lossen en dit is DE SNELSTE aanpak waarbij middleware het voortouw moet nemen en de samenwerking tussen teams moet initeren.

Lesson 7: Zichtbaarheid

Integratiespecialisten: Als je het gevoel hebt dat je onzichtbaar bent, is dat OK — het betekent dat je goed werk levert.

Lesson 8: Erkenning

De enige manier om de situatie te voorkomen waarin mensen hun fouten verbergen, vervagen en bedekken, is hen te laten zien dat fouten kunnen gebeuren en dat het moet worden gezien als een gebied voor verbetering, niet voor verwijten.
Erken mensen die geholpen hebben met de oplossing als een ‘goed voorbeeld’.

Lesson 9: Samenwerken

Samenwerken en niet met de vinger wijzen is het juiste antwoord. Met een beetje respect en waardering voor integratie werk, kan zelfs ‘b’ OK zijn voor integratie specialisten. Laten we streven naar een oplossing, niet alleen naar het vinden van ‘schuldigen’.

Twee mensen

Stel je een high-tech bedrijf voor met 10k+ werknemers.
Ze zijn een van de wereldleiders in hun sector. Zoals de meeste bedrijven tegenwoordig begrijpen ze volledig dat de enige manier om te overleven in een competetieve markt, is om ‘digitaal te denken’.

Dus wordt er geld geïnvesteerd in Apps, O&O en Cloud-oplossingen. De complexiteit van het applicatielandschap neemt toe. Er zijn meer dan 1000 componenten in het lanschap. En raad eens, de hele integratie wordt beheerd door slechts… TWEE mensen.

Deze twee mensen zijn echte professionals, dus de hele oplossing werkt prima met een beperkt budget.

Wat kan er nu mis gaan?

Nou het volgende:

1️⃣ Vanwege de kleine capaciteit kunnen ze niet alle nieuwe IT-initiatieven beoordelen en daarom beheren applicatieteams ‘soms’ de directe integraties (en omzeilen het integratieteam).
2️⃣ Een onvoorspelbaar productieomgeving verstoren de ontwikkelingsplannen.
3️⃣ Sommige projecten worden on hold gezet.
4️⃣ Het bedrijf kan niet het VOLLEDIGE potentieel uit hun gegevens halen.
5️⃣ Constante overbelasting beperkt de ruimte voor leren/innovatie.

Lesson learned 10: Voldoende resources

Igor geeft aan “Dit is geen zeldzaam verhaal. Ik heb het in meerdere bedrijven gezien en in twee gevallen eindigde het zelfs met een burn-out.”

Een integratieteam zal in lijn moet zijn met de rest van IT. Daarnaast zal een goede CIO de belangen van integratie moeten inzien en ervoor zorgen dat het middleware-team een stabiel en betrouwbaar onderdeel van IT is. Omgekeerd zal integratie de organisatie in staat moeten stellen om zelf integraties te maken. Dat is wel de belangrijkste les.