-
Notifications
You must be signed in to change notification settings - Fork 0
integratie proces
Een integratie omgeving opbouwen gaat grofweg in drie fases. Daarin worden telkens dezelfde stappen doorlopen.
De implementatiefase kenmerkt zich door introductie, vervanging of vernieuwing van het integratieplatform. Integratieplatformen ondersteunen meestal meerdere architectuurstijlen. De eerste stap is vaak te bepalen welke architectuurstijl je kiest. Vaak zie je later dat er meerdere door elkaar lopen, maar dat zou zeker niet het uitgangspunt moeten te zijn. Uiteraard is dit een requirement die aanbod komt bij de aanschaf bij het integratieplatform.
De tweede stap is inrichting van het platform. Bij cloud (iPaas) is deze stap al gedaan, maar bij on premisse 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 draaien. Je kan 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 laten lopen. Als je de data berichten heb vastgesteld die bij de implementatie van belang zijn, ga je ontwerp per data bericht maken. Elk data bericht is een aparte metrolijn. Elk station zou je als een aparte stap kunnen beschouwen die kunnen technische stap of een functionele stap zijn. Als alle stappen en wat in de stappen gebeurd compleet zijn dan is het ontwerp van de data interface af.
Het hangt er een beetje van de werkwijze af, maar je kan het ontwerp van alle data interfaces van te voren vastleggen. Meestal wordt tegenwoordig een meer agile benadering gekozen, waarbij eerst een eenvoudig interface wordt opgezet, het ontwerp wordt aangepast en er steeds weer een schakel aan toe wordt gevoegd.
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 zal end-to-end ketentesten gedaan 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 in productiename. Alle stappen van de OTAP-straat zijn doorlopen.
De uitbreidingsfase bouwt de interfaces op het platform verder uit. Net als een extra aftakking naar een andere wijk of een nieuw metrostation, komt er een aftakking naar een nieuw aangeschaft systeem. Zolang het applicatielandschap evalueert, evalueert het integratie platform mee. Dit kunnen nieuwe applicaties of data berichten zijn.
Bij elke uitbreiding zullen dezelfde stappen worden doorlopen. Dus ook bij een aanpassing aan een bestaande interface wordt er ontworpen, gebouwd, getest, geaccepteerd en in productie genomen. En net als in metrosysteem, vormen aanpassingen in een productieomgeving meer voorzichtigheid. Vaak ligt een metrosysteem in de nacht nog stil, maar integratiesysteem verwerken doorgaans 24/7 data.
De laatste fase is 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 dat er per databericht over wordt geschakeld.
De belangrijkste processen van integratie::
- Incident proces
- Problem proces
- Change proces
- Release proces
- Continuous Improvement proces
- Application lifecycle management proces
Incident/Problem/Change proces zijn niet anders voor integratie als voor andere software. Incident herstelt verstoringen, problem lost structurele fouten/verstoringen op en change begeleid wijzigingen. Het releaseproces beschrijven we wat uitgebreider.
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.
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 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.
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.
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.
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.
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.
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.