11. Lessons learned!
Waar loop je in de integratie praktijk tegenaan?
“Over een paar maanden zul je geen integratiespecialist meer nodig hebben”, zegt de IT-manager van Aleksandra. Alle data is dan inmiddels met allerlei integraties “aan elkaar geknoopt”. Alle stromen zijn geautomatiseerd en ze maken gebruik van allerlei EDI-standaarden. Na verloop van tijd vraagt de manager of hij toch niet nog een integratiespecialist mag aannemen?
Geen werk voor integratiespecialisten? Was dat maar waar! Het omgekeerde is het geval, met elk nieuw-geïntroduceerd protocol, standaard of technologie krijgen integratiespecialisten het weer een beetje drukker. Al is de oplossing nog zo geavanceerd, de werkelijkheid is meestal toch wat weerbarstiger. Dus ondanks alle standaardisatie, protocollen, dataformaten en tools, blijven vele integraties een uitdaging.
Veel van deze uitdagingen zijn opgetekend door Igor Tkac, directeur van IGT Consulting, in de series #IntegrationStories een aantal van zijn observaties.
De Bermudadriehoek
Waar komt veel complexiteit vandaan? Bij integratie heb je om te beginnen altijd met minimaal twee systemen te maken. Vaak verschillen die niet alleen in technologie, maar zijn ze ook door verschillende personen gemaakt en worden ze door verschillende afdelingen beheerd.
Daar bovenop wil een organisatie haar eigen bedrijfsprocessen ondersteunen. Dit leidt tot een soort Bermudadriehoek:
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. Systeem B zorgt weer voor alles rondom de functie “werving & selectie”.
De organisatie gebruikt beide dus voor andere doeleinden. Iemand die door de organisatie geworven is (Systeem B), moet bijvoorbeeld automatisch in het HRM-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 wel het volgende aangehouden:
90% is overleg, de rest is analyseren, bouwen, testen en uitrollen van integraties. Nu is dit geen wetenschap, maar het gevoel dat velen hebben die met integraties bezig zijn. Waar komt dat gevoel vandaan?
Laten we ons voorbeeld verder vervolgen:
“Oke iedereen, er komt een project dat de HR, Werving & Selectie en Finance-applicaties ‘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. We moeten naar de cloud.”
De managers zijn enthousiast over de business-voordelen, de architecten zijn ambitieus over de technische vernieuwing. Onderschat wordt vaak dat in die 26 jaar toch wel een hoop gebeurd is. Maatwerkcomponenten, scripts en tools zijn om de integraties gebouwd. Allerlei processen zijn in place en jaren van finetuning zijn 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 het management 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”
… enzovoorts.
Daarnaast brengt de architectuurambitie (Event-Driven, API-Driven, Cloud-First, Microservices etc.) veel nieuwe elementen in die soms niet in verhouding staan tot het project.
Het idee is bijvoorbeeld om over te gaan naar een microservices- architectuur. Na twee weken komen de technici erachter dat je 90 procent van de integraties op deze nieuwe manier kunt doen. Maar hoe zit het met die overige 10 procent?
Ook komt het team erachter dat de nieuwe technologie nog veel kinderziektes bevat en je extra tijd nodig hebt om er ‘omheen’ te programmeren. Daarnaast biedt de nieuwe microservices-architectuur veel meer complexiteit.
Langzaam valt het ontwikkelteam 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?
Binnen een nieuwe architectuur die bijvoorbeeld in de cloud draait, gaat integreren vaak relatief makkelijk. Ook de legacy-systemen laten zich makkelijk verbinden on premise. Beide verbinden, cloud services met on premise-applicaties, is echter hel.
Lessons
- 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 zult 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 als nieuwe applicaties kunnen worden verbonden. Vaak is dit een broker of een gateway van waaruit de cloud en on premise mee kan worden verbonden. Beide kanten zullen hier netwerk-technisch toegang tot moeten krijgen.
De mate van complexiteit
Oke, het project begint al aardig op stoom te komen. Er is inmiddels een helder beeld van het aantal integraties. De enterprisearchitect heeft een ‘praatplaat’ gemaakt, waarbij elke verbinding tussen middleware en applicaties één lijntje vormt. De solutionarchitecten 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. Intussen is de integratie al een aardig lange keten geworden. Tenslotte gaan de ontwikkelaars aan de slag, blijkt er nog een aantal lijken uit de kast te vallen en zijn er nog wat technische hobbels die overwonnen moeten worden.
Het oorspronkelijke plaatje:
De uiteindelijke integratie:
Maar dit gaat slechts over de integratiestappen die daarbij komen kijken. In moderne integraties zijn er nog heel andere uitdagingen, namelijk:
- infrastructuur
- security
- 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 voegt vanuit het integratieperspectief eigenlijk geen businesswaarde toe.
Het proces voor toegang vragen, netwerkconfiguratie, 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 twee belangrijke feiten niet:
- door hoeveel (fysieke en virtuele) lagen hun gegevens moeten gaan, vanaf toepassing A tot het bereiken van toepassing B
- 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 wekenIk 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.
Lessons
Lesson learned 3: oog voor infrastructuur
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, door refactoring en soms door “nee” te zeggen op de integratielaag. Leonardo da Vinci wist het al: “eenvoud is de ultieme vorm van verfijning”.
Het team
Het projectbudget is er eindelijk doorheen, het is 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 rechtstreekse opleiding voor en vaak hebben IT’ers alleen zijdelings met integratie te maken gehad. In functiebeschrijvingen 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 technologieë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 omgaat. Een integratiespecialist is iemand die:
➣ graag naar anderen luistert
➣ voldoening haalt uit het helpen van anderenWat 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 integratiewerk 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.
Lessons
Lesson learned 5: een evenwichtige skillset
Vaak is IT opgedeeld in praters en regelaars aan de ene zijde en technici aan de andere zijde. Uiteraard heb je daar allerlei smaken in. Bij een integratiespecialist is dit vrijwel altijd 50/50, waardoor de soft en hard skills 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 een 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 productie name 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 om te hebben…
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 integratielaag en 💥 … de data komt niet door, applicaties vertonen fouten en de backend 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 integratieteam en zeg hen dat de middleware niet werkt
Yep … ‘b’ is meestal de keuze. En hier moet je al je integratieteamleden (vooral junioren) op voorbereiden. Hoe groter bedrijven zijn, hoe zwakker de communicatie is tussen verschillende IT-teams (die zich vaak letterlijk aan de andere kant van de wereld bevinden).
Integratie als ‘lijm en brug’ geeft meestal 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 een slecht licht (wat frustrerend 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 initiëren.
Lessons
Lesson 7: zichtbaarheid
Integratiespecialisten: als je het gevoel hebt dat je onzichtbaar bent, is dat oke — het betekent dat je goed werk levert.
Lesson 8: erkenning
De enige manier om een situatie te voorkomen waarin mensen hun fouten verbergen, vervagen en bedekken, is hen te laten zien dat fouten kunnen worden gemaakt en dat dit 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 integratiewerk, kan zelfs ‘b’ oke zijn voor integratiespecialisten. Laten we streven naar een oplossing, niet alleen naar het vinden van ‘schuldigen’.
Twee mensen
Stel je een hightech 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 competitieve 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 landschap. En raad eens, de hele integratielaag 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 onvoorspelbare productieomgeving verstoort 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.
Lessons
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 moeten 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.
Inhoudsopgave:
