One Shoe logo

De ins & outs voor strategische en succesvolle Enterprise software development

Software ontwikkelen en implementeren kan een uitdaging zijn. Afhankelijk van het doel waarvoor je de software ontwikkelt, kan de aanpak en focus van de ontwikkelstrategie nogal uiteenlopen. In deze blog serie (zie ook artikelen 2, 3 en 4) delen we de inzichten die we hebben opgedaan over de belangrijke verschillen tussen het ontwikkelen van software voor een doel (hierna: built for purpose) en het ontwikkelen van software voor de lange termijn (hierna: built to last).

Tibor Uittenbogaard | 03 dec 2018

Built for purpose

Bij built for purpose software kun je zeggen dat het project volbracht is nadat de software is ontwikkeld en (op)geleverd. Het project kan dan worden beschouwd als volbracht, en gesloten worden. Anders gezegd, de software is ontwikkeld voor het doel dat het moet dienen. Niets meer, niets minder.

Built to last

Het ontwikkelen van built to last software is anders. Dit soort software ontwikkeling gaat eigenlijk over projecten die nooit af zijn. Built to last software is, in het feite het ontwikkelen van (software) oplossingen voor de lange termijn, zodanig dat de software aan te passen is bij veranderingen. En kunnen omgaan met deze veranderingen is waar de ontwikkelaars van Enterprise Content Management- en Enterprise Software rekening mee moeten houden, soms over tijdspannes die vele jaren kunnen omvatten.

Het ontwikkelen van built to last software oplossingen, vereist een bepaalde mate van volwassenheid aan de bureauzijde, en een extra set ontwikkel- en organisatie vaardigheden. Bij het bouwen van built to last software moet het bureau en het ontwikkelteam rekening houden met een breed scala aan mogelijke scenario’s waarmee de software geconfronteerd kan worden gedurende zijn levenscyclus.

Verschillende doelen vereisen verschillende benaderingen

Het ontwikkelen en implementeren van built for purpose software kan een behoorlijke uitdaging zijn. Om dit succesvol te kunnen doen zijn goede bureau- en ontwikkel vaardigheden nodig. Maar in mijn optiek behoort het naar tevredenheid leveren (van de software applicatie), op tijd, zoals afgesproken en met de juiste functionaliteiten voor het doel dat de applicatie moet dienen, tot de basisvaardigheden die je mag verwachten van een hedendaags bureau voor webdevelopment en software development (digital agency). Het verschil, vergeleken met built to last software oplossingen, is dat deze projecten een kop en een staart hebben. Ze zijn daardoor te overzien. Je kunt deze projecten kwantificeren, plannen, en begroten, en er zit een einde aan.  

Op het technische vlak moeten built to last software-, CMS- en Enterprise Content Management systemen rekening houden met - bijvoorbeeld -, groei van het platform (gebruikersaantallen, data opslag, etc.), prestaties (snelheid, capaciteit bij piekbelasting), een open architectuur die voorbereid is op de integratie van 3e partij systemen en databases (“koppelingen”), veranderingen in de aard van functionele wensen en eisen, veranderende bedrijfsdoelstellingen, en veranderingen in het landschap van IT systemen en software. Ieder van deze factoren kan de ontwikkelstrategie beïnvloeden of veranderen.

Als development bureau moet je je hiervan bewust zijn en er zeker van zijn dat de applicatie de test van de tand des tijds kan weerstaan. In dat opzicht zou je built to last ook ‘built to test’ kunnen noemen. Het toekomstbestendig maken van de software oplossing en de (strategie) ontwikkeling ervan, is grotendeels de verantwoordelijkheid van de ontwikkelaar. Echter, ook de klant, heeft hier invloed op. Op de rol van de klant kom ik later terug.

Om er zeker van te zijn dat de website, app of software applicatie die je ontwikkelt toekomstbestendig is, moet je aandacht besteden aan:

  1. Lifecycle management. Anticipeer en wees voorbereid op mogelijke toekomstige veranderingen voor de klant en jouw bedrijf.
  2. Test coverage. Dit is een belangrijk onderdeel voor je project maar moet ook praktisch,ondersteunend en onderdeel van het documentatieproces zijn.
  3. Partnership. Stel (als bureau en klant) de juiste vragen.