SOA gaat over services – dienstverlening dus. Dat heeft eenpaar belangrijke gevolgen.
Het eerste gevolg is dat IT vrijwel onbelangrijk is. Vanalle vragen die beantwoord moeten worden als je SOA wil invoeren, is de vraagmet welke IT componenten dit moet gebeuren, vrijwel het makkelijkst tebeantwoorden (korte versie: wil je geld uitgeven aan licenties of aan mensen).Voor de IT industrie is dit ook duidelijk: er wordt veel aandacht besteed aanhet scheiden van interfaces (gestandaardiseerd) van implementaties(vendor-specifiek).
Een ander gevolg is dat de gewone, ouderwetsedienstverlening weer wel belangrijk is. Gewoon weer mensen bellen, papier enhandtekeningen, elkaar in de ogen kijken etc. Bedrijven die aan SOA willenbeginnen, dienen de inrichting van hun dienstverlening aan te pakken. Bedrijvenmet succesvolle SOA implementaties hebben hun bedrijfsprocessen strak op orde,en elk bedrijfsonderdeel weet wat het toevoegt aan het grote geheel.
Tegelijkertijd is de sterke relatie met dienstverlening éénvan de lastige aspecten van SOA. In Nederland is namelijk vrijwel iedereenbezig met dienstverlening, in enige vorm. En wil dan ook zijn of haar variatievan dienstverlening terugzien in het concept van SOA, en dat is dan weer debron voor veel vermakelijke spraakverwarring. Bovendien, als dienstverlening eendergelijk breed concept is, en een belangrijk deel van SOA is dienstverlening,dan wordt SOA vanzelf all things to all people, all the time. En dit kandan wel een beschrijving zijn van de feitelijke situatie, wenselijk is dievolgens mij niet.
Wat nu, uithuilen en opnieuw beginnen? Strakker definiëren,die term? Of wachten op volgende keer, als ik ga schrijven dat SOA niet overdienstverlening gaat?
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, http://en.wikipedia.org/wiki/Wag_the_Dog). 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.