De praktijk wijst uit dat binnen SOA projecten veel tijd verloren gaat aan de discussies rondom data. Vragen als “Welke data hebben we nodig?”, “Wat betekent deze dataeigenlijk?” tot aan “Deze data hebben we helemaal niet ter beschikking!” komenmaar al te vaak voor. Sommige organisaties constateren dat zelfs bijna 40% vande kosten van het integreren van nieuwe services (intern/extern) op gaat aandeze vragen. Integratie gaat dus ook zeker over goedeen duidelijke afspraken maken over data.
De oplossing voor bovenstaande problematiek binnen integratie projecten is dus te vinden in het goed overleggen welke data een rol gaat spelen en wat de betekenis ervan is. Het vastleggen van deze aspecten vindt plaats in een Common Data Model (CDM), soms ook Canonical Data Model genoemd. De telecommarkt is hier bijvoorbeeld al heel ver mee, zij beschikken over het SID (Shared Information& Data model) en de gezondheidszorg kent het HL7 RIM model.
Als een CDM dan nog niet bestaat, waar haal je het dan vandaan? De projecten waarbij wij tot nu toe betrokken zijn geweest, hebben de klanten hun model o.a. gehaald uit een bestaande database, Excel-spreadsheet of een UML modelling tool.
Een CDM zorgtvoor het laatste stukje (data)loskoppeling binnen een SOA en zou dus garant moeten staan voor de meest optimale flexibiliteit van een SOA en vormt daarmee een kritisch component.
Mijn constatering is jammer genoeg dat vele SOA/Integratie projecten nog zonder een CDM plaatsvinden. Enerzijds omdat een CDM binnen het project gewoonweg nog niet bestaat. Anderzijds om dat dit gezien wordt als een enorme kostenpost en dit moelijk uit te leggen is naar de business (geldschieter). Maar ook hier geldt net zoals bij SOA, we beginnen met kleine stapjes en laten het CDM meegroeien met de behoefte van de organisatie. Een andere reden voor de afwezigheid van een CDM, is dat de meeste EAI/ESB vendors deze concepten nog niet ondersteunen in hun tooling.
Afsluitend, een SOA heeft een CDM nodig voor succes!
Helemaal mee eens! Naast het modeleren van de data is het ook belangrijk te kijken naar:- beslissingen over de data- de opslag van de data- het transporteren van de dataVoor alledrie de punten geldt dat ze decentraal of centraal opgelost kunnen worden.Zie voor meer informatie http://www.theenterprisearchitect.eu/archive/2007/10/11/data_sharing_in_a_serviceorien (engels)
Ook ik kan mij geheel vinden in de constateringen van Paul. het ontbreken van een goed datamodel is echter in mijn ogen niet zozeer een SOA-gerelateerd issue, al hebben SOA-implementaties er absoluut last van. Het is m.i. één van de generieke vraagstukken binnen systeemontwikkeling: hoe modelleer je je bedrijfsdata en wel zo dat data ook tot informatie (content) gepromoveerd kan worden. Want zonder een goede modellering is goed contentbeheer niet mogelijk. En dit heeft vervoglens weer direct impact op de kwaliteit en het gebruik van informatiesystemen. Je zou m.i. wel kunnen stellen dat SOA hier nog meer last van gaat krijgen, omdat het aantal koppelingen en mate van integratie toeneemt met het aantal services dat op elkaar ingrijpt. En hierdoor ontstaat een toenemend afbreukrisico op betrouwbaarheid en kwaliteit van informatie als deze niet op juiste en eenduidige wijze is vastgelegd, c.q. gemodelleerd. En dat een CDM hiervoor een vereiste is staat niet meer ter discussie…of zou SOA een begin kunnen zijn van een nieuwe wijze van datamodellering in de trant van ‘data als een service’?Oscar Roelofs/ion-ip