SOS is het internationaal noodsignaal en ik stuur vandaag een SOS uit voor SOA. Een SOS uitsturen is niet iets wat je zomaar doet, je belt ook niet zomaar 112, maar ik hoop dat mijn actie leidt tot de juiste discussies. Maar laat ik beginnen met het toelichten van mijn keus om een SOS uit tezenden.
De voorspelde ROI van ons SOA Project is gerealiseerd, of niet soms?
Zoals jullie misschien hebben gelezen op http://www.gridshore.nl/ heeft een recent SOA – ESB projectmeer dan 50 miljoen euro aan besparing opgeleverd bij een investering van maar 3 miljoen. Och, je kon de post niet vinden… sorry, vergeten te vermelden dat de post is verwijderd. Maar het maakt niet uit, ik had de cijfers toch maar verzonnen 😉 om goedkeuring te krijgen voor mijn business case.
Zoek je hulp om je eigen SOA – ESB business case te maken, dan kun je met een paar simpele zoektermen in Google verschillende whitepapers, toolkits en zelfstrainingen vinden die aangeboden worden door de leveranciers van deze tooling. Echter, je zult ook genoeg artikelen vinden die ingaan op het feit dat ROI voor SOA projecten niet aan te tonen is.
Goed, we vragen budget aan voor ons SOA project, wetende 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. Gelukkig niemand die het achteraf controleert. En al die gerapporteerde succesvolle projecten dan hoor ik jullie denken. Mijn observatieis dat het succes van een project wordt afgemeten aan het feit of de opdrachtgever en de opdrachtnemer nog met elkaar door één deur kunnen en willen. Succesvol is een project als:
- Beide erin geslaagd zijn het project niet te veel over budget en tijd heen te laten gaan.
- De opdrachtgever het marketing succesverhaal naar buiten durft te brengen.
- De opdrachtgever dit durft omdat er vertrouwen is in het feit dat de komende 2 releases de daadwerkelijke benodigde functionaliteit gaan opleveren.
- Niemand de oorspronkelijke ROI berekeningen boven water durft te halen.
De carrière van zowel de opdrachtgever als de opdrachtnemeris (te) vaak afhankelijk van het succes van het project, dus beide is er niets aan gelegen om elkaar zwart te maken behalve natuurlijk als er geen redden meeraan is.
Punt 1, De waarde (business case) voor een SOA – ESB project is niet realistisch en niet uit te leggen
Punt 2, De succesverhalen verdienen een nauwkeurige analyse m.b.t. ROI
Maar het project heeft er in ieder geval voor gezorgd dat het bedrijf zich sneller kan aanpassen aan de snel veranderende wereld om ons heen, of niet soms?
We hebben na een langdurig architectuur studie en analyse "services" gedefinieerd en deze afgebeeld op het huidige applicatielandschap bestaande uit Siebel, SAP, onze eigen legacy-systemen (Cobolen C) en natuurlijk de wat nieuwere systemen gebouwd in .NET en Java. De bestaande applicaties zijn voorzien van zogenaamde SOA "Wrappers" en de ontbrekende "services" zijn gebouwd als Webservice in Java en draaien op een Java Enterprise applicatieserver. Natuurlijk hebben we een Enterprise Service Bus aangeschaft met een Business Process Engine en een Business Process modeleer tool. Om problemen te voorkomen met uitwisselbaarheid hebben we besloten om bij één leverancier te blijven. We zijn nu in staat om bedrijfsprocessen te tekenen, de webservices op te nemen in het proces en simulaties te doen over het getekende proces. We beginnen met de simpele processen (workflow) aangezien de complexe bedrijfsprocessen te veel uitzonderingen kennen.
Echter, een simpele wijziging in het proces behelst meer dan het wijzigen van het procesplaatje. Het omvat het wijzigen, compileren, deployen, testen en uiteindelijk in productie nemen van ieder gewijzigde of nieuwe "service" en ook nog eens het volledig doortesten van het hele proces. Theoretisch is dit logisch, praktisch is dit een nachtmerrie. Niet alleen krijgen we te maken met de governance van iedere "service" en daarmee ook de discussie met de eigenaar over de SLA en de release planning. Ook moeten we de hele constellatie aan producten en "services" consistent zien te houden over de verschillende OTAP omgevingen heen. Alleen het testen van een kleine wijziging kan maanden aan doorlooptijd kosten aangezien IT hun OTAP omgevingen moet reserveren (slot planning). Dan spreek ik nog maar niet van de fouten dieonvermijdelijk worden gevonden.
Punt 3, SOA en toenemende flexibiliteit zijn een tegenstelling als gevolg van toenemende complexiteit
Punt 4, Bedrijfsprocessen zijn altijd dusdanig complex dat deze niet gevat kunnen worden in tweedimensionale plaatjes.
Maar in ieder geval heeft de ons SOA project veel herbruikbare "services" tot gevolggehad, of niet soms?
Het denken in "services" heeft z´n voordelen. Zo helpt het om het productgericht denken te doorbreken en de klant centraal te stellen. Alleen heeft in het verleden het productgericht silo denken ons opgezadeld met productgerichte afdelingen met ieder hun eigen productgerichte siloapplicaties die ieder hun eigen versie van mij als klant hebben. Het doorbreken van deze silo´s is niet zo eenvoudig als vaak wordt gesteld. Technisch zijn er natuurlijk hobbels te nemen waarvan in mijn beleving de meest belangrijke is hoe er omgegaan wordt met de invulling van "klant centraal stellen". Wie is deeigenaar van de klantgegevens? Maar de echte problemen liggen op het menselijk vlak. Ieder bedrijf wil zich kunnen onderscheiden om succesvol te kunnen worden. Dit geldt ook voor de afdelingen binnen een bedrijf en natuurlijk de mensen binnen een bedrijf. Iedereen doet zijn best om zo verschillend (uniek) mogelijk te zijn. Dus als we gaan praten over "generieke services" voelt niemand zich aangetrokken, als we praten over meer "specifieke services" voelt men dit als concessie doen aan een ander en daarmee afhankelijkheid van de ander. Waarom hebben business afdelingen hun eigen IT, en hun eigen budgettering? Juist…
Tijdens een SOA congres waaraan veel banken deelnamen werd de vraag "hoeveel % aan services is herbruikbaar" gesteld. Uiteindelijk kwamen de op basis van discussie en ervaringcijfers van sommige banken niet hoger dan 30%. Ik moet hierbij aantekenen dat de meeste "services" maar 1 of 2 maal werden hergebruikt. Een veel kleiner aantal "services", die betrekking hadden op klantgegevens, werd tot 20 maal hergebruikt.
Punt 5, Hergebruik?, Hergebruik van wat? Herbruikbaarheid van "services" wordt zwaar overschat
Punt 6, Iedereen wil de voordelen maar niemand wil afhankelijk worden
Op zijn minst heeft de IT-afdeling geprofiteerd van standaardisatie, of niet soms?
Standaardisatie kan alleen bereikt worden door controle en hier wringt te schoen. Postels wet "be conservative in what you do; be liberal in what you accept from others." is de oorzaak dat veel standaarden in werkelijkheid geen standaard zijn. Joel On Software beschrijft in zijn blog Martian Headsets (http://www.joelonsoftware.com/items/2008/03/17.html) zeer treffend hoe het komt dat "Web Standards" geen standaard zijn. Ook de post Shooting ducks (http://www.gridshore.nl/2008/03/21/shooting-ducks/)geeft zeer treffend weer hoe er in het kamp van de ontwikkelaars er verschillend wordt gedacht over de aanroep en implementatie van "services".
As we were all taught by the likes of Tony Hoare and Edsger Dijkstra (see Hoare Logic), the precept of all programs is that a program S is guaranteed to terminate in a well-defined state Q if andonly if it starts in a state conforming to precondition P of S. That is to say, a program can only function correctly if it is started in a state that matches certain assumptions. It is not possible, in general, to write a program that will always carry out its task no matter what. This is why we do things like input validation and parameter checking – to ensure that our programs can workat all.
Iedere leverancier interpreteert op zijn eigen manier de standaarden en dus kun je stellen dat er geen standaarden zijn.
Punt 7, Iets wat standaard lijkt, blijkt in de praktijk in het geheel niet standaard te zijn.
Ik hoop met dit noodsignaal een gezonde discussie te starten over de daadwerkelijke voordelen van een SOA – ESB implementatie. Begrijp me niet verkeerd ik onderschrijf het belang van "service" gericht denken en ben voor bewezen concepten als "separation of concern" maar ik geloof in de verste verte niet dat SOA de wereld gemakkelijker en flexibeler maakt. We moeten eens ophouden met het doen van uitspraken die we niet kunnen waarmaken, bewaken en meten.
Hi Freddie,Een goede discussie is alleen maar toe te juichen.De punten die je noemt zijn herkenbaar en in sommige gevallen 100% juist. Echter wil ik wel graag wat kwijt over je belangrijkste punt.De ROI van een SOA project is niet altijd te meten en dat is iets wat we met zijn allen moeten accepteren. Dit mag alleen niet de reden zijn om niets met de principes van een SOA te doen. Begrijp me niet verkeerd; projecten moeten natuurlijk een duidelijk resultaat opleveren. Misschien moeten we gewoon geen SOA project doen, om het doen van een SOA project. SOA is geen doel en maar in specifieke gevallen het middel.We moeten projecten doen die een duidelijk resultaat opleveren en als de organisatie (zowel IT als Business) er klaar voor is kunnen er SOA aspecten gebruikt worden. De maturity van de organisatie bepaald hoe ver we kunnen gaan. Naarmate er meer projecten gedaan worden zullen we leren hoever dat is. Service oriëntatie is vooruitgang en vooruitgang is niet te stoppen. Zelfs niet door een niet meetbare ROI. Cheers,Roel Derksen
Beste Roel,Ik ben het helemaal eens met je stelling dat je projecten moet kunnen doen ook als de ROI niet duidelijk is. Dit zijn de zogenaamde STRATEGISCHE beslissingen waarvan je hoopt dat deze goed gaan uitpakken maar je weet het niet zeker.Innovatie is zeker vooruitgang, weet niet of Service Orientatie gezien moet worden als innovatie. Zelf zie ik het meer als oude wijn in nieuwe zakken, natuurlijk met wat nieuwe kenmerken (het Web, XML) maar in hoeverre verschilt het nu daadwerkelijk van good old CORBA of Component Based Development? Is XML nu echt de oplossing of genereert het alleen maar extra overhead vanwege de validatie en parsing?Wie het weet mag het zeggen..
Freddie,Klopt, service orientatie is niet nieuw, maar de brede acceptatie er van wel. XML gebaseerde webservices maken de service wel echt implementatie onafhankelijk, dus als dat een requirement is, dan is XML een oplossing. Als het geen requirement is om implementatie onafhankelijk te zijn dan zijn de alternatieven vaak sneller.Maargoed, ik ben ook wel benieuwd naar andere meningen :)Cheers,Roel
Interessante discussie… alleen geloof ik niet in een SOS voor welke technologie dan ook.Maar laten we eerst eens kijken naar de argumenten die je aandraagt. Allemaal valide. Echter, ze zijn herbruikbaar voor bijvoorbeeld ECM. Wellicht ook BPM. Veel van dergelijke projecten zijn zo blij met compliance als stok achter de deur. In de VS is het noemen van een compliance gerelateerd woord gelijk aan een toverspreuk voor het beschikbaar stellen van ongelimiteerde middelen. Gelukkig is Nederland (misschien zelfs Europa) een stuk nuchterder.In zekere zin kun je beter stellen dat het een SOS is voor de huidige IT wereld.De business case is verworden tot een verplichte activiteit om het benodigde budget voor een project los te krijgen. De ROI daarin is slechts een nummertje. Is dit cynisch? Ik noem het realistisch. Want laten we eerlijk zijn. Met een business case met daarin de juiste verwachtingen en cijfers heeft nu eenmaal een kleine kans op effectuering. Het heeft veel weg van de Hollandse Zuinigheid waarbij we een goede deal scoren als we meedoen aan de ‘3 halen, 2 betalen’ actie terwijl we er zelfs niet eens 1 nodig hadden. Je kunt zeggen dat je geld bespaart hebt. We weten allemaal dat we geld hebben weggegooid.Terug naar het begin. Is de SOS nodig? Ik denk van niet.De afgelopen 10 tot 15 jaar is er veel veranderd in IT land en springen we van hype naar hype. Geen enkele technologie krijgt nog de tijd om volledig begrepen, geimplementeerd en benut te worden. Zij sterven allemaal in schoonheid nog voor de volwassenheid wordt bereikt. Omdat er weer een nieuwe technologie is die aan de (vermeende) tekortkomingen van de technologie van vandaag tegemoet komt.Maar laten we eens goed in de tuin van de buren kijken. Net als in het bedrijfsleven komt winstgevendheid niet in de eerste jaren. Eerst gaan we een goede business case maken en die realiseren zoals afgesproken. Tijdens realisatie en na afloop meten of het ons brengt wat we ervan verwachten. Bijstellen indien nodig. Net als een business plan voor een bedrijf.Dat heet gezonde bedrijfsvoering. Daarvoor is geen SOS nodig.Groeten,Ed
Beste Ed,Voor wat betreft de ROI en de Business Case kan ik mij vinden in jou argumentatie ten aanzien van punt 1 en 2. Maar wat als jij de opdrachtgever bent en het je eigen geld is wat je moet uitgeven, hoe kijken we dan naar de punten 1 en 2? Als het mijn geld zou zijn, zou ik toch meer meetbare resultaten willen zien en zou ik bijv. gaan discussieren over de ROI van een nieuwe service. Natuurlijk blijven de strategische investeringen bestaan, en als mijn buikgevoel zou zeggen dat dit strategisch belangrijk zou zijn voor mijn bedrijf dan zou ik de waarschijnlijk de investering doen.Allen, ik zou ook graag reacties zien op de overige 5 punten die vaak in verband worden gebracht met SOA en ESB implementaties. Het SOS betreft dus 7 punten en niet alleen de eerste 2.mvgFreddie
Een SOA project bestaat niet !!Freddie, Roel,uit jullie discussie kunnen we dus vaststellen dat een SOA project niet bestaat. SOA is een reis (journey) die waarschijnlijk nooit zal eindigen. Of er komt toch een moment, dat we met z’n allen hebben besloten dat SOA vervangen gaat worden door bijvoorbeeld EDA (Event Driven Architecture). En dan beginnen we weer gewoon van voor af aan.Mijn reden om deze reactie te geven is eigenlijk gebaseerd op mijn ervaringen van afgelopen dinsdag. Ik heb een prospect (CIO van een internationale organisatie) meegenomen, die op zoek was naar SOA/ESB oplossing naar een tweetal van onze klanten. Alles is zeer goed verlopen en we zijn er van overtuigd dat zij voor ons gaan kiezen ;-). Bij beide klanten kwam de vraag naar voren van de prospect of de eerste stap gedreven was door de business of IT. Bij beide klanten is het initiatief tot SOA gedreven door de business, maar is door IT aangegrepen om de eerste stappen van SOA binnen de organisatie te introduceren. In beide situaties is het onderwerp van ROI bij SOA niet echt op tafel gekomen.In beide gevallen is de eerste stap gedreven door de visie (het geloof in succes) door de IT verantwoordelijke en wordt dus niet gedreven door een onderbouwing van ROI. In dit specifieke geval was het geloof van de prospect in SOA dermate, dat de eerste stappen zonder betrokkenheid van de business zullen gaan plaatsvinden.Als afsluiting, SOA is dus geen project en het staat of valt bij het geloof van de IT verantwoordelijke. Het zal de business een zorg zijn, hoe zijn problemen opgelost worden.Een uitdagende groet,Paul Broekhoven
Beste Paul,Of er nu wel of niet SOA project bestaan hangt af van met wie je praat. Alles valt of staat natuurlijk met de definitie van een SOA project. Een zoektocht op het internet levert een veelvoud aan definities op. De één zegt “service-oriented architecture is essentially a collection of services” en verwijst naar de goede oude tijd van Corba en DCOM. De ander beweert “SOA is a computer systems architectural style for creating and using business processes, packaged as services”. Ik ken ook SOA projecten die zich zo noemen omdat ze WSDL gebruiken maar ook SOA projecten zonder ook maar één Webservice maar wel met goed gedefinieerde Services die communiceren via MQ.Ik ben met je eens dat SOA geen doel is maar het middel zou moeten zijn. Vraag blijft “een middel waarvoor?” en “kunnen we de investering vor het SOA middel rechtvaardigen?” of waren er ook andere wegen die naar Rome leiden tegen misschien lagere kosten en een meetbare ROI.Servus (zit nu in Wenen),Freddie van Rijswijk
Hallo Freddie, 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 is daarom moeilijker om de ROI te berekenen. Maar het is mogelijk. Voor bepalen van ROI kijken we enerzijds naar infrastructuur, licenties, training en supportkosten, en extra Governance investering voor SOA beheer. Qua baten, zijn er twee categorieën. De kwantitatieve baten zijn het eenvoudigst te berekenen: kostenvermindering door sneller implementaties, extra inkomsten met nieuwe klantkanalen, operationele verbeteringen door flexibeler procesmanagement en sneller reageren door inzet van procesmonitoren etc.Kwalitatieve factoren zijn moeilijker te berekenen, maar moeten ook meegenomen worden in de ROI: verbetering in procesflexibiliteit, complexiteitsvermindering van IT landschap, hogere klant tevredenheid etc. We hebben aantal ROI berekeningen van grote bedrijven gedaan een paar jaar geleden en terugkijkend komen ze redelijk overeen met de realiteit.
Ik lees met belangstelling alle reacties hiervoor. Ze hebben wat mij betreft allemaal een kern van waarheid. Ik vind wel dat een SOA project altijd in de business moet beginnen. Er kunnen dan verschillende drijfveren zijn, bijvoorbeeld voldoen aan compliance (zie Amerika). Zo zijn er talloos andere externe drijfveren te vinden, bijvoorbeeld implementatie van nieuwe wetgeving door de overheid, multi-channeling, etc. Zoals aangegeven zijn dit veelal externe drijfveren: de druk voor veranderen moet kennelijk van buitenaf komen. Deze druk kan liggen in kansen (nieuwe markten, maar omzet), bedreigingen (verkleinen marktaandeel door nieuwkomers) of wettelijke verplichtingen.Interne drijfveren komen veelal uit de IT afdeling, bijvoorbeeld reductie van de beheerskosten door het ontwarren van de huidige spaghetti van gekoppelde software en daarmee vervanging van (legacy)systemen eenvoudiger te maken. De business zal niet uit zichzelf gaan bedenken SOA in te voeren. Daarmee heeft de IT 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 efficienter maken?Ik heb zelf in het verleden 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 voor SOA moeten helder worden. Of er dan sprake is van een ROI vind ik minder relevant. Grote vraag is ook altijd wat men bedoeld met ROI: wanneer moet ik mijn investering terugverdienen? De meeste ROI berekeningen gaan uit van een terugverdientijd binnen 3 jaar. Is dit realistisch als bijvoorbeeld de gehele diesntverlening 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. Veelal ontstaan de beste veranderingen ook vanuit een kleine kern die met beperkte middelen nieuwe mogelijkheden onderzoekt.De nieuwe situatie met SOA lijkt complexer dan de oude, maar het blijkt ook dat wij meer zijn gaan automatiseren in een SOA omgeving dan wij voorheen deden. Plotseling blijken ook bedrijfsprocessen te ondersteunen, nog wel beperkt weliswaar. We ontdekken dat SOA nieuwe mogelijkheden biedt, maar ook nieuwe uitdagingen. Herbruikbaarheid van services lijkt de weg, maar vaak komen we bedrogen uit. Granulariteit van services is ook altijd een vraag. Laten we ons daar niet druk om maken: het probleem is om nieuwe services samen te stelle met al ontwikkelde services die vervolgens de bedrijfsvoering ondersteunen.Een volgende stap is mogelijk dat we er achter komen dat we vanuit de bedrijfsvoering eigenlijk alleen geinteresseerd zijn in deze samengestelde services. De achterliggende systemen doen er niet meer toe: wat onder de motorkap zit moet werken. Software as a Service komt in zicht. Kan ik niet betalen voor het gebruik van services (pay-per-use) in plaats van betalen voor de software en de hosting? Kan ik kosten delen met anderen die dezelfde toepassingen gebruiken? Ziet een dienstverlener er brood in om SaaS aan te bieden voor bijvoorbeeld een financiele adminstratie?Ik zie daarom meer de kansen en nieuwe mogelijkheden die SOA ons nog gaat bieden. We staan aan het begin van een verandering en alle begin is moeilijk, vooral de eerste stap.Wout Hofman
SOA is een architectuurstijl, net zoals meerlagen model, 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 wat je in een project bouwt en afmaakt en zoiets zou dan business waarde moeten hebben. Het doet me denken aan de tijd dat ieder groot bedrijf een eigen applicatie “framework” ging bouwen om op den duur nieuwe applicaties veel sneller te kunnen opleveren. Dat bleek in prakijk over het algemeen helemaal te mislukken omdat de middel het doel is geworden en de IT wereld te snel verandert.In andere woorden, SOA is een stijl om concrete, vaak enterprise doelstellingen / 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.