Bestaat de Enterprise Service Bus ?

Om op basis van SOA een landschap van services op te bouwen, te verbinden en te onderhouden wordt vaak een Enterprise Service Bus (ESB) ingezet. Een ESB wordt over het algemeen gezien als een software suite van componenten om relatief snel en gecontroleerd te voorzien in een bedrijfsbrede implementatie van processen, services, synchrone en asynchrone aansturingsprotocollen (SOAP, JCA, JMS, MQ etc) en aanvullende componenten als process modelling, portal en monitoring. Doelstelling is vaak standaardisatie op één type product, vermindering van kosten, snellere time-to-market van projecten en effectievere kennisopbouw.

Mijn stelling is dat vanuit technisch perspectief één single-type ESB implementatie prima mogelijk is maar dit organisatorisch bijna niet uitvoerbaar is.

We zien in grote organisaties bijna zonder uitzondering dat door historie (overnames, fusies), strategische keuzes en verdeling van budgetten op business-unit (BU) niveau er een nogal exotisch landschap ontstaat aan integratie software, services, message-oriented-middleware, applicatieservers en kennis.  Elke BU heeft eigenlijk een eigen ESB op lokaal of domein niveau met haar eigen, vaak succesvolle implementatie. Volgens mij kunnen we dan ook beter spreken van “Domain Service Buses” in termen van product en technologie.

Overnames zorgen bijna zonder uitzondering voor een mix van technologieen in het nieuwe enterprise IT-landschap door de verschillende strategische keuzes voor leveranciers uit het verleden. Bijvoorbeeld een IBM landschap gaat samen met een Oracle landschap of een SAP-unless bedrijf gaat samen met een Microsoft-unless infrastructuur. Dit impliceert op enterprise niveau een mix van ontwikkelplatformen (.NET en J2EE), message-oriented-middelware, portals, Business Process Management (BPM) tools en Business-2-Business exchanges. Los van deze technische mix is er ook een politieke historie gekoppeld aan deze bestaande inrichting waardoor verandering niet altijd wenselijk is.

De verdeling van budgetten op BU niveau is zeer gangbaar. Vaak moet een referentie-architectuur, city-plan of blauwdruk zorgen voor een referentiekader van standaarden binnen de enterprise waarbinnen elke BU autonoom beslist en aankoopt.  In de meeste gevallen is de referentiearchitectuur niet bindend en worden er lokaal of regionaal andere keuzes gemaakt. Op over het algemeen zeer valide gronden wordt vaak bij de CIO bedongen dat een afwijkende keuze echt het beste is voor de betreffende BU. Deze BU is immers ook verantwoordelijk voor het lokale proces wat de ESB moet gaan ondersteunen en wordt daar dan ook op afgerekend.  Het fenomeen “eigenwijze” business-units is in deze context waarschijnlijk wel bekend.

Als we de ESB bekijken als een virtuele omgeving van gekoppelde domain oplossingen en technologieen, dus niet als product, is de haalbaarheid hiervan een stuk eenvoudiger geworden.

Het inrichten van een bedrijfsbrede, "echte" ESB wordt dan een andere afweging met betere ROI. Het gaat hier naast de noodzakelijke organisatieveranderingen om concrete vragen als :

Vervang ik technologie ofcombineer ik de verschillende technologieen tot virtueel één ?
Vervang of bridge ik de verschillende message-oriented-middleware ?
Koppel ik alleen domeinoverschrijdende services ?
Hoe integreer ik bestaande message-based integratie en data integratie in een SOA ?
Hoe monitor en manage ik het gehele SOA landschap ?

Doormiddel van adapters en bridging software kunnen de verschillende domeinoplossingen aan elkaar gekoppeld worden en kunnen niet-SOA domeinen ook onderdeel worden van een ESB.  Voordeel is dat alleen de domeinoverschrijdende processen gekoppeld worden (vaak een goede business case), de organisatie minder hoeft te veranderen, politiek geen zware beslissingen genomen hoeven te worden en de quick-wins motiverend werken.

Business Intelligence en SOA Goverance kunnen als centrale implementatie zorgen voor inzicht in- en kostenreductie op gekoppelde “Domain Service Buses”.

Edgar de Groot
Business Architect – Information Builders & iWay Software