9. Processen

Integreren is geen technologie, maar een proces

Het is maart. Een vaag zonnetje schijnt en de wind waait nog guur over het verlaten industrieterrein. Maar het is zover, Robèrt van Beckhoven, Neerlands meesterbakker, neemt een grote schaar in de hand en knipt het lint door. De nieuwe fabriek van “The Bakery Group” is geopend.

Ja, nog niet alle productielijnen zijn af, maar de eerste mensen zullen Aleksandra’s beroemde appeltaart weldra eten. Robèrt roemt de kwaliteit van de recepten en hoopt dat heel Holland niet bakt, maar kennis maakt met de taarten van Aleksandra!

De productielijn

Een bakkerij kent verrassend weinig mensen in de productielijn. Grote balen met ingrediënten als meel gaan in grote machines waarna een lange oven de broden of taarten bakt. Aan het einde ruikt het naar vers brood en wordt het snel automatisch verpakt.

Hoe meer variatie en maatwerk, hoe meer mensen er bij komen kijken. Bij de productielijn van data integraties is er vaak veel maatwerk, waardoor er weer verrassend veel mensen aan integraties werken. Toch met goede standaarden en richtlijnen, zijn nieuwe en gewijzigde integraties snel te realiseren.

Traditioneel staat er een aantal rollen aan de productielijn van een integratie.

De meest bekende zijn:

• Analist
• Ontwikkelaar
• Tester
• Beheerder

Er zijn natuurlijk veel andere rollen bij betrokken, zoals architecten, product owners, scrum masters en managers. Die staan echter niet zozeer aan de ‘productielijn’ zelf.

Data Analist

De analist vormt de brugfunctie tussen de business en de technologie. Een analist spreekt vaak eerst over de gewenste functionaliteit, de business processen en betrokken applicaties. De volgende stap is het business proces op te delen in één of meerdere integraties. Per integratie is er een ontwerp, waarin meestal de applicaties en integratie services onderverdeeld zijn in een diagram met swim lanes. Soms wordt er een officiële notatie gebruikt, zoals BPMN, maar dat is niet strikt noodzakelijk.

Op functioneel vlak wordt vaak beschreven “wat” er nodig is. Dit is nog erg high-level. Om het te bouwen moet het “hoe” precies beschreven worden. Functioneel wil ik bijvoorbeeld een taart met appels, maar om het recept (het ontwerp) daadwerkelijk bruikbaar te maken moet ik precies weten welke appels nodig zijn, hoeveel gram er nodig is en in welke grootte ze gesneden moeten worden.

Bij software luistert het eigenlijk nog nauwer. Stel: de business geeft aan dat alleen bestelorders van het type 6 naar applicatie B gerouteerd moeten worden. Wat is dan precies het veld waarop gerouteerd wordt? Heet dit veld “type” of “OrderType”? En moet het veld hoofdletters of kleine letters bevatten? Één afwijking zorgt er voor dat de integratie niet werkt.

Naast routeringen en filters bevat het ontwerp veel data over de connecties met de applicaties en de mapping van de formaten tussen applicaties. Bij een mapping gaat het erom dat veld X bij het ontvangend systeem veld Y heet. Goede voorbeelden en schema’s van databerichten zijn ook belangrijk om de mapping op te stellen.

Vaak wordt het ontwerp nog doorgenomen met architecten en developers. Is dit werkelijk wat gewenst is? Voldoet het aan de architectuurrichtlijnen? Is het technisch uitvoerbaar? Bij sommige organisaties wordt een “Definition of Ready” gebruikt, waarbij het ontwerp compleet geacht wordt om te bouwen.

Ontwikkelaars

Integratieontwikkelaars 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 technologieën van de applicaties.

Een programmeur daarentegen bevindt zich vaak in één domein, bijvoorbeeld .Net of Java. Bij data integratie verschillen de technologieën, zoals databases, API’s en talen soms per integratie. Zo kan een .Net webservice heel anders opgebouwd zijn dan één in Java. Met behulp van integratie-frameworks, tools en code worden integraties 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, meestal aangevuld met volgende standaarden:

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

In zoverre wijken deze standaarden niet erg af van wat programmeurs gewend zijn. En vaak zie je dan ook dat de code en naamgevingsstandaarden aansluiten bij programmeerstandaarden. Bijvoorbeeld standaarden uit de Java wereld voor het noemen van een Class.

Hoewel deze werkwijze gangbaar is, is hij niet altijd het meest logische. Immers: niet objecten of functies vormen de kern van data integratie, maar data, flows, API’s en berichten. Vaak wordt de data entiteit, zoals “article” of “order” als basis genomen. Overigens is meervoud gangbaarder bij integraties, in tegenstelling tot bijvoorbeeld database entiteiten. Je zult er van “articles” of “orders” spreken.

Het ontwikkelproces loopt meestal lokaal, waarbij de ontwikkelaar stap voor stap de integratie bouwt (programmeren of configureren) en test. Uiteindelijk, als de stappen samen één service vormen, wordt vaak nog een unittest gemaakt. Dit proces met behulp van version control als SVN of GIT verschilt dus niet heel van applicatieontwikkeling, maar de integratie-ontwikkelaar zal vaker op tooling op iets hoger niveau teruggrijpen.

Het is best practice bij het ontwikkelen van integraties zoveel mogelijk uit te gaan van grafisch modelleren of services te configureren. Dit om beter inzicht te krijgen in de flow van data. In tweede instantie wordt vaak de complexere en maatwerkintegratielogica geprogrammeerd.

Tester

Een integratietester kijkt niet slechts of er volgens ontwerp is gebouwd, maar kijkt vooral ook naar de verschillende wegen die databerichten kunnen doorlopen. Is het bericht bijvoorbeeld wel of niet door het filter gegaan? Er zijn vaak veel scenario’s mogelijk. Elke route wordt als scenario gedefinieerd en getest.

Leidend bij het testen is of de data output overeenkomt met de verwachte output. Daarbij kan gekeken worden naar specifieke integratieservices, maar over het algemeen kijken de testers naar het business-proces. Dus de analist gaat van het business-proces naar de technische integratie, de ontwikkelaar bouwt deze, terwijl de tester weer terug keert naar het business-proces.

Beheerder

Het domein van de beheerder is de productieomgeving. De rol van integratiebeheerder ligt dicht bij die van applicatiebeheerder. Allereerst is de beheerder de gatekeeper van de productieomgeving. Is de integratie correct gebouwd, getest en gedocumenteerd?

Vervolgens is de beheerder verantwoordelijk voor de installaties van integraties en correcties bij incidenten, inclusief foutafhandeling. Tenslotte gaat het om de productieomgeving zelf. Draait het integratieplatform en de integraties op het platform goed? Alles staat in het teken van de continuïteit van de organisatie.

Op beheervlak is de afgelopen jaren veel gebeurd. De belangrijkste ontwikkelingen zijn:

• CI/CD: geautomatiseerd, continu en voorspelbaar in productie nemen van nieuwe software
• Log management: automatisch inlezen van logs in een search engine (Elastic, Solr, Splunk etc)
• Monitoring: het 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 gebruikt kan worden als stuurinformatie voor verbeteringen. Daarnaast gaat hij preventief te werk, om zo incidenten te voorkomen.

Governance

De klant en aannemer willen er uiteraard op toezien dat de fabriek en het produceren in de fabriek aan de verwachtingen voldoet. Hier is een stuk governance voor nodig. Bij integratie gaat het bij governance om de volgende zaken:

1. Principes

Architectuurprincipes zijn richtinggevende uitspraken die aangeven wat wenselijk is. Een architectuurprincipe kan worden gezien als een beleidsuitspraak die specifiek betrekking heeft op de inrichting van organisatie, processen en informatievoorziening.

Bij integratie is het bijvoorbeeld vaak een principe om van open standaarden (denk aan HTTP of OpenAPI) gebruik te maken. Een ander bekend principe is die van “ontkoppeling”. Applicaties worden niet op elkaar aangepast (tightly-coupled), maar maken gebruik van berichten en middleware voor uitwisseling van gegevens (loosely-coupled).

Een bekende lijst met architectuurprincipe zijn de NORA-principes (https://www.noraonline.nl/wiki/Principes). Dit zijn principes van de overheid voor een referentiearchitectuur van het IT landschap. Ook buiten de overheid wordt hier vaak gebruik van gemaakt.

2. Control mechanismes

Verschillende momenten in het voortbrengingsproces zorgen voor het in control zijn. Dat wil zeggen dat architectuurprincipes en organisatierichtlijnen worden uitgevoerd. Vaak zie je dat bij overdrachtssituatie deze mechanismes in werking treden. Bijvoorbeeld als het ontwerp overgedragen wordt om te ontwikkelen, bij het testen van de integratie (quality assurance) en bij de inproductiename. Denk aan checks door beheer en change management.

3. Meten

Vroeger werd de integratielaag puur gezien als black box. In zekere zin is dit vanuit de applicatielaag nog steeds zo. Organisatiebreed is echter veel meer de nadruk gekomen om te sturen op basis van data. Daarbij geldt het aloude “meten is weten”. Door middel van monitoring, performance en logging weten we waar iets gebeurt en wat er gebeurt.

4. Communicatie

Bij integratie zijn per definitie altijd meerdere partijen betrokken. In elke fase (ontwerp, bouw, test en productie) dienen de verschillende partijen op de hoogte worden gebracht. Governance moet er voor zorgen dat er niet te weinig, maar zeker ook niet te veel wordt gecommuniceerd.

5. Verantwoordelijkheden

De keten van verantwoordelijkheden heeft bij integratie twee aspecten. Enerzijds de verdeling van verantwoordelijkheden bij het voortbrengen van nieuwe integraties, inclusief overdrachtsmomenten. Anderzijds verantwoordelijkheden van data tijdens uitwisseling tussen systemen. Dit laatste heeft te maken met wat te doen bij incidenten en hoe rekening te houden met privacy-wetgeving.

Binnen de richtlijnen

Richtlijnen

Aan de hand van richtlijnen (in het Engels meestal guidelines) wordt de implementatie gestuurd. Het zorgt ervoor dat je een vaste kwaliteit uitdraagt en je er ook bewust van bent als je hiervan afwijkt. In de woningbouw is bijvoorbeeld de richtlijn de bouwstenen verzet neer te leggen, alle muren zijn dan niet alleen stevig, ze zien er ook hetzelfde uit.

Richtlijnen bij integraties richten zich vaak op vragen als:

1. Welke patterns horen op de integratielaag en welke niet? Bijvoorbeeld routing is onderdeel van de integratielaag, maar berekeningen niet.
2. Wat is de naamgeving van integraties?
3. Wat zijn de richtlijnen voor security?
4. Wat zijn de richtlijnen voor protocollen?
5. Wat zijn de richtlijnen voor data formats?

Een richtlijn bij integratie kan bijvoorbeeld zijn “Cloud-first” en “API-Driven”. Dat wil zeggen: bij de verwerving van een nieuwe applicatie prefereer je een SaaS-applicatie die via REST communiceert boven SFTP. Goede richtlijnen zorgen ervoor dat vragen beantwoord kunnen worden met behulp van een beslisboom.

In de praktijk zie je bij integraties vaak een druk op het naleven van de richtlijnen, omdat van integratie wordt verwacht dat zij de “lijm” in de organisatie vormen. Het actief naleven van richtlijnen levert echt veel voordelen bij de schaalbaar- en onderhoudbaarheid van de omgeving.

Standaarden

Een standaard is een set van regels die beschrijven hoe mensen materialen, producten, diensten, technologieën, taken, processen en systemen dienen te ontwikkelen en beheren. In sommige gevallen zijn deze verplicht. Bijvoorbeeld als de uitwisseling volgens een specifieke EDI-standaard moet lopen of de authenticatie via de OAuth- of SAML-standaard. Als het niet volgens deze standaarden loopt dan mag het niet geïmplementeerd worden.

Get Raymond Meester’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In andere gevallen kan een bepaalde standaard alleen een richtlijn zijn. Bijvoorbeeld dat JSON of XML geprefereerd wordt boven ASCII en CSV. Ook hier geldt vaak dat buiten security wordt verwacht dat de integratielaag relatief flexibel omgaat met verschillende standaarden.

Fases

Een integratie omgeving opbouwen gaat grofweg in drie fases. Daarin worden telkens dezelfde stappen doorlopen.

Implementatiefase

De implementatiefase kenmerkt zich door introductie, vervanging of vernieuwing van het integratieplatform. Integratieplatformen ondersteunen meestal meerdere architectuurstijlen. De eerste stap bestaat vaak uit het bepalen van de architectuurstijl. Vaak zie je later dat er meerdere stijlen door elkaar lopen, maar dat zou zeker niet het uitgangspunt moeten zijn. Uiteraard is dit een requirement dat aan bod komt bij de aanschaf van het integratieplatform.

De tweede stap is de inrichting van het platform. Bij cloud (iPaaS) is deze stap al gedaan, maar bij on premise zal het systeem geïnstalleerd en geconfigureerd moeten worden.

In deze stap ben je nog niet met de daadwerkelijke integratie bezig, maar met de fundamenten om data interfaces te kunnen draaien. Je kunt het vergelijken met een metrotunnel: eerst moet de tunnel er zelf komen. De tunnel moet geboord worden en de wanden moeten gestut worden. In de volgende fase ga je de daadwerkelijke rails leggen waar ‘de metro’ over gaat rijden. In deze fase gaat het om de data die je over het platform laat lopen. Als je de databerichten hebt vastgesteld die bij de implementatie van belang zijn, ga je een ontwerp per databericht maken. Elk databericht is een aparte metrolijn. Elk station zou je als een aparte stap kunnen beschouwen. Dit kan een technische stap of een functionele stap zijn. Als alle stappen en wat in de stappen gebeurt compleet zijn is het ontwerp van de data interface af.

Het hangt een beetje van de werkwijze af, maar je kunt het ontwerp van alle data interfaces van te voren vastleggen. Meestal wordt tegenwoordig voor een meer agile benadering gekozen, waarbij eerst een eenvoudige interface wordt opgezet, het ontwerp wordt aangepast en er steeds weer een schakel aan de integratielaag wordt toegevoegd.

Je komt nu in de bouwfase. Hoe te bouwen is sterk afhankelijk van het integratieplatform. Het ene platform levert grafische tools, andere gaan van programmeren uit.

Zodra het platform opgebouwd is zal in de testfase eerst gekeken worden of berichten van A naar B komen. Dit noemen we unit of technische testen. Vervolgens zullen er end-to-end ketentesten uitgevoerd worden, waarbij gekeken wordt of de data gebruikt kan worden als informatie door de business. In sommige gevallen is er nog acceptatiefase door de eindgebruikers. De laatste fase is die van inproductiename.

Uitbreidingsfase

In de uitbreidingsfase worden de interfaces op het platform verder uitgebouwd. Net als een extra aftakking naar een andere wijk of een nieuw metrostation, komt er een aftakking naar een nieuw aangeschaft systeem. Dit kunnen nieuwe applicaties of databerichten zijn. Zolang het applicatielandschap evalueert, evalueert het integratie platform mee.

Bij elke uitbreiding zullen dezelfde stappen worden doorlopen. Dus ook bij een aanpassing aan een bestaande interface wordt een integratie ontworpen, gebouwd, getest, geaccepteerd en in productie genomen. En net als in metrosysteem zorgen aanpassingen in een productieomgeving voor meer voorzichtigheid. Vaak ligt een metrosysteem in de nacht nog stil, maar integratiesystemen verwerken doorgaans 24/7 data.

Uitfaseringsfase

De laatste fase begint als het integratieplatform niet meer gebruikt wordt. Het kan zijn dat er nieuwe integratiecomponenten worden ingezet, een nieuwe architectuurstijl of een ander platform. Vaak zie je dat er per databericht over wordt geschakeld.

Het is niet ongebruikelijk dat deze fase wordt verwaarloosd. De aandacht gaat volledig uit naar het nieuwe platform en er komen nieuwe eisen en wensen van de business.

Met name vanuit ontwikkeling en beheer zal hier constant aandacht moeten worden gevraagd. Integraties die nog steeds in gebruik zijn, kosten tijd en geld voor onderhoud. Ook de resources van servers die blijven draaien kosten geld. Een ander belangrijk argument is een groter risico op beveiligingslekken vanwege verouderde software.

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

Het incident proces, het problem proces en het change proces zijn niet anders voor integratie dan voor andere IT afdelingen. Het incident proces herstelt verstoringen, het problem proces lost structurele fouten op en het change proces begeleidt wijzigingen. Procesraamwerken als ITIL beschrijven deze processen uitgebreid. Hier gaan we alleen kort in op integratie-specifieke incidenten.

Incidenten

Specifiek voor integratie is dat er een hoop componenten van derde partijen in zitten. Een integratie is gevoelig voor netwerkverstoringen, corrupte of incomplete data, of voor verstoringen bij ontvangende systemen. Een voorbeeld is dat er artikeldata van Nestlé en de programmatuur of het ontvangende systeem niet met een accent op de é overweg kan. In dit geval is het vaak onvoldoende alleen de fout te loggen, er moet ook het bericht op een error destination geplaatst worden, zodat deze kan worden meegenomen in de foutanalyse en indien nodig opnieuw aangeboden kan worden. Vooral modernere systemen, zoals Kafka, houden expliciet rekening met netwerkverstoring of een situatie waarin consumers tijdelijk uit de lucht zijn.

Pieperdienst

Integraties zijn de levensader van een bedrijf. De meeste integraties werken daarnaast 24/7. Een klant kan ‘s nachts een bestelling plaatsen of er draait een batch om 2 uur ‘s nachts. Beide maken dat het instellen van een pieperdienst onvermijdelijk is. Hierbij kan rekening gehouden worden met:

• 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).
• Pieperdienstvergoeding: Het draaien van pieperdiensten (met name bij 24/7) heeft een grote impact op medewerkers. Deze moeten er immers rekening mee houden snel te kunnen inloggen op systemen. Bij 24/7 dien je dan altijd je laptop bij je te hebben, ook als je naar een verjaardag of feestje gaat. Ook kun 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 en hoe moeten deze uren administratief worden afgehandeld.
• Pieperdienstafhandeling: Wat zijn de verwachtingen wanneer een incident voorvalt? Wat is de reactietijd? Over het algemeen wordt er verwacht dat er binnen een half uur wordt gereageerd. De dienstdoende beheerder zorgt ervoor dat de normale stand van zaken hersteld wordt en eventuele betrokkenen worden geïnformeerd. Administratie (uren, tickets) en Root-Cause-analyse vindt later plaats.
• 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.
• Derde partijen: Bij integratie dient ook rekening gehouden te worden met SLA’ s met derde partijen. Je kunt wel een pieperdienst inregelen, maar als SaaS-applicaties van bijvoorbeeld SAP eruit liggen moet het wel zin hebben ze op bepaalde uren te contacten en vragen dit te herstellen.
• 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 en er fouten optreden. Moet het direct hersteld worden of kan het ook de volgende ochtend? Uiteindelijk moet de business waarde duidelijk hoger zijn als de kosten van de pieperdienstvergoeding.

Voorbeeld van de pieperdienst bij The Bakery Group:

Het hele jaar door zijn er mensen jarig. De bakkerij begint daarom al ‘s ochtends vroeg te draaien (zelfs op zon- en feestdagen). Als de klanten ‘s avonds bestellen dan moet de taart ‘s ochtends gemaakt worden. Als de integraties tussen de web-, order- en magazijnsystemen niet draaien kost dit duizenden euro’s. Redenen voor The Bakery Group om 24/7-diensten te draaien.

Releaseproces

In het begin was het nog makkelijk. Aleksandra bakte gewoon een taart en gaf die aan een gelukkige 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 gebeurt. Zomaar aan de slag 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 en dat in elke fase precies duidelijk is wie welke code heeft gemaakt en uitgerold.

OTAP-straat

Rechtstreeks in productie interfaces aanpassen en testen is iets wat in elk bedrijf weleens gebeurt. Hoe groter en complexer de omgeving, hoe meer de behoefte is dit te voorkomen en gefaseerd en stapsgewijs te werk te gaan. Meestal wordt er gestart met een aparte ontwikkelomgeving. Zodra er ketentesten plaatsvinden wordt er vaak een aparte testomgeving en, voor gebruikerstesten, een acceptatie-omgeving opgetuigd. Die laatste is meestal gelijk aan de productie.

Het gangbare acroniem is hier OTAP-straat (Ontwikkel, Test, Acceptatie, Productie) of in het Engels DTAP (Development, Test, Acceptance, Production). Hoeveel omgevingen er nodig zijn is vaak afhankelijk van de bedrijfsgrootte. Een klein bedrijf heeft wellicht voldoende aan een OP (ontwikkel/productie) of een OTP (ontwikkel/test/productie)-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 integratieperspectief lastig. Vaak zie je dat er bij aangesloten applicaties verschillen bestaan. Zo heeft de ene applicatie wel een acceptatie omgeving en de andere niet. Of is de rol verschillend. In deze gevallen zijn ketentesten lastig op te zetten.

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.

Versiebeheer

Versiebeheer 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 geüpload/gedownload van en naar de server. Het bekendste voorbeeld is Subversion (SVN). Bij decentrale versiebeheer heeft ieder een volledige kopie van de code en is er dus geen centrale server nodig. Hier is het bekendste voorbeeld GIT.

Over het algemeen verschilt het versiebeheer bij integratie niet zoveel van gewone applicatieontwikkeling. Wel zie je dat in het geval van applicatieontwikkeling een applicatie vaak in één of enkele projecten is ondergebracht, terwijl er bij interfaces vaak meerdere projecten (honderden) worden gebruikt.

Tailoring

Een issue dat met name voor de connectiviteit speelt is dat sommige parameters per omgeving verschillen. In de testfase zullen de berichten bijvoorbeeld naar een andere URL worden gestuurd dan in de productiefase. Uiteraard mag dit niet omgedraaid worden, d.w.z. een productie-URL gebruiken om te testen. Om voor de juiste omgeving de juiste parameters te kiezen wordt gebruik gemaakt van tailoring. De broncode is tailor-made voor een specifieke omgeving in de OTAP-straat.

Deployment

Deployment bevat de daadwerkelijke installatie van de release in een specifieke omgeving in de OTAP-straat. De bouw van het installatiebestand en de uitrol zijn meestal op basis van een (build)script.

Build programming languages

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

Releasecommunicatie

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

Moderne productielijnen

Bij het opzetten van een goede “Code factory”, of in ons geval een productielijn die integraties produceert, komt veel kijken. Het zijn meestal niet de softwarecomponenten, maar bovenstaande processen die het zo tijdsintensief maken een goed integratieplatform op te zetten. Het hoort bij het continue verbeterproces om de productielijn steeds te optimaliseren. Dit kan door procedures aan te scherpen of integraties te verbeteren. Er zijn verschillende manier om de productielijnen te moderniseren. De belangrijkste zijn:

Cloud

Cloud richt zich met name op het wegnemen van het installeren en draaien van software. Traditioneel zou de it-afdeling moeten berekenen wat de benodigde capaciteit is, daar vervolgens een server voor aanvragen en daarop de integratie software op installeren en configureren. Tenslotte dient deze omgeving nog bewaakt te worden en de loggingen weggeschreven. Al deze zaken regelen de cloud-diensten.

Continuous Integration/Continuous Delivery (CI/CD)

Bij Continuous Delivery gaat het erom sneller, vaker en voorspelbaarder opleveringen te kunnen doen. Het sleutelwoord is hier automatiseren van onderdelen van de productielijn. Bij een fabriek zou je kunnen denken aan robotisering, bij software (zoals integraties) gaat het om automatisering, meer specifiek automatisering van het bouwen van software package, geautomatiseerd testen en geautomatiseerd uitrollen. Vaak 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 organisaties gaan uit van een IDE waarin de integratie lokaal ontwikkeld wordt. Soms wordt de integratie volledig in code uitgeschreven en lokaal getest. Via versiebeheer/continuous delivery wordt deze vervolgens uitgerold op een server. Bij low code werk je eigenlijk al rechtstreeks in een testomgeving en niet in code, maar zoveel mogelijk grafisch. De business analist ontwerpt en bouwt de integratie in één keer.

10. Testen & Monitoren

Inhoudsopgave: