zaterdag, oktober 14, 2006

7 Manieren om EAI-experts te ontdooien (deel I)

Alweer enige weken geleden verschenen in Software Release Magazine: een soort van Nederlandstalige re-run van mijn eerdere schrijfsel op de Capgemini-site over de geneugten van Enterprise Application Integration. Voor de volledigheid de integrale versie hieronder:

Ik zeg het gelijk maar om alle misverstanden te voorkomen: ik koester een intens warme band met EAI-experts. Enterprise Application Integration: je kunt me ervoor wakker maken! Eigenlijk droom en adem ik het onderwerp en soms valt het moeilijk om zakelijk en privé gescheiden te houden; sta je opeens tijdens het weekend met een EAI-expert aan de zijlijn naar het voetbal te kijken.

Het valt me daarom des te moeilijker om een kritische noot te laten horen. Want laten we eerlijk zijn: ooit was het niets minder dan kunst – of in ieder geval een schaarse ontwerpvaardigheid – het aan elkaar lijmen van al die verschillende, heterogene systemen. Om maar niet te spreken van het absorptievermogen dat je nodig had om al die verschillende EAI tools en platformen uit elkaar te houden. De betiteling ‘EAI-expert’ werd daarom met trots als geuzennaam op visitekaartjes gebruikt.

Toch lijkt de balans de laatste tijd door te slaan: sommige vakgenoten lijken integratie als hun enige en onvervreemdbare levensdoel te zien. En dat vertroebelt de kijk op zowel de ontwikkeling van technologie en strategie als op waarom de bedrijfsvoering EAI ook alweer nodig had.

EAI-experts moeten soms ontdooid worden uit hun diepgevroren existentie. En om dat voor elkaar te krijgen, moet je wel eens je toevlucht zoeken tot schokeffecten. Laat ik daarom via deze column 7 gezichtspunten introduceren om de discussie weer op gang te krijgen, allen gebaseerd op jarenlange ervaringen met integratie-experts in uiteenlopende organisaties en zelfs bij productleveranciers:

Integreren is slecht
Het is allemaal Open Source
Je bent de data vergeten
Het wordt meegeleverd met SAP
Gewoon in het Server Rack schuiven
Amazon doet het
Alleen Verticaal doet ertoe

Er is sprake van een oplopende volgorde, min of meer gebaseerd op de zwaarte van het effect. Alles hangt af van de ernst van de bevriezingsverschijnselen. Laten we eens zien of de eerste drie argumenten al afdoende zijn:

1. Integreren is slecht. Er is maar éen effectieve manier om meer code te produceren: minder code schrijven. Evenzeer zou een EAI-expert eerst moeten proberen het aantal systemen dat moet worden geïntegreerd te verkleinen voordat zelfs maar het eerste project wordt overwogen. Dat kan door het consolideren van versies, het uitfaseren van applicaties die allemaal ongeveer hetzelfde doen en het implementeren van standaardpakketten. Complexiteitsreductie betekent niet dat je voortaan nog maar één Integration Broker gebruikt: het betekent dat je zo’n tool zoveel als mogelijk vermijdt.
2. Het is allemaal Open Source. Er zijn niet veel organisaties meer die er een huisgemaakte database of besturingssysteem op nahouden. Maar er zijn er nog genoeg die elke dag worstelen met hun eigen, verouderde integratie-middleware: iconen uit een vergaan tijdperk. Neem eens een kijkje in de Open Source-wereld: daar vind je uitstekende, moderne tools die ook nog eens op open standaards zijn gebaseerd. Of vervang de eigen huisvlijt simpelweg door een commercieel, industry-strength product. Bespaart in ieder geval tijd en geld. Integreren is slecht, maar integreren mogelijk maken is slechter.

3. Je bent de data vergeten. Voordat er allerlei systemen aan elkaar worden gekoppeld, is het misschien een goed idee om eerst eens na te gaan wat voor data er allemaal over die blinkende Enterprise Service Bus gaat reizen. De hysterische belangstelling voor serviceoriëntatie heeft de belangstelling voor een goed ontworpen datastructuur nog verder doen kelderen. En dat is een fatale fout: het heeft geen nut om services met elkaar te verbinden als er geen eensgezindheid is over de informatie die heen en weer gaat. Dit verklaart waarom Master Data Management momenteel zo hoog staat op de prioriteitenlijstjes van IBM, SAP en Oracle.

Veel succes met deze eerste drie openingszinnen. Mochten er nog hardere maatregelen nodig zijn: ik kom daar in mijn volgende column op terug.

Geen opmerkingen: