Normalized Systems Theory

Spotify, Walmart, Paypal en Amazon zijn succesvol geworden door het slimme gebruik van microservices. Een mooi voorbeeld van deze microservices-architectuur zijn containers, omdat ze bedrijven in staat stellen zich te concentreren op het ontwikkelen van die services zonder zich zorgen te hoeven maken over afhankelijkheden. Als het ware een LEGO-bouwpakket, een verzameling modules. Elke module draagt letterlijk zijn ‘steentje’ bij aan de totale applicatie en de geleverde dienst. Theorieën als de Normalized Systems Theory (NST) duiden hoe je modulariteit in een systeem ontwerpt om schaalbaarheid en duurzaamheid in door de mens gemaakte artefacten te borgen. Waardoor evolutie, upgrades, verandering en innovatie van een systeem mogelijk blijft. Modulair gebouwde software als een decennialang goed te onderhouden en te vernieuwen kapitaalgoed. Zoals software pionier Douglas McIlroy zei: ‘De echte held van programmeren, is degene die negatieve code schrijft’.

Enterprise Architecture and Information Engineering

John Zachman wordt wel de vader van de Enterprise Architectuur genoemd. Zijn ‘Zachman Framework for Enterprise Architecture (1987)’ is een schema van classificaties om ordening te realiseren: het doel van iedere architectuur. De basis is communicatie via de primitieve vragen: wat, hoe, wanneer, wie, waar en waarom. Daarnaast het gebruik van reïficatie, iets abstracts in concrete termen kunnen definiëren. Door Zachman gelabeld in het Framework: Identificatie, Definitie, Representatie, Specificatie, Configuratie en Instantiatie. Met deze kennis uit oude disciplines van zowel architectuur/constructie als engineering/manufacturing kon Zachman op eenduidige holistische wijze, complexe informatie-technische functies beschrijven. De geboorte van Information Engineering.

De ontwikkelaar van Information Engineering (IE) was Clive Finkelstein, die samen met James Martin de IE-revolutie ontketende. Zij ontwikkelden methoden om de creatie van Enterprise Architecturen te automatiseren, ook wel Enterprise Engineering genoemd. Het ontwerpen en produceren van complete Enterprise Architecturen (EA), inclusief definitie en inhoudelijke creatie van regels, databases en systemen. De methodologie voor het automatisch ontwerpen en bouwen van software was geboren. Steeds sneller, makkelijker maar ook steeds groter.

Wet van de toenemende complexiteit

De uitdaging bij grote applicaties was altijd de groeiende complexiteit. Hoe kon men de applicatie lange tijd blijven vernieuwen, evolueren en innoveren? De wet van toenemende complexiteit van Manny Lehman (1980) stelt dat: ‘Naarmate een zich ontwikkelend programma voortdurend wordt gewijzigd, neemt de complexiteit ervan – die de verslechterende structuur weerspiegelt – toe, tenzij er wordt gewerkt aan het behouden of verminderen ervan’. Het toevoegen van functionaliteit aan bestaande informatiesystemen maakt ze in de loop van de tijd steeds complexer en kostbaarder in onderhoud en instandhouding. Slechts intensief onderhoud en continue rigoureuze vernieuwing kan de kwaliteit van software in stand houden.

Software-onderhoud is inderdaad de duurste fase van de levenscyclus van een informatiesysteem. Het leidt tot toename van de architectonische complexiteit en afname van de software-kwaliteit. Herkenbaar in het feit dat – zonder vernieuwing – budgetten van IT-afdelingen elk jaar groeien. Bovendien stelt Lehman ook dat naarmate software complexer wordt, het minder bruikbaar en onderhoudbaar wordt. Een bord met een groeiende hoeveelheid spaghetti: als je ergens aan trekt, beweegt er steeds meer . . .

Negatieve code

Hoe kun je software modulair ‘genoeg’ ontwerpen en bouwen, opdat het continu vernieuwd kan blijven worden? Hoe zien evolueerbare software-architecturen voor bedrijfssystemen eruit? In feite de invulling van de uitspraak van de software pionier Douglas McIlroy: ‘De echte held van programmeren, is degene die negatieve code schrijft’, waar negatieve code wordt opgevat als regelreductie. Vergelijkbaar met de anekdote van beroemde Apple-ontwikkelaar Bill Atkinson: ‘Pas wanneer een wijziging in een programmabron het aantal regels code doet afnemen (‘negatieve’ code), zal de algehele kwaliteit, leesbaarheid of snelheid verbeteren.’

Dat zijn een beetje de principes waaruit de Normalized Systems Theory (NST) is ontwikkeld. Welke software architectuur is nodig opdat er geen combinatorische explosies ontstaan bij vooraf gedefinieerde wijzigingen in het systeem? Informatiesystemen bouwen op basis van routines die als ‘gelijkblijvende families van bouwstenen’ blijven bestaan. Dusdanig modulair ontwerpen dat de componenten als onafhankelijke zwarte dozen kunnen worden beschouwd. Door deze modules elke paar maanden opnieuw te generen, blijft de software jong en flexibel. Jan Verelst (Universiteit Antwerpen) heeft veel bijgedragen aan deze theorie en als spin-off richtte hij samen met Herwig Mannaert het bedrijf NSX op dat toepassingen ontwikkeld op basis van NFT.

Evolueerbaarheid van systemen

Theorieën als de Normalized Systems Theory (NST) duiden hoe je modulariteit als LEGO-blokjes in een systeem ontwerpt om schaalbaarheid en duurzaamheid in door de mens gemaakte artefacten te borgen. Waardoor evolutie, upgrades, verandering en innovatie van een systeem mogelijk blijft. Modulariteit komt uit de wereld van systems engineering waar ik al vaker over geschreven heb: het ontwerpen, bouwen en lange tijd in standhouden van grote kapitaalgoederen. Deze visie wordt met NFT 1:1 toegepast op software. Modulair gebouwde software als een decennialang goed te onderhouden en te vernieuwen kapitaalgoed.

NFT heeft een aantal principes om op een systematische manier softwarestructuren te engineeren. Het ‘voorkomen van combinatorische effecten’ en het ‘scheiden van zorgen’ door scheiding van taken, waardoor elke verandering geïsoleerd kan worden uitgevoerd. Daarnaast ‘transparantie van de gegevens- en actieversie’ door inkapseling van data-entiteiten en taak-entiteiten, waardoor scheiding van stappen in een workflow mogelijk wordt. Fijnmazige en ‘ingekapselde’ bouwstenen die modulair en onafhankelijk kunnen worden onderhouden. Hiervoor zijn 5 primitieve elementen benoemd: gegeven, actie, workflow, connector en trigger waarmee elk software systeem kan worden gebouwd.

De komst van microservices en containers

NFT stelt dat de creatie van software zo generiek mogelijk moet zijn om het zo lang en zo goedkoop mogelijk in stand te kunnen houden. De levenscyclus van software overstijgt immers vele malen de (eerste) ontwerpcyclus. Voor grotere, cloud gebaseerde applicaties leidde dit tot de ontwikkeling van microservices. Een architecturale en organisatorische benadering van software-ontwikkeling waarbij een programma is samengesteld uit vele kleine onafhankelijke services die communiceren via goed gedefinieerde API’s. Deze diensten worden ontwikkeld en beheerd door kleine, zelfstandige teams (Agile-development). Een uitdaging bij het gebruik van microservices is de groeiende noodzaak tot data-consistency als het aantal microservices groeit. En dit betekent een groeiende noodzaak voor datacentrische systeemontwikkeling.

Een mooi voorbeeld van deze microservices-architectuur zijn containers, omdat ze bedrijven in staat stellen zich te concentreren op het ontwikkelen van die services zonder zich zorgen te hoeven maken over afhankelijkheden. Als het ware een LEGO-bouwpakket, een verzameling modules. Elke module draagt letterlijk zijn ‘steentje’ bij aan de totale applicatie en de geleverde dienst. Grote cloud-native applicaties worden gewoonlijk gebouwd als microservices door gebruik te maken van containers. Spotify, Walmart, Paypal en Amazon zijn succesvol geworden door het slimme gebruik van microservices. Ook API’s kunnen geheel of gedeeltelijk uit microservices bestaan. De microservice-architectuur is geen ‘silver bullet’ of wondermiddel maar wordt – zeker vanuit de NST-gedachte – tegenwoordig overal succesvol gebruikt voor grote applicaties.

Door: Hans Timmerman (foto)