Out-of -the-box of maatwerk, that's the question

Waar ik ook advies geef, altijd steekt de maatwerk-discussie weer de kop op. "We willen absoluut geen maatwerk, alles moet 'out-of-the-box'!", is daarbij een veelgesteld standpunt. In de praktijk, echter, werkt dit standpunt nogal eens averechts; angstvallig vermijden van maatwerk kan namelijk ook onnodig geld en tijd kosten. En afgezien daarvan is vaak ook niet echt duidelijk wat wordt verstaan onder "maatwerk" en "out-of-the-box". Tijd dus om een en ander eens uitgebreid te behandelen om licht op de zaak te werpen en zo beter beslissingen te kunnen nemen.

Definities
Laten we beginnen met wat definities te geven en beschrijvingen wat maatwerk, out-of-the-box en de "smaken" daartussen in zijn.

Maatwerk, oftewel custom software: is software die speciaal voor een bepaalde situatie is gemaakt. Dit is niet gebaseerd op een bestaand platform, maar is vanaf de grond af speciaal ontworpen en gebouwd, speciaal voor de situatie.

Out-of-the-box software is software die, als het ware, na installatie al kan worden gebruikt voor het doel waarvoor het is aangeschaft. Dat is nogal ambitieus, want iedere situatie is namelijk anders en een software fabrikant kan natuurlijk nooit helemaal voorspellen waarvoor zijn software(platform) zal worden ingezet.

Vandaar ook dat aanpassingen aan software(platforms) vaak noodzakelijk zijn om deze aan te passen aan de situatie waarin ze gebruikt worden. En deze aanpassingen kunnen de volgende vormen aannemen:
- Aanpassingen in de vorm van configuratie; via de gebruikersinterfaces van de software instellen en aanpassen van de werking en functionaliteit van de software
- Uitbreidingen van de software, in de vorm van modules, adapters, enz..

Naast goed te weten wat voor type aanpassingen er aan de software mogelijk zijn is het ook belangrijk te weten wanneer welk type aanpassing in welke situatie gewenst is. De keuze om bijvoorbeeld voor out-of-the-box te kiezen, bijvoorbeeld, hoort namelijk geen doel op zich te zijn, maar een valide doel te dienen. En om dit doel te daarvoor moeten we wat breder kijken dan de ICT projecten zelf en kijken hoe een organisatie alternatieven beoordeelt. Het beoordelen van alternatieven gaat vaak, en ook in dit geval, op basis van risico inschattingen.

Risico's
Een organisatie streeft doelen (kwaliteit) na en die doelen kunnen op verschillende manieren worden gerealiseerd, waarbij kosten worden gemaakt en tijd wordt verbruikt. Geld en tijd is meestal van tevoren gereserveerd en beschikbaar, waarbij men ernaar streeft dit uit te geven met zo min mogelijk risico voor overschrijding en het niet behalen van de gestelde doelen en kwaliteit. En dat is de kern van de maatwerk vs. out-of-the-box problematiek: bepalen van het alternatief waarbij de gestelde doelen met een minimum aan risico kunnen worden behaald.

Maar hoe schatten we dat risico nu in? Waar moeten we naar kijken? Waar heeft dat risico betrekking op?

Vaak wordt helaas alleen gekeken naar de bouw van de eerste versie van een software oplossing, en nog niet eens naar installatie ervan, laat staan onderhoud, uitbreidingen en andere werkzaamheden. En dat terwijl de keuze voor out-of-the-box, maatwerk of een tussenvorm verdergaande gevolgen kan hebben.

Een praktijkvoorbeeld:
In een SharePoint ontwikkelomgeving wordt, volgens het out-of-the-box principe een prototype gebouwd van een website die vervolgens moet worden geïnstalleerd in de productie omgeving. Hiervoor blijken scripts noodzakelijk te zijn die ervoor moeten zorgen dat de website automatisch wordt geïnstalleerd in deze omgeving. De scripts moeten als maatwerk worden ontwikkeld, terwijl het uitgangspunt out-of-the-box was.

Een ander voorbeeld:
Een software oplossing wordt uitgebreid met een interface waardoor het mogelijk wordt om content via de RSS standaard te delen met andere applicaties. Hier wordt uitgegaan van maatwerk, maar met als gevolg dat verwachtte uitbreidingen kunnen worden gebaseerd op een standaard, hetgeen koppelen met out-of-the-box software oplossingen mogelijk wordt.

Het verdient daarom aanbeveling om te kijken naar de gehele software life cycle, en ook te kijken naar de gevolgen (impact) van de introductie van de oplossing binnen de organisatie.

Software life cycle
Software wordt niet eenmalig gebouwd, om vervolgens onaangepast tot in de eeuwigheid te functioneren. Grofweg zijn de volgende levensfasen van een software(platform) te onderscheiden:
1. Bouw en installatie van de eerste versie
2. Onderhoud, aanpassingen, uitbreidingen
3. Migratie naar een nieuwe versie
4. Afbouw

In alle bovenstaande fasen kan sprake zijn van maatwerk, out-of-the-box of een tussenvorm. En wanneer een eerste versie van een software oplossing wordt gebouwd als out-of-the-box wil dat niet zeggen dat voor de rest van de levensfasen uitgegaan kan worden van datzelfde out-of-the-box principe.

Het verdient dus aanbeveling om de gevolgen (impact) van de keuze voor maatwerk, dan wel out-of-the-box of een tussenvorm te bepalen voor alle levensfasen van de software oplossing.

Impact breder bekeken
Nu we het toch hebben over gevolgen (impact), laten we deze impact ook eens bepalen voor de omgeving waarin de software wordt gebruikt. Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk (als IAF) waarin helder gemaakt kan worden wat de gevolgen van oplossingskeuzen zijn voor business(processen, functies), informatiearchitectuur, technische infrastructuur, beheer en beveiliging. De keuze voor out-of-the-box kan bijvoorbeeld grote gevolgen hebben voor business processen.

Voorbeeld:
Introductie van een collaboratie platform waarbij eindgebruikers zelf hun omgeving kunnen inrichten (b.v. virtuele werkruimten aanmaken, collega's toegang geven, zelf content beheren) lijkt in eerste instantie de ontwikkelkosten voor een eerste versie te minimaliseren. Immers: in plaats van "dure" ICT specialisten, doen "gewone" eindgebruikers het (ontwikkel)werk. Echter, vanuit oogpunt van beheerbaarheid (governance) wordt een deel van de verantwoording bij niet-experts neergelegd, waardoor extra risico's worden gelopen op bijvoorbeeld wildgroei, waardoor beheerkosten en migratiekosten uiteindelijk hoger uitvallen.

Het nut van een bredere kijk op de gevolgen van keuze voor maatwerk, out-of-the-box of een tussenvorm is daarmee aangetoond.

Het lijkt allemaal logisch, maar toch denken we iedere keer weer van tevoren niet genoeg na over de keuze tussen maatwerk, out-of-the-box of een tussenvorm. De vraag is natuurlijk wat hiervan de oorzaak is.

De beperkte blik van projectmanagement
In de praktijk blijkt het hebben van een brede kijk op ICT projecten een uitdaging op zich te zijn. Reden hiervan is de manier waarop software ontwikkeling is georganiseerd; dit leent zich niet altijd voor een bredere (en daarmee kritische) kijk. Projecten worden namelijk beheerd door projectmanagers en projectmanagers worden beoordeeld kwaliteit, doorlooptijd en kosten van slechts een zeer beperkt deel van de software levensloop, vaak alleen de bouw van de eerste versie. Als de bouw van de eerste versie van een software oplossing naar tevredenheid verloopt, volgt een goede beoordeling. De gevolgen voor kosten, doorlooptijd en kwaliteit in volgende levensfasen, zal de projectmanager niet interesseren, hij is er immers niet verantwoordelijk voor. Zeker wanneer het project onder druk staat (lees: wanneer vooral doorlooptijd, en/of kosten dreigen te worden overschreden) zal een projectmanager kiezen voor oplossingen op de korte termijn, hetgeen gevolgen heeft in de latere levensfasen van de software oplossing.

De gevolgen
De gevolgen laten zich raden: implementatie - en onderhoudskosten voor ICT projecten rijzen de pan uit en lijken onbeheersbaar te zijn. Te hoge verwachtingen van mogelijkheden die platformen out-of-the-box aan functionaliteit bieden leiden tot teleurstellingen en moeten achteraf worden waargemaakt door (duur) maatwerk of sterk worden bijgesteld.

Dit kan natuurlijk beter.

Praktische tips om beter om te gaan met de keuze voor maatwerk, out-of-the-box of tussenvormen
In het algemeen: over de gevolgen van de verschillende strategieën zal van tevoren en projectoverstijgend nagedacht moeten worden.
Eerst zullen de verschillende mogelijke strategieën: van out-of-the-box tot en met maatwerk, goed gedefinieerd moeten worden. Wanneer wordt bij voorbeeld iets gerekend tot out-of-the-box? Aan welke eigenschappen moet het voldoen?
Daarna zal duidelijk moeten worden wat de gevolgen zijn van de mogelijke strategieën, in de verschillende levensstadia van de betreffende software oplossing.Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk als IAF.
Op basis van de bovenstaande uitwerking kan een onderbouwde keuze worden gemaakt.

Tenslotte zullen de genomen beslissingen projectoverstijgend moeten worden bekrachtigd; de verantwoordelijkheid van de projectmanager, als hij niet voor de hele software lifecycle verantwoordelijk is, is hierbij onvoldoende.