SOS voor SOA

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.

Roel Derksen, 24-03-2008 20:40

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

Freddie van Rijswijk, 24-03-2008 21:14

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..

Roel Derksen, 24-03-2008 23:02

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

Ed Steenhoek, 25-03-2008 9:16

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

Freddie van Rijswijk, 25-03-2008 9:44

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

Paul Broekhoven, 26-03-2008 22:09

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

Freddie van Rijswijk, 26-03-2008 23:00

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

Michael Widjaja, 27-03-2008 0:08

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.

Wout Hofman, 27-03-2008 8:47

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

Viktor Grgic, 27-03-2008 15:25

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.

Mendel Koerts, 27-03-2008 18:38

Stel je hebt een nieuwe baan als verkoper van een onbekend IT-platform. Je bent bezorgd over de mogelijkheid dat je aanbieding wordt afgeschoten op basis van het ROI argument. Je zoekt dus naar tegenargumenten. Wat doe je dan? Dan luid je publiekelijk de noodklok en verzamelt lachend alle reacties die je helpen het ROI argument om zeep te helpen... Welnu, ik zou eens kijken naar pakketleveranciers als SAP of Oracle. Die hebben daar een aardig antwoord op: de standaard functionaliteit die zij leveren is het snelst en voordeligst aan de praat te krijgen op het NetWeaver dan wel Fusion platform. Gegarandeerd compatible, is getest en wordt gesupport (zolang je betaalt, natuurlijk).

Edwin van Asch, 28-03-2008 13:14

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 bv 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).

Freddie van Rijswijk, 28-03-2008 14:15

Allen,Laat ik beginnen met iedereen te bedanken voor zijn bijdrage tot nu toe. Het heeft me opnieuw aan het denken gezet. Als ervaren IT´er heb ik veel dingen zien komen en gaan, veel oude wijn in nieuwe zakken geproefd en heb ik natuurlijk mijn eigen deuntje mee geblazen en vele projecten gedaan waaronder ook SOA projecten. Echter,de vraag “ bestaan SOA projecten wel?” (Paul, Roel)is terecht. SOA is een Infrastructuur (Erwin, Michael), SOA is een Architectuurbenadering (viktor), SOA = NetWeaver (Mendel), en dan heb je nog de techie´s die het gebruik van WebServices zien als definitie voor een SOA project.De discussie heeft mij gesterkt in de gedachte dat een ROI berekening maken voor een financiële business case geen sinecure. Maar een NIET financiële Business Case (Prince II) om de mensen op C-level te overtuigen zou je toch zeker mogen verwachten zoals terecht gesteld door Wout. Er zijn veel argumenten en doelen om SOA te introduceren. Ieder heeft hiervoor zijn eigen strategie. Sommige gaan voor een Enterprise-aanpak en dus voor een buy-in op C-level, anderen kiezen voor een project na project aanpak en weer anderen kiezen een totaal oplossing in de vorm van een pakket. Het mag duidelijk zijn dat iedere strategie ook zo zijn eigen definitie van SOA kent.AMR Research Finds Average Spending on SOA Software and Services Reached $1.4 Million in 2007<a href=" http://www.amrresearch.com/Content/view.asp?pmillid=21204" rel="nofollow"> http://www.amrresearch.com/Content/view.asp?pmillid=21204</a>Maar er is een belangrijke kanttekening bij dit rapport. De auteur Finley geeft in een interview aan “The AMR survey found that most companies DON´T REALLY KNOW why they are investing in SOA” en volgens de auteur Finley maakt dit een lange-termijn commitment voor SOA twijfelachtig. Finley maakt zich zorgen over het feit dat SOA niet verder opgepakt gaat worden dan door de early adopters – voornamelijk grote bedrijven als financiële instellingen, telecom en overheid. Organisaties die van nature een sterkere architectuur cultuur hebben en minder sturen op meetbare voordelen op korte termijn. Vraag is dus wat er gaat gebeuren met het grote SOA denken als de economie verslechterd. Recessie leidt meestal tot het minder op de lange-termijn denken wat zo kenmerkend is voor enterprise architectuur. De grote budgetten voor SOA programma´s zullen waarschijnlijk minder worden en de tijd van kleiner minder zichtbare projecten breekt aan. Dit brengt tegelijkertijd een uitdaging met zich mee want er moet wel degelijk grote investeringen gedaan worden in een SOA Infrastructuur en met een project na project benadering, waar de business betaald en dus ook een (financiële) Business Case heeft, is het maar de vraag of deze investering daadwerkelijk gedaan kan worden.Maar laten we ons niet weerhouden om de good-old Services te blijven promoten. Het maakt me niet uit het een API, MQ-listener of Webservice is. En als er onverhoopt geen Service gedefinieerd is dan kunnen we altijd nog rechtstreeks praten met de Database of een XML bestand inlezen :-).MvgFreddie

Gerben, 28-03-2008 16:29

Jammer van die laatste paar zinnen Freddie. Vond het een leuke op zichzelf staande discussie. Geen produkt verkooppraatje. Maar goed, het is je deze keer vergeven. Laten we eens zien wat er in de komende paar jaar gaat gebeuren met SOA of AIA or EIA etc. etc. Maar denk dat we het er wel over eens kunnen zijn dat we nu met z'n alleen een weg in zijn geslagen die toch tot op zekere hoogte tot een grotere standaardisering zal gaan leiden, en daar hebben we allemaal profijt van!

Peter Hermans, 30-03-2008 22:02

Goed om met een kritische blik ook eens wat balans in de discussie te brengen naast alle “hosanna” verhalen die je in de markt hoort over SOA.Ofschoon ik de meeste punten herken (op een aantal zal ik hieronder ingaan) ben ik niet van mening dat, zelfs wanneer dit allemaal waar is, we het dan ernaar bij moeten laten zitten en SOA ten grave moeten dragen.Allereerst, voor alle duidelijkheid: SOA is een architectuur concept, niet meer en niet minder. De eerste business case van sec een architectuur moet ik nog zien !Normaliter zijn business projecten de drivers die de veranderingen in het IT landschap aanjagen. Ligt er een kans of bedreiging in de markt, dan reageert de business met een project voorstel incl. een business case waarin een de financiële impact t.o.v. “do nothing” wordt uitgewerkt.Ik stel echter vast dat wij momenteel leven in een periode waarin de business (soms gedreven door activistische aandeelhouders) sterk op korte termijn resultaten is gefocusseerd: het kwartaal resultaat telt. Dus wanneer mandaat en budget bij de business ligt, maakt een SOA benadering zoals door IT bepleit, doorgaans weinig kans: Immers “de eerste passagier betaalt niet de hele bus “ en een point- point oplossing is sneller en goedkoper.Naar mijn mening is, kijkend vanuit een meer strategische optiek er echter wel een business rechtvaardiging te vinden voor de initiële meerkosten die een SOA/ESB aanpak vergt.Dit vergt echter visie en lef bij het top management van de onderneming.De technologische ontwikkelingen rondom service oriëntatie (webservices) leiden onmiskenbaar tot een grotere interoperabiliteit tussen bedrijven, onderdelen binnen bedrijven en klanten, en maken het daarmee mogelijk in principe om tot een herschikking van functies, opbrengsten en kosten te komen op de waarde keten. Dit leidt tot het ontstaan van nieuwe bedrijven(business modellen), transformaties van bestaande bedrijven of op termijn het failliet gaan bedrijven. Vaak vraagt deze herschikking om bundeling/ ontbundeling van bedrijfsfuncties, iets wat met een SOA architectuur kan worden gerealiseerd.Het daarom door een onderneming niet mee gaan in de trend van Service Oriëntatie is m.i. daarom gelijk aan het zich afsluiten voor een omgeving, waarin continu bewegingen op de waarde keten plaatsvinden als gevolg van o.a. technologische ontwikkelingen. Daarmee zou een onderneming zich buiten spel zetten en is zij op lange termijn niet meer levensvatbaar.Concreet reagerend op enkele punten:Punt 1 ”de waarde (business case) voor een SOA-ESB project is niet realistisch en niet uit te leggen ”: Bezien vanuit een korte termijn focus, is dat voor een ondernemingsbreed SOA waarschijnlijk zo, indien echter continuïteit van de onderneming op lange termijn ook wat waard is (zie hierboven), zou dat anders moeten liggen. Probleem daarbij is wel hoe deze vergrote “adaptability” op onderneming niveau op waarde te schatten en tot uitdrukking te laten komen in de dagelijkse beurskoersen (vandaar visie en lef). Punt 3: “SOA en toenemende flexibiliteit zijn een tegenstelling als gevolg van toenemende complexiteit”. Ik denk dat dit zo is, echter niet zozeer omwille van de redenen die worden aangegeven.Ik herken dat er in het denken over hoe implementeer en beheer je een SOA architectuur nog wel een paar stappen te maken zijn. Wanneer wij onze huidige ”applicatie centrische” werkwijzen 1 op 1 projecteren op een SOA implementatie dan gooien we inderdaad wellicht het kind met het badwater weg. Immers het ging toch om ”loosely coupled” ?Wanneer we echter deze horde de komende jaren genomen zullen hebben, dan echter voorzie ik nieuwe complexiteit ontstaan die nu nog voor ons verscholen ligt.Hoe straks complexiteit te beheersen in een wereld van informatie integratie en mash-ups, in een mix van services van binnen en buiten de onderneming ?Punt 4: “bedrijfs processen zijn dusdanig complex dat deze niet in 2 dimensionale plaatjes kun je worden vervat”. Vaak is dat zo inderdaad, hetgeen voor mij echter ook een indicatie is dat er op het gebied van Business-IT alignment nog wel wat te doen is. Hoe komt het immers dat processen zo complex zijn of moeten zijn ? We zouden moeten sturen op simpele processen (processen zijn ook services) en de event (klant) gedreven orchestratie daarvan niet in een BPM laag moeten implementeren maar daarboven (event driven architectuur). De technologische mogelijkheden vandaag gaan al veel verder dan het bevattingsvermogen van een businessmanager, dus hoog tijd samen om de tafel te gaan zitten.Punt 5: “hergebruik van services wordt zwaar overschat”. Ik herken dat vanuit mijn eigen ervaring maar ben van mening dat wanneer we eerst een jaar gestudeerd zouden hebben op de definitie van de generieke service set, er geen enkel SOA initiatief gestart zou zijn. De business wacht daar niet op, en terecht. Naar beste inzicht en vermogen worden vandaag services ontwikkeld en al gaande weg worden die samen gevoegd en geredesigned in een latere fase. Een percentage van 30% zegt daarmee meer over de ontwikkelings fase van een SOA, inclusief over hoe de governance van service ontwikkeling is geregeld. Dus afsluitend, een SOS als alarm signaal ? of een Statusreport over de Ontwikkeling van SOA ?Groeten Peter HermansPs wellicht is het een idee dat computable ook eens een sessie organiseert (’s avonds) zodat we elkaar eens kunnen ontmoeten.

Bauke Teerenstra, 31-03-2008 20:01

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 door de 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.

Freddie van Rijswijk, 31-03-2008 23:48

Ben het met Peter eens, dat we zouden moeten spreken van een status rapport en misschien niet zozeer een SOS. Maar enige scepsis is op zijn plaats. Anne Thomas Manes werkzaam voor de Burton Group heeft recent nog gesuggereerd dat het 15 tot 20 jaar zou kunnen kosten voordat de huidige systemen volledig hergebruikt worden m.b.v. een SOA! Wie het weet mag het zeggen :-)Voor mij heeft deze discussie naast nieuwe inzichten ook nieuwe onderwerpen opgeleverd waar we nog een paar leuke discussies over kunnen voeren:1) Helpt standaardisatie of blokkeert het innovatie?2) Wordt Business Agility bereikt door rigide processen, standaarden en tools of zijn het de mensen die het werk uitvoeren die een Business Agile maken?3) Is Complex Event Processing realistisch?4) Gaat CEP in de BPM discussie de boventoon voeren en waarom (niet)?Wie neemt het stokje over om een discussie te starten? Laten we beginnen met het onderwerp van Michael.mvbFreddie van Rijswijk

Ted Stravers, 01-04-2008 9:21

Er bestaat veel scepsis over SOA en vaak wordt gesteld dat het oude wijn in nieuwe zakken is. Het geeft mij een déjà vu-gevoel van het ontstaan van internet toen de kritiek ook niet van de lucht was. De opmars van SOA betekent echter een trendbreuk met de traditionele, starre koppeling van informatiesystemen. Met een SOA is technisch te realiseren wat voorheen niet mogelijk was. SOA is vooruitgang, een proces dat parallel loopt met het ontstaan van internet. Het biedt het fundament om vanuit de bedrijfsprocessen geredeneerd een flexibele en dynamische IT-infrastructuur op te zetten, waarin applicatiecomponenten zijn te combineren en te hergebruiken. Oftewel: integratie tussen front- en backoffice, informatie bundelen, verbeteren van ketensamenwerking, klanten verschillende toegangskanalen tot de organisatie bieden, sneller kunnen reageren op veranderingen, klantbehoeften centraal stellen ......hoezo geen aantoonbaar ROI?Ted Stravers, Marketing Consultant Service Oriented Architecture (SOA) bij Inter Access

Freddie van Rijswijk, 01-04-2008 10:15

Ted,Ik zou graag deze mogelijkheid willen aangrijpen om de discussie over ROI af te sluiten maar een verdieping aan te brengen op de overige punten.Je stelt dat "De opmars van SOA betekent echter een trendbreuk met de traditionele, starre koppeling van informatiesystemen. Met een SOA is technisch te realiseren wat voorheen niet mogelijk was." Zou je hier concreet kunnen worden en aangeven wat het verschil is met 8 - 10 jaar geleden toen Component Based Development, CORBA, DCOM, XML nog HOT waren? Om te illustreren wat ik bedoel heb ik een Google Search gedaan op Component Based Development en de eerste hit leverde me dit artikel uit 2000 (IEEE) op:"Building software systems with reusable components brings many advantages. The development becomes more efficient, the reliability of the products is enhanced, and the maintenance requirement is significantly reduced. Designing, developing and maintaining components for reuse is, however, a very complex process which places high requirements not only on the component functionality and flexibility, but also on the development organization."Een paar links verderop "What is a component? A typical definition of software component runs something like this: A component is something that can be deployed as a black box. It has an external specification, which is independent of its internal mechanisms". Zie je de overeenkomsten met een Service? Ik realiseer mij terdege dat bij de ontwikkeling van Services in tegenstelling tot Components minder de aandacht op de systeemfunctie gelegd dient te worden maar meer op het business proces. Maar volgens mij maakt dit het ontwikkelen van Services alleen maar moeilijker ten opzichte van Components.Ok, even verder met googlen, dan een artikel in computerworld "Component-Based Development: Why Hasn't the Vision Met Reality?". Is CBD het niet geworden omdat het technisch niet goed genoeg uitgedacht was? Ik denk het niet, volgens mij ligt de oorzaak iedere keer weer bij de mensen. Aan standaarden, best practices, artikelen, trainingen geen gebrek echter zoveel mensen zoveel meningen en zoveel implementaties. Ik zie wel degelijk de voordelen van een SOA zoals ook genoemd op Wikipedia:1) Agility: Modulariteit en flexibiliteit. Door de ontkoppeling van de services wordt het veel eenvoudiger om services bij te voegen of te verwijderen. 2) Governance: Beheersbaarheid, het wordt veel eenvoudiger om de bedrijfslogica te veranderen, omdat deze niet meer inherent aanwezig is in de implementatie van de services. Maar ik zie dit als IT voordelen en niet persé als Business voordelen. Agility in de IT systemen hoeft niet te leiden tot Agility in de Business. Beheersbaarheid van een service hangt in hoge mate af van het feit hoevaak deze wordt hergebruikt en of het contract (input x geeft output y) gehandhaaft kan blijven.Natuurlijk zie ik de voordelen die een High Cohesion and Loose Coupled systeem ons kan bieden en vooral in combinatie met Internet. Waar ik echter voor wil waarschuwen is het feit dat bij het opstellen van een SOA men heel duidelijk de scope voor ogen moet hebben en ook daadwerkelijk de opgelegde standaarden moet gaan controleren. Dit kan alleen als je controle kan uitoefenen op de Service Consumers en Service Providers. En dit laatste is soms al erg lastig in grote organisaties waar je over afdelingsgrenzen heen moet werken die ieder hun eigen ICT afdeling hebben.Laat dit ook een tip zijn voor de mensen die voor de Belastingdienst een SOA gaan ontwerpen. Als Architect ben je niet alleen verantwoordelijk voor het opstellen van de Architectuur en richtlijnen maar ook voor de bewaking ervan. Zorg er dus voor dat je genoeg mandaat heb om dit ook in de praktijk te kunnen en bouw regelmatig evaluatiepunten in om bij te kunnen sturen.mvgFreddie van Rijswijk

Service Oriented Architecture / Opinie

SOS voor SOA

Technologische beloften versus business risico’s

Inzet van BTO voor de optimalisatie van SOA

Computable Events SOA

JBoss Operations Network vernieuwd

Coca-Cola verkort tijd interne begripsvorming

EDA wordt de nieuwe hype

We leren nu pas werken met ICT