integratie proces

Het is maart. Een vaag zonnetje schijnt en de wind waait nog guur op het verder verlaten industrieterrein. Maar het is zover. Robèrt van Beckhoven, Neerlands meesterbakker neemt de schaar en knipt het lint door. De fabriek is geopend. Ja, nog niet alle productielijnen zijn af, maar zullen de eerste mensen Annekes appeltaart eten. Robert roemt de kwaliteit van de recepten en hoopt dat heel holland niet bakt, maar kennis gaat maken met de taarten van Anneke.

De productielijn

Een bakkerij kent verassend weinig mensen in de productielijn. Grote balen met ingredienten als meel gaan in in grote order waarna een lange oven de broden of taarten bakt. Deze worden automatisch verpakt. Hoe meer variatie en maatwerk, hoe meer mensen er bij komen te kijken. Bij de productielijn van data integraties is er vaak veel maatwerk, waardoor er weer verrassend veel mensen aan werken. Toch met goede standaarden en richtlijnen, kan er aardig gericht worden om een productielijnen waar bij nieuwe en gewijzigde integraties mogelijk zijn.

Traditioneel staan er een aantal rollen aan de productielijn van een integratie. De meest bekende zijn:

• Analist
• Ontwikkelaar
• Tester
• Beheerder

Analist

De analist vormt de brugfunctie tussen de business en technologie. Het spreekt vaak eerst over functionaliteit, business processen en de betrokken applicaties. De volgende stap is het proces op te delen in één of meerdere integraties. Per integratie is er een ontwerp, maar daarin meestal de applicaties en integratie service onderverdeeld in een diagram met swimlanes. Soms wordt er officiële notatie voor gebruikt, zoals BPMN, maar dit is niet striks noodzakelijk. Een integratie heeft een bron van de data en een destination. Daartussen zitten de verschillende verwerkingsstappen.

Vaak moeten de verschillende stappen op detailniveau worden uitgewerkt. Dit komt, omdat zaken op functioneel vaak beschreven in de vorm van "wat". Een high-level resultaat. Om het te bouwen moet het precies. Functioneel wil ik een taart met appels, maar om het recept (het ontwerp) daadwerkelijk moet ik precies weten welke appels en hoeveel gram nodig is en in hoe grote stukken ze gesneden worden. Bij software luistert het eigenlijk nog nauwer.

Stel de analist geeft aan orders van het type 6 moet gerouteerd worden naar applicatie B. Wat is dan precies het veld waarop gerouteerd worden? Misschien zijn er meerdere kandidaten. Naast routering en filterts, staat in het design met name veel over de connecties en de mapping van de formaten. Bij mapping gaat het dat veld X bij het ontvanged systeem veld Y heet. Goede voorbeelden zijn ook belangrijk om te beginnen

Vaak wordt het ontwerp nog doorgenomen met architecten en developers. Is dit werkelijk wat we willen? Is het technisch uitvoerbaar? Bij sommige organisatie wordt een "Definition of Ready" gebruikt, waarbij het ontwerp compleet geacht wordt om te bouwen.

Ontwikkelaars

Integratie ontwikkelaars zijn meestal geen diehard programmeurs, maar eerder duizendpoten. Zij moeten de principes van het ontwerp begrijpen en zich aanpassen aan de standaarden van de organisatie en technologiën van de applicaties. Een programmeur bevindt zich vaak in één domein, bijvoorbeeld .Net of Java. Bij integratie verschillen de technologiëen, zoals databases, API's en talen. Zo kan een .Net webservice heel anders zijn opgebouwd als één in Java. Met behulp van integratie frameworks, tools en code wordt een integratie gebouwd. Soms kan dit binnen één integratiefunctie, bijvoorbeeld een API Management. Vaak zijn er meerdere tools tegelijk nodig.

Bij het bouwen sluiten de ontwikkelaars aan bij de architectuurrichtlijnen, maar meestal aangevuld met volgende standaarden:

* Code en configuratie standaarden
* Naamgevingstandaarden
* Versiebeheer procedures (bijv een GIT flow)
* Review procedure
* Test procedure
* Versienummering

Vaak zie je dat de code en naamgevingsstandaarden aansluiten bij programmeerstandaarden. Bijvoorbeelden standaarden uit de Java wereld voor het noemen van een Class. Ondanks dat dit gangbaar is, is het niet altijd het meest logisch. Immers niet object of functies vormen de kern van data integratie, maar data, flows, API's en berichten. Vaak wordt de entiteit (meervoud is gangbaar, in tegenstelling tot database entiteiten) als basis genomen. Bijvoorbeeld "articles" of "orders".

Het ontwikkelproces loopt meestal lokaal, waarbij de ontwikkelaar stap voor stap de integratie bouwt (programmeren of configuren) en test. Uiteindelijk als de stappen samen een service vormen wordt vaak nog unit test gebouwd. Dit proces met behulp van version control als SVN of GIT verschilt niet heel van applicatieontwikkeling, maar de integratie ontwikkelaar zal vaker op tooling op iets hoger niveau terug grijpen.

Tester

Een tester kijkt niet slechts of er volgens ontwerp is gebouwd, maar kijkt vooral ook naar de verschillende wegen die data kan doorlopen. Is het bericht wel of niet door de filter gegaan. Er zijn vaak veel scenario's mogelijk. Leidend is of de data output overeenkomt met de verwacht output. Daarbij kan gekeken worden naar specifieke integratie services, maar over het algemeen kijken de testers naar het businessprocess. Dus de analist gaat van het business process naar de technische integratie, de ontwikkelaar bouwt deze, terwijl de tester weer terug keert naar het business process.

Beheerder

Het domein van de beheerder is de productieomgeving. De rol van integratiebeheerder ligt dicht bij die van applicatiebeheerder. Draait het integratieplatform goed en de integraties er boven op. Als eerste is de beheerder de gatekeeper. Is de integratie correct gebouwd, getest en gedocumenteerd. Vervolgens is de beheerder verantwoordelijk voor de deployments van integraties. Correcties bij incidenten, inclusief foutafhandeling. Alles om de continuïteit te bewaken

Op beheervlak is de afgelopen jaren zeer veel gebeurd. Belangrijkste ontwikkeling:

• CI/CD: Geautomatiseerd, continu en voorspelbaar in productnemen van programmatuur.
• Log management: Automatisch inlezen van logs in een search engine (Elastic, Solr, Splunk etc)
• Monitoring: monitoren van servers, tools en integraties

De kern van een moderne beheerder is data-driven te werk te gaan, zodat altijd duidelijk is wat er aan de hand is en de data kan worden gebruikt als stuurinformatie voor verbeteringen.

Processen

De belangrijkste processen van integratie:

• Incident proces
• Problem proces
• Change proces
• Release proces
• Test proces
• Continuous Improvement proces
• Application lifecycle management proces

Incident/Problem/Change

Incident/Problem/Change proces zijn niet anders voor integratie als voor andere software. Incident herstelt verstoringen, het problem proces lost structurele fouten/verstoringen op en change begeleid wijzigingen. Procesraamwerken als ITIL beschrijven deze processen uitgebreid. Hier gaan we alleen kort op integratie specifieke zaken:

• Incidenten: Specifiek voor integratie is dat er een hoop componenten van derde partijen in zitten. Een integratie is gevoelig voor netwerkverstoring, corrupte of incomplete data, ontvangende sytemen. Een voorbeeld is dat er artikeldata van Nestlé en de programmatuur of het onvangende systeem niet met een accent op de é overweg kan. In deze geval is het vaak onvoldoende om alleen de fout te loggen, maar ook de bericht op een error destination te plaatsen, zodat deze kan meegenomen in de foutanalyse en indien nodig opnieuw aangeboden worden. Vooral modernere systemen, zoals Kafka, houden expliciteit rekening met netwerkverstoring of dat consumers uit de lucht zijn.

Pieperdienst

De meeste integraties werken 24/7. Een klant kan 's nachts een bestelling plaatsen of er werkt een batch in de nacht. Daarnaast zijn de integraties de levensader voor data van het bedrijf. Beide maakt dat het instellen van een pieperdienst onvermijdelijk is. Hierbij kan rekening gehouden met:

1. Pieperdiensttijden: Op welke tijd loopt het dagelijkse beheer en wat valt hier buiten? Is het alleen doordeweeks nodig of ook in het weekend? Voorbeelden zijn 10/5, 12/6 en 24/7. Meestal loopt de pieperdienst van maandagavond tot/met maandagochtend (waarbij maandag een eventuele overdracht kan plaats vinden)

2. Pieperdienstvergoeding: Het draaien van pieperdiensten (met name bij 24/7) heeft een grote impact op medewerkers. Immers moet deze rekening houden snel te kunnen inloggen op systemen. Bij 24/7 dien je dan altijd je laptop bij te hebben, ook als je naar een verjaardag of feestje gaat. Ook kan je midden in de nacht iets moeten herstellen. Het gaat hierbij om vragen als: Wat is de vergoeding per uur? Hoe om te gaan met zon- en feestdagen? Hoe om te gaan met extra gemaakte uren? Hoe moeten deze uren administratief worden afgehandeld.

3. Pieperdienstafhandeling: Wat zijn de verwachtingen wanneer een incident gebeurd? Wat is de reactietijd? Over het algemeen wordt er verwacht dat er binnen een half wordt gereageerd. De dienstdoende beheerder zorgt er voor dat de normale stand van zaken hersteld wordt en eventuele stakeholders geïnformeerd. Administratie (Uren, Tickets), Root-Cause analyse vindt later plaats.

4. Pieperdiensten draaien: Wie gaan de pieperdiensten draaien. Meestal zijn dit technici (DevOps) met toegang tot productiesystemen. Daarnaast dient er een weekrooster worden gemaakt, rekening houdend met vakanties.

5. Derden partijen: Bij integratie dient ook rekening gehouden met SLA met derde partijen. Je kan wel een pieperdienst inregelen, maar als SaaS applicaties van bijv Unit4 of ADP eruit liggen dan moet het wel zin hebben ze op bepaalde uren te connecteren en vragen dit te herstellen.

6. Alerting: Tenslotte dienen degene die pieperdienst draaien niet actief te monitoren, zij dienen getriggered te worden door een monitoringsysteem. Voorbeelden zijn bepaalde alerts per SMS sturen, Telegram of Mail notifier (we gebruiken bijvoorbeeld eNotify die mailbox kan monitoren en op basis van de afzender en/of onderwerp een piepje op de smartphone laat afgaan.

De start voor het opzetten van de pieperdienst voor integratie is meestal de lijst met integraties door te nemen met de business. Wanneer draaien deze en wat is de impact als de niet loopt, fouten loopt. Moet het direct hersteld worden of kan het ook de volgende ochtend. Uiteindelijk moet de businesswaarde duidelijk hoger zijn als de kosten van de pieperdienstvergoeding. Voorbeeld van de pieperdienst bij een supermarkt:

Supermarkten zijn tegenwoordig elke dag open (Zelfs op zon- en feestdagen). De meeste distributiecentra starten om circa 4 uur met de orders te picken, zodat deze daarna door de vrachtwagen gebracht om de filialen de bevoorraden. Wanneer DC’s geen orders bevatten, kostte dit meer dan een ton per uur. Redenen voor de supermarkt om 24/7 diensten te draaien.

Releaseproces

In het begin was het nog makkelijk. Anneke bakte gewoon de taart en gaf die aan een gelukkig persoon. Piece of cake. Bij grote aantallen dien je leveranciers, medewerkers en klanten op elkaar af te stemmen. Ze moeten goed inzicht hebben in welke fase wat gebeurd. Zomaar aan de slag te gaan is een recept voor mislukking.

Bedrijven hebben vaak een groot applicatielandschap, waar overal in projecten en scrums gewerkt wordt. De interfaces (bijvoorbeeld API's) worden voortdurend aangepast. Een goed versiebeheer en releaseproces is daarom van cruciaal belang om niet alles in de soep te laten lopen.

Het releaseproces zorgt er voor dat de code door alle verschillende fases gaat, dat in elke fase precies weet wie welke code heeft gemaakt en uitgerold.

OTAP

Rechtstreeks in productie interfaces aanpassen is iets wat in elk bedrijf gebeurd. Hoe groter en complexer de omgeving, hoe meer de behoefte is gefaseerd en stapsgewijs te werk te gaan. Meestal wordt er gestart met een aparte ontwikkelomgeving. Zodra er ketentesten plaatsen vinden dan wordt er vaak een aparte testomgeving en voor gebruikerstesten een acceptatieomgeving. Laatste is meestal gelijk aan productie.

De gangbare acroniem is hier OTAP straat (Ontwikkel, Test, Acceptatie, Productie) of in het Engels DTAP(Development, Test, Acceptance, Production). Hoeveel omgevingen je nodig is vaak afhankelijk van bedrijfsgrootte. Een klein bedrijf heeft wellicht voldoen aan een OP of een OTP straat. Grotere bedrijven voegen soms nog een preproductie, een uitwijk of een opleidingsomgeving toe.

Een goed ingerichte OTAP-straat is het halve werk. Het voorkomt issues in productie, daar waar klanten, medewerkers of beheer direct last van hebben. Het voorkomt daar veel ergernissen en kosten. Toch is een goed ingerichte OTAP-straat vanuit integratie-perspectief lastig. Vaak zie je dat er bij aangesloten applicaties verschillen bestaan. Zo heeft de ene applicatie wel een acceptatieomgeving en de andere niet. Of is de rol verschillend. In dit geval zijn ketentesten lastig op te zetten.

Versiebeheer

Versiebeheer of versioning houdt alle wijzigingen van alle code (tekstbestanden) bij. Er zijn hier twee smaken te vinden, namelijk centraal of decentraal. Bij centraal wordt de code centraal opgeslagen code wordt geupload/gedownload van een naar de server. Bekendste voorbeeld is Subversion (SVN). Bij decentrale versiebeheer heeft ieder een volledige kopie van de code en is er dus geen centrale server nodig. Bekendste voorbeeld is GIT.

Over het algemeen verschilt het versiebeheer bij integratie niet zozeer van gewone applicatieontwikkeling. Wel zie je dat applicatieontwikkeling vaak een applicatie in één project is ondergebracht, terwijl bij interfaces vaak meerdere projecten (tientallen) worden gebruikt.

Releases

De code moet uiteindelijk samengesteld worden, zodat ze kunnen worden uitgerold op een OTAP omgeving. Bij applicatieontwikkeling wordt dan broncode omgezet naar binaire code. Vaak is dit voor integratie tools of platforms niet nodig, omdat ze al op een hoger niveau opereren. Een samenstelling van de tekstbestanden is dan vaak genoeg.

Tailoring

Een issue dat met name voor de connectiviteit speelt is dat sommige parameters verschillen per omgeving. Op test zullen de berichten bijvoorbeeld naar een andere URL worden gestuurd dan op productie. Uiteraard mag dit niet omgedraaid worden. Om voor de juiste omgeving de juiste parameters te kiezen wordt gebruik gemaakt van tailoring. De broncode wordt tailor-made gemaakt voor een specifieke omgeving in de OTAP-straat.

Deployment

Dit bevat de daadwerkelijk installatie van de release op een specifieke omgeving in de OTAP-straat. De bouw van het installatie bestand en de uitrol is meestal op basis van een (build)script.

Build programming languages

De taken in releaseproces zoals versiebeheer, releases, tailoren en deployen horen bij elkaar. Tegenwoordig zijn er meerdere Domain-Specifieke programmeertalen (DSL) die zich op deze taken richten. Meest gangbare zijn Ant, Maven en Gradle.

Communicatie

Een onderdeel van het releaseproces is het aankondigen, toetsen en publiceren van releases. Het aankondigen geeft aan dat wanneer de release plaats vind en welke systemen er worden geraakt. Het toetsen gebeurt meestal door specialisten in bijvoorbeeld een Change Management/Advisory Board om de impact te bepalen en de afstemming met andere wijzigingen. Het publiceren geeft meestal aan dat de wijziging actief is en link naar de documentatie.

Testproces

Het testproces geeft aan in welke volgorde test worden genomen en door wie. Hierbij wordt vanuit gegaan dat niet geslaagd testen rework opleveren. Dat wil zeggen een aanpassing door een developer, herstellen van een verbinding of verbetering van een release. Het proces is opgesteld bij Test types van verschillende integraties

Basisproces testen: Nieuwe integratie

1. Connectie test: Een nieuwe integratie start met het testen van de verbinding. Reden is dat er hier een afhankelijkheid is van derde partijen. Dit zijn bijvoorbeeld de leveranciers of netwerkbeheer.

2. Unit test: Het testen van de programmatuur. Een unit test is in dit stadium nog niet heel relevant, maar is vooral van belang bij wijzigingen. De connecties zijn vervangen door mockup.

3. Module test: Dit test met reallife input van de bron of een bericht goed verwerkt wordt door de module en de output goed ontvangen wordt. Soms wordt ook onderdeel gezien van een unit test zonder mockups (maar dat laat het lastiger automatiseren voor CI/CD).

4. Smoke test: Na release een korte test of alles vergelijkbaar werkt als in de module test, maar dan op een test of acceptatieomgeving. Hiermee

test je voral de uitrol. Denk hierbij is de uitrol volledig, maar vooral ook aan verschillen tussen de ontwikkel omgeving en test/acc zoals verbindingen en omgevingsvariabelen (properties). Doel is ook dat er technische fouten op te sporen, zodat er goed getest.

5. Functioneel (keten) test: Test van een volledige interface door middel van scenarios. Deze loopt van bron naar doelapplicatie. Hier wordt daadwerkelijk ook naar de inhoud van de output gekeken. Allereerst meestal door de gangbare situatie (happy flow), vervolgens naar alternatieve verkomende scenario's en ten slotte naar foutscenarios. De ketentest is de meest volledige test. Als deze slaagt

6. Release test: De beheerder test de uitrol op de acceptatieomgeving. Hiermee bekijkt of aan alle acceptatiecriteria (technische overdracht) is voldaan.

7. Load test: De beheerder test of de interface met gangbare load (op basis van representieve data) functioneert. Eveneens test deze de maximale capaciteit.

8. Shadow test: De beheerder test op een pre-productie systeem met live data of een nieuwe wijziging geen fouten oplevert. Deze test is minder gangbaar bij kleinere omgeving of zie je alleen bij grotere upgrade of migraties naar een ander integratie platform.

9. Acceptatie test: De gebruikersorganisatie test integratie op basis reallife data. Ze zien de integratielaag als een blackbox en gaan alleen van applicatielaag aan. Hier is de invoer en bekijken, zoals ook op productie gebruiken.

Moderne productielijnen

Bij laten lopen van een goede "Code factory", of in dit geval een productielijn die integraties produceert komt veel kijken. Het zijn vaak niet de software componenten, maar bovenstaande processen die het zo tijdsintensief maken om een goed integratie platform op te zetten. Het hoort bij het continu verbeterproces om de productielijn steeds te optimaliseren. Dit kan door procedures aan te scherpen of integraties te verbeteren. Er verschillende manier om de productielijnen te moderniseren. Belangrijkste zijn:

Cloud

Cloud richt zich met name op het wegnemen van het installeren en draaien van software. Traditioneel zou berekenen wat de capaciteit is, daar een server voor aanvragen, vervolgens de integratie software op installeren en configuren. Ten slotte dient deze nog gemonitoord worden en de loggingen weggeschreven. Al deze zaken nemen cloud diensten weg, waarbij deze zaken door de cloud vendor kunnen worden overgenomen.

Continuous Integration/Continuous Delivery

Bij Continuous Delivery gaat het om sneller, vaker en voorspelbaarder opleveringen te kunnen doen. Het sleutelwoord is het automatiseren van onderdelen van de productielijn. Bij een fabriek zou je kunnen denken aan robotisering, bij software (zoals integraties) gaat het om automatisering. Het automatiseren van het bouwen van software package, geautomatiseerd testen en geautomatiseerd deployen. Veelal met behulp van scripts (build scripts, test scripts en deploy scripts) die je in een pipeline achter elkaar en door een CI/CD server (zoals Jenkins of Bamboo) laat uitvoeren.

Low code

Veel traditionele organisatie gaat uit van een IDE waarin de integratie lokaal ontwikkelt worden. Soms wordt de integratie volledig in code uitgeschreven en lokaal getest. Via versiebeheer/continuous delivery wordt deze vervolgens gedeployed op een server. Bij low-code werk je eigenlijk al rechtstreeks op een testomgeving en niet in code, maar zoveel mogelijk grafisch. De business anlist ontwerpt en bouwt de integratie in één keer.

In de praktijk maken de ontwikkelingen het maken van integraties makkelijker en sneller, maar low-code is nog altijd niet zo flexibel als low-level integraties te maken. Tegenwoordig zie je dat organisatie eenvoudige integraties (zeg maar een standaard taart) via een moderne productielijn laten lopen, maar nog altijd de mogelijkheid behouden om complexere integraties via maatwerk (de bruidstaart, zeg maar).