Al jaren doe ik werk voor IT afdelingen van bedrijven, in voorkomende gevallen zelfs IT organisaties genoemd. Soms als interne collega maar meestal als externe consultant. Als mij jaren geleden gevraagd was wat IT afdelingen doen, dan had ik waarschijnlijk gezegd “Die doen IT”. Inmiddels weet ik beter, ik heb eens goed nagedacht over deze overduidelijk simpele vraag en het resultaat wil ik graag met jullie delen. Het beantwoorden van een overduidelijk simpele vraag geeft soms toch bijzondere inzichten.

Het resultaat was voor mij erg verhelderend. Ik begrijp nu de vier hoofdtaken van IT afdelingen; “Maintenance” – het beschikbaar houden van bestaande functies, “Projects” – het verwerven van nieuwe functies, “What’s on the Radar” – welke ontwikkelingen worden belangrijk en “Decommisioning” – het afvoeren van verouderde technologie, systemen en applicaties. Dit is dan ook wat alle IT afdelingen gemeenschappelijk hebben. In zekere zin lijken ze dus op elkaar, in ieder geval qua generieke uitdaging. Maar hoe omschrijf je dan het nut van IT afdelingen voor de organisatie?

Acceleration

Ja, wat doet een IT afdeling voor het bedrijf waar zij deel van uit maakt? En dan met name vanuit een business perspectief gezien? Aanvankelijk was mijn eerste serieuze suggestie, “De IT afdeling ondersteunt de business”. Vluchtig bekeken lijkt dat zinvol, maar “Ondersteunen” is wel passief. Mijn tweede gedachte was daarom ook “De IT afdeling versnelt de business”. Dat was veel beter, want het geeft aan waar het nut van de afdeling zit.

Ik heb eerder geschreven over versnelling, dus deze gedachte is geen grote verrassing. Maar overweeg het omgekeerde, stel dat de IT afdeling de business vertraagt, zou de organisatie er dan wel geld aan willen uitgeven? Zeg nu zelf, dat doet geen enkele organisatie. Dan gaat het dus om versnelling. En dan met versnellen bedoel ik dan dingen sneller doen, ze beter doen, tegen lagere kosten, minder complexiteit en met minder fouten. Dat is toch wel wat organisaties van IT verwachten? Gecombineerd met de vier generieke taken van de IT afdeling, ontstaat er het volgende beeld.

Maintenance

Het overgrote deel van de inspanning van een IT afdeling betreft “Maintenance”. Het beschikbaar houden van bestaande functionaliteiten. Er wordt geen nieuwe functionaliteit geïntroduceerd, maar men behoudt wat er is. Vergelijk het met onderhoud aan een auto. Je verwacht dat na het onderhoud alles weer optimaal functioneert, maar niet dat er ineens een autoradio is toegevoegd. Deze “Maintenance” functie van de IT afdeling doet ze liefst zo efficiënt en kosteneffectief mogelijk. Er wordt tenslotte niets nieuws gemaakt. Je zou dit kunnen vergelijken met het behouden van een bepaald niveau, een plafond zo je wil. Het “Plafond” is het maximaal haalbare, je kan het alleen slechter doen. Daarom is de kern bij “Maintenance”, “Efficiëntie”.

Projects

Een andere belangrijke taak van een IT afdeling is in mijn ogen “Projects”. Nieuwe functionaliteit wordt namelijk in projecten gerealiseerd. Dus waar het bij “Maintenance” gaat om het bereiken van het “Plafond” (en het dus om “Efficiëntie” draait), gaat het hier om het verhogen van het “Plafond” en de kern is dan “Effectiviteit”. Waarom? Nou, natuurlijk willen we projecten graag op tijd en binnen budget afgerond hebben, maar als ze geen waarde toevoegen (ze de organisatie niet versnellen), dan is het alsnog verspilde moeite. Bijvoorbeeld, een project dat later dan afgesproken wordt opgeleverd en misschien duurder was dan gebudgetteerd, maar wel de organisatie versneld, heeft toch waarde. “Effectiviteit” is daarom belangrijker dan “Efficientie”. In het voorbeeld van de auto zou je bijvoorbeeld kunnen denken aan het monteren van een trekhaak. Dat heeft niets met onderhoud te maken maar realiseert een nieuwe functie – het kunnen trekken van een aanhanger.

On the Radar

De derde functie van een IT afdeling is wat ik “What’s on the Horizon” of “What’s on the Radar” noem. Dat zijn onderwerpen waar de IT afdeling in de toekomst mogelijk iets mee moet. Dat kunnen nieuwe technologieën zijn, bedrijfsveranderingen zoals overnames of veranderende wet- en regelgeving. Deze taak kent twee uitdagingen. De eerste is, kunnen we succesvol vaststellen of een onderwerp belangrijk wordt voor de organisatie? We kunnen bijvoorbeeld denken dat een onderwerp belangrijk gaat worden, maar achteraf gezien is dat niet het geval (type 1 error), of we denken dat een onderwerp niet belangrijk is, maar achteraf gezien is dat toch wel zo (type 2 error). Als we deze twee soorten fouten hebben kunnen voorkomen, dan hebben we nog een volgende “Hobbel” te nemen.

Deze “Hobbel” is wat de Eisenhouwer Matrix genoemd wordt. Deze matrix kent twee dimensies, “Belangrijk” versus “Urgentie”. Dit leidt dan tot 4 combinaties. Is een onderwerp eenmaal relevant bevonden (dus geen type 1 of een type 2 error), is de vraag of we die op de roadmap kunnen krijgen? Meestal krijgen onderwerpen die urgentie hebben voorrang, ongeacht of ze belangrijk zijn. Onderwerpen die geen urgentie hebben, maar wel belangrijk zijn worden uitgesteld. In het voorbeeld van de auto zien we bijvoorbeeld aankomen dat elektrisch rijden de toekomst is. We willen ons daarop voorbereiden. Zo kunnen we dan besluiten alvast laadpalen te plaatsten nog voordat iedereen elektrisch rijdt. Dat is belangrijk. Wachten we tot de elektrische auto’s rond rijden, dan zijn we te laat met het plaatsen van de laadpalen.

Deze “On the Radar” functie van de IT afdeling is erg lastig uit te voeren vanwege de genoemde uitdagingen. De kern is “Relevantie”. Het correct bepalen van relevante onderwerpen is de sleutel tot succes.

Decommisioning

De laatste functie bij een IT afdeling is “Decommisioning” van oude technologie en applicaties. Waarom is dit een belangrijke functie? Oude technologie en applicaties vragen veel onderhoudswerk en vragen dus een onevenredig groot deel van het budget. Bovendien heeft oude / verouderde technologie vaak security issues die veel werk vragen en afbreukrisico kennen. Het is daarom verstandig oude technologie af te voeren zodra dat kan. Niet te vroeg, want dat schaad de organisatie, maar zeker ook niet te laat. Kortom, de kern van deze functie is dan ook “tijdigheid”. In het voorbeeld van de auto kunnen we denken aan het afvoeren (verkopen) van een brandstof auto omdat elektrisch rijden de toekomst heeft.

Als je dit leest vraag je je waarschijnlijk af hoe deze vier functies zich tot elkaar verhouden voor wat betreft het percentage inspanning. Dat vroeg ik me ook af. Grok heeft me hier even geholpen, 

- onderhoud 55% tot 70%, 
- projecten 15% tot 25%, 
- on the Radar 10% tot 20% en het 
- afvoeren van oude technologie 3% tot 10%

Hier zie je overigens gelijk nog een reden waarom het bij "Maintenance" om "Efficientie" gaat. Het is verreweg de functie die de meeste inspanning vergt. Een  efficientieslag hier levert het meeste op.

In de praktijk zal “Decommisioning” een project zijn, of onderdeel zijn van een groter project. Als een applicatie bijvoorbeeld vervangen wordt, is het logisch het afvoeren van de oude applicatie daar als laatste stap aan toe te voegen.

“Maintenance” legt “Projects” beperkingen op

Nu de basisfuncties van de IT afdeling geïdentificeerd zijn, kunnen we het model “Testen”. Kunnen we er wat mee? Geeft het ons inzicht? Het eerste dat opvalt is dat de resultaten van de projecten eindigen bij “Maintenance”. Dus, hoe sneller / succesvoller we projectresultaten opleveren, hoe meer onderhoudswerk er te doen is. Dus gaat er meer budget naar “Maintenance”. En als gevolg hiervan kunnen we dan weer minder projecten doen. Er is dus een negatieve feedback loop tussen “Maintenance” en “Projects”. Dat is een interessant inzicht.

De vier hoofdtaken kennen een soort "Flow". Items "On the Radar" worden een keer een project. Het resultaat daarvan komt bij "Maintenance" terecht en na verloop van jaren worden die opgeruimd ("Decommissioning"). Feitelijk is dit een "Product Life Cycle".

Budget invloeden

Veel IT afdelingen hebben tegenwoordig te maken met budgetbeperkingen. Soms worden budgetten “Bevroren” of zelfs kleiner. Het is dan de vraag hoe kan er dan ruimte gemaakt worden voor projecten – want het versnellen van de business blijft nodig. Ik zie hier een paar mogelijkheden.

De eerste optie is het budget toch opgehoogd te krijgen. Soms lukt dat, als de business case goed is of wanneer het zakelijk belang dermate groot is dat het verantwoord is.

Een alternatief is bijvoorbeeld projecten te schrappen of later uit te voeren. Dit is een relatief makkelijk oplossing waarvoor vaak gekozen wordt. Het probleem hiermee is, we versnellen de organisatie niet. Dat gaat maar een tijdje goed. Maar zodra we een concurrentie achterstand gaan ervaren, zijn we te laat. Het is dan ook een tijdelijke oplossing. Er is nog een factor die dit onderstreept. Beheercontracten zijn altijd langerlopende contracten. Deze zijn lastig of niet voortijdige te beëindigen. Dat is waarom als eerste op projecten bezuinigd wordt.

Een andere en logische optie is “Maintenance” efficiënter uit te voeren. Dit maakt budget vrij voor projecten. Dit is daarom de onderbouwing waarom de “Efficiëncy” de kern is van “Maintenance”. IT-onderwerpen die betrekking hebben op efficiëntieverbeteringen, betreffen daarom altijd de onderhoudsfunctie van de IT afdeling.

Als laatste mogelijkheid zie ik het afvoeren van oude technologie, applicaties en technische schuld (“Decommisioning”). Dit verlaagd de onderhoudsinspanning en dus het beslag op het budget.

DevOps?

Veel bedrijven werken vandaag volgens de DevOps aanpak waarbij het team zowel verantwoordelijk is voor software development als het beheer ervan. Dit wordt ook wel aangeduid als "You build it, you run it". Is dit dan strijdig met wat hierboven beschreven is? Nee, het zijn twee taken die bij hetzelde team belegd zijn. Het development werk is feitelijk een doorlopend project, of meerdere kleine projecten (we noemen dit vaak "Sprints"). Voor het beheerwerk ("Maintenance") geldt ook hier dat het zo efficient mogelijk gedaan moet worden. Beheerwerk gaat letterlijk ten kosten van development uren. Een groot voordeel van DevOps is dat dezelfde mensen de beheer consquenties voelen van hun development werk. DevOps vergroot dan ook de kans op slim software ontwikkelen met een minimale beheer impact. En dat is wenselijk.

En security dan?

Kan dit model ons helpen inzicht te krijgen in het onderwerp security? De meeste security onderwerpen hebben betrekking op “Maintenance”. Want zowel de inspanning om de security op peil te houden, maar ook veel van de werkzaamheden als gevolg van security incidenten doen een beroep op (het budget van) “Maintenance”. Security is daarom voornamelijk een “Maintenance” aangelegenheid. Er is wel een uitzondering. Want wat zou security in projecten kunnen zijn? Dan heb je het over “Secure by design”. En dat is slim omdat het security level, na oplevering (en dus tijdens “Maintenance”) makkelijker op peil te houden is. Minder werk en dus minder kosten. Het heeft daarom zeker nut security als specifiek onderwerp in een project mee te nemen. Hetzelfde geldt voor “Decommisioning”. Waarom ontwerpen we systemen in de projectfase niet zo dat zij met minimale inspanning afgevoerd kunnen worden. Een soort exit strategie van de applicatie.

Technical Debt

Ik heb vaak bij klanten gezien dat verouderde applicaties en technologie problemen gaven. Er moest extra veel tijd in “maintenance” gestoken worden en soms kon de applicatie zelfs niet meer goed onderhouden worden. Dat kwam bijvoorbeeld doordat upgrades onmogelijk geworden waren. Dat laatste is een bron van security problemen. Kortom, technische schuld geeft ellende, vertraagt en doet een te groot beslag op het budget. De vraag is dan natuurlijk, hoe voorkom ik dat ik vandaag de technische schuld van morgen creëer? En net als bij security ligt het antwoord bij de projecten die je doet. Kan je projecten (en technisch ontwerpen) zo maken dat je toekomstige technische schuld – by design – beperkt? Ik denk het wel. Bijvoorbeeld door alle handmatige werkzaamheden te voorkomen en door de onderhoudbaarheid van applicaties als ontwerpcriterium mee te nemen.

Een goede “Design” vraag is dan ook, kan mijn applicatie onderhouden worden als ik die straks opgelever? En wat hebben mijn collega’s dan nodig om dat efficiënt te kunnen doen? En dat betekent vandaag nadenken over de onderhouds uitdagingen van morgen. Ik kan je verzekeren dat die te maken hebben met efficiëntie.

De overduidelijk simpele vraag

Als je nog steeds leest dan hoop ik dat het beantwoorden van deze overduidelijk simpele vraag ook voor jou verhelderend is. Voor mij is de (business) werking van een IT afdeling nu veel logischer. Ik begrijp nu hoe en waarom groepen van werkzaamheden zijn zoals die zijn en hoe ze elkaar beïnvloeden. Dat we een “Product Life Cycle” achtige “Flow” zien in de taken. Met een paar voorbeelden heb ik geprobeerd het model te “Toetsen” zo je wil. Door te zien of het ons inzicht verschaft en dat doet het naar mijn idee. Er zijn vast meer voorbeelden te bedenken. Het model staat, doe er je voordeel mee.