Als je jezelf als architect echt onmogelijk wilt maken, moet je eens proberen om aan het management voor te stellen een maatwerkoplossing te bouwen. Waarschijnlijk valt er even een stilte. Daarna legt een van de aanwezigen kort maar krachtig uit dat die tijden nu echt voorbij zijn, en dan gaat men weer over tot de orde van de dag. Verdere carrièrestappen zijn uitgesloten voor de architect die er klaarblijkelijk helemaal niets van begrepen heeft. Maatwerk is uit de mode. Pakketoplossingen zijn in. Elke zichzelf respecterende organisatie heeft tegenwoordig een lijst met architectuurprincipes, en op al die lijsten staat –ergens bovenaan– het adagium ‘Buy before Build’. Soms nog uitgebreid tot ‘Reuse before Buy before Build’.

Er zijn natuurlijk goede redenen waarom je een computerprogramma beter kunt kopen dan zelf maken. In de eerste plaats mag je van een leverancier verwachten dat die gespecialiseerd is in het schrijven van software en dat je daarom kwaliteit in huis haalt. In de tweede plaats heeft een leverancier meerdere klanten voor zijn software, zodat de ontwikkelkosten verdeeld worden. Ondanks de commerciële marge die de leverancier hanteert, ben je als klant toch goedkoper uit. In de derde plaats koop je bij een leverancier software “met ervaring” en wordt je niet geconfronteerd met het testen en debuggen dat bij zelf ontwikkelen onvermijdelijk is. In de vierde plaats is de doorlooptijd van het aanschaffen van software veel korter dan die van het ontwikkelen ervan (behalve voor wie trapt in de valkuil die customisation heet). En in de vijfde plaats ten slotte hoef je zelf niet het onderhoud van het pakket te doen.

Maar het kwaliteitsargument vervalt als je zelf beschikt over een deskundige en professionele ontwikkelafdeling. Sterker nog, je beschikt alleen dan over diepgaande kennis van het systeem. Ook het argument van niet hoeven testen en debuggen is relatief. Ondanks de aanvankelijke keuze voor proven technology ben je door het testen van nieuwe releases en patches toch al snel proefkonijn! En ook de andere genoemde argumenten gaan niet altijd op.

Een goede afweging tussen maatwerk en confectie is aan te bevelen. En er is een belangrijke reden waarom maatwerk de juiste keuze kan zijn, ook als vergelijkbare pakketten bestaan. De vraag is: Wat is het dat je met de software wilt bereiken? Gaat het om slechts ondersteunende processen? Kies dan vooral een pakketoplossing. Maar gaat het om activiteiten die wezenlijk zijn voor de organisatie, waarmee je je onderscheidt van de concurrentie en waarmee je een unieke propositie in de markt zet? Dan is maatwerk zo’n slecht idee nog niet. Want hoe kun je nu uniek zijn wanneer je volledig afhankelijk bent van standaardpakketten? Elke concurrent kan je toch zo na-apen?

Zelf ontworpen en ontwikkelde applicaties maken echt unieke proposities mogelijk die met standaardpakketten niet mogelijk zijn. Bovendien leveren de ontwikkeltrajecten heel veel kennis en inzicht op die onmisbaar is om te kunnen innoveren. Maatwerk is zo gek nog niet!

Erwin Oord ( Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken ) is principal consultant en partner bij ArchiXL

Reacties (1)

Alleen geregistreerde gebruikers kunnen reacties geven.
Log in of registreer.