Al ver voor de grootste financiële crisis in deze eeuw werd ook een iets minder bekende schuld onverantwoord hoog opgebouwd. De IT schuld. Echter ook na de wereldwijde wake-up-call eind 2008, is het opbouwen van schuld in architectuurland nog altijd een zeer hardnekkige gewoonte. Ondanks dat we in 2002 beloofden dat al onze nieuwe systemen web-based, modulair en onafhankelijk van andere systemen moesten werken (‘loosly coupled’), het is anno 2014 nog altijd niet gelukt. Sterker nog de architectuurschuld neemt nog steeds iedere dag toe!
Architectuurschuld kan worden gezien als het tijdelijk afstappen van een zeer goed architectuurprincipe. Vaak onder het motto dat we de schuld later wel zullen voldoen. Ofwel: binnen niet al te lange tijd verbouwen we het systeem zodat het wel in lijn is met de architectuurprincipes, maar nu even niet. Reden voor het opbouwen van een architectuurschuld zijn bijvoorbeeld:
- Een zeer confronterende opleverdatum;
- Een iets wat optimistische business case, waar nét geen plaats is voor het voldoen aan de zorgvuldig afgestemde enterprise architectuurprincipes;
- Tekort aan budget. Goed voor lange termijn is nu eenmaal vaak net wat duurder dan goed genoeg voor nu.
- Geen pijn voor projectarchitecten en projectmanagers bij het afwijken van architectuurprincipes. Na oplevering van het project vertrekken de projectarchitecten en managers naar een volgend project. Binnen of buiten de organisatie. De pijn van de opgebouwde architectuurschuld wordt gevoeld door de exploitatieafdelingen en wordt vaak zichtbaar door de jaarlijkse stijgende exploitatiekosten om allerlei exotisch gebouwde systemen werkend te houden.
Het constateren en bewust opbouwen van architectuurschuld is eenvoudig en kost relatief weinig tijd en geld in vergelijking met het wegwerken van deze schuld. De analogie met een financiële schuld is dan ook snel gemaakt. Betalen met een creditcard is handig. Maar bij het te lang wachten met aflossen van de schuld stijgen de kosten exponentieel. De schulden betalen met een andere creditcard lost het probleem natuurlijk niet echt op, maar in de IT architectuurwereld doen we dit helaas wel vaak.
Bij veel legacy systemen is de opgebouwde architectuurschuld namelijk dermate groot, dat de ‘credit card’ optie wordt toegepast. Voor een nieuwe uitbreiding wordt een extra stuk architectuurschuld bijgebouwd. Vaak via een extra interface via een service-oriented architectuurconcept om zo op papier een kloppende architectuurbalans te hebben. In werkelijkheid wordt de schuld echter groter en groter, wat vaak pijnlijk duidelijk wordt bij een simpele wijziging die vanwege wetgeving of reorganisatie intern in een systeem moet worden doorgevoerd.
Het verschijnsel van architectuurschuld is eenvoudig te verklaren voor wie het begrip ‘Hyperbolic discounting’ kent. Ofwel de exponentiele kromme (Hyperbool) waar ons brein maar moeilijk mee overweg kan. In het kort betekent het dat iets wat vandaag goed lijkt aantrekkelijker is dan iets waarvan we weten dat het in de toekomst beter is. Een kleine concessie op architectuurvlak versneld het project, we weten dat het niet goed is, maar toch geeft deze korte termijn beslissing ons een goed gevoel ondanks dat we weten dat het op lange termijn desastreus kan zijn. Architectuur is nu eenmaal niet nodig om op korte termijn een werkend systeem op te leveren. Wel is architectuur noodzakelijk om op lange termijn kosten beheersbaar te houden en het systeem wendbaar te houden.
Voor mensen is het erg moeilijk om effecten en kosten voor lange termijn goed in te schatten. Wie kan bijvoorbeeld direct kosten voor performance verbeteringen, functionele wijzigingen of operationele beheerkosten voor lange termijn goed inschatten? Toch gaan software systemen vaak veel langer mee dan de initiële business case. Zelden stoppen we geheel met een systeem of technologie. Zo vinden we nog overal obscure programmeertalen, exotische alles-in-een ERP pakketten en worstelen we dagelijks om applicaties op onze mobiel of tablet werkend te krijgen.
Een paar uur langer nadenken voor je het voorstel doet om architectuurschuld op te bouwen kan soms nét het verschil maken. Maar kiezen voor het beperken van de architectuurschuld binnen een bedrijf zal een architect zelden de populariteitsprijs opleveren…
