In 1996 riep Ward Cunningham de term ‘technische schuld’ in het leven. Technische schuld is een concept binnen de softwareontwikkeling dat de kosten van werk wat overgedaan moet worden afspiegelt tegen het voordeel van kort-door-de-bocht- oplossingen of het uitstellen van werk. Terug in 2010 hoorde ik hier voor het eerst over van Philippe Kruchten in een boeiende talk die me altijd bij zal blijven. Het riep een interessante gedachte bij me op: wat als we in geld zouden kunnen uitdrukken hoeveel sloppy software ons kost? Oftewel, wat is het voordeel van het voorkomen of repareren van tekortkomingen?
Waar liggen de struikelblokken?
Het mag duidelijk zijn dat we hier te maken hebben met tal van struikelblokken. Ten eerste worden de kantjes er altijd bewust vanaf gelopen onder tijdsdruk. (Dit bestond al voordat het concept van een ‘minimum viable product’ populair werd). Daarnaast zijn er de keuzes die individuele ontwikkelaars maken, omdat hun kennis op het gebied waarin ze werken onvolledig is. Er ontstaan ook problemen als er niet genoeg concentratie is, als de druk oploopt voor een aankomende deadline bijvoorbeeld. Zaken aanpakken zonder gedegen voorbereiding is nog een struikelblok. En, tot slot, kan het niet vinden van de juiste mensen voor een team problemen opleveren.
Er is ook nog iets heel anders wat meespeelt: Tijd. Chris Sterling definieerde het als: “de achteruitgang van het gedrag van en tussen componenten wanneer de functionaliteit van een applicatie voldoende is voor minimale klanttevredenheid.” We weten allemaal dat deze minimale vereisten na verloop van tijd groeien. Technologie gaat vooruit. Designs ontwikkelen zich. De behoefte voor vernieuwing is slechts een kwestie van tijd. Zoals een huis af te toe een likje verf nodig heeft, zo is ook software nu en dan aan een ondehoudsbeurt toe.
Vicieuze cirkel
“Als ik het nog eens zou bouwen, met wat ik ondertussen geleerd heb, dan zou ik mijn code heel anders gestructureerd hebben.” Hoe vaak heb ik dat niet tegen mezelf gezegd? Ik weet het, tijd is niet terug te draaien. Je kunt ook niet op de tijd vooruitlopen. Dus het beste wat je kunt doen is het ontwerp inrichten op onbekende toekomstige wijzigingen. Dit doe je door projecten flexibel, open en makkelijk te onderhouden op te bouwen. Hierdoor zorg je ervoor dat je designs up-to-date, eenduidig en makkelijk te begrijpen zijn. En dat zijn precies de kantjes die er het vaakst afgelopen worden als de tijdsdruk oploopt. Technische schuld veroorzaakt meer technische schuld. Dat wil niemand, maar zo werkt het nu eenmaal.
Gedurende de levensloop van een product, heeft de schuld de neiging op te lopen en zou zelfs uit kunnen groeien tot een onderhoudsnachtmerrie. Er is een manier om dat te voorkomen. Tenminste, onder dat mom wordt regelmatige ‘refactoring van code’ aan de man gebracht. Deze refactoring houdt de software schoon en open voor toekomstige veranderingen die ongetwijfeld zullen komen. Doe je dat niet, dan zal je schuld uiteindelijk uitlopen in een faillissement.
Paradigmaverschuiving
Volgens mij is dit vandaag de dag echter niet genoeg. Zoals we weten gaat het niet alleen maar om pure functionaliteit. Beschikbaarheid, prestatie, bruikbaarheid, privacy en prijs zijn voorbeelden van andere aspecten die meespelen. De wereld is inderdaad veranderd in een veeleisende omgeving. Weten we zeker dat het systeem dat nu zo goed lijkt te werken niet vervangen kan worden door iets goedkopers, snellers en beters? Is jouw idee, dat jouw systeem vanuit jouw perceptie niet stuk is, voldoende aanleiding om het niet te repareren? Eigenaren van producten verwachten tegenwoordig de hoogste kwaliteit tegen de laagste prijs en de snelste levering. De oude manier van denken zal niet de nieuwe uitkomsten opleveren waar de nieuwe realiteit om vraagt. Op dat punt zullen onze paradigma’s moeten verschuiven. En precies dat is wat er gaande is.
Wanneer paradigma’s verschuiven, zullen quick fixes niet veel helpen. Een facelift is slechts een erg oppervlakkige vernieuwingspoging. Of je wil of niet, we zitten als sector midden in een verandering die ons op alle punten uitdaagt in hoe we dingen doen. Het nieuwe motto is “Cloud Native” met voorkeur voor massaal gedistribueerde microservices die allemaal met een klein bereik harmonieus samenwerken en zo een hecht interactief netwerk vormen. Het is op allerlei manieren de volgende stap in de transitie van een data-gerichte naar een digitale mindset. Hier worden de nieuwe standaarden van kwaliteit, kosten en veranderingssnelheid bepaalt en dit verklaart tegelijkertijd waarom zoveel traditionele systemen en diensten nu een architectuurschuld hebben.
Bevrijd je gedachtengang
Dus, als ik terugkijk op mijn eerdere werk, zit er vooral een luchtje aan mijn design. Maar als ik dat design opnieuw zou moeten maken met de kennis en de technieken van vandaag, dan zou ik hele andere afwegingen maken. Virtualisatie is de magische staf die het nieuwe paradigma voortdrijft. Ieder onderdeel kan zijn eigen virtuele database hebben, zonder dat ik me zorgen hoef te maken over de daadwerkelijke dataverwerking. Ik voel me vrij om een relationele database te ontwerpen voor een dienst door een complexe query te implementeren, of een object-database voor een dienst die een object van het ene in het andere model verandert, of een key-value opslag voor declaratively managed services, allemaal als onderdeel van een enkele bovenliggende dienst. Ik zou een paar jaar geleden zelfs niet van zo’n ontwerp hebben durven dromen, maar vind het nu eigenlijk best bevrijdend. Ik kan nu gewoon de juiste tools voor iedere klus uitzoeken.
Dit geldt voor databasetechnologie, maar ook voor middlewaretechnologie, voor computationeel intensieve technieken zoals machine learning en zelfs voor pipelines voor gegevensdistributie. Zolang ik ze als een service kan gebruiken en de barrière om ze te adopteren laag is, zijn er geen echte nadelen aan heterogeniteit. Ik zal de juiste mensen erbij moeten betrekken. Dat blijft een feit. En ja, het team dat ik heb zou de te maken ontwerpkeuzes kunnen beperken.
Omarm de cloud
Vandaag de dag ligt de grootste architectuurschuld voornamelijk in het niet gebruiken van moderne cloudeigen principes (zoals Containers, Orchestration, Distribution, CI/CD, noSQL, Data Mesh, Service Mesh) en in het vrij spel geven aan de kracht van machine learning technieken om steeds slimmere oplossingen te creëren. Deze twee zijn nauw met elkaar verbonden. De cloud geeft de mogelijkheid om op een schaalgrootte en snelheid te werken die voorheen ongekend was, waardoor big data gegenereerd wordt die direct klaar is om real-time geanalyseerd te worden. Ik weet dat dit nogal verschillend is voor afzonderlijke organisaties in verschillenden sectoren, maar ik heb nog geen organisatie leren kennen waar geen grote potentie ligt om te profiteren van deze technieken.
Inertie
Dat brengt me op nog een ander soort schuld. Inertie, ofwel traagheid. Het is een bekend feit dat mensen dingen graag doen op de manier die ze gewend zijn. Ze denken er geen seconde over na om een relationele database te gebruiken. Ze zouden kunnen overwegen een container te gebruiken, zoals met de lichtgewicht virtual machine waar ze aan gewend zijn. Ze zouden een API aan kunnen bieden, maar dan meer als een extra laagje om de bestaande interface. Hoewel inertie niet per se schadelijk lijkt, kan het op de lange duur flink wat kosten. Om het positief uit te drukken: des te technisch terughoudender je bent, des te meer potentie er nog in je zit.
Je architectuurschuld aflossen
Ik geloof dat software-architecten voorop zouden moeten lopen in het aflossen van hun architectuurschuld. Ik geloof ook dat software-architecten de eersten zouden moeten zijn die de nog onzichtbare potentie van de cloud helder voor ogen hebben. En ik geloof tot slot dat software-architecten kennis in huis zouden moeten hebben over verschuivende paradigma’s en in moeten kunnen zien dat tegenwoordig afwegingen anders gemaakt moeten worden dan voorheen. Of je het nu kunt kwantificeren of niet, moderniseren levert toegevoegde waarde op.
Wellicht ben je niet de persoon die direct voorop loopt bij opkomende technieken. Dat is prima. Maar dat betekent niet dat je maar lekker achterover kunt hangen. Het zegt alleen dat je timing anders is. Om mezelf een geheugensteuntje te geven voor mijn eigen timing, houd ik ervan om nieuwe technieken in qua prioriteit in drie categorieën te verdelen:
- Tijd om toe te kijken, adoptie van de technologie kan wachten. Probeer begrip te krijgen van de mogelijke impact.
- Tijd om op te letten, technologie die volwassen aan het worden is of mogelijk toe te passen is. Klaar staan om de technologie te evalueren.
- Tijd om voor te bereiden. Klaar staan om de technologie op te nemen.
Ik kan van harte aanbevelen om deze vorm van actief management van je technologieradar te gebruiken. Deze simpele handvatten helpen je om op tijd mee te doen met veranderingen en zo relevant te blijven als software-architect.
Dus, als je dat nog niet gedaan hebt, investeer dan de nodige tijd zodat je het nieuwe paradigma gaat begrijpen. Bestudeer de Design Principles for Cloud Native Applications. Denk erover na. Lees het dan nog een keer. Graaf dan nog wat dieper. Het is een radicaal andere manier van denken, die de belofte genoemd wordt voor betere oplossingen op een hoger tempo en tegen lagere kosten. Het is alom bewezen. Het is betrouwbaar. Er zijn geen alternatieven op mijn radar. En jij kunt er ook van profiteren.
Aan de slag
Op dit punt zou je een idee moeten hebben van hoe groot je schuld is. Misschien kun je het niet exact in geld uitdrukken, maar het is niet te ontkennen dat het hier om flinke bedragen gaat. Het is de hoogste tijd om jouw architectuurschuld af te lossen. Begin met een experiment en probeer de slag te pakken te krijgen. Maak niet iedere keer op keer dezelfde fout. Laat het oude paradigma achter bij het ontwerpen van nieuwe oplossingen. Leer, groei en vaar er wel bij.
Je hoeft de reis niet alleen te maken. Wij staan klaar om samen met je op te trekken. Wij weten immers hoe je overstapt op micro.
Through the MicroScope is een reeks blogs die zich richt op het ontwerp van veerkrachtige, cloudeigen architectuur. Iedere editie zal de microsfeer vanuit een andere hoek benaderen. Lees ook de andere blogs in deze reeks.
