SOA is de hype voorbij en biedt alle beloofde voordelen aan zowel de organisatie als de ict-afdeling, maar waarom wordt daar nog niets mee gedaan? Waarom is dat het geval en wat moet daarvoor vooral aan de organisatiekant van SOA nog gebeuren?
SOA is niet nieuw meer en SOA is geen hype meer. Dus we begrijpen SOA en we passen het goed toe. We hebben bereikt met SOA wat we beoogden.
Niet dus.
Naar mijn mening zijn we nog lang niet daar waar SOA ooit voor was bedoeld. SOA was bedoeld om de organisatie in staat te stellen snel en flexibel haar processen aan te passen, gebruik makend van de services die door de ict-organisatie geleverd zouden worden. Ict zou daarmee veel meer een leverancier worden en de organisatie zou zelf veel meer controle krijgen over veranderingen die het zou willen doorvoeren, met name in de procesvoering.
Als we kijken wat er bereikt is met SOA, dan kunnen we vaststellen dat de techniek rond SOA sterk is ontwikkeld. Het kan nog altijd beter, maar er zijn alom standaarden en vooral op integratiegebied worden ze geaccepteerd en gebruikt.
Bedrijven passen ook veelvuldig SOA toe, tenminste als we naar het technische aspect kijken. Vrijwel elk bedrijf met een substantiele ict-huishouding maakt gebruik van een enterprise service bus, waarover services worden aangeroepen die de gewenste functionaliteiten uitvoeren. Misschien nog niet altijd perfect of geoptimaliseerd, maar het gebeurt. Hetzelfde geldt voor de toepssing van services in processen. Gelijktijdig en soms voorafgaand aan de invoering van de enterprise service bus is in de meeste bedrijven ook de moderne variant van business process management ingevoerd. Hiermee is het toepassen van services relatief eenvoudig mogelijk en wordt ook gedaan.
Betekent dat dan dat SOA geslaagd is? Nee!
Dat services binnen een business process management-systeem worden gebruikt, wil absoluut niet zeggen dat de organisatie nu gebruik maakt van services om haar processen zelf snel en soepel aan te passen aan wijzigingen in de markt, in de productvoering of aan interne efficiëntie.
Vraag in de organisatie wie verantwoordelijk is voor procesinrichting of wie er met services bezig is en het antwoord zal steevast ‘ict’ zijn. En dan niet ict als leverancier die voldoet aan de vraag van de business om bepaalde veranderingen door te voeren, maar ict als kennishebber, beslisser en uitvoerende. De organisatie is veelal nog steeds aanjager van de projecten, maar haakt af zodra een servicedefinitie, ESB- of BPM-oplossing in de buurt komt.
SOA is geen technologie voor de organisatie
Het is logisch dat de organsatie afhaakt. SOA is ver doorgeschoten in de techniek en daar zijn grote groepen mee bezig. WS-x-initiatieven, HTTPx, allemaal techniekgedreven initiatieven. Maar equivalente groeperingen van echte gebruikers zijn niet of nauwelijks te vinden. Waar zijn de fora van organisatiemensen die flexibiliteit in hun processen door middel van services proberen te bereiken? Ze zijn er niet of nauwelijks en als ze er zijn worden ze gesponsord door een softwareleverancier…
Moeten we het daarbij laten en denken dat dit weer een mislukt inititatief is om organisatie en ict dichter bij elkaar te brengen? Naar mijn veronderstelling niet. SOA heeft wel degelijk mogelijkheden om de organisatie de controle over procesvoering te geven, maar niet zo. Daarvoor moet de SOA-techniek veel meer onder de motorkap verdwijnen en zal SOA ook in begrijpelijke termen voor de organisatie moeten worden vertaald. Daarnaast zal de inzichtelijkheid in de diensten, die de organisatie in de vorm van services ter beschikking staan, veel beter moeten worden. Probeer nu maar eens de beschrijving van een service te vertalen naar iets dat toegevoegde waarde aan de organisatie levert.
Diensten zullen ook veel beter extern te halen moeten zijn. Standaardisatie is daarvoor essentieel en voor een groot deel ook al beschikbaar, maar we zullen wel een stap verder moeten zetten. Er moet veel meer aandacht zijn voor beveiliging. Hoe zorg je er bijvoorbeeld voor dat een externe service aansluit bij het beveiligingsbeleid van de organisatie? En op basis waarvan vertrouw je een externe service? Is het verstandig een externe service privacygevoelige gegevens te laten verwerken en wat is het risico als die service provider de gegevens per abuis openbaar maakt? Wat wil je extern halen? Wat is je eigen kennis en toegevoegde waarde en wat kun je extern inkopen? Hoe staat de ict-organisatie daar zelf tegenover? Als meer en meer diensten extern belegd worden, wat is dan nog de toegevoegde waarde van de ict-organisatie, behalve een beheerder zijn en operationele problemen oplossen? Werkt de ict-organisatie wel mee aan een dergelijk andere kijk op automatisering?
Een ander, niet te onderschatten probleem, is de overgang van het huidige systeemlandschap naar een dienstengeorganiseerd landschap. Technisch zijn er allerlei oplossingen om bestaande systemen te ‘verservicen', maar wat bereik je daarmee behalve een lichtelijk eenvoudigere integratie? Kun je daardoor de helft van het proces intern uitvoeren en de andere helft extern beleggen? Wat betekent dat dan vanuit een organisatieperspectief?
Kortom, het is vanuit de organisatie gezien nog lang niet mogelijk om SOA te gebruiken en toe te passen zoals het ooit bedoeld was, om snel en eenvoudig de manier van werken aan te passen op basis van services die door ict ter beschikking worden gesteld. Er zijn nog teveel afhankelijkheden tussen services onderling, de standaardisatie is er nog niet op businessniveau en het benodigde vertrouwen in externe services is nog niet daar.
Organisatiegedreven SOA-projecten
De organisatie zal niet in staat zijn zelf service-oriëntatie toe te passen zonder de kennis van de ict-organisatie. Om de echte voordelen van SOA te benutten, zal ict de organisatie veel meer moeten ondersteunen om het beloofde business-succes te maken. Hoe?
Luisteren en begrijpen is als altijd de belangrijkste factor. Het daadwerkelijk helder krijgen van de behoeften vanuit de business is stap één. Het op basis daarvan openen van het ict-landschap is de belangrijke volgende stap. Het openen of verservicen moet dan niet plaatsvinden vanuit de technische mogelijkheden, maar vanuit de daadwerkelijke businessbehoefte. Doorvragen wat de business wil bereiken met bepaalde diensten is essentieel om dit goed te doen.
Het ondersteunen van de organisatie op de reis die SOA heet, moet ook veel meer gebeuren dan nu het geval is. Nu is vaak een presentatie van SOA vanuit een technisch perspectief de manier om SOA te verkopen. De ict doet een belofte over flexibiliteit en snelheid in aanpasbaarheid zodra alles verserviced is. Daarvoor is dan een flink budget nodig en het duurt een lange tijd voordat de eerste resultaten zichtbaar zijn voor de business, maar het budget is dan wel grotendeels op.
SOA-projecten moeten veel minder een ict-project worden en veel meer worden aangestuurd door de organisatie zelf, inclusief de dagelijkse aansturing van deze projecten. Het opzetten van een SOA-aanpak vanuit de organisatie zelf is hierbij essentieel. Dat is de belangrijke stap die de organisatie moet maken om de daawerkelijke SOA-doelstellingen te halen. Een organisatie die haar processen snel kan aanpassen aan de gewijzigde omstandigheden, met een minimale ondersteuning van ict. Ict is hierin een algemene dienstverlener en niet de beheerser van het veranderingsproces.
Wat een niet te onderschatten probleem is bij het aanbieden van SOA via een Shared Services Organisatie is de vraag wie voor wat (het meeste) betaald en dus uiteindelijk de “horizontale” functionaliteit bepaalt. Ik heb bij menig grote organisatie gezien dat “de business” binnen zo’n organisatie met het grootste budget ook het meeste voorelkaar krijgt – en waarschijnlijk terecht.
Vaak worden oplossingen specifiek gebouwd voor zo’n business unit binnen de multinational. Zo’n oplossing bestaat dan uit een veelheid aan verticale “interfaces” en een aantal (in potentie zeer herbruikbare) horizontale componenten. Deze horizontale componenten zouden door het hele bedrijf gebruikt moeten worden omdat hierin vaak zaken als governance en andere monitoring en management aspecten ondergebracht zijn.
Vaak worden de specifieke eisen van een business unit doorgedrukt wat resulteert in meerdere versies van de horizontale componenten en uiteindelijk dus onbruikbaarheid van de governance modellen met als resultaat “ontmeetbare” oplossingen. Dit probleem is bijna niet op te lossen door een shared services organisatie, tenzij deze meer macht zou hebben. Dit is echter bijna nooit het geval omdat “de business” het voor het zeggen heeft. Wrijving zal er dus altijd blijven!
Inderdaad, benader het maar eens als een veranderproject.
Lees ook mijn eigen eerdere column in het soa-topic met de titel ‘Kan een architect veranderen’ er op na.
Peter Hermans
Valcre BV (collega SOAtopic expert)