ArchITectuur Bedrijven: Naakte SOA

Jim Webber komt de eer toe om als eerste – of op z'n minst één van de eerste – software analist publiekelijk zijn afkeer geuit te hebben van een “fat SOA”. Zijn levendige en amusante bijdrage aan de Qcon 2007 conferentie onder de titel “Guerilla SOA” [1] heeft ongetwijfeld velen aan het denken gezet. De laatste weken zijn vele industrie-goeroes hem in zijn voetsporen gevolgd. Onder hen bekende namen als Martin Fowler [2], David Linthicum [3] en Joe McKendrick [4]. Het onderwerp prikkelt op z'n minst de creativiteit. Kwalificaties als “Manboobs”, vergelijkingen met “Junk Food” en woordgrapjes als “Enterprise Service Busted”, “Erroneous Spaghetti Box” en “Same Old Atrocity” zijn niet van de lucht. Het lijkt wel een collectieve actie van de softwareontwikkelaars en -architecten gericht tegen de grote boze leveranciers met hun dikke, dure middleware. Tijd voor een dieet?

Het debat

Een naakte SOA is een “back to basics” architectuur. De gedachte is even sympathiek als simpel. Het web is de beste architectuur die het vakgebied tot nu toe heeft voortgebracht. Sir Tim Berners-Lee heeft als geestelijk vader van het web een voorbeeldige prestatie verricht. Het web is schier oneindig schaalbaar, en het biedt een platform voor applicaties die in de verste verte niet te voorzien waren. Waarom zouden we het dan nu moeilijk maken met een ESB?

Het web is van nature één en al middleware. En de grote kracht van het web is dat het zo dom is. Berners-Lee heeft heel bewust voor gekozen voor een oersimpele architectuur. Hij wilde bijvoorbeeld het probleem van de “broken links” niet door het netwerk op te laten lossen. Dat kunnen de gebruikers van het netwerk veel beter zelf doen. In Europa zouden ze zoiets het subsidiariteitsbeginsel noemen – probeer de verantwoordelijkheid voor het oplossen van een probleem zo dicht mogelijk bij de bron te leggen. En applicatieontwikkelaars met een integratieprobleem hebben een meer dan begrijpelijke weerzin tegen het oplossen van zo'n probleem op enterprise niveau (waarschijnlijk nog meer dan met enterprise technologie).

Het web als middleware is goed, het is bewezen, dus wie nog betere middleware aan de man wil brengen moet van goede huize komen. En als “betere middleware” alleen zou betekenen dat er intelligentie in het netwerk wordt gesmokkeld die innovaties tegengaat en die dus de oerkracht van het web ondermijnt, dan zou het inderdaad tijd worden om de stormbal te hijsen.

Toch zijn er ook geluiden dat leveranciers niet zelden al te gemakkelijk als zondebok voor jammerlijk mislukte SOA-projecten worden gebruikt. Het is nou eenmaal verleidelijk om de schuld van zulke mislukkingen buiten de eigen organisatie te zoeken. Ik heb zelf nog geen enkel SOA-project gezien dat is mislukt puur vanwege falende technologie. Ik ken wel projecten die zijn mislukt omdat er overspannen verwachtingen waren van de magische vermogens van technologie om architectuurproblemen te verhelpen. Typische voorbeelden van het “Same Old Architecture” probleem. Iedere keer als dezelfde architecten die een bestaand architectuurprobleem niet hebben kunnen voorkomen geacht worden om het op te lossen, dan is de kans niet denkbeeldig dat ze opnieuw in dezelfde valkuilen vallen.

Het is de verdienste van David Linthicum [5] om al zeker 10 jaar onvermoeibaar te hameren op het gevaar van “vendor driven architecture” [3], [6-9]. Hij laat ook geen gelegenheid onbenut om erop te hameren dat een succesvolle transformatie naar een SOA geen tactische operatie is die in een projectvorm tot een goed einde kan worden gebracht, maar dat het een strategische keuze moet zijn die een verandering van lifestyle vereist. In die zin is het domweg opbergen van de bestaande inter-application spaghetti in een blackbox met het label ESB inderdaad een recept voor ellende. Maar is dat nou de schuld van de leveranciers?

De naakte waarheid

Hoe zat het ook al weer. David Chappel – de auteur die het begrip ESB groot heeft gemaakt – stelt het zo: “The ESB provides a highly distributed, event-driven Service Oriented Architecture (SOA) that combines Message Oriented Middleware (MOM), web services, intelligent routing based on content and XML data transformations” [10]. Afgezien van het gebruik van het woord “architectuur” als synoniem voor “infrastructuur” beschrijft dit de kern van de ESB-propositie. De ESB als glueware, met een rijkdom aan functionaliteit om componenten en services losjes (“loosely”) te koppelen.

Oracle beschrijft een ESB als “the underlying infrastructure for delivering a service-oriented architecture (SOA) and event-driven architecture (EDA)” [11]. IBM houdt het op een “infrastructure service that provides robust communication, intelligent routing, and sophisticated translation and transformation of services” [12].

ESB is dus geen oplossing voor een architectuurprobleem. Het is een tool om makkelijk bestaande applicaties van een service-interface te kunnen voorzien, om makkelijk composiete services samen te kunnen stellen en om bepaalde governancetaken te centraliseren. In een ideale wereld zou je waarschijnlijk geen proprietary ESB willen gebruiken. Vendor-lock-in's zijn nooit aan te bevelen. Misschien kun je zelfs wel stellen dat het niet wenselijk is om in een green-field situatie een ESB als concept te gebruiken. Complexiteit voorkomen is altijd beter dan complexiteit beheersen, niet waar?

Een ESB kan naar mijn mening wel degelijk helpen om bijvoorbeeld een legacyprobleem op te lossen. Zie het maar als een stap in een migratiestrategie. Als een truc om gedurende de vlucht de lekke band van een vliegtuig te plakken. Noem het van mij part een “One-night stand”. Weggooiarchitectuur desnoods. Een noodzakelijk kwaad. Maar zie een ESB als een nuttig instrument om problemen die in de loop van de jaren zijn gegroeid te tackelen. Een ESB is niet de bron van de organisatorische en architecturele problemen. Dan is het toch raar om leveranciers te verwijten dat hun EBS die niet kan oplossen?

Een paradigmaverandering gaat altijd gepaard met vallen en opstaan. Het was zo bij de invoering van relationele databases, het was zo met de adoptie van het web en het is zo bij de transformatie naar enterprise architectuur. Succesverhalen en mislukkingen wisselen elkaar af, maar uiteindelijk vinden we met z'n allen een balans die de industrie een hoger plan brengt. Daarbij hebben technologische innovaties altijd een rol gespeeld en er is geen enkele reden om te denken dat zoiets dit keer niet zal gebeuren. De “peak of inflated expectations” [13] ligt inmiddels achter ons, zo veel maakt dit debat wel duidelijk. We zullen de “trough of disillusionment” nog doormoeten om te ontdekken welk potentieel ESB's op termijn zullen bieden, dan wel hoeveel of hoe weinig kleren een effectieve SOA infrastructuur nodig heeft.

Een ding is zeker. Een typische eilandorganisatie met een bijbehorende archipelarchitectuur zal heel wat weerstand moeten overwinnen voordat het zich een cultuur van bruggenbouwen en samenwerken eigen heeft gemaakt. Op termijn is het opsplitsen van zulke organisaties het enige alternatief voor synergetische samenwerking. Wat dat betreft is de markt ongenadig.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 10^de in een reeks die op dit weblog gepubliceerd zal worden.

Bronnen

[1] http://www.infoq.com/presentations/webber-guerilla-soa

[2] http://www.infoq.com/presentations/soa-without-esb

[3] http://weblog.infoworld.com/realworldsoa/

[4] http://blogs.zdnet.com/service-oriented/

[5] http://www.davidlinthicum.com/WhoWeAre.html

[6] David S. Linthicum: “Enterprise Application Integration”; Addison-Wesley, 1998.

[7] David S. Linthicum: “B2B Application Integration: e-Business-Enable Your Enterprise”; Addison-Wesley, 2000.

[8] David S. Linthicum: “Next Generation Application Integration”; Addison-Wesley, 2003.

[9] http://www.davidlinthicum.com/paperspresentations.html

[10] David A Chapel: “Enterprise Service Bus”; O'Reilly, 2004.