Enterprise Application Integration’ (EAI) is een nieuwe modekreet. Zolang ik mij kan herinneren proberen IT-afdelingen applicaties te integreren, met eigen mensen of met externen. Integratie is een enorm complex probleem, dat waarschijnlijk nooit volledig zal worden opgelost. Waarom niet moge duidelijk zijn: er is nooit één moment waarop een organisatie al zijn systemen kan veranderen. Applicaties ontwikkelen zich in een verschillend tempo; sommige zijn oud, andere zijn nieuw. Het integreren van oude en nieuwe applicaties vergt onvermijdelijk een extra inspanning.
Integratie is niet alleen een probleem als het om applicaties gaat. Historisch gezien staat de applicatie in dienst van een bedrijfsproces. Het waarom van bepaalde stappen wordt daarbij zelden ter discussie gesteld. Inmiddels is duidelijk dat bedrijfskundigen en IT’ers moeten samenwerken, en dat daarbij soms een compromis gesloten moet worden. Het integreren van verschillende personen met verschillende vaardigheden en verschillen in aanzien is een lastige taak, die gemakkelijk kan worden verstoord door tegenwerking van sleutelpersonen.
Het lijdt geen twijfel dat de huidige generatie applicaties zich in de goede richting ontwikkelt. Ze heten nu ‘enterprise resource planning (erp) systemen in plaats van gegevensverwerkende systemen, maar dat is verkooppraat. Moderne database-technologie maakt het mogelijk uitgebreide applicaties te bouwen, waarbij de fundering bestaat uit een gemeenschappelijke database. Oudere applicaties bestonden uit afzonderlijke programma’s en databases, met extra programma’s om relevante gegevens van de ene database naar de andere over te hevelen, meestal in een nachtelijke batch-job. De eerste systemen beschikten gewoonweg niet over de technologie om een geïntegreerd product te maken, maar de erp-systemen van vandaag hebben dat wel. Helaas krijgen de integratiemogelijkheden teveel aandacht. Een erp-systeem is best uitgebreid, maar een organisatie zal nog steeds een aantal specialistische applicaties naast de centrale erp-applicatie moeten hebben.
Een erp-systeem zou daarom de belangrijkste applicatie moeten worden, maar dan wel één die moet kunnen samenwerken met andere applicaties en die kan worden geïntegreerd met tools voor werkstroom- en kopie-beheer. De erp-leveranciers propageren hun eigen werkstroom- en ‘datamart’-oplossingen, maar in feite integreren zij slechts de functies van het erp-pakket.
Veel organisaties hebben inmiddels de erp-weg bewandeld en komen er nu achter dat de kosten veel hoger zijn dan ze dachten. De belangrijkste kostenpost vloeit voort uit de noodzaak om toegang tot de database te verkrijgen, al was het alleen maar om oude en nieuwe applicaties te integreren. Dit moet op logisch niveau gebeuren; SQL is onbruikbaar. De leveranciers vragen geld voor toegang, zowel voor het lezen van gegevens uit de erp-database als voor het schrijven van gegevens naar de erp-database. De Api’s worden verkocht aan leveranciers van Olap-tools en dergelijke.
Andere organisaties werken aan het integreren van bestaande applicaties met web-frontends. Hierbij gebruiken ze applicatieservers. Velen zullen uiteindelijk gebruik gaan maken van op Java gebaseerde herbruikbare componenten, zoals het San Francisco-project. Dat is misschien wel moderner, maar lost de integratieproblemen niet op.
Al deze realistische eisen hadden tot betere producten moeten leiden dan nu het geval is. De industrie had meer aandacht moeten besteden aan het ontwerpen van bedrijfsprocessen, case-tools, ontwerptools, ‘workflow’ en ‘groupware’. In plaats daarvan zijn we op een dwaalspoor gebracht met C++, RAD-tools, client/server-systemen enzovoort. Kortom hetzelfde als we vroeger deden, maar dan anders. Vooruitstrevend is het allemaal niet. Gevolg is dat we nu een hele software-industrie hebben die producten maakt om applicaties te integreren zonder gebruik te hoeven maken van primitieve programmeertalen. De verzamelnaam is ‘middleware’. Enkele weken terug had ik het op deze plaats nog over standaarden voor middleware. Het is deprimerend om te zien hoe echte standaarden als DCE, Corba, Java en dergelijke worden ontwikkeld, en hoe naïef organisaties zijn door in plaats daarvan inferieure ‘de facto’ standaarden te gebruiken. Het gevolg is dat grote hoeveelheden geld worden verspild aan improductief technisch geneuzel.
Als IT-afdelingen en business units werkelijk het belang van het bedrijf willen dienen, dan moeten ze proberen niet in de technologische valkuil van de leveranciersspecifieke producten te lopen. Om ‘Enterprise Application Integration’ te ondersteunen moeten we ons richten op simulatietools, ontwerptools, repositories, ‘workflow-engines’ en dergelijke; projectmanagement en risico-analyse moeten veel meer aandacht krijgen. EAI moet ook gaan over projectmanagement, ontwerp, operationeel beheer en dergelijke; daarnaast moeten we natuurlijk goede en vooral onderhoudbare technologie gebruiken. Helaas lijkt de enige vooruitgang te bestaan uit het bedenken van nieuwe namen voor oude ideeën en vooral veel nieuwe drieletterige afkortingen (DLA’s).
