De prijs van standaardisatie

Binnen ons vakgebied werken we graag met talen die aan standaarden voldoen. Het gebruik van leverancierafhankelijke oplossingen geeft ons altijd een slecht gevoel, want dan draaien onze applicaties alleen bij de gratie van die leverancier. Nee, leverancieronafhankelijkheid staat hoog bij ons in het vaandel. Het is een van de redenen waarom SQL ooit doorbrak en waarom momenteel Java en XML zoveel aandacht krijgen. Maar hebben we ooit uitgerekend hoe duur het eigenlijk is om met standaarden te werken? Levert het eigenlijk wel wat op?

Het gebruik van standaarden verhoogt inderdaad de mate van leverancieronafhankelijkheid. Het maakt de overstap naar producten van concurrerende leveranciers eenvoudiger. Als de producten van onze eigen hofleverancier niet meer voldoen, te duur geworden zijn, of als de leverancier zelf in financiële problemen geraakt is, dan bieden standaarden ons een ontsnappingsroute. Iedereen begrijpt dit en is zich bewust van dit voordeel.

Leveranciers hebben echter de neiging om, als ze een standaard implementeren, er extensies aan toe te voegen. Dit zijn vaak prestatieverbeterende of productiviteitverhogende faciliteiten. Een klant die deze extensie niet gebruikt en zich gewoonweg aan de standaard houdt, kan makkelijker overstappen, maar legt zichzelf restricties op. De applicatie zal qua performance te wensen overlaten en er zal meer tijd nodig zijn om de applicatie te ontwikkelen. Het is dan ook begrijpelijk dat klanten uiteindelijk de aantrekkingskracht van die extensies niet kunnen weerstaan. 

Het is goed om te realiseren dat als we ons wel aan een standaard houden, we een prijs betalen voor een product waarvan we niet alle faciliteiten gebruiken. In feite gooien we een deel van ons geld weg als we ons tot een standaard beperken.

Een ander aspect betreft de productiviteit van de ontwikkelaars. Heeft iemand al eens uitgerekend of het ontwikkelen met standaarden goedkoper is? Veronderstel dat er bij een klant een applicatie ontwikkeld moet worden en er gekozen kan worden tussen een gestandaardiseerde programmeertaal (3GL) of een niet-gestandaardiseerde 4GL. Stel dat tevens blijkt dat het ontwikkelen met de 3GL drie keer zo lang duurt als met een 4GL. Het nadeel van de 4GL is inderdaad dat alles leverancierafhankelijk is en dat de applicatie geheel opnieuw gebouwd moet worden als de klant wil overstappen. Maar als de ontwikkeling drie keer zo snel gaat, dan kan de applicatie twee keer herbouwd worden en dan is nog steeds niet meer geld uitgegeven. 

En laten we eerlijk zijn, hoe vaak wordt een applicatie nu eigenlijk overgezet? Bij de meeste applicaties gebeurt dat in hun lange leven nooit. Denk maar aan alle mainframe applicaties. Met het bovenstaande voorbeeld wil ik niet stellen dat het ontwikkelen met een 3GL echt af te raden is, maar wel dat het tijd wordt dat we voor het werken met standaarden eens een financiële berekening maken. Hoe duur is nu eigenlijk het ontwikkelen met standaarden? 

Let wel, dit artikel is geen pleidooi om standaarden vaarwel te zeggen. Ik ben een groot voorstander van het werken met standaarden, daarom heb ik zelf jaren in een standaardisatiecommissie gezeten. 

Het is enerzijds een pleidooi om pragmatisch met standaarden om te gaan. Alleen maar melden dat iets een standaard is en daarom gunstig, is te dogmatisch en te simplistisch. Probeer aan te tonen dat het gebruik van de standaard ook inderdaad iets oplevert.

Anderzijds is dit artikel een pleidooi voor leveranciers om productiviteit- en prestatieverbeterende faciliteiten toe te voegen aan een standaard, maar doe dit niet op een leverancieronafhankelijke manier. Want dat ontkracht de waarde van de standaard. Nu lijkt het alsof leveranciers alleen de standaarden gebruiken om klanten te lokken en vervolgens implementeren ze extensies om ze weer te houden.