Hou zou u het vinden als er drie architecten, onafhankelijk van elkaar, aan het ontwerp van uw huis werken? De ene ontwerpt het fundament, de andere het huis en de derde is verantwoordelijk voor het dak. Let wel, ze ontwerpen zonder van elkaars plannen af te weten. Hoe denkt u dat uw huis er gaat uitzien?
U kunt het wel raden. Waarschijnlijk zal het huis niet aansluiten op het fundament, want de ene architect heeft een fundament ontworpen voor een flatgebouw, terwijl de ander een tekening heeft gemaakt voor een bungalow. Tevens zal het dak te groot of te klein zijn en ongetwijfeld zullen er nog veel meer zaken niet ‘passen’. De ongelukkige bouwer die de opdracht krijgt dit huis te bouwen, zal veel tijd moeten steken in het aan elkaar ‘plakken’ van deze creatieve ideeën.
Hoe zou u dit vinden als het uw geld is? Geïnteresseerd? Waarschijnlijk niet. U kunt zich niet eens voorstellen dat dit ooit zou gebeuren. Dit is echter wel de wijze waarop we vandaag de dag de meeste moderne informatiesystemen in elkaar zetten. Laat ik dit toelichten.
Een doorsnee applicatie bestaat voornamelijk uit drie aspecten: gegevensverwerking, gegevensopslag en gegevensuitwisseling. In de wereld van gegevensverwerking zijn de objectgeoriënteerde (oo) concepten dominant aanwezig. Een moderne ontwikkeltaal dient de oo-concepten te ondersteunen. Met andere woorden, gegevensverwerking verloopt volgens het oo-gegevensmodel.
Voor gegevensopslag is het relationeel gegevensmodel (in de vorm van SQL) commercieel nog steeds de meest succesvolle. Er bestaan wel databaseservers die uitgaan van andere modellen, maar de meest geïnstalleerde zijn toch op SQL gebaseerd.
En voor gegevensuitwisseling hebben we nu XML (eXtensible Markup Language) gekozen, dat een hiërarchisch gegevensmodel heeft.
(Trouwens, we laten nu voor het gemak gegevenspresentatie buiten beschouwing, de code die de gegevens op het scherm en op papier zet.)
Op alle drie de gegevensmodellen, zowel obkectgeoriënteerd als relationeel en XML, is wel kritiek te leveren, maar in principe is voor alledrie afzonderlijk wat te zeggen. Het vervelende is alleen dat ze niet bij elkaar passen, want de wederzijdse concepten zijn niet op elkaar afgestemd. De hiërarchische concepten van, bijvoorbeeld, XML zijn niet één-op-één te transformeren naar relationele equivalenten en de oo-concepten kunnen we niet eenvoudig naar XML vertalen. We hebben te maken met drie niet op elkaar afgestemde gegevensmodellen. Erg handig!
Het betekent dat een programmeur die een oo-programmeertaal (voor gegevensverwerking) en SQL (voor gegevensopslag) gebruikt, veel code moet schrijven om de oo-concepten die binnen zijn programma gecreëerd zijn, te vertalen naar SQL-concepten voordat ze opgeslagen kunnen worden. Ook moet code ontwikkeld worden voor het vertalen van uit de database opgehaalde gegevens naar de wereld van object-oriëntatie.
Een ander voorbeeld betreft de komst van XML voor gegevensuitwisseling. Een hele horde programmeurs is begonnen met het schrijven van code voor het vertalen van XML-documenten naar relationele concepten en andersom.
De historie leert ons dat we meestal niet zo succesvol zijn met die vertaalslagen. Bijvoorbeeld, een aantal leveranciers van relationele databaseservers hebben enkele jaren geleden getracht de vertaalslag naar de oo-wereld te verkleinen door SQL met vergelijkbare concepten uit te breiden. Afgezien van de kwaliteit van hun exercitie was het een commerciële flop, want bijna niemand gebruikt ze. Leveranciers van post-relationele databaseservers (met bijvoorbeeld een hiërarchisch model) hebben getracht relationele lagen op hun systemen te implementeren. Nooit een succes geworden.
Een vertaling impliceert bijna altijd dat niet alle concepten vertaald kunnen worden, met als effect dat ontwikkelaars zich moeten beperken tot de vertaalbare concepten. Hiermee halen we nooit de volledige kracht uit een bepaald gegevensmodel.
Het ontwerpen en ontwikkelen van deze vertaalslagen (zes in totaal) heeft ook niets te maken met bedrijfslogica. Met deze vertaalslagen verkoopt een verzekeringsmaatschappij niet één polis extra of een oliemaatschappij meer benzine. Het is een puur technologisch probleem dat opgelost moet worden.
Bij de ontwikkeling van oo-talen is nooit nagedacht hoe ze ooit geïntegreerd zouden moeten worden met SQL. Het is alsof de ontwerpers dachten dat dat nooit zou gebeuren. En bij de wat recentere ontwikkeling van XML is nooit rekening gehouden met de opslag ervan in SQL-databases.
Een veel betere situatie zou geweest zijn dat de drie modellen op elkaar afgestemd waren. We zitten nu helaas met deze erfenis en we moeten realistisch zijn en niet denken dat we deze extreme vorm van suboptimalisatie zomaar kunnen terugdraaien. De kans dat we op de korte termijn één gegevensmodel voor gegevensverwerking, -opslag en uitwisseling hebben, schat ik zeer klein in.
Het is weer een mooi voorbeeld van de status waarin de informaticawereld zich bevindt: iedereen leeft op zijn eigen eiland, beschermt die met hand en tand en heeft de arrogante verwachting dat iemand anders wel de bruggen zal maken. In ieder geval houdt het de ontwerpers en programmeurs wel uit het café. Misschien was dat wel de achterliggende gedachte. Een andere kan ik niet bedenken.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
Pluim: Rick van der Lans kan heel toegankelijk knelpunten aangegeven waar IT ontwikkelingen op elkaar aansluiten, of dus niet. Hier XML (hierarchisch) en XML (relationeel). Mooie bijsluiter bij een rapport.