Van tevoren achterhalen wat software moet bereiken, is even belangrijk als het ontwerpen van ict-sytemen op basis van de samenhang tussen bestaande ict-systemen en de aansluiting daarvan op bedrijfsprocessen. Dat zeggen de development-experts van Computable als antwoord op de vraag of zij denken dat enterprise-architectuur budgetoverschrijdingen kan voorkomen.
'Het komt weinig voor dat softwareontwikkelprojecten niet gebaseerd zijn op bedrijfsprocessen en -systemen', zegt testadviseur Mark Westenberg van Ps_testware. 'Wel kunnen aanzienlijke kosten worden bespaard door een goede degelijke analyse te doen van wat nu eigenlijk nodig is. Wat wil de opdrachtgever bereiken? Welk proces wordt geautomatiseerd? Is het een bestaand of een nieuw proces?'
Ook Eric van der Vliet van Logica wijst op het belang van goede vereisten als basis voor een softwareontwerp. 'Als hier fouten inzitten, zijn de kosten om ze te vinden en op te lossen gemiddeld 1,2 uur per fout, mits in dezelfde fase gevonden. Als de fouten pas later worden gevonden, kunnen de kosten oplopen tot gemiddeld 18,7 uur per fout. Op basis van deze cijfers schreef ik in 2006 een publicatie waarmee ik aantoon dat door betere kwaliteit in het software-ontwikkeltraject 21,5 procent aan kosten kan worden bespaard.'
Architectuur vaak over hoofd gezien
Daarnaast onderschrijven de experts de hoofdconclusies uit het onderzoek van Raymond Slot, namelijk dat architectuur de ict-kosten verlaagt. 'Projecten waarbij het softwareontwerp niet goed te relateren is aan het bedrijfsproces, lopen uiteindelijk gegarandeerd tijdens de acceptatietestfase uit of zelfs helemaal mis', weet senior testadviseur Gerlof Hoekstra van Atos Origin. Ik ken zelfs een project dat voortijdig werd gestopt nadat wij moesten constateren dat de bedrijfsprocessen onvoldoende input waren geweest voor het softwareontwerp. Het project was heel druk met het ontwikkelen van een oplossing voor een niet bestaand probleem.'
Ook testadviseur Jos van Rooyen van Bartosz vindt dat 'hoe beter de voorkant is neergezet, hoe gemakkelijker de bouw en test kunnen worden uitgevoerd. Er zijn voorbeelden dat een fout in productie een factor honderd duurder uitvalt, dan wanneer je hem in het ontwerp zou hebben gevonden.' WIlcor Toele, managing partner testadvies bij Active Professionals: 'Het is logisch dat je bij de ontwikkeling van huidige en nieuwe applicaties meeweegt hoe je huidige organisatie is ingericht qua processen en welke systemen deze processen nu ondersteunen. Mijns inziens is dit niet nieuw, maar wordt het helaas toch vaak over het hoofd gezien.'
Terugverdienen
De experts bevestigen bovendien de conclusie van promovendus Slot dat organisaties steeds vaker hun hoop richten op enterprise-architectuur. Jaap Schekkerman van Logica: 'Ook in Nederland zien we steeds vaker zowel bij overheid als bedrijfsleven dat enterprise-architectuur een belangrijke plaats inneemt bij de besluitvorming en de uitvoering van veranderingen in business en ict.'
Adviseur Albert Mietus van SoftwareBeterMaken.nl is wat sceptisch over deze trend: 'Een deel van de ict richt zijn hoop op elke mogelijke, nieuwe 'silver bullet'. Niet dat er iets mis is met enterprise-architectuur. Ik ben alleen bang dat het weer een hype wordt: voor elke spreekwoordelijk sheet moet een dik, duur document worden geschreven, met als enige eis dat het de juiste titel heeft (nu: enterprise-architectuur). Laten we ophouden met nieuwe termen bedenken. Het is tijd dat nadenken weer belangrijk wordt.'
Software-architect Christiaan Heidema van Sogeti denkt daar anders over: 'Enterprise-architectuur vraagt om jarenlange investeringen, die op de middellange termijn dubbel worden terugverdiend.'
Wat een belachelijke titel heeft dit artikel.
De basis van een Architectuur ligt n.l. in de vereisten, weliswaar van een hogere orde dan waar in dit artikel aan wordt gerefereerd.
Principles, de grondslagen waarop een architectuur wordt opgesteld, zijn in de kern gewoon vereisten!!
Zowel een uitgebreide architectuur aanpak als het goed van te voren vaststellen van de vereisten zijn gebaseerd op dezelfde aanname: dat je door goed nadenken kan voorspellen hoe de oplossing moet werken.
Laat die voorspelbaarheid nu net vaak het probleem zijn. Blijkbaar is het erg moeilijk om goede voorspellingen te maken.
Mijn visie: ja, beiden zijn belangrijk om te weten wat je moet doen, echter het blijven aannames die je moet bewijzen. Dus: de oplossing in kleine stapjes opbouwen en tussentijds steeds de theorie toetsen op basis van de werkelijkheid.
Minder theorie en meer gezond verstand, minder voorspellen en meer bewijzen lijkt mij de betere richting. UWV en de belastingdienst hebben dat denk ik wel bewezen.