Goed herkenbaar.Kenmerkend voor de meeste dienstverlening die ik tegenkomt is de vrijheid om het 'net' even wat anders te doen. Als er al een beschrijving van de dienst is (kijk, daar staat 'tie, in de kast!) dan houden we ons er niet strak aan. Dat geldt zowel voor geautomatiseerde als niet geautomatiseerde interfaces. Om over de details nog maar te zwijgen. Kortom: strakker definieren is volgens mij niet de weg naar succes. Bespreken hoe we willen omgaan met deze vrijheid lijkt mij een betere tijdsbesteding.Ben benieuwd naar je volgende verhaal, want tot heden heb ik de neiging te roepen dat SOA alles met dienstverlening te maken heeft.

Je stelt:"Bedrijven die aan SOA willen beginnen, dienen de inrichting van hun dienstverlening aan te pakken."Ik zou eerder andersom redeneren, bedrijven die hun dienstverlening willen verbeteren (doel) kunnen SOA (middel) gebruiken om hun (IT) Architectuur beter hierop te laten aansluiten, maar daarmee ben je er nog niet. Een SOA opzich geeft geen enkele garantie voor een verbeterde dienstverlening."Bedrijven met succesvolle SOA implementaties hebben hun bedrijfsprocessen strak op orde, en elk bedrijfsonderdeel weet wat het toevoegt aan het grote geheel."Ook hier denk ik dat je iets te kort door de bocht gaat, het goed op orde hebben van je bedrijfsprocessen is maar ten dele het gevolg van een sucessvolle SOA implementatie, daar is nog veel meer voor nodig.Dus dienstverlening en SOA hebben wel iets met elkaar te maken maar niet zoveel als je in je artikel stelt.

SOA is dienstverlening voor bedrijven die ermee beginnen, met name in het begrijpen van de begrippen. Daar waar SOA langdurig dienstverlening of projecten nodig heeft, zal haar waarde (ROI) niet meer hebben. Idealiter zou bedrijven een SOA architectuur implementeren waar ze verder onafhankelijk kunnen opereren, zonder dienstverlening.

SOA gaat over bedrijfsprocessen.Onderdeel van een SOA zijn services, die maar een enkele taak hebben en dat is het op een flexibele manier ondersteunen van de bedrijfsprocessen. Dat er afspraken gemaakt moeten worden over de taken, rollen en interfaces van deze services mag duidelijk zijn. Dit valt onder het kopje "SOA Governance". Dat hier een sociaal aspect aan zit, zoals afspraken maken, elkaar in de ogen kijken en contracten maken (handtekening zetten) mag ook duidelijk zijn. Daarom mag SOA ook wel vertaald worden met 'Socialy Oriented Architecture'. Services op zich hebben niets te maken met dienstverlening, op zich kunnen ze en weten ze niets, het gaat helemaal om de koppeling met een bedrijfsproces. Dus niet SOA maar de bedrijfsprocessen gaan over dienstverlening.

Je hebt gelijk dat SOA over services gaat, dienstverlening dus. Maar dan wel digitale dienstverlening. Je zal zeker je bedrijfsprocessen helder moeten hebben, maar dat geldt voor elke vorm van automatisering die je kiest. Je bepaalt telkens of automatiseren wel gewenst is en voordelen biedt. De noodzaak om je bedrijfsprocessen helder te krijgen is geen direct gevolg van de keuze voor SOA!SOA is juist bedoeld keuzes en combinaties te kunnen maken tussen verschillende software oplossingen voor verschillende deelproblemen. Waar je vervolgens in het verleden leveranciers nodig had voor aanpassingen (en dus vele overleg momenten) zijn de eigen mogelijkheden bij SOA een flink stuk uitgebreid. Directe en fysieke communicate met allerlei leveranciers is zeker geen absolute noodzaak meer. Sterker nog, als de leverancier haar diensten op correcte wijze (dus inclusief documentatie) aanbiedt kan je zonder tussenkomst direct gebruik gaan maken van haar diensten.De leverancier dient wel te zorgen voor beschikbaarheid, betrouwbaarheid, continuiteit en backward compatibility van haar digitale diensten. Mocht ze daar niet in slagen, dan is fysiek contact meer dan gewenst.

Als je terug gaat naar waar SOA vandaan komt en hoe het is ontstaan, dan komt het vanuit de ICT zelf. Het (hogerliggende) doel van deze architectuur gedachte is om de effectiviteit van ICT in de business processen te vergroten. Deze toename van effecitiviteit kan liggen hogere efficiency, hogere kwaliteit, meer flexibiliteit, betere klantgerichtheid en/of in mogelijkheden voor nieuwe bedrijfsprocessen en diensten. Het vertekpunt is dus geweest meer toegevoegde waarde bieden vanuit de ICT aan de business. De drivers hiervoor liggen enerzijds in de verdergaande acceptatie en toepassing van internet in de businessprocessen en de consument en anderzijds de verdergaande technologische ontwikkelingen o.b.v. WEB2.0, XML, JAVA/AJAX, BPEL, Portalomgevingen, hogere bandbreedtes, TCP/IP, e.d.Vervolgens heeft de voorlopers in de business gezien welke opportunities dit met zich meebracht en is er ingezet op nieuwe diensten en nieuwe businessporcessen uitgaande van de mogelijkheden van SOA. En hier komt dan wel de dienstverlening om de hoek kijken.Je zou dus kunnen stellen dat SOA, oorspronkelijk vanuit de ICT is ontstaan en nu een zich een positie aan het verwerven is in de business procesmodellering.Oscar Roelofsion-ip

Leuke stelling! De SOA grondgedachte was inderdaad al vanaf het begin dat het dienstverlening tussen bedrijfsapplicaties makkelijker zou maken. IT speelt daarbij een ondergeschikte maar belangrijke rol. Echter SOA brengt niet zozeer meerwaarde in dienstverlening zelf, maar in het faciliteren daarvan. Het voordeel zit in het makkelijker bereikbaar en beschikbaar maken van dienstverlening aan elkaar. Men kan SOA het best vergelijken als een telefoon netwerk. Iedereen kan de pizzabezorger op de hoek via het telefoonboek vinden en bellen voor een bestelling. De bezorger heeft dan misschien wel een ander toestel (i.e. andere bedrijfsapplicatie) dan de beller, hij kan gewoon de bestelling opnemen. De dienstverlening zelf moet echter al bestaan en het succes van de winkel hangt af van de dienstverlening kwaliteit. Dus gaat een telefoonnetwerk over dienstverlening (i.e. pizzabezorging) zelf of is het meer een facilitatie middel voor dienstverlening?

Spraakverwarring. Je stipt het - kenmerkend genoeg – al aan. Het mixen van termen in verschillende contexten leidt tot ambiguiteit. Hierdoor sla je te snel een brug tussen de verschillende aspecten. Het toepassen van een helder referentiekader of architectuurraamwerk zet zaken in perspectief.Door het inzetten op SOA sturen we op herbruikbare stukjes IT functionaliteit (services), die vervolgens eenvoudig binnen verschillende bedrijfsprocessen kunnen worden ingezet. Het effect hiervan is dat bedrijfsprocessen gemakkelijker kunnen worden herzien of verfijnd.SOA stelt organisaties in staat om verandering mogelijk te maken en zich daarop aan te passen; verbeteren van dienstverlening kan daarbij het doel zijn. SOA gaat mijns inziens daarom slechts ten dele over dienstverlening.

Ontkoppel dienstverlening en SOA.Ik zet dit met opzet in deze volgorde. Voorop staat de dienstverlening, SOA is vervolgens 1 van de mechanismes om dienstverlening met elektronische middelen te ondersteunen. Je kunt net zo goed berichten hanteren; veel dienstverlening is 'asynchroon' en vereist niet direct een antwoord. Ik zou veel meer nadruk leggen op de interacties en hun volgorde ('choreography'), waarbij die interacties met applicatie services ondersteund kunnen worden.Het volgende probleem is natuurlijk de integratie van deze interacties in mijn bedrijfsprocessen. Dienstverlening en bedrijfsprocessen hangen direct met elkaar samen: bedrijfsprocessen zijn ingericht om dienstverlening te faciliteren. Daarover later hopelijk meer.Kortom, een benadering vanuit principes (zoals deze in een architectuurraamwerk zijn vastgelegd) is leidend, techniek zoals SOA is daarin een middel.Nu wil ik niet direct uitsluiten dat SOA en dienstverlening alles met elkaar te maken hebben. Het denken over SOA en de mogelijkheden die dit biedt, stimuuleert per slot van rekening het denken over dienstverlening.

Dank je voor jullie gedachten! Ik zie een aantal nuances die ik natuurlijk expres niet zelf al heb aangebracht, anders krijg je zo'n mitsen en maren-stuk, dat wordt het in de werkelijkheid natuurlijk wel. Ik wil nog even benadrukken: ik blijf erbij dat "dienstverlening op orde" en "succesvolle SOA implementatie" niet zonder elkaar kunnen. Het punt dat ik hier wil maken is dat het op orde hebben van dienstverlening niet vanzelfsprekend is, hier dient tijd en aandacht aan worden besteed. Verder, ben ik ervan overtuigd dat implementeren van SOA niet als breekijzer hiervoor kan fungeren (de staart kwispelt niet met de hond, al kan het zijn dat de staart daar anders over denkt, <a href=" http://en.wikipedia.org/wiki/Wag_the_Dog )." rel="nofollow"> http://en.wikipedia.org/wiki/Wag_the_Dog ).</a> Ik zie nog wel een paar themas voor interessante discussies: oorzaak en gevolg dus, maar ook doelstellingen van SOA en “SOA als IT feestje”. Hmm, dat wordt nog wel leuk.

Ik ga een stapje verder, SOA gaat alleen over dienstverlening.Neem een eens grote financiële instelling van 100 jaar geleden. Er zijn afdelingen en kantoortjes. Ieder met een specifieke taak, bijvoorbeeld het nemen van een bepaalde beslissing. Verantwoordelijkheden zijn duidelijk gescheiden en worden gerespecteerd. De afdelingen communiceren schriftelijk met elkaar (er is nog geen telefoon), de interne post zorgt dat alles rondgaat. Asynchroon is de norm, de afdelingen functioneren autonoom (minikoninkrijkjes) en worden geactiveerd door de inkomende post. Een financiële instelling als deze is in wezen diensten georiënteerd. SOA is een oud en in de praktijk bewezen principe.Precies dit principe is wat is wat de IT vorm moet geven als zij het heeft over SOA. Het ontbreken van standaarden op het gebied van interoperabiliteit was het laatste obstakel.Vandaag de dag is voldoende techniek beschikbaar om de business SOA te automatiseren. Diensten en berichten. Maar… wel vanuit de business!

Ik zie SOA als middel en niet als doel. Concurrentie, globalisering, mondige burgers, dwingen ondernemingen in toenemende mate tot klantoriëntatie. In de transitie van product naar klant focus is vaak het issue, hoe product georiënteerde IT-landschappen (silo’s) van een organisatie te ontsluiten voor de front office,zonder dat alles weer direct met elkaar “verknoopt” wordt. Het concept van ontkoppeling via services, en het verwijderen van proceslogica uit IT applicaties (orchestratie) kan daarbij bijdragen aan een betere dienstverlening (ontsluiten van informatie en transacties) en het vermogen om een continu veranderende markt sneller te kunnen volgen. Standaardisatie in SOA leidt m.i. tevens tot verhoogde interoperabiliteit (binnen en tussen ondernemingen en hun afnemers). Ondernemingen concentreren zich op hun core business (naast klant focus) en maken keuzes welke producten/diensten zelf te realiseren en bedrijfsfuncties zelf uit te voeren, dan wel van derden te betrekken.Uiteindelijk zal een SOA ook deze waardeketen herschikkingen kunnen faciliteren waarbij een betere dienstverlening ontstaat door nieuwe producten/diensten (zelfs cross sectoraal). Echter,toename van interoperabiliteit zal ook leiden tot verhoogde complexiteit en daarmee tot een beheersbaarheid issue met een negatief effect op dienstverlening.

Alleen kijken naar het aspect van 'Diensten verlenen' is te eenzijdig. SOA gaat over diensten aanbieden en consumeren. En SOA gaat over architectuur. SOA lijkt een term geworden te zijn die eigenlijk staat voor service-oriented applicatiearchitectuur. Het gaat om geautomatiseerde diensten. Terwijl het concept van 'denken in diensten' enterprise-wide toegepast kan worden.

Afgelopen weekend was ik een van de velen die naar de uitzending van Peter R, de Vries heeft gekeken. Een verhaal dat het nodig stof heeft doen opwaaien. Is er wettelijk en overtuigend bewijs geleverd ?Volgens bij 7 miljoen mensen wel, alleen de juristen hebben grote twijfels. Zij kijken dan ook met een andere, formelere bril naar de materie en stellen de vraag wat er dan met feiten bewezen is ?Een dergelijk parallel valt ook te trekken naar een Service Oriented Architecture (SOA). Iedereen is het erover eens dat SOA een grote toegevoegde waarde heeft voor bedrijven en instellingen. Alleen heeft SOA zich al voldoende bewezen om conclusies te trekken ? Er zijn genoeg voorbeelden te vinden van goede implementaties. Echter de stelling dat succesvolle SOA implementaties alleen kan slagen bij organisaties met ordentelijke processen is een snelle conclusie. Ik vermoed dat de slagingskans van een SOA implementatie bij een organisaties met een hoger volwassenheidsniveau groter is. Maar geldt dat ook niet voor andere implementatie wijzen (zoals ERP of maatwerk) ?Voor gefundeerde conclusies binnen een bepaalde context hebben we meer nodig. Zoals Gershon terecht opmerkt: "Het mixen van termen in verschillende contexten ... architectuurraamwerk zet zaken in perspectief.". Naar analogie met juristen zouden we nog een stap verder moeten gaan, het zorgvuldig semantisch definieren van termen.De combinatie stelt ons in staat beter en sneller verschillende inzichten te kalibreren, zodat we werkelijk over dezelfde dingen communiceren. Digitale communictatie kan zelfs niet buiten een semantische context voor termen (google bijvoorbeeld eens op de nederlandse term "SOA"). Zorgvuldiger definieren wat we bedoelen helpt ons verder omdat we dan niet blijven hangen in cyclische discussie. Laten we daarom vooral werk maken van een gemeenschappelijk architectuurmodel met eenduidige definities ...PS: SOA is gebaseerd op de engelse term "service" met als nederlandse vertaling "dienst". Voor het verschil tussen dienst en dienstverlening, kijk eens op de engelstalige wikipedia met de zoekterm "customer service"