Soa is geen lapmiddel

Met gekromde tenen las ik de column 'Het datapakhuis en de soa' (Computable, 21 mei 2004) van Van der Lans. Ik ben het niet eens met zijn betoog over datapakhuizen en de soa (service oriented architecture). Volgens mij zijn het twee werelden die niet alleen Van der Lans maar ook veel leveranciers 'aan elkaar proberen te knopen'. Vanzelfsprekend, want hiermee boren we nieuwe markten aan; er zijn aanzienlijke bedragen mee gemoeid voor zowel it als consultancy. Echter, noch de klanten noch de markt vragen hierom.

Op één hoop

Wanneer ik Van der Lans' betoog zorgvuldig analyseer, kan ik niet anders dan constateren dat hij verschillende onafhankelijke problemen op een hoop heeft geveegd. Datakwaliteit: is een datapakhuis het spiegelbeeld van de datakwaliteit van de bronsystemen of een verbetering hiervan? Architectuur: is een datapakhuis een voor de soa geschikt informatiesysteem? Organisatie: waarom zijn veel organisaties niet of onvoldoende in staat om informatiesystemen betrouwbaar te ontwikkelen, te beheren en te onderhouden?
Ik vind het niet netjes om deze zaken op een hoop te gooien; het geeft een vertekend beeld en je bereikt er niets mee. Wat betreft datakwaliteit: je moet niet roomser dan de paus willen zijn. Ten eerste moet je inzichtelijk maken welke problemen er zijn en moet je deze niet wegpoetsen. Ten tweede kent een datapakhuis vaak geen of juist veel eigenaars: wie bepaalt welke data erin komt en hoe data mag worden gecorrigeerd? Ten derde, op het moment dat je andere data toont dat de bron(nen), wie heeft er dan gelijk?
Wat betreft architectuur: ik heb al moeite met de eerste regel van Van der Lans' column. Volgens mij is een datapakhuis nog steeds bedoeld voor de ondersteuning van beslissingsprocessen. Nagenoeg alle datapakhuizen waar ik mee te maken heb worden gebruikt om maandelijkse cycli mee te kunnen bedienen. Sommige streven al naar wekelijks. Dagvers is voor de meeste nog ver weg. Wanneer services worden geïntroduceerd om informatie op te vragen, hebben we het ineens over een geheel ander informatiesysteem; services zijn vaak synoniem met tijdigheid ofwel (bijna) realtime. Een (cluster van) 'operational data store(s)' (wellicht is bronkopieën een goede Nederlandse vertaling) is hier geschikt voor; we moeten het datapakhuis met rust laten.
Wat betreft de organisatie: verreweg het grootste probleem in een organisatie die it toepast is de organisatie zelf. Primaire systemen kennen een duidelijke eigenaar met duidelijke verantwoordelijkheden, een enorm belang, allerlei it-wensen, zelfs privileges. Gemiddeld delft de it-organisatie, zeker dat deel dat een datapakhuis beheert, het onderspit, want problemen worden af- of doorgeschoven naar de zwakste schakel. Ik ben in ieder geval nog geen datapakhuis of it-organisatie tegengekomen die het beleid 'tot aan de voordeur en niet verder' kan voeren. Het is vaak slikken of stikken. Het is wel nuttig om met behulp van de soa controles en beperkingen generiek als service te ontwikkelen, zodat je deze niet telkens bij de ontwikkeling van een nieuwe informatiesysteem opnieuw moet uitvinden.

Miskend

Het probleem van de datakwaliteit moet bij de oorzaak van het probleem worden aangepakt: de bron. Een datapakhuis is een afspiegeling van de datakwaliteit in de informatiesystemen van de organisatie. Datakwaliteit is feitelijk slechts een onderdeel van datamanagement, wat in zijn geheel vaak een (miskend) probleem is. In datapakhuisland merken we dit soort problemen nu eenmaal op.
Het probleem van de datapakhuisarchitectuur is triviaal. Een datapakhuis is functioneel in principe niet te verenigen met de soa. Hiervoor kan je andere informatiesystemen bedenken die veel geschikter zijn, zoals de bronkopieën. Overigens, technisch gezien kunnen het datapakhuis en de soa dezelfde infrastructuur gebruiken, maar functioneel zullen we in combinatie met het datapakhuis geen services aanbieden aan derden.
Het probleem van de organisatie ligt complexer. Elke organisatie die over een datapakhuis beschikt of gaat beschikken, moet zich ervan bewust zijn dat ze een duidelijk organisatie- en beleidsmodel moet implementeren waarin verantwoordelijkheden, bevoegdheden, eigenaarschap, vruchtgebruik, strategie en beleid expliciet en eenduidig worden vastgesteld.
Voor externe data moet je intern een bron definiëren. Eén afdeling is verantwoordelijk voor contacten, aanlevering en interfaces met de externe bron. Dit doet de datapakhuisomgeving niet zelf. Indien de gegevens voor meerdere afnemers in de onderneming wenselijk zijn, kan besloten worden dat de 'interne bron' met behulp van de soa wordt ontsloten. Dit heeft niets met het datapakhuis te maken, dat kan gewoon nog steeds een (incrementele) dump ontvangen.

Opvoeden

Zoals Van der Lans zelf terecht concludeert zijn verreweg de meeste datapakhuizen 'er nog lang niet aan toe' om met behulp van soa continu diensten te verlenen. De kosten die je moet maken om aan de datapakhuiszijde services te bieden zijn aanzienlijk hoger dan de toegevoegde waarde daarvan.
Anders is het gesteld met de kosten die je moet maken om de bronsystemen dusdanig te verbeteren dat deze wel de minimale (data)kwaliteit leveren om toegelaten te worden aan de datapakhuiskant. Mochten er informatiesystemen ('bron') zijn die moeite hebben om aan deze kwaliteit te voldoen, dan heb je drie mogelijkheden: herbouw van het betreffende informatiesysteem (dan maar meteen inclusief component-gebaseerd en soa); aanpassing van het betreffende informatiesysteem, door er een voorportaal voor te plaatsen - de intermediair tussen bron en datapakhuis; of tussenvoegen van een of meer bronkopieën tussen de bronnen en het datapakhuis. Ik spreek geen voorkeur uit; het is geheel afhankelijk van de situatie. In ieder geval is het niet de bedoeling om het datapakhuis in combinatie met soa als lapmiddelen te gebruiken voor datakwaliteit.
Concluderend: het toepassingsgebied van een datapakhuis is nog steeds primair het ondersteunen van beslissingsprocessen. Wanneer een datapakhuis met behulp van services bijna realtime continu wordt ontsloten, hebben we beslist te maken met een ander soort informatiesysteem. Een datapakhuis zou ik het dan zeker niet willen noemen. Ik denk dat hier feitelijk het opvoeden begint.6

 
Martin Misseyer, Ordina VisionWorks