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?
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”