‘De ROI van SOA is niet aan te tonen’

Op het weblog SOA op het gelijknamige Computable Topic zendt Freddie van Rijswijk een s.o.s. uit voor soa. Een van zijn zeven ‘kritiekpunten' is dat de return on investment (roi) van een soa niet aan te tonen is. Er waren veel reacties op zijn artikel, waarvan we er hier een aantal afdrukken. Het artikel en alle reacties zijn te vinden op https://www.computable.nl/artikel/ict_topics/soa/2495267/2204519/sos-voor-soa.html.

Freddie van Rijswijk, senior executive bij ISIS Papyrus Netherlands, stelt op het SOA-weblog van Computable vraagtekens bij de return on investment bij soa-projecten. […] "We vragen budget aan voor ons soa-project, wetend dat de roi niet direct meetbaar is, maar gelukkig is er niemand die daadwerkelijk de gerealiseerde roi meet. Herkenbaar? We houden elkaar voor de gek en aan het werk. Wie kent niet de zware budgetprocessen die veel geld en tijd kosten? Uiteindelijk roepen we maar het magische roi-getal dat ons het budget oplevert." Hij komt tot de volgende stelling: De waarde (business case) voor een soa-esb-project is niet realistisch en niet uit te leggen.

Michael Widjaja
Partner en senior executive
Accenture

Soa levert de tools en architectuur voor applicatie, systeem en procesintegratie. Het is meer een it commodity (net als een datanetwerk) dan een softwarepakket. Meerdere partijen maken er gebruik van en het is daarom moeilijker om de roi te berekenen. Maar het is mogelijk. Voor het bepalen van roi kijken we enerzijds naar infrastructuur, licenties, training en supportkosten, en een extra governance-investering voor soa-beheer. Qua baten zijn er twee categorieën. De kwantitatieve baten zijn het eenvoudigst te berekenen: kostenvermindering door snellere implementaties, extra inkomsten met nieuwe klantkanalen, operationele verbeteringen door flexibeler procesmanagement en sneller reageren door inzet van procesmonitoren etcetera.
Kwalitatieve factoren zijn moeilijker te berekenen, maar moeten ook meegenomen worden in de roi: verbetering in procesflexibiliteit, complexiteitsvermindering van ict-landschap, hogere klanttevredenheid enzovoorts. We hebben een paar jaar geleden een aantal roi-berekeningen van grote bedrijven gedaan en terugkijkend komen ze redelijk overeen met de realiteit.

Edwin van Asch
Solution architect
Systemation

Soa is voor een belangrijk deel infrastructuur, de roi van infrastructuur berekenen is over het algemeen erg lastig. Het verbreden van de A2 levert voor de b.v. Nederland vast wel rendement op, maar kun je er een roi-calculatie op loslaten?
Soa is ook nooit een doel op zich, dus soa zal ook geen roi hebben op zichzelf. Het doel moet altijd iets in de business zijn en daar moet dan een roi-berekening op losgelaten worden. Soa wordt in het project meegenomen als middel om een probleem op te lossen, en misschien heeft het project dan extra budget nodig om de infrastructuur op orde te brengen (lees bijvoorbeeld een esb te implementeren).

Wout Hofman
Senor consultant
TNO ICT/E-IT

Er zijn veel externe drijfveren voor soa-projecten te vinden, bijvoorbeeld compliancy, implementatie van nieuwe wetgeving, multi-channeling, etcetera. De druk voor veranderen moet kennelijk van buitenaf komen. Interne drijfveren komen veelal uit de ict-afdeling, bijvoorbeeld reductie van de beheerkosten door het ontwarren van de huidige spaghetti van gekoppelde software om daarmee vervanging van (legacy)systemen eenvoudiger te maken. De business zal niet uit zichzelf gaan bedenken soa in te voeren. Daarmee heeft de ict-afdeling het zwaar: hoe maak ik aan de business duidelijk dat de winkel verbouwd moet worden, zodat zij in de toekomst beter op veranderingen in de vraag kunnen inspelen? Kan soa hun proces efficiënter maken?
Ik heb zelf wel eens geprobeerd een business case instrument op te zetten om dit laatste inzichtelijk te maken, maar dit vergt een andere werkwijze voor integratie dan de meeste it'ers gewend zijn en is daarom lastig.
Wat mij betreft moet je wel altijd proberen een business case op te stellen voor een soa-project. De drijfveren moeten helder worden. Of er dan sprake is van een roi vind ik minder relevant. Grote vraag is ook wat men bedoelt met roi: wanneer moet ik mijn investering terugverdienen? De meeste roi-berekeningen gaan uit van een terugverdientijd van 3 jaar. Is dit realistisch als bijvoorbeeld de gehele dienstverlening van de overheid moet veranderen en meer klantgericht moet worden? Heeft een bank gekeken naar de terugverdientijd van internetbankieren of heeft zij dit aangegrepen als een mogelijkheid kantoren te sluiten en vervolgens via internet multichannel banking aan te bieden?

Bauke Teerenstra
IT architect
Atos Origin

Een soa-project bestaat niet. Soa is een visie en heeft dus betrekking op de langere termijn. Het doel bij soa is business agility, een flexibele organisatie die zeer snel kan inspelen op veranderingen vanuit de markt. Soa is dus niet het speelveld van de it alleen.
Dit inzicht moet nog flink wortelen binnen it. Te vaak (nog) worden it-projecten met een fantastische roi bedacht waarbij men verwacht (en belooft!) dat met het binnenhalen van het nieuwe speeltje de problemen zijn opgelost. Ik moet hen teleurstellen.
Bij soa is de gebruikte techniek van ondergeschikt belang, veel belangrijker is hoe er mee wordt omgegaan.

Viktor Grgic
Agile it architect
Xebia

Soa is een architectuurstijl, net zoals meerlagenmodel, domaingedreven ontwerp, enzovoort. Roi van een stijl definiëren is vreemd, lastig of zelfs onmogelijk. Door verschillende invloeden hebben we van soa een tastbaar ding gemaakt dat je in een project bouwt en afmaakt. Zoiets zou dan businesswaarde moeten hebben. Het doet me denken aan de tijd dat ieder groot bedrijf een eigen ‘applicatieframework' ging bouwen om op den duur nieuwe applicaties veel sneller te kunnen opleveren. Dat bleek in praktijk over het algemeen helemaal te mislukken omdat het middel het doel is geworden en de ict-wereld te snel verandert.
In andere woorden, soa is een stijl om concrete, vaak enterprisedoelstellingen/requirements te bewerkstelligen. Roi bepaal je op basis van een concrete koppeling tussen de business requirements, ontwerp en de gekozen oplossing. Het laatste is dan eventueel een oplossing met soa als de onderliggende stijl.