Follow Us on Twitter

Integratie maar dan lean

Gepubliceerd in

Binnen haar informatievoorziening heeft vrijwel elke organisatie behoefte aan het integreren van data en het hergebruiken van logica. Het afgelopen decennium hebben we geleerd dat het vrijwel onmogelijk is om met één applicatie of zelfbouw de volledige informatie en automatiseringsbehoefte af te dekken.

De laatste jaren zijn veel organisaties steeds verder gegaan in het realiseren van de integratie tussen de verschillende systemen in hun IT-landschap. Met integratie bedoelen we in deze context het continu proces om onafhankelijke applicaties of componenten als een geheel samen te laten werken. Tijdens de inspanning die daarbij verricht is, wordt duidelijk dat de resultaten lang niet altijd zo helder en succesvol zijn als de plaatjes en PowerPoint presentaties van softwarehuizen ons voorhielden.

Of je nu in de positie van IT-manager, software-ontwikkelaar, architect of integratiespecialist zit; de uitdaging om veranderingen snel doorgevoerd te krijgen ligt op jouw bord; of het nu gaat om nieuwe functionaliteit, aanpassing van het bestaande functionaliteit of de migratie van één van de systemen betrokken bij de integratie. Dat terwijl software componenten zo opgezet moeten worden dat ze ook beheersbaar en aanpasbaar moeten zijn.

In dit Whitebook wordt een aantal handvatten aangedragen gebaseerd op een lean aanpak die je kunnen helpen bij integratie van IT-systemen. De volgende punten zullen worden besproken: Hoe bereid je je voor op verandering en welke ontwerp- en ontwikkelactiviteiten voor integratie kunnen geautomatiseerd worden.

Nog een ding over lean, de architectuur en het proces

Lean is een methode gericht op het creëren van waarde in een proces en het verminderen van overbodige processtappen. Lean is grotendeels afgeleid van het Toyota Productie Systeem en is inmiddels overal in de wereld ingezet in allerlei productiebedrijven. Het kent een sterke focus op het creëren van waarde voor de afnemer, het continue verbeteren van productie processen en het verminderen van verspilling. Naast de inzet in productieomgevingen wordt het steeds vaker ingezet binnen andersoortige processen, bijvoorbeeld: productontwikkeling, dienstverlening en IT-processen zoals softwareontwikkeling en projectmanagement.

Zoals aangegeven in de inleiding zien we integratie van applicaties en software componenten als een continu proces. Ook binnen dit proces loont het om te kijken welke stappen waarde toevoegen en welke niet. In de volgende paragrafen worden daarvan diverse voorbeelden gegeven. Daarnaast loont het om het proces continu te blijven verbeteren en de stappen die daarvoor nodig zijn in het ontwikkel- en integratieproces in te bouwen. Het realiseren van integratie is niet een eenmalig proces. Niet alleen kunnen er meerdere organisaties, meerdere applicaties en/of componenten betrokken zijn bij de integratie.  Een integratie traject wordt in de loop van een aantal jaar ook regelmatig aangepast of het kan nodig zijn dat er nieuwe functionaliteit wordt bijgebouwd.

Architectuur

Het opstellen, uitvoeren en beheren van een architectuur brengt structuur in het ontwerp, de realisatie en het onderhoud van applicaties en andere software componenten. Architectuur brengt eenbeperking van de oplossingsruimte aan. Deze beperking van de toegestane keuzen tijdens alle fasen van het proces van softwareontwikkeling, zorgt voor een sterke vereenvoudiging van de realisatie en het beheer van de software. Het is dan ook van belang om na te gaan of er inderdaad een voor ontwerpers en ontwikkelaars hanteerbare set van richtlijnen is opgesteld in de architectuur die het aantal keuzes die zij moeten maken terugbrengt.

De opgestelde architectuur moet een structuur bieden die aansluit bij het realiseren van de software. Een eindeloze lijst van indelingen van services waarbij geen keuze wordt gemaakt, voegt geen waarde toe. Ook indelingen die zich niet kunnen verhouden tot de implementatie dragen niet bij. Het is een gemiste kans als ontwikkelaars de vertaling van de architectuur naar de componenten die zij moeten implementeren niet kunnen maken.

Proces

Ook voor het proces van het realiseren van integraties wordt een gedisciplineerde manier van werken gevraagd. Dit betekent niet dat discipline het probleem is van het falen van software-implementaties! Vaak is het ontbreken van een proces en/of een toepasbare architectuur de oorzaak. De tijd en moeite die het kost om dit recht te zetten gaat ten koste van de hoeveelheid functionaliteit, de kwaliteit en de doorlooptijd.

Veel organisaties hebben geen expliciet proces voor het vastleggen architectuur en/of het ontwikkelen en implementeren van software. Dit heeft nadelige gevolgen voor de effectiviteit en de efficiency waarmee software gerealiseerd kan worden. Daarnaast heeft het negatieve consequenties voor de snelheid waarmee functionaliteit beschikbaar komt. Als een proces niet expliciet is, kan ook niet worden vastgesteld of er van is afgeweken en met welke consequenties. Dit maakt het sturen van teams in een dergelijke omgeving lastiger dan nodig. 

Als er wel een proces aanwezig is beschrijft het vaak niet wat er bij afwijkingen of fouten moet gebeuren. Lean heeft hier speciaal aandacht voor. De focus op continu verbeteren en leren heeft binnen lean speciale aandacht. 

Plan voor verandering

Om voorbereid te zijn op verandering, worden in deze paragraaf drie handvatten aangereikt. Zo kun je in ieder geval zorgen dat werkzaamheden in behapbare, op zichzelf staande brokken worden opgedeeld. Daarnaast gaan we op zoek naar mogelijkheden om genomen beslissingen terug te kunnen draaien of eenvoudig te kunnen wijzigen. Ten slotte wordt besproken hoe de documentatie zo ingericht kan wordt dat het levende documentatie wordt.

Vermijd verplichte afhankelijkheden

Soms zijn in de architectuur, de manier van werken of door de macht der gewoonte afhankelijkheden tussen activiteiten ontstaan die niet altijd nodig zijn. Hier geldt dat door de waarom-vraag te stellen, achterhaald kan worden of een bepaalde afhankelijkheid waarde toevoegt of niet.

Door afhankelijkheden ontstaan wachttijden. Wachten is binnen lean één van de 7 verspillingen. De tijd tot oplevering wordt er sterk negatief door beïnvloed. Door in een multidisciplinair team te werken, waarin zowel ontwerpers, softwareontwikkelaars en testers zitten, die vrijwel gelijktijdig aan een stuk functionaliteit werken, wordt de wachttijd bij overdracht sterk terug gedrongen.

Het is van belang om een modulair proces met bijbehorende producten/deliverables te hebben. Daarmee kan worden bereikt dat alleen die modules worden gebruikt die noodzakelijk zijn voor het realiseren van een project of software component. Het is eenvoudig voor te stellen dat een project met vier man en een doorlooptijd van twee maanden behoefte heeft aan een heel ander proces dan een project van acht man met een doorlooptijd van twee jaar.

Een binnen de IT bekende aanpak voor het beperken van afhankelijkheden is loose coupling. Hierbij wordt de hoeveelheid kennis die de aanroepende component heeft over de component die de functionaliteit levert beperkt. Het implementeren van een canoniek datamodel (gemeenschappelijke taal vastgelegd in data definities, onafhankelijk van de applicaties) en een service virtualisatie laag (bijvoorbeeld in een service bus) kunnen daar een belangrijke bijdrage aan leveren.

Een canoniek datamodel verbetert de ontkoppeling omdat alleen vertalingen tussen de applicatie en het canonieke model nodig zijn. Voor de ene applicatie is dus geen kennis meer nodig van de datadefinitie van de andere applicaties.

Een service virtualisatie laag draagt bij aan een verdere ontkoppeling doordat applicaties niet meer rechtstreeks aangesproken worden. Hierdoor is het bij wijzigingen van bijvoorbeeld end-points nog maar nodig om deze op één punt aan te passen.

Omkeerbare beslissingen

De aanpasbaarheid van automatisering en ook van de integratie van softwarecomponenten, hangt voor een belangrijk deel af van de mate waarin beslissingen die op een bepaald moment zijn gemaakt omkeerbaar zijn. Het terugdraaien van een beslissing komt er vaak op neer dat software (terug) moet worden aangepast. Voor het verhogen van de aanpasbaarheid  zijn  verschillende mogelijkheden. De eerste die we noemen is instelbaarheid. Door bijvoorbeeld in rule-engines grenswaarden, factoren en andere parameters instelbaar te maken, wordt het relatief makkelijk om een uitgestippeld pad te verleggen. 

Een andere mogelijkheid om snel aanpassingen te kunnen maken, is om vanuit een model of configuratie bestand (onderdelen van) een integratie te genereren. Denk hierbij aan een oplossing vergelijkbaar met het genereren van JAXB op basis van XSD’s. Een ander concreet voorbeeld is de mogelijkheid om met een beperkte inspanning een stuk software te schrijven die voor een SOA Suite SCA composite een EDL (Event Definition Language) en bijbehorende XSD genereert op basis van een XML configuratie bestand. Een stap verder zou het zijn om ook de mplan (Mediator configuratie file) te genereren die dit zou kunnen doorzetten naar een database adapter (bijvoorbeeld op een procedure met een xmltype input parameter). Dit vraagt een investering die te overzien is en die zich gedurende de levenscyclus van de software eenvoudig en vooral snel terugverdiend.

Levende documentatie

Zoals ook in het recente Whitebook van Sjors Wagenaar aangegeven is het voor hergebruik van belang dat softwareartefacten en documentatie kunnen worden terug gevonden en beschikbaar zijn op het moment dat daar behoefte aan is. Daarvoor worden er minimaal twee eisen aan documentatie gesteld:

  • Het moet centraal beschikbaar en toegankelijk zijn;
  • Er moet eenvoudig op informatie kunnen worden gezocht.

Het realiseren en aanpassen van documentatie moet een geïntegreerd onderdeel van het software ontwikkel- en beheerproces zijn. Dat kan relatief eenvoudig door dit een vast onderdeel van de definition of done (wordt binnen scrum gebruikt om te bepalen of het werk compleet is) te maken. Een aanvullende maatregel is om aan het einde van elke meeting de besluiten in de documentatie te verwerken.

Tenslotte is het ook mogelijk om een deel van de documentatie te genereren. Dat geldt niet alleen voor documentatie van Java code. Het is evengoed mogelijk om dit te doen door op een handige manier documentatie op te nemen binnen XSD en XSL files.

Automatiseer integratie-werkzaamheden

Het mag niet als een verrassing komen dat door automatisering de efficiency flink kan worden verbeterd. Dat geldt zeker ook voor de automatisering van de automatisering. Hoewel binnen maatwerk projecten en zeker ook binnen integraties unieke producten worden gemaakt, is de manier waarop dat gebeurt goed in een proces vast te leggen. Dan kan het niet anders zijn dat er repeterende taken in zitten. Alles wat je vaker dan 1 keer doet komt in aanmerking om geautomatiseerd te worden. Op z’n minst moet worden vastgesteld of er een positieve business case is.

Deployment

Deployment, oftewel het beschikbaar maken van een integratie of applicatie op een server, is typisch een activiteit die vaak voorkomt. Je wilt dat dit een consistente set is die door de OTAP straat gaat. Als het proces hiervoor niet goed op orde is, blijkt dit foutgevoelig. Dit onderdeel van het ontwikkelproces is daarmee een duidelijke kandidaat om te automatiseren.

De overdracht tussen omgevingen bij de promotie van softwarecomponenten binnen een OTAP straat, blijkt een typisch moment waar software-artefacten en kennis verloren gaan. Instellingen en afhankelijkheden die op een testomgeving al uitgezocht en geïmplementeerd zijn, worden dan niet meegenomen naar de acceptatieomgeving. De tijd die het kost om de opnieuw ontstane problemen op te lossen, is een rem op de snelheid waarmee software naar productie kan worden gebracht. Uit het voorgaande blijkt dat het van belang is om bij elke eenheid die gedeployed gaat worden  afhankelijkheden en configuraties vast te leggen.

Op het moment dat de deployment geautomatiseerd is, gaat dit sneller en met minder fouten. Als dit ook nog goed geparametriseerd wordt opgezet met properties per omgeving, blijkt het ook nog relatief eenvoudig om indien nodig snel extra omgevingen in te richten. Dit maakt het ook eenvoudiger om met wijzigingen in of van een omgeving om te gaan.

Testautomatisering

Testen is een van de meest voor de hand liggende onderdelen binnen integratiewerkzaamheden om te automatiseren. Bij de testwerkzaamheden is er een duidelijke uitkomst die kan worden geverifieerd. Testen is ook typisch een activiteit waarvan je wil dat deze herhaalbaar is. Als je bijvoorbeeld een unittest niet automatiseert, is het risico dat er te beperkt getest wordt hoog. Daarmee zal het aantal defects en dus de verspilling stijgen.

Om het automatiseren van je test goed geregeld te krijgen, moet het ontwikkelproces en –deliverables hiervoor worden ingericht. Als je bijvoorbeeld kijkt naar unit testen voor operaties binnen services, is het van belang dat in het ontwerp van een operatie ook de pre- en postcondities worden opgenomen. Zodra je dat doet zijn meteen alle kandidaten voor de test scenario’s beschikbaar.

Omdat er in integratie projecten altijd meerdere applicaties en/of componenten betrokken zijn, is het doen van regressietesten van groot belang. Hierbij wordt immers getest of het geheel nog werkt na het maken van aanpassingen in (soms erg kleine) onderdelen. Als je vaak en met een hoge snelheid wil opleveren, is het geautomatiseerd testen noodzakelijk.

Afsluiting

In dit Whitebook is een aantal handvatten aangedragen gebaseerd op een lean aanpak die kunnen helpen om integraties sneller te realiseren. We hebben gezien dat het ontwikkelen van integraties een continu proces is. Het loont om dit proces expliciet te maken en vast te stellen of een stap waarde toevoegt. Dit kan verschillend zijn voor verschillende typen integraties.

Het is belangrijk dat de architectuur aansluit op het ontwikkelproces. De architectuur moet een herkenbare structuur hebben voor ontwerpers en ontwikkelaars. Implementeer een canoniek datamodel en een service virtualisatie laag voor ontkoppeling.

Zorg voor ontkoppeling of verminder het aantal overdrachtsmomenten in het ontwikkelproces. Gebruik de beschreven handvatten voor het verhogen van de aanpasbaarheid. Automatiseer waar mogelijk binnen het ontwerp en realisatie van integraties. Een goed startpunt hiervoor is het automatiseren van deployment en test.

Referenties

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.