Strategie build or buy wordt bepaald door de beheervraag

Sinds jaar en dag bestaat er een discussie binnen IT-afdelingen over een fundamentele kwestie: ga ik mijn applicaties zelf bouwen of schaf ik een standaard oplossing aan? De voor- en nadelen zijn door de jaren heen uitgekauwd, maar het echt aanpakken van de oorzaken lijkt pas nu op gang te komen. 

De build or buy-discussie dateert al vanaf het prille begin van de softwareontwikkeling. De voorkeur van de markt verandert daarbij om de zoveel tijd. Je kan het bijna zien als een golfbeweging. In de eerste jaren was er nog niet veel standaard software. Bovendien bevatte standaard software vaak nog kinderziektes, wat het vertrouwen ook niet sterkte. Zelf applicaties bouwen was daardoor het devies.

Build or buy: that’s the question 

Maar dit bleef niet zo. Pakketten werden stabieler en steeds uitgebreider, waardoor standaard software door de jaren heen steeds meer een valide optie is geworden. Daar kwam bij dat maatwerk ook de nodige problemen met zich meebracht. Het onderhoud van de applicaties nam veel tijd in beslag, doordat iedere applicatie op z’n eigen unieke manier was geschreven. De complexiteit van het applicatielandschap nam toe en integratieprojecten waren daardoor moeilijk te verwezenlijken. Verandertrajecten werden lang en kostbaar en gingen (en gaan) ook vaak mis, zoals recent nog het project van de Sociale Verzekeringsbank negatief in de belangstelling was.

Vanwege dit soort incidenten zijn veel bedrijven afgelopen jaren gaan werken met strandaard pakketten. De perceptie dat het goedkoop is, snel in te zetten en gemakkelijk te onderhouden zijn de belangrijkste redenen waarom bedrijven voor standaardisatie kiezen. Een groot nadeel is echter dat bedrijven die werken met standaardproducten minder gemakkelijk het verschil kunnen maken met IT. Dat met name goed te zien bij de inzet van ERP-pakketten. Bedrijfsprocessen worden afgestemd op wat het pakket te bieden heeft. Men wil meestal geen maatwerk binnen een standaardpakket vanwege de hoge implementatie- en beheerkosten, maar de behoefte aan maatwerk blijft bestaan. Om toch aan de innovatiebehoefte te kunnen voldoen ontstaan weer maatwerkoplossingen, vaak buiten het bereik van IT, met een enorme groei van het shadow IT tot gevolg.

Beheerlast 

De laatste jaren is de innovatiecyclus voor bedrijven enorm verkort, zeker met de opkomst van mobiel. Mobiele oplossingen hebben over het algemeen een zeer korte life cycle. Dus speelt de aloude vraag buy or build weer op. Bedrijven snappen dat ze iets met maatwerk moeten om te kunnen innoveren. Maar wanneer ze voor een maatwerkstrategie kiezen, willen ze niet in de oude valkuilen stappen. Het eigenlijke probleem is namelijk het beheer van de applicaties. Het kost anno 2014 nog te veel tijd om applicaties te onderhouden en doordat er tegenwoordig veel meer applicaties worden ontwikkeld dan vroeger lopen backlogs snel op. Zaken als DevOps en continuous delivery, methodes waarbij het IT-beheer bewust bij de ontwikkeling betrokken wordt, zijn tegenwoordig populair.

De eigenlijke vraag is dan ook helemaal niet buy or build, maar hoe ga ik applicaties beheren? En daar komen heel andere subvragen bij kijken. Wat zijn bijvoorbeeld je core applicaties en waar wil je snel kunnen innoveren? Het Gartner’s Pace-Layered Application Strategy kan hierbij een mooie kapstok zijn. Applicaties worden er geschaard in drie categorieën: applicaties met common requirements, applicaties die een unieke businessfunctie ondersteunen en applicaties die bedrijven gebruiken om te innoveren en experimenteren. Iedere groep kent een eigen veranderdynamiek en ondersteuningsbehoefte. Degenen die de in de wereld beschikbare IT-tools hier het best voor in kunnen zetten, gaan uiteindelijk het verschil maken.