Wat ik veel zie gebeuren onder de noemer soa valt het best te typeren als service oriented applicaties. Dit zijn applicaties waarbij de koppelingen naar andere onderdelen binnen de applicatie of de interfaces naar andere systemen worden uitgevoerd als service, vaak in de vorm van web services.
Maar dit is niet wat de meeste mensen bedoelen met soa. De meeste mensen streven een hoger doel na waarbij ‘herkenbare' business functionaliteit beschikbaar wordt gesteld aan andere bedrijfsprocessen. Als belangrijkste voordelen worden hierbij genoemd:
- Nieuwe applicaties kunnen sneller en goedkoper worden gebouwd doordat bestaande functionaliteit opnieuw gebruikt kan worden.
- De organisatie wordt er meer wendbaar door (more aglie) omdat wijzigingen sneller kunnen worden doorgevoerd door op een eenvoudige wijze de verbindingen tussen applicaties te veranderen. Dit heet ook wel orkestreren.
Maar lukt dit ook in de praktijk?
Het bouwen van service oriented applicaties is zeker zinvol. Het is snel in elkaar gezet en het geeft een verregaande mate van platform onafhankelijkheid. Omdat de afnemers hier vooraf bekend zijn kan de service op maat worden gemaakt. Maar het hogere doel van soa is vaak veel minder succesvol. Voordelen halen uit een brede soa inspanning is moeilijk. Het probleem hier is alles behalve technisch, het is menselijk. De techniek is tegenwoordig gemakkelijk. Het probleem zit in menselijke factoren.
Stel, er wordt een nieuwe applicatie gebouwd en het team wil er services bovenop bouwen volgens het lopende soa initiatief. Hun doel is de functionaliteit beschikbaar te maken voor toekomstig gebruik door anderen uit de organisatie. De projectsponsor echter ziet extra onkosten op zijn budget verschijnen terwijl het toekomstige voordeel voor anderen buiten zijn blikveld ligt. Kortom, de projectsponsor zegt ‘nee'. Services vergen een investering vooraf.
Het projectteam ondervangt dit creatief door niet te vragen maar gewoon te doen. Ze bouwen services volgens wat zij denken dat juist is. Later dienen de afnemers zich aan. De eerste is enthousiast, maar wil nog wel een paar kleine dingen erbij. Ook nummer twee heeft extra wensen en voor men het weet zit men te kijken met een groot versie probleem. Het is verdraaid moeilijk om op voorhand services te bedenken die herbruikbare business functionaliteit bieden.
Maar stel dat ook dat lukt, er zijn services die algemeen bruikbaar zijn en er zijn tevreden afnemers. Dan is er nog de business eigenaar van de applicatie. Hij heeft de applicatie aangeschaft ten behoeve van zijn gebruikers ter ondersteuning van zijn bedrijfsproces. Hij is bang dat de services zijn applicatie gaan belasten en hij ziet support aankomen ten behoeve van externe gebruikers. Dat is niet in zijn belang en hij zegt nee.
Soms werkt het brede soa initiatief wel. Bijvoorbeeld isv's (independent software vendors) hebben veel externe klanten, zij kennen hun gebruikers en kennen hun processen. Zij kunnen op voorhand bedenken waar de afnemers behoefte aan hebben en zij hebben een belang bij de investering. Maar voor maatwerk applicaties werkt het bijna nooit. Het bouwen van applicaties met services is niet hetzelfde als het bouwen van een bedrijfsbrede infrastructuur rond services. Toch is dat laatste wat SOA beoogt.
Ik ben een grote fan van soa, het is een prachtig idee, maar toch ben ik sceptisch geworden door wat ik in de praktijk zie gebeuren. Ik hoorde onlangs iemand het volgende zeggen: "Hoeveel cio's maken zich 's nachts zorgen over hoe ze kunnen voorkomen dat hun datacentrum wordt ontmanteld en verhuist naar ‘de cloud'? Antwoord: veel. En hoeveel cio's liggen wakker met de vraag of hun services infrastructuur de volgende business strategie van de ceo kan ondersteunen? Antwoord: niet genoeg".
Een infrastructuur rond services is fundamenteel om je te onderscheiden op de markt en is dus fundamenteel voor de business strategie. Dit illustreert volgens mij de kern van het probleem waarmee we te maken hebben: Het verband tussen wat we doen in de it en de business strategie is gewoon niet duidelijk voor veel mensen in de business.
