Metaforen voorsoftwareproductiemisleidend

De reden is dat men zo makkelijker over de bouw, het ontwerp en de kosten van software denkt te kunnen praten met niet-technici. En daarbij wordt alle software vaak over één kam geschoren. En daar beginnen de problemen.
Eerst categoriseren we deze verschillende geautomatiseerde informatiesystemen die binnen organisaties voorkomen; de consumentenmarkt laten we buiten beschouwing. Aan de ene kant van het spectrum staan de standaardsoftwaresystemen die over de hele wereld en door iedereen gebruikt worden. Ze bieden standaardfunctionaliteit als tekstverwerking, spreadsheets, mail, browsers en zoekmachines. Deze informatiesystemen zijn echte massaproducten die een fantastische prijs-prestatieverhouding hebben. De prijs per functiepunt van een gemiddelde tekstverwerker is fenomenaal en de prijs-prestatieverhouding van gratis diensten als Google en MSN is feitelijk zelfs oneindig. Tegenover deze waarde staat natuurlijk het feit dat je als gebruiker niets te kiezen hebt. Je kiest ervoor het product te gebruiken zoals je het krijgt/koopt. En als het niet bevalt, dan neem je een vervangend product want de switchkosten zijn laag, of afwezig.
Helemaal aan de andere kant van het spectrum staan de systemen met een heel lage prijs-prestatieverhouding: de corporate administratieve systemen. Het gerucht gaat bijvoorbeeld dat een gemiddelde energieleverancier 40 euro per jaar per aangesloten klant betaalt voor het ERP-systeem van de organisatie (eigenlijk betaalt die klant dat natuurlijk). Het lijkt ons veel. Deze hoge prijs wordt natuurlijk niet voor niets geaccepteerd: de organisatie vindt de investering terecht omdat het een goede businesscase heeft. Zonder het systeem zou het verwerken van de administratieve taken (nog) veel duurder uitvallen, zo is de overtuiging.
De problemen in software-implementatieprojecten ontstaan als verkeerde metaforen gebruikt worden. Zoals gezegd, wordt in de IT-branche makkelijk de auto- of huismetafoor gehanteerd; ook voor de corporate administratieve systemen.
Waarom is zo’n verkeerde metafoor dan zo schadelijk? Het is toch maar een beeldspraak? De essentie is dat de focus van het project verkeerd gekozen wordt.
We pakken een voorbeeld om dit aan te tonen. Indien je de auto als metafoor voor een corporate administratief systeem (zeg een polisadministratie) kiest, dan vergelijk je het productieproces voor auto’s met het productieproces van de software voor de verzekeringsadministratie. Een misvatting. De auto is namelijk een standaardproduct dat door één gebruiker gebruikt gaat worden voor een heel specifiek doel (rijden) en tot op zekere hoogte op klantwens uitgeleverd kan worden, maar na uitlevering (het verlaten van de fabriek) niet meer aangepast zal worden aan veranderde eisen en wensen. De polisadministratiesoftware kent hele andere kenmerken: veel gebruikers met verschillende rollen, grotendeels op maat gemaakt voor een klantorganisatie, veel aanpassingen na het verlaten van de fabriek.
De goede metafoor voor een polisadministratie is gelukkig in hetzelfde domein te vinden. Software is geen product als een auto, het is een productiefaciliteit. In autotermen gesproken: als we het hebben over administratieve systemen, dan is software niet wat er uit de fabriek komt, het is de fabriek zelf. Ofwel: de software voor de polisadministratie is de assemblagelijn, de slimme logica in die software zijn de robots, de medewerkers van de verzekeringsmaatschappij zijn de mensen aan de lopende band (dat vinden ze niet leuk om te horen overigens) en de polissen zijn de auto’s.
In dat licht bekeken worden de in de IT-branche zo enthousiast gepromote concepten opeens heel vreemd. Ooit een assemblagelijn van een autofabriek vanuit een ‘model driven architecture’ zien ontstaan? Ooit installateurs van een fabriek enthousiast horen vertellen dat ze dit soort assemblagelijnen volkomen fabrieksmatig en repeterend neerzetten? CMMI? “We outsourcen alle werkzaamheden aan de installatie van onze productielijn naar India, want dat is goedkoper!” Ooit iemand in de industrie horen zeggen dat ze die oude fabriek wel automatisch converteren naar een nieuwe fabriek?
Het is domweg de verkeerde metafoor: het bouwen van software is geen fabrieksmatig proces, omdat elk softwaresysteem anders is. Fabrieksmatige processen, zoals het bouwen van auto’s, zijn fabrieksmatige processen omdat er een heleboel min of meer dezelfde producten in korte tijd met zeer lage toleranties gebouwd moeten worden. In het geval van software moet er ‘maar’ één systeem gebouwd worden. Er valt dus niks te winnen in efficiëntie met een fabriek. En daarbij is de efficiëntie bij de softwareproductie veel minder belangrijk. De efficiëntie bij het onderhoud en de aanpasbaarheid over langere termijn, dat is waar het om gaat bij software: de total cost of ownership (TCO) over de hele lifecycle, niet de projectkosten (die hooguit 20 procent van de totale TCO bedragen).
Software is niet wat er uit de fabriek komt, het is de fabriek zelf. En dat levert dan in een keer een hoop inzichten op. Laten we eens wat vergelijkingen trekken tussen de auto-industrie en de informatieverwerkende industrie.
Als er een nieuwe auto wordt ontwikkeld, dan laat men eerst een groepje mannen met moeilijke brillen en grappige overhemden los op een groot stuk klei. Daaruit komt een hele grote klei-auto, die de ontwerpstudie wordt genoemd. Als het publiek daar enthousiast op reageert, wordt er onmiddellijk een groep ingenieurs naast de ontwerpjongens gezet. De industrie weet dat als de ontwerpers vrijspel krijgen, er weliswaar een hele mooie auto uit de klei komt, maar dat die vervolgens niet of niet goedkoop op straat te zetten valt. Zie hier het lot van al die mooie conceptauto’s die op elke autoRAI staan te glimmen. De ingenieurs zorgen ervoor dat er een productiefaciliteit te bouwen is voor de auto, en laten weten dat het ontworpen achterlicht weliswaar heel mooi is, maar dat er andere exemplaren voorradig zijn, waardoor de auto 1.000 euro goedkoper wordt om te produceren.
Daarnaast worden de ontwerpers in lijn gehouden doordat ze al tijdens de voorstudie (het grote blok klei) in contact komen met de gebruikers van de auto. Er worden vele focusgroepen gewijd aan de zitpositie, de grootte van de deur, de lengte van de versnellingspook en de kleur van de lak.
Vergelijk dit met de software-industrie. Daar geeft de klant een specificatie af van de productiefaciliteit. Dat wil zeggen: de klant beschrijft hoe hij wil dat het softwaresysteem gaat functioneren. Dat zou vergelijkbaar zijn met de klant die enige bemoeienis zou hebben met de inrichting van de fabriekshal van zijn favoriete automerk.
Een direct gevolg van deze situatie is de verzuchting van elke projectleider in elk softwareproject waar ook ter wereld: “De klant weet ook niet wat hij wil.” Nee, natuurlijk niet. Niet als de klant de productiefaciliteit moet specificeren. De klant weet natuurlijk heel erg goed wat hij wil. Hij wil van A naar B rijden. Of om in de IT-sfeer te blijven: hij wil 5.000 polisaanvragen per dag kunnen verwerken tegen lagere kosten dan zijn concurrent. En hij wil dat de hypotheekaanvragers die zijn beste klanten zijn, voorrang krijgen bij hun aanvraag, en hij wil dat er middels patroonherkenning een voorspelling wordt gedaan over welke hypotheekaanvragers zijn beste klanten gaan worden, zodat die een speciale behandeling kunnen krijgen (customer intimacy, volgens de marketingboeken), of hij wil gewoon geen gezeur en hij wil de polisaanvragen zonder menselijke tussenkomst en masse tot een polis om kunnen zetten (straight through processing, operational excellence). En hij wil dat alles automatisch naar de notaris gaat, zodat zijn klanten daar geen last van hebben. En hij wil op elk moment van de dag weten hoeveel aanvragen er liggen, hoe lang ze er al liggen, hoe lang een aanvraag gemiddeld duurt. En nog veel meer. En als het systeem klaar is, dan wil hij nog allerlei andere dingen.
Het kiezen van de juiste metafoor is cruciaal. En het kiezen van de verkeerde kan rampzalig uitpakken. Is het softwaresysteem een standaardproduct dat door duizenden gebruikt wordt? Vergelijk het gerust met een auto. Veel functionaliteit voor weinig geld en makkelijk te gebruiken is wat je wilt. Is het softwaresysteem een webportal dat klanten moet binden en waar verkocht moet worden? Vergelijk het met een winkel. Maak een marketeer leading, zorg dat het snel aanpasbaar is aan de marketing-waan-van-de-dag en zorg dat de kassa en de beveiliging degelijk zijn.
Is het softwaresysteem een instrument waar hele afdelingen dagelijks productie mee moeten draaien? Zie het als een fabriek. Onderhoudbaarheid, aanpasbaarheid, toekomstvastheid, lage prijs per geproduceerd product is wat je wilt.
Fabrieksmatige, modelgedreven ontwikkeling van software? Who cares? De beste industriële productieprocessen worden gerealiseerd door ingenieursbureaus die zeer nauwgezet aangestuurd worden door klanten die precies weten wat ze willen produceren onder welke randvoorwaarden. Waarom leert de IT-branche daar niet van? Wij zien veel softwareprojecten mislukken omdat ze moeten voldoen aan eisen die er niet toe doen, en niet voldoen aan eisen die er wel toe doen. Onnodig.

Dr. Tobias Kuipers en ir. Jan Willem Klerkx (jw.klerkx@sig.nl) zijn beiden als directeur verbonden aan de Software Improvement Group, een onafhankelijk instituut dat de kwaliteit van softwareprojecten beoordeelt in opdracht van grote Europese ondernemingen en overheidsinstanties.