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.
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).
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).
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 2007http://www.amrresearch.com/Content/view.asp?pmillid=21204Maar 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
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!
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.
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.
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
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
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