Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Wat te doen met bloemkool-automatisering?

Veel directies vinden het lastig om de aard en omvang van hun it-landschap te overzien. Niet omdat ze incapabel zijn, maar omdat de omvang en complexiteit van de huidige it-systemen het lastig maken om dit in zijn geheel te overzien. Het goedkeuren van een wijziging op een bestaand systeem klinkt vaak eenvoudiger dan besluitvorming over een nieuw systeem of een compleet nieuwe architectuur..

Als je, zoals ik, al een tijdje in de it rondloopt herken je dit wellicht: een organisatie heeft een systeem, het is al gebouwd en ‘up and running’. Maar na een tijdje verandert de wens. De gebruikers ontdekken dat ze iets extra’s willen of dat een bepaald stuk functionaliteit net iets anders moet worden.

Om allerlei redenen - zoals project, planning, roadmap, budget - is er van bovenaf besloten om deze functionaliteit toe te voegen aan het bestaande systeem. Gewoon omdat het huidige systeem er al is of omdat het te complex, duur of politiek onhandig is om een nieuw traject te starten. De realisatie wordt ondergebracht bij het beheer (of DevOps als we in een modern bedrijf werken) en de financiering komt uit het onderhoudsbudget. Dit alles gebeurt niet eenmalig, maar meerdere keren. Zo ontstaat er een soort bloemkool-systeem, waarbij er iedere keer een nieuwe stronk aan functionaliteit bij komt. En er gaat nooit iets weg. Zo 'stronken' we ons richting een situatie waarin het volledige it-budget wordt opgesoupeerd aan het in de lucht houden van de systemen die we de afgelopen jaren zelf hebben gemaakt. Geen geld meer voor vervanging, laat staan voor innovatie. We bloemkolen onszelf volledig vast.

Complexiteit maakt besluitvormig lastig

Veel directies vinden het lastig om de aard en omvang van hun it-landschap te overzien. Niet omdat ze incapabel zijn, maar omdat de omvang en complexiteit van de huidige it-systemen het lastig maken  om dit in zijn geheel te overzien. Het goedkeuren van een wijziging op een bestaand systeem klinkt vaak eenvoudiger dan besluitvorming over een nieuw systeem of een compleet nieuwe architectuur..

Recentelijk illustreerde Anneke van Zanen-Nieberg, directeur van Auditdienst Rijk, dit fenomeen treffend met de volgende beeldspraak: 'Vergelijk een nieuw it-project met een aanschaf in de huiselijke sfeer. Bij de aanschaf van een nieuw bankstel denk je na wat je met het oude gaat doen. Geven we het aan de kinderen, zetten we het op marktplaats, brengen we het naar de kringloopwinkel of naar het grof vuil? Stel je eens voor dat we hetzelfde doen als bij bestaande it-systemen. We zetten onze nieuwe sofa gewoon bovenop de oude bank. En vervolgens na een aantal jaar een nieuwe daar bovenop. Dit maakt het gebruik niet eenvoudiger, en naast de nieuwe sofa moeten we de oude banken ook nog stofzuigen en onderhouden. Neem dit principe mee naar de wereld van de it.'

Neem bij ieder systeem de lifecycle fase mee in de beslissing. Wat zijn de kosten van onderhoud en wat zijn de kosten van nieuwbouw? Een goede maatregel is om bij ieder projectvoorstel verplicht  een paragraaf 'Wat gaan we na dit project weg gooien?' op te nemen. Hiermee verplicht je het projectteam om na te denken over het vervangen van bestaande systemen terwijl we bezig zijn met het toevoegen van nieuwe functies.

Dit maakt een dergelijk besluit relatief eenvoudig. Als het plan voor het nieuwe systeem een gedegen strategie bevat voor de vervanging van een aantal bestaande systemen, dan vormt het een goede basis voor de verdere ontwikkeling en lifecycle management van de totale it-infrastructuur. Zit dit plan er niet bij, dan is er een grote kans dat er een nieuwe stronk aan je bloemkool in de maak is.

Bedenk wat je wilt gaan opruimen

Natuurlijk is dit niet altijd zo eenvoudig als het lijkt. Wellicht is het opdelen van je landschap in een architectuur van microservices veel aantrekkelijker. Maar zonder de 'wat gooien we weg'-regel is dit alleen maar het splitsen van een grote bloemkool in een grote schaal aan kleinere stronken. Dit neemt niet weg dat we altijd moeten nadenken over hetgeen we moeten opruimen voordat we iets nieuws starten. Het stellen van de vraag is al een goede start. Blijf dus alert op nieuwe bloemkolen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5673047). © Jaarbeurs IT Media.
?

 

Reacties

Absoluut mee eens en heel herkenbaar. Het is niet alleen een nieuwe sofa, maar in de IT heeft die sofa nog afhankelijkheid van de oude sofa zodat opruimen steeds moeilijker wordt. Dit is bijna de definitie van een technische schuld. En ja, als je kijkt naar microservices zonder governance dan lijkt dat net op het Java framework. Heel netjes gestapeld, maar nog steeds verweven en dus een probleem. Als zo'n bloemkool door groeit en de technische schuld stijgt wordt het steeds moeilijker afscheid te nemen en stijgen de onderhoudskosten. Dan wordt het systeem als geheel als legacy aangeduid. Het functioneert en heeft waarde, het is alleen erg verouderd en men kan er niet zomaar vanaf.

Het slechte nieuws is dat niet (goed) te voorkomen is, zelf niet met life-cycle management of enterprise architectuur, of om George Box te citeren: "all models are wrong but some are useful".

Het goede nieuws is dat er wel een aantal principes te hanteren zijn uit enterprise architectuur / life-cycle management die in ieder geval helpen het probleem beheer(s)baar (jaja wie roept mij nu?) te houden.

En in mijn ogen is dat toch door het gebruik van (micro) webservices en cloud computing. Je zult echter iets centraal moeten hebben waar alles doorheen stroomt en in mijn ogen is dat Identity Access Management (IAM) in de breedste zin. Alle users en authenticatie systemen zoude in dit systeem moeten samen komen zodat je centraal kunt monitoren, meten, authenticeren, autoriseren, et cetera.

Iedere stronk van de bloemkool moet uit deze IAM stam voortkomen. Past het niet? Dan komt het er niet in ook niet onder druk en stress.

Hoe kom je daar? Door klein opnieuw te beginnen met een (cloud gebaseerd) IAM systeem en stapje voor stapje dingen over te zetten geheel volgens Gall's Law. Dit is in feite één van de stappen die vallen onder het "rationaliseren van het applicatie landschap". Ron Tolido (Cap Gemini) heeft daar hele mooie artikelen over geschreven.

Het vergt wel een dictator en een visie, maar is voor ieder bedrijf dat langer dan vijftien jaar bestaat noodzakelijk.....

@Robbrecht:
Deze onderwerpen zijn in de financiële analyse in je BC benoemd en uitgelegd. Of zijn er bedrijven die zomaar in hun ict investeren zonder verder nadenken?

Ik heb een jaar geleden een term geïntroduceerd: "Wegwerp-architectuur"

Dit betekent dat je met de huidige ontwikkelingen rekening moeten houden met de totale vernieuwing binnen 3 tot 5 jaar. In dit kader kijk je niet alleen naar de financieel aspecten ( initiële investering, onderhoud, beheer, ontwikkeling, ROI etc) maar ook de inrichting van je diensten en architectuur.
Doe je dat niet dan ga je legacy creëren die je op alle fronten meer gaat kosten.

Dank Reza en Henri. voor deze waardevolle aanvulling. Helemaal mee eens. .

Helder en herkenbaar stuk. Mooie analogie ook! En om in analogieën te blijven: Stel ik hou van muziek luisteren, af en toe een TV / DVD kijken en ook wat rondsurfen op Internet. De hoeveelheid technische oplossingen / invullingen zijn tegenwoordig legio en in de loop der tijd stapelen deze zich inderdaad op. TV, Tablet, Smartphone, iPod, Streamer, DVD/CD speler etc. Allemaal natuurlijk zo smart mogelijk en met elkaar verbonden. De aansluitmogelijkheden (en vergeet toch niet de aanwezige bekabeling) is voor een normaal mens bijna niet meer te bevatten. Daar heb ik dus een architectuur-plaat voor gemaakt. Als mijn Streamer eruit moet, omdat ik iets beters heb gevonden, kan ik niet alleen blind ontkoppelen, ik weet ook aan welke minimale "requirements" het nieuwe stuk techniek moet voldoen.

Echter... ik ga op dat moment helemaal voorbij aan waar het ook al weer om ging; welke waarde wil ik immers creëren? Zodra we dat uit het oog hebben verloren (door de toename van complexiteit?) zijn we niet echt efficiënt bezig toch? En daarom ben ik zo bloedfanatiek op het gebied van up-to-date procesbeschrijvingen en architectuurplaten, niet omdat we iets moeten automatiseren of compliancy moeten kunnen aantonen, maar simpelweg om de wereld wat beter te snappen. Zeker na verloop van tijd...

Prima analyse. Herinnert mij aan https://www.computable.nl/artikel/opinie/overheid/2998823/1509029/architecten-terug-naar-de-blokkendoos.html waarin ik het (gebrek aan) operationeel gerichte architectuur aan de orde stelde. Nog steeds is de ICT-procedure belangrijker dan het primaire proces...

Na het lezen van de titel kom ik maar niet af van een carnavalsliedje, de kater waar auteur het over heeft wordt tenslotte steeds vaker bezongen. Blijkbaar hebben alle business innovation managers eindelijk ook het wiel (van Cozijnsen?) ontdekt nu Gartner er wat over heeft geroepen met Bimodal IT idee.

Dat - zoals Anneke van Zanen-Nieberg constateerde - er vaak sprake is van 'lasagne-architectuur' doordat verschillende lagen elk een eigen lifecycle hebben is niet echt nieuw en al een aantal jaren wordt er gewezen op de Enterprise Lifecycle uitdaging die (Gartner) steeds groter wordt als je EA tools niet aansluit op het configuratie management.

BC versus EA is als in de winkel een grote breedbeeld TV kopen om er thuis achter te komen dat de TV kast te klein is. Dimensionering (CDB?) blijft lastig nu de infrastructuur door een virtualisatie op (bijna) alle lagen dynamisch is geworden. Ook helpt het niet als het eerste wat na een project weggegooid wordt de handleiding voor het beheer is, DevOps is hierdoor vaak alleen maar een andere pasta soort.

Walter vergeet dat 'ontkoppelen' om de stekkers gaat en die mooie nieuwe breedbeeld TV heeft HDMI maar het oude 5.1 surround systeem niet. Ja, ja die aanbieding leek in de winkel zo mooi maar ondertussen staat de TV niet op de goede kijkhoogte en is de audio beleving toch wel wat mager. En dat alles alleen maar omdat ik de ondertiteling niet meer kon lezen;-)

En daarom pleit ik steeds voor KISS.
Hoe komplexer, hoe slechter beheersbaar, hoe meer risiko op bloemkolen.

Laat funktionele specifikaties nooit door it-ers maken maar door mensen van de werkvloer die weten waar het knelt, een iter kan dan wat mogelijke oplossingen aandragen maar toetsen moet iemand "uit de business" om binnen de geliefde terminologie te blijven.

Wie maakt vandaag de dag nog een planning die 5 jaar mee kan?

Channelweb Expert
Robbrecht van Amerongen

Robbrecht van Amerongen
Business Innovation Manager, AMIS Services. Expert van Channelweb voor de topics Development en Security.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×