Verticale 'monolithische' architecturen bieden een one-stop-shop: koop een groot standaardpakket. Er kan meteen mee worden gewerkt en het is makkelijk te vervangen. Het klinkt goed, maar zo'n ogenschijnlijke kostenbesparing kan duur uitpakken.
Omdat geen enkel bedrijf hetzelfde is, is maatwerk in standaardsoftware meestal onvermijdelijk. Het verticale model is echter lastig aan te passen. Communicatie tussen de pijlers is soms nodig, maar een wijziging van de ene pijler vereist werk aan de andere. Bovendien is de gebruikersinterface veelal vervlochten met het achterliggende systeem. Een aanpassing aan die interface betekent dan automatisch een aanpassing aan de achterkant. Bij veel verticale ict-trajecten wordt de total cost of ownership (tco) dus bepaald door de kosten van aanpassingen. Om die enorme kostenpost door onderhoud en maatwerk te drukken, is de horizontale aanpak bedacht: soa.
Het idee achter soa is de communicatie tussen systemen te laten verlopen op basis van diensten. Deze diensten worden geleverd via universele, platformonafhankelijke webservices. Een dienst wordt vastgelegd in een soort contract, met daarin input versus output. Dit contractmodel is er op gericht zo eenvoudig en goedkoop mogelijk wijzigingen te kunnen doorvoeren. Onder de motorkap sleutelen kan namelijk ongestraft, zolang alle toepassingen zich maar aan hun bestaande contract houden. Behalve flexibiliteit, biedt het model nog een paar voordelen. Meerdere applicaties kunnen worden benaderd vanuit een enkele interface. Denk bijvoorbeeld aan allerlei portaltoepassingen die erp-applicaties gebruiken. Bovendien wordt hergebruik wordt makkelijker, omdat dezelfde dienst door meerdere systemen op verschillende platforms kan worden afgenomen.
Hoewel de moderne variant is gebaseerd op web services, is soa eigenlijk niet nieuw. Corba (common object request broker architecture) is naar hetzelfde principe gemodelleerd. Webservices zijn echter gebaseerd op wereldwijd geaccepteerde standaarden zoals xml en soap.
De meest voorkomende variant van een horizontale aanpak is tamelijk halfslachtig. Binnen veel grote bedrijven wordt een architectuur opgebouwd die weliswaar op xml-services is gebaseerd, maar in feite werkt met vermomde http verzoeken.
Dit heeft een spaghetti van aanroepen naar verschillende applicaties tot gevolg en niet de beoogde overzichtelijke tussenlaag. Het kan goed gaan, maar dat hangt af van twee randvoorwaarden:
1. Er zal een overeenkomst in technisch platform moeten zijn tussen de aanbieder en de afnemer van de dienst.
Dat kan eigenlijk alleen maar binnen grote bedrijven, in een gecontroleerde omgeving. Zelfs daar blijken platforms echter vaak niet overeen te komen. Het potentieel buiten het bedrijf om, naar leveranciers bijvoorbeeld, kan op deze manier bijna niet worden aangesproken.
2. De afnemende applicatie zal vaak moeten worden aangepast om de communicatie met de aanbieder aan te kunnen.
Aanpassingen en onderhoud zijn dus vaak nog steeds duur. Continue werkzaamheden kunnen leiden tot een wirwar van code die voor iedere dienst anders is.
Een eerste succesfactor bij het implementeren van een horizontale architectuur is het toepassen van universele standaarden. Dit betekent dus xml, maar zeker ook het protocol soap. Alleen dan is er sprake van enige vrijheid bij onderhoud en vervanging van de diverse onderdelen van het totale systeem.
Om te voorkomen dat legacy-toepassingen allemaal moeten worden verbouwd om hier aan te voldoen, is een integratielaag onmisbaar. Eai-middleware is natuurlijk al langer bekend, maar stierf eind vorige eeuw een roemloze dood. Sinds de introductie van webservices, xml en soap gaat integratiesoftware weer een nieuw leven tegemoet.
Een integratielaag regelt het verbinden en vertalen van diensten in xml, via bijvoorbeeld soap, jms, http, https, smtp, ssl en s/mime. Legacy-systemen kunnen door bijgeleverde adapters toch diensten bieden als webservices in een soa-omgeving.
Traditionele eai-toepassingen van bijvoorbeeld Microsoft, IBM en Vitria zijn opgebouwd volgens de 'centrale hub' methode. Alle informatiestromen gaan door één enkele applicatie en de bijbehorende adapters. Als deze hub nu net uw adapter niet heeft, heeft u een probleem.
Esb-technologie (enterprise service bus) biedt meer flexibiliteit. Esb-systemen van Sonic Software (SonicESB), PolarLake (Jintegrator), Kenamea (Web Messaging Platform) en Spiritsoft (SpiritWave) laten toe dat applicaties boodschappen versturen over een gedeeld netwerk. Dit netwerk is op open standaarden gebaseerd. Is de adapter er bij de ene aanbieder niet, dan heeft de ander deze wel beschikbaar.
Binnen een enkel bedrijf is het meestal prima om met een centrale hub te werken. Als er sprake is van een heel uitgebreide, gedistribueerde architectuur door meerdere bedrijfstakken, platforms en misschien zelfs landen, dan kan esb een nuttig alternatief zijn.
Sander Nagtegaal