SOA

Een (web)service is pas een service als deze wordt gebruikt en vooral wordt hergebruikt voor andere doeleinden of toepassingen dan waar de service oorspronkelijke voor in het leven is geroepen. Maar, hoe bevorder je nu (her)gebruik van bedrijfsservices?

Een veel gebruikte methode om het gebruik van services te bevorderen is het instellen van ‘governance’. Een comité stelt beleid op ten aanzien van de benodigde services en het gebruik ervan. En daar waar beleid wordt gecreëerd dient deze ook te worden afgedwongen. Eventueel zelfs met repercussies. Een goed comité zorgt ervoor dat het opgestelde beleid breed gedragen wordt binnen een organisatie. Bijvoorbeeld door belanghebbenden uit de organisatie innig te betrekken bij het opstellen van het beleid.

Desondanks blijkt de praktijk weerbarstig en loop je bij de implementatie van services tegen zaken als de volgende aan:

• SOA webservices, met name W3C webservices, zijn sterk gestandaardiseerd. De standaarden zijn echter complex en ook de op de standaarden gebaseerde software is technisch complex;
• Services zijn vaak een compromis qua functionaliteit. Er is altijd iemand die teleurgesteld is in wat een service kan. Dit remt hergebruik;
• Doorontwikkelingen kosten in de praktijk vaak veel tijd. Vanwege de complexiteit van de software, maar mogelijk ook vanwege de regeldruk van de governance zelf;
• Financiering kan een rol spelen. Bijvoorbeeld: de eigenaar van een service wil niet dat de ontwikkelkosten van een gewenste functionaliteit van een andere afdeling op zijn/haar budget drukt;
• Versiebeheer van W3C webservices maakt bijvoorbeeld dat afnemers vaak gedwongen hun software moeten aanpassen zonder dat er voor hen een directe noodzaak is of dat er direct voordeel uit te halen is.

Daar waar webservices binnen bedrijven vaak maar moeizaam worden (her)gebruikt zijn services die gekoppeld zijn aan applicaties en diensten op het internet vaak enorm populair. Sterker nog, de webservice vormt soms zelfs de basis van het succes van een internet applicatie. Wat maakt deze webservices zo populair? En wat kunnen eigenaren van webservices binnen bedrijven hiervan leren?

Een goed voorbeeld is Twitter. Twitter heeft een website waarmee je Twitter berichten kan schrijven. Maar, de meeste mensen gebruiken één van de vele Twitter programma’s voor op hun computer of voor op hun mobiele telefoon om Twitter berichten te volgen en te schrijven. Die vele tientallen programma’s kunnen ontstaan omdat Twitter een eenvoudig te gebruiken webservice aanbiedt.

Laten we de Twitter webservice eens zelf gebruiken. De volgende link toont alle Twitter berichten van de gebruiker ‘infoinnovator’ in zogenaamd JSON formaat: Twitter berichten van InfoInnovator. Wat je te zien krijgt is afhankelijk van de browser die je gebruikt, maar als het goed is zie je een lijst van Twitter berichten met nog een hele hoop informatie er omheen.

Waar het mij met dit voorbeeld om gaat is de eenvoud. Een simpele url die je in je browser kan plakken geeft je toegang tot de gestructureerde informatie van een internet dienst. Iedereen kan dit doen. Als afnemer heb ik aan niemand toestemming hoeven te vragen om dit te doen. Ik hoef ook aan niemand verantwoording af te leggen wat ik met de informatie ga doen. Ik kan mijn idee, om bijvoorbeeld een helemaal te gek en hip Twitter programma te maken, heel snel uitproberen. De drempel voor ontwikkelaars maar ook anderen om de Twitter webservice te gebruiken is dus heel erg laag. Dat verklaart de grote hoeveelheid aan Twitter programma’s en andere vormen waarin Twitter wordt gebruikt. Gebruikers kiezen hun favoriete programma en gaan Twitteren dat het een lieve lust is. En het gebruik van het Twitter platform en dus niet zozeer de website zelf, groeit enorm. Twitter is een platform. Een dienst waarop anderen hun diensten weer kunnen bouwen. Een informatie ecosysteem met de dienst Twitter in het middelpunt.

Natuurlijk is niet alle informatie op Twitter zo gemakkelijk toegankelijk. Bepaalde functies zijn beveiligd en alleen toegankelijk na authenticatie. Maar, de basis blijft eenvoud.

Als ik een aantal populaire internet webservices langs loop dan hebben die de volgende kenmerken. De webservice…

• heeft een voor de gebruiker duidelijk en nuttig doel;
• is laagdrempelig, eenvoudig en simpel in gebruik;
• kent een (zeer) liberaal beleid ten aanzien van het gebruik van de webservice;
• kent een levendige en actieve community van gebruikers die elkaar informeren en helpen en waarbij de webservice eigenaar actief participeert in die community;
• biedt continu nieuwe, innovatieve en of verbeterde mogelijkheden;
• heeft zo min mogelijk beveiliging daar waar het kan en een zo streng mogelijke beveiliging daar waar het moet;
• is technisch eenvoudig, waarbij de techniek heel nauw aansluit bij reeds bestaande en algemeen geaccepteerde technieken (REST);
• is flexibel in het ondersteunen van meerdere formaten waarin je de informatie kan opvragen;
• kent een informatiestructuur die losjes en iteratief tot stand is gekomen;
• heeft uitstekende documentatie die de service beschrijft met praktisch toepasbare voorbeelden;
• kent een duidelijk (informatie)beleid ten aanzien van nieuwe versies van de webservice met ruime overgangsperioden;
• is financieel vaak omzet gedreven in tegenstelling tot interne bedrijfsservices die vaak kosten gedreven zijn. Dit verschil is ook van invloed op hoe je tegen doorontwikkelingen van de webservices aankijkt.

Mijn persoonlijke mening is dat het succes van internet webservices uiteindelijk zal overslaan op het bedrijfsleven en de overheid, waarbij de goede dingen van W3C enterprise webservices elkaar zullen ontmoeten in de goede dingen van de internet REST webservices.

Bedrijven, gemeenten en instellingen hebben zo hun eigen dynamiek. Het zijn niet allemaal hippe internetbedrijven. Per bedrijf zal je moeten kijken wat het beste bij je past. Of juist sterk gestandaardiseerde systemen met stevige governance of juist meer laagdrempelige, eenvoudig te gebruiken systemen met een meer liberaal gebruiksbeleid of wellicht een mix van beide. Kies, maar kies weloverwogen.

Berry Groenendijk is informatie architect bij Caerleon.

Er wordt gezegd dat Service Orientatie de brug tusse Business en ICT weet te slaan. In Archimate, the Architectuur taal, kan het concrete resultaat hiervan worden gezien. Services zitten in het hart van de taal. Dit kern element is aanwezig op alle architectuur niveaus. Externe business services overbruggen het gat naar de buitenwereld en externe applicatie services overbruggen het gat tussen de de business architectuur en de informatie architectuur. Technische services doen hetzelfde tussen informatie architectuur en technologie architectuur.

Kunnen services worden getekend tussen de horizontale Zachman lagen vraag ik me af?

Vandaag was ik aan het werk met het vinden van geschikte business services. Zoals altijd legde ik lakmoes proef criteria aan zoals een goede abstracties, goede verdeling van verantwoordelijkheden en maximale cohesie en minimale koppeling. Ook keek ik naar de toegevoegde waarde van een gevonden verzameling services, ik keek of ik er op ieder niveau 7 +/- 2 had gevonden en of ik voor een service ook afnemers kon vinden. Maar de ontwerpbeslissingen die ik nam bevredigden me niet volkomen. Plotseling kreeg ik een ingeving: is er niet net zoals bij de database theorie zoiets als een service normaal vorm, met standaard regels hoe je ze vindt, hoe je ze valideert en optimaliseert?

Al surfend op internet bleek dat  anderen al eerder dezelfde gedachte hadden gehad. Ze hebben onderzocht "welke eigenschappen een "goede" service zou moeten hebben". Ik zal het lezen en er later eens op terugkomen.

Ik ben gecharmeerd van de figuur hieronder (origineel van Oracle BEA). De meeste van de gelaagde SOA modellen plaatsen de GUI laag bovenaan, bij de gebruiker. Dan volgt de proceslaag, de business of domein logica laag en de data services laag.

Ik heb me altijd afgevraagd welke laag nu het initiatief had. Het leek er altijd op alsof het initiatief van de gebruiker moest komen via de GUI laag.

In deze figuur lijkt het er veel meer op (als de gebruiker zich bovenaan de afbeelding bevindt) dat de proces laag het initiatief heeft. Alleen door een actie van die laag krijgt de gebruiker zijn presentatiescherm. Presentatie is niet eerst. Dat lijkt mij de goede volgorde. Bovendien heeft de proces laag toegang tot alle andere lagen, zonder via andere lagen te moeten. Ook dat lijkt me zinnig. De Information Services direct toegankelijk hebben, zonder domein laag, is vooral zinnig op informatie te bekijken.

Ik werd gewezen op de bijdrage van Niels Klinkenberg aan het LAC 2007 met betrekking tot SOE (de Service geOrienteerde Enterprise). In zijn presentatie wordt de relatie gelegd tussen service orientatie en een network van organisaties, gericht op slimme samenwerking. De presentatie definieert de condities waaronder je succesvol een SOE kunt neerzetten en hoe je hem werkend krijgt.

Ik was in gesprek vandaag met Ruud van Vliet over de twee werelden die SOA lijkt op te leveren.

We merkten op dat SOA een trage wereld van core competenties, core services, oplevert die een zeer hoge kwaliteit en grote robuustheid moeten hebben. Dergelijke services worden typisch in releases opgeleverd die 3 maanden of meer duren. In de meeste bedrijven liggen die services verborgen in erfenis systemen (een leukere term dan legacy) en die kunnen stap voor stap worden ontsloten.

Daar tegenover staat een snelle wereld van mashup, samenstellen, integreren and via een proces aan elkaar knopen, waarin veranderingen dagelijks of wekelijks kunnen worden doorgevoerd. Soms is daarbij een ontwikkelcyclus nodig, soms zelf niet. Door het combineren en remixen van bestaande data en services kun je snelle veranderingen in de business doorvoeren.

Dit kan gaan leiden tot hele nieuwe rollen bij informatie innovatie. Aan de ene kant de communicatief vaardige, snelle business analist die nieuwe business ervaringen kan configureren in korte tijd, door hergebruik van bestaande services uit een service repository. Anderzijds techneuten, die nieuwe core services in een veel grote tijdspanne opleveren.

Ik las laatst een blog van David Straus waarbij hem werd gevraagd wat er na SOA zou komen. Hij weigerde dat te beantwoorden want 'we kunnen SOA nog niet eens goed op de rit krijgen'. En vervolgens volgt een obligaat lijstje met best practices om van SOA een succes te maken.

In my latest blogentry I wrote about SOA as one of more architecture approaches. I restudied older approaches I have been using and looked into new ones. Event Driven Architecture, based on the business events that trigger the business to work, is a new one. I once bought David Luckham's The Power of Events, as an introduction to Complex Event Processing.

Reading on the internet I found Jack van Hoof's blog (http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-...) about the relation between SOA and EDA. He sees SOA as manifested in the earlier in this blog defined strongly coupled information systems. SOA as based on command and control style, the 'slower' world of core business services.

And he sees the EDA as the fire and forget style, the mashup style of very loosely coupled services, the 'faster world'. Events form the linking pins between core business services.

This way, it seems my original SOA consists of two patterns, which you have to combine by making the right design decisions/trade offs.

I had a SOA round table last night with some clever minds. I told them that in my opinion the service oriented paradigm is just one paradigm I use as an enterprise architect.

Some-one refreshed my insight today into flexibility, especially in the alignment between business and information architecture and technology. He told me that inflexibility in information architecture and technology in relation to the business comes into existance if the (flexibility in the) model used for information architecture and technology is very different than the (flexibility in the) model of the business. In that case, simple changes in the business (for which flexibility they designed themselves) turn out to be very complex changes in information or technologie.