‘Enterprise application integration’ en de noodzaak van integratie was eind jaren negentig hét onderwerp voor analistenconferenties en vakbladen. Stroomlijn alle interne bedrijfsprocessen en verbind applicaties realtime met handelspartners. Tegelijkertijd moesten applicaties sneller geïntegreerd worden, met meer flexibiliteit en minder ontwikkelaars, risico’s en kosten. Webservices zouden alles ‘plug-and-play’ maken, maar dat valt in de praktijk tegen.
Bedrijven gingen veel investeren in integratieproducten. De omzet van de leveranciers groeide snel. Van 1996 tot 2000 verdubbelde de omzet elk jaar. Toen webservices als nieuwe ontwikkeling opkwamen droegen analisten en de vakpers integratie-middleware echter vrijwel direct ten grave. Webservices zouden applicaties ‘plug-and-play’ maken. Applicatie-integratie zou daardoor een basisproduct worden. In de praktijk is dit alles nogal voorbarig gebleken. Het zal nog jaren duren voordat de standaarden voor webservices uitgekristalliseerd en volwassen zijn. Bovendien blijft het probleem rond integratie bestaand, ook bij de inzet van webservices.
Standaardisatie
Eén van de redenen waarom bedrijfsapplicaties lastig te integreren zijn, is dat het moeilijk is om ze met elkaar te laten communiceren. Verschillende applicaties zijn op diverse tijdstippen en computers gebouwd met verschillende talen, besturingssystemen, middleware en databases. Slechts een deel maakt gebruik van api’s, die bovendien niet altijd op elkaar afgestemd zijn. Eigenlijk is het dus al geweldig als applicaties data uitwisselen. Standaardisatie is dan ook het uitgangspunt voor webservices. Als alle applicaties standaard interfaces gebruiken, is communicatie niet langer een probleem.
Het nut van standaarden is evident, maar we moeten realistisch blijven. Voor elke succesvolle standaard, zoals tcp/ip, is er minimaal één volledig mislukt, bijvoorbeeld dce. Om te bepalen of webservices als standaard een kans maken, is de ‘scorecard’ een bruikbaar instrument. In dit geval gaan we uit van het CMM (Capability Maturity Model) van het Software Engineering Institute. Dit model is onderverdeeld in vijf niveaus, op basis waarvan it-managers bepalen in welke fase van een groeiproces hun ontwikkelinspanningen zich bevinden. Om dit model op standaarden toe te passen, is het SMM (Standards Maturity Model) in het leven geroepen.
De eerste fase is eenvoudig. Er is een probleem waarvoor alleen maatwerkoplossingen beschikbaar zijn. In de tweede fase werken leveranciers of bedrijven aan de ontwikkeling van een nieuwe standaard. Er zitten echter altijd nog gaten in versie 1.0 van een product. Dat geldt zeker voor vroege versies van een standaard. Ondanks mogelijke hiaten worden de gedefinieerde specificaties van de standaard in de tweede fase wel voorgelegd aan organisaties als W3C of Oasis. Daarbij leveren zowel gebruikers als leveranciers veel input voor de verdere ontwikkeling.
In fase drie komt alles bij elkaar. De standaard wordt een aantal keren herzien. De producten van leveranciers van ontwikkeltools en applicaties gaan de standaard concreet ondersteunen. Vroege gebruikers bouwen ‘proof of concepts’ en sommige avontuurlijke bedrijven nemen producten uit deze fase zelfs in productie. De standaard is uiteindelijk functioneel inzetbaar in de vierde fase. Dit betekent dat bijna alles werkt zoals gepland. De standaard biedt een oplossing voor het oorspronkelijke probleem. Hoewel een standaard nooit perfect is, gebruiken ontwikkelaars hem in veel applicaties. De standaard bereikt de laatste fase als het merendeel van de gebruikte applicaties er echt op gebaseerd zijn.
Dwang
In de praktijk halen de meeste standaarden fase vijf niet. Hoewel iedereen het belang ervan erkent, stappen zowel bedrijven als leveranciers snel over naar een andere veelbelovende standaard. Onderlinge concurrentie speelt daarbij vaak een rol. Standaarden beperken immers het onderscheidend vermogen in de markt. Verder is de acceptatie vaak kostbaar. Zeker in de vijfde fase moeten ook bestaande applicaties en systemen aan de nieuwe standaard worden aangepast.
Succesvolle standaarden zijn doorgaans het resultaat van dwang. Deze dwang heeft verschillende gedaantes. Er is de dwang van regel- en wetgeving. De Hipaa-regelgeving bijvoorbeeld dwingt grotere Amerikaanse gezondheidszorgaanbieders om het standaard b2b-protocol en standaard elektronische documenten te gebruiken voor terugbetaling van ziektekosten. Dwang kan ook komen van een sterke leider in een kanaal. Toen Wall Mart aangaf dat leveranciers as2 moesten gebruiken voor het indienen van facturen, was het overduidelijk wat leveranciers te doen stond.
De derde vorm, economische dwang, is gevarieerder. Een voorbeeld is de ontwikkeling van Rosettanet door een aantal pc-leveranciers. Met dit platform, inclusief communicatieprotocol, regels voor documentuitwisseling en documentcontent standaarden, wilden HP, IBM en Compaq de gehele pc-toeleveringsketen stroomlijnen. Zo wilden ze de concurrentie met Dell aangaan. Dat bedrijf had zijn leiderschap binnen het kanaal ingezet om de toeleveringsketen te stroomlijnen en te koppelen aan het ‘direct naar de consument’-verkoopmodel.
Zinvolle communicatie
Wat betekenen al deze invloedsfactoren voor de webservices standaard op dit moment? Allereerst is er geen sprake van duidelijke dwang tot de acceptatie van webservices. De economie zit in een dip en iedere organisatie wil haar bedrijfsprocessen stroomlijnen. Dit is echter niet bepalend voor een brede en snelle acceptatie van standaarden. Alle standaarden voor webservices bevinden zich op de lagere SMM-niveaus.
De enige aan webservices gerelateerde standaarden die niveau vijf hebben bereikt zijn tcp/ip, http en ssl. Deze standaarden bestonden al vóór de opkomst van webservices. Zelfs XML, de fundamentele standaard voor webservices, bevindt zich nog op het vierde niveau. Andere webservices standaarden, zoals soap, wsdl en uddi, zijn nog volop in ontwikkeling. Zij zitten nog in de derde fase. Uiteindelijk duurt het zeven tot tien jaar voordat ‘plug-and-play’ data-uitwisseling met webservices mogelijk is, ofwel voordat alle webservices standaarden niveau vijf van het SMM bereiken.
Webservices zullen zich blijven ontwikkelen tot de moeilijkheden rondom data-uitwisseling opgelost zijn. Het uitwisselen van informatie tussen applicaties is echter nog geen integratie. Zinvolle communicatie tussen applicaties vereist dat ze dezelfde taal spreken. Java- en .Net-applicaties kunnen aardig gegevens uitwisselen, maar ook dat is nog steeds geen sprake van volledige integratie. De ene applicatie gebruikt bijvoorbeeld ponden en de andere kilogrammen om een gewicht te omschrijven, waardoor er verschillen blijven bestaan. Echte integratie vereist data-uitwisseling via een webservices interface, wat weer vraagt om ‘datamapping’ of transformatiemogelijkheden.
Eén keer leren
Een andere kwestie is dat iedere organisatie werkt met eigen deelprocessen voor de opbouw van de bedrijfsprocessen. Alleen al de interne data-uitwisselingen zijn afzonderlijke integratie-uitdagingen. Daarmee verloopt de interactie tussen twee bedrijven nog lang niet optimaal. Het is beter om deze opeenvolgende interacties te definiëren, te automatiseren, te beheren en te optimaliseren in de context van een compleet bedrijfsproces met verschillende stappen, van offerte tot betaling. Alle tussenstappen vereisen integratie, sommige intern, andere ook extern.
Om b2b-interactie effectief te automatiseren, te monitoren en te beheren moet een gefaseerd bedrijfsproces geïmplementeerd worden onder de paraplu van een bpm-product (business process management). Daarbij moet je beseffen dat niet alle processen via webservices zullen verlopen. Sommige leveranciers of partners zijn te klein of hun diensten lenen zich niet voor deze aanpak. Bovendien kunnen interne wensen de integratiestructuur sterk beïnvloeden.
Een bruikbare integratietoolkit omvat verschillende elementen: ‘messaging’, portaal, adapters, transformatie, b2b-communicatie, beheer van partnerprofielen, procesbeheer en ontwikkeling van werkstromen en gebruikersinterfaces. Zo’n toolkit kan op verschillende manieren samengesteld worden: je koopt verschillende losse producten van even zoveel leveranciers of alle producten bij één leverancier. Financieel gezien is het slim om alles bij één leverancier te kopen.
Je krijgt meer voor hetzelfde geld als je licenties voor verschillende producten bij één partij koopt. Hier valt echter niet de meeste winst behalen. De positieve effecten zijn groter als je kijkt naar de gevolgen voor de ontwikkelkosten. In plaats van zes of zeven verschillende ontwikkelproducten voor de integratie van het ‘offerte tot betaling’-proces hoeven ontwikkelaars maar één toolkit te leren kennen om een volledige oplossing te bouwen. De techneuten hoeven niet zes tot acht verschillende runtime-beheertools te gebruiken om net zoveel runtime-omgevingen te optimaliseren; er is maar één tool nodig voor beheer en optimalisatie van één omgeving.
Hergebruik
In plaats van de foutgevoelige handmatige activiteiten rondom configuratiebeheer en impactanalyses kunnen ontwikkelaars deze taken ook via een toolkit uitvoeren. Door de inzet van een soa (service oriented architecture) zijn componenten opnieuw te gebruiken. Het is eenvoudiger om een herbruikbare component te vinden dan om een volledig nieuwe te schrijven. Dit wordt vergemakkelijkt door alle integratie- en ontwikkelcomponenten binnen een ontwikkelomgeving zichtbaar te maken.
Verder biedt een geïntegreerde integratietoolkit voordelen tijdens de inzet en in runtime. Eén beveiligingsnetwerk vereenvoudigt de implementatie van beveiliging op gebruikers- en berichtenniveau. Verder geldt dat een runtime-beheerraamwerk de kosten voor de installatie en inzet van integratie-oplossingen en samengestelde componenten verlaagt. Dit raamwerk vermindert ook de inspanningen en kosten voor beheer, monitoring en optimalisatie.
Dat diverse integratieonderdelen van dezelfde leverancier komen, betekent echter lang niet altijd dat ze echt met elkaar geïntegreerd zijn. Sommige leveranciers leveren toolkits die bestaan uit producten die aangekocht zijn of die ze alleen wederverkopen. Leveranciers kunnen de toolkits wel dezelfde naam geven, bijvoorbeeld Bigkit, PBM, Bigkit Messaging of Bigkit Business Integration, maar dit is geen garantie dat deze producten ook echt geïntegreerd samenwerken. In het slechtste geval ben je dan dus de integratietools aan het integreren. Dat vergroot het oorspronkelijk probleem: afzonderlijke technologieën laten samenwerken. Het ‘integreren van integratietools’ mag misschien een grappige uitdrukking zijn, in de praktijk is het met het oog op tijd, kosten en risico’s helemaal geen grap.< BR>
Ross Altman, chief technology officer Seebeyond
