Wat kost die S in SOA eigenlijk?

Dat lijkt een rare vraag, maar vreemd genoeg maken de meeste mensen zich wel zorgen over wat de A (van architectuur) kost, maar slechts weinig mensen kunnen of willen iets zeggen over de kosten van de S (de services). Een beetje vergelijkbaar met wel willen weten wat de fietsenfabriek kost, maar niet wat je voor een fiets moet betalen.

Integrale kostprijs berekening komt voort uit erp en MRP-fabricage-omgevingen. Met behulp een BOM (Bill of Materiaal) en een routing met machinebewerkingen kan haarfijn de kostprijs van een product berekend worden. Afhankelijk van de gekozen fabricagemethode kan dezelfde fiets overigens tegen verschillende kostprijzen worden geproduceerd. Zo zal een nieuwe volautomatische machine vaak goedkoper produceren dan een meer handmatig proces, althans bij ons in het westen. Maar ook de gekozen bandensoort kan een verschil in kostprijs betekenen. In fabrieken over de hele wereld zijn bedrijfsbureaus dagelijks bezig met nemen van operationele beslissingen op basis van kostprijsmodellen: "Welke lijn gebruiken we vandaag voor de omafietsen en spaken we de wielen zelf of is het deze week economischer om voorgespaakte wielen in te kopen?"

In de it zien we dit veel minder. Hier lijkt het wel of het gebruik geen invloed heeft op de kosten. "Die computers staan er nu toch, de software hebben we al betaald en de operators moeten er toch zijn. En of we ze nu gebruiken of niet, we moeten ze toch betalen." Met andere woorden, de enige variabele kostenpost van it was stroom, en die werd en wordt vaak niet doorbelast. Maar is dat vandaag de dag nog wel zo? Mede dankzij de inzet van soa zijn lang niet meer alle it-kosten vast. Zo sluiten hardwareleveranciers contracten af waarbij de klant betaalt per tik, schaffen we software inclusief de benodigde reken- en opslagcapaciteit steeds vaker aan als service (SaaS) en werkt die operator nu vaak voor een outsourcer, zodat hij zijn niet bezette tijd prima kan inzetten (en doorbelasten) aan andere klanten van zijn baas.

Opeens maakt het dus wel een verschil of het doorrekenen van een hypotheekofferte 12 of 18 eurocent kost en of dat we zes offertes of zestien offerteberekeningen per getekende hypotheekakte moeten doen. Als we dan ook nog, op basis van actuele vraag en capaciteit, at runtime kunnen beslissen of we deze hypotheekofferte zelf bereken of als third party service vanuit onze soa aanroepen, word het opeens toch een beetje raar dat we hier niet meer mee rekenen.

Zeker als we ons realiseren dat steeds meer traditionele 'producten' eigenlijk gewoon 'verpakte it-services' zijn. Denk maar aan een mobiel telefoongesprek (een programmaatje op je gsm praat met een programmaatje op het netwerk) en aan bankingtransacties (vroeger was de service goed als de heren en dames achter de balie glimlachten, nu als de home-bankingapplicatie bereikbaar is). Maar denk ook aan steeds meer medische 'producten', zoals MRI-scans, echo's en pacemakerpulsjes.

Om hieraan te rekenen zijn wel geaccepteerde standaardmodellen nodig. Modellen waarmee it-managementsystemen de integrale 'standard' en 'actual' kostprijs per service kunnen bepalen. Net zoals erp-systemen met behulp van BOM en routing al jaren voor traditionele producten berekenen, kan men verwachten dat CMDB's dit voor it-services gaan doen. Verwar dit overigens niet met Service of Activity Based Costing-modelen. Deze meer gebruikelijke methoden houden zich bezig met het toerekenen van in essentie 'vaste-overheadkosten' aan kostendragers, terwijl CMDB-based costing  (remember where you heard it first) de daadwerkelijke variabele kosten berekent.

Ps. Nog leuker wordt overigens de volgende stap: 'Design for Manufacturing'. Na zo'n honderd jaar industriële productie kwam men erachter dat je pas echt efficiënt kan produceren als je in je ontwerp al rekening houdt met het productieproces. Met andere woorden: als je niet voor iedere tv een unieke besturingschip en voor iedere fiets een unieke versnellingsnaaf ontwerpt, maar gebruik maakt van componenten die vaker gebruikt worden (… soa!) en van productieprocessen waar razendsnel tussen producten omgeschakeld kan worden (… virtualisatie!). Mijn verwachting is dat de gemiddelde ontwikkelaar hier voorlopig nog niet bij stilstaat als hij op een control klikt om weer moeiteloos tweehonderd nieuwe java legacy classes te genereren.