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
Het is inderdaad een groeiende trend dat meerdere ESBs binnen één organistatie worden ingezet, zij het in een gerelateerde manier op basis van federatie, dan wel losstaand ten behoeve van specifieke integratietaken.Vreemd is deze beweging overigens niet:Acquisities en fusies worden al genoemd als reden voor deze diversiteit aan ESBs, maar andersinds kan ik mij heel goed voorstellen dat de inzet van meerdere ESBs ook een hele praktische kant heeft, zoals focus op specifieke integratietaken, bijvoorbeeld met externe partners, of voor ongestructureerde content met typisch zware loads. Maar ook bewuste scheiding van bijvoorbeeld security zones.Ook qua ESB-keuze wordt de overweging wat genuanceerder: de ESB heeft immers een centrale rol in een SOA; waarom één kiezen en voorschrijven (een lastige opgave), terwijl federatie van enkele ESBs ook kan? Het is immers een producteigen kenmerk: vereenvoudigde integratie! Het later besluiten of de ESBs al dan niet geconsolideerd moeten worden volgt vanzelf, al lerende wat waar het beste werkt op een meer granulair niveau.Een andere stuwende kracht achter deze trend is dat veelal grote, organisatiebrede implementaties erg lastig zijn te overzien en potentieel evenzo grote problemen met zich kunnen meebrengen. SOA is betrekkelijke nieuwe materie; de contouren beginnen zich inmiddels duidelijker af te tekenen, maar het blijft een nog erg vloeibaar geheel. Het aantonen van werkelijke waarde door realisatie van quick-wins of door het toepassen op subdomeinen is dus erg benodigd. Dit maakt dat typisch korte, niet enterprise georiënteerde, gefocuste projecten meerwaarde proberen aan te tonen door slimme toepassing van deze nieuwe technologieën en dus gaande weg meerdere ESB implementaties in de hand werkt.De stelling één single-type ESB implementatie te willen nastreven komt daarmee eigenlijk ook vanuit technisch perspectief onder druk te staan. Voorgenoemde overwegende voorzie ik bij het aanhouden van één grote, alles verwerkende single-type ESB waarop organisatiebreed alles moet aansluiten een behoorlijke toename in complexiteit en beheersbaarheid. Segmenteren door toepassing van meerdere ESBs is dan nog lang niet zo’n verkeerd idee.
Uit bovenstaande posts van Edgar en Gershorn komt de stellingname dat één ESB niet volstaat, en dat is een interessante. Zou de oplossing hiervoor liggen in het combineren met een andere trend nl. virtualisatie. Oftewel krijgen we zo meteen één functionele, virtuele ESB, fysiek opgebouwd uit meerdere ESB’en, wellicht van verschillende leveranciers afkomstig. Is dit dan meteen de opstap naar verdergaande automatisering van de automatisering?Ik ben benieuwd. Wie durft…?Oscar Roelofsion-ip