De software-assemblagestraat

Het bouwen van de duizendste auto is daarmee goedkoper dan het eerste exemplaar. Voor softwareprojecten geldt deze productiviteitsgroei niet, blijkt uit onderzoek van onder anderen prof. Manny Lehman en de Standish Group. Sterker nog, het realiseren en  inpassen van het duizendste softwareproject in eenzelfde IT-landschap kost meer tijd en geld en levert vaak minder op dan één op zichzelf staand project. Ofwel, softwareontwikkeling wordt beheerst door Lehmans wet van toenemende complexiteit. Deze wetmatigheid is vergelijkbaar met de ‘wet van de toenemende (relatieve) kosten’, waarbij het inzetten van steeds meer middelen leidt tot een steeds lagere opbrengst.

Productiviteitsgroei zoals die gerealiseerd wordt in andere industrieën, lijkt nog ver uit het zicht van de software-industrie. De bouwers van IT-hardware is het wel gelukt om in de afgelopen decennia de kosten van processoren in relatie tot hun capaciteit te verlagen. Deze productiviteitswinst staat bekend als de wet van Moore en stelt dat het aantal transistoren op een computerchip door de technologische vooruitgang elke twee jaar verdubbelt. Ook op het gebied van netwerken is een soortgelijke groei bekend onder ‘de wet van Metcalfe’, waarbij de waarde van het netwerk toeneemt naarmate het netwerk groeit. Twee telefoons in de hele wereld zijn weinig waard, maar als iedereen een telefoon heeft is de waarde gigantisch.

Evolueerbare software, zonder technische schuld, is inmiddels haalbaar.

Onderzoek van de afgelopen jaren (onder andere Universiteit Antwerpen) heeft geleid tot het inzicht dat de snelheid van softwareontwikkeling factoren omhoog kan als een groot deel van de bouw wordt geautomatiseerd. Tot op de dag van vandaag heeft de softwarebranche dit echter niet opgepakt en de gewenste productiviteitstoename niet laten zien.

Voorwaarden

De vraag is, waarom niet? Is het, omdat eigenlijk ‘niemand’ in de software-industrie zit te wachten op een technologische innovatie die het huidige verdienmodel, waarbij in uren wordt afgerekend, onhoudbaar maakt? Of zijn het de werknemers in bedrijven die niet zitten te wachten op innovatie die naast een hogere productiviteit mogelijk ook banenverlies oplevert. Hoe zou een bedrijf eruitzien als de productiviteit met een factor 10 toeneemt? Veel organisaties hebben afgelopen decennia een complete bedrijfsstructuur gebouwd rondom het produceren en aanschaffen van software. Hierin bevinden zich informatiemanagers, architecten, ontwerpers, analisten, bouwers, testers, managers, inkopers. De kans is groot dat een deel van dit bouwwerk dan niet meer nodig is. En de vraag die dan natuurlijk als eerste opkomt is: Welke kalkoen zet zichzelf met kerstmis op het menu? Welke leverancier gaat helpen met een oplossing die een factor 10 goedkoper is en waarmee hij zijn eigen verdienmodel om zeep helpt? Wat moeten we met outsourcingscontracten als blijkt dat het meeste werk gaat zitten in het specificeren en de communicatie met de business en dit het beste ‘on site’ kan?

Welke kalkoen zet zichzelf met kerstmis op het menu?

Dit soort vragen zijn uitingen van een ander vraagstuk, namelijk van de voorwaarden die nodig zijn, om innovatie geadopteerd te krijgen. Bovenstaande en andere vragen zullen dus eerst beantwoord moeten worden voordat de gewenste innovatie doorgang kan vinden.

Natuurlijk is het een kwestie van tijd dat deze manier van softwareontwikkeling op grote schaal haar intrede doet, maar dat werd ook jaren geleden beweerd van de elektrische auto. Een markante uitspraak van de ANWB in de Kampioen van meer dan 118 jaar geleden (1898) illustreert de lange weg: ‘Het is te voorzien, dat het vervoermiddel der toekomst voornamelijk door elektrische drijfkracht zal worden bewogen.’ Pas met de komst van de lithium-ion batterij aan het begin van de eenentwintigste eeuw, een uitgebreid netwerk van laadpalen en subsidies van de overheid, krijgt de elektrische auto een nieuwe kans.

Doorbraak

Inmiddels lijken we op de drempel te staan van een echte doorbraak. Evolueerbare software, zonder technische schuld, met hergebruik en daardoor hoge productiviteit is inmiddels haalbaar. Echter, ook is duidelijk dat – net zoals de elektrische auto – er een worsteling nodig is voordat de technische, bedrijfseconomische en kennisinfrastructuur een kritische massa heeft bereikt die de software-industrie zal transformeren.

Op basis van de laatste inzichten is een aanpak ontstaan waarbij uitgekristalliseerde fijnmazige softwarebouwblokjes – analoog aan lego – door softwarerobots in elkaar worden gezet in een software-assemblagestraat. Hoewel deze aanpak niet nieuw is – op de NATO-softwareconferentie in 1968 reeds aangekondigd – en al jaren ‘veelbelovend’ wordt genoemd, bleek deze tot op heden niet duurzaam. Óf het landschap van ‘ontelbare’ bouwblokjes werd onoverzichtelijk werd óf – het andere uiterste – de bouwblokken bleken toch te groot, wat de onderhoudbaarheid en aanpasbaarheid beperkte. Met andere woorden: de introductie van het ontwerp van de bouwblokken- en generatorenaanpak leidde tot problemen (bekend als technische schuld) met de onderhoudbaarheid en aanpasbaarheid of op termijn met de prestaties van het systeem.

Dat verandert als gebruik wordt gemaakt van fijnmazige ‘genormaliseerde’ blokjes die voor een groot deel door softwarerobots kunnen worden gerealiseerd zonder additionele complexiteit die leidt tot technische schuld. Dan ontstaat er een software-assemblagestraat analoog aan een productiestraat zoals gebruikt wordt in andere industrieën. Een dergelijke manier van softwarebouw stelt de bouwers samen met gebruikers in staat om snel software te ontwikkelen door middel van evolutionaire prototyping. Immers de softwarerobots bewaken binnen de architectuur of een nieuw bouwblokje technisch past als een puzzelstukje in het landschap. Deze softwarerobots construeren, in vaktermen ‘expanderen’ (wat ongelijk is aan genereren van code uit functionele specificaties), dan de – automatisch geteste – software.

Softwarerobots bewaken of een nieuw bouwblokje technisch past.

Combineer de bovenstaande aanpak met reeds beschikbare halfproducten, zoals business rule engines, business proces engines en de best practices die zich momenteel vormen rondom continuous delivery pipelines, en er ontstaat een situatie waarbij we kunnen spreken van functiepunten per uur in plaats van de huidige uren per functiepunt.

De aanpak combineert meerdere zaken. Enerzijds is een bepaalde maturiteit ontstaan in de kwaliteit van producten uit de software-industrie, die als een soort halffabricaat kunnen worden ingezet. Anderzijds is een soortgelijke maturiteit ontstaan binnen het wetenschappelijke domein van software, die vrij is van technische schuld met de Normalized Systems Theory (zie kader) en de inzet van de DEMO-methodiek van Jan Dietz (zie http://www.ee-institute.org/) voor het ontwerpen van de organisatie en het standaardiseren van de requirements.

Feitelijk gezien is de aanpak niet meer dan een ‘best of breed’-aanpak, waarbij de lessen van de afgelopen veertig jaar toegepast worden, gecombineerd met wetenschappelijke en praktische inzichten op basis van onderzoek. Dus geen Big Design Upfront, geen megalomane projecten, maar: theoretische onderbouwing, meten, teamwork, verbeteren, klantwaarde leveren en in kleine stapjes vooruit.