Stoppen met Zaniken

In een recente post op het weblog “Between the Lines”, met de intrigerende titel “IT as Whiners – the great debate”, attendeerde Larry Dignan me op de discussie die Patrick Gray heeft aangezwengeld. Zijn ietwat provocerende post “Note to IT: Stop whining” heeft al heel wat stof doen opwaaien in de blogosfeer. Een groot deel van de IT-taken zijn nou eenmaal ondankbaar werk waarin niemand geïnteresseerd is, althans zolang het maar gewoon goed gaat. Tegelijkertijd zijn er veel vakgenoten die IT zien als een cruciale factor in de bedrijfsvoering die schromelijk wordt ondergewaardeerd door ondankbare en onverantwoordelijke leiders in organisaties – lees de reacties op de post van Patrick Gray er maar op na. Wie heeft er gelijk? En welke van de twee redeneringen kunnen we afdoen als

Flauwekul?

Er is iets bijzonders met de IT functie in organisaties. Het is een functie met twee gezichten. Het ene gezicht is dat van de loodgieter. Het gezicht van de serverruimtes met tevreden snorrende machines en kasten met switches. Het is een bij uitstek infrastructurele functie die vraagt om toegewijde system engineers en zorgvuldige beheerders. Het is een functie waarvan al velen hebben voorspeld dat die zich bij uitstek leent om op te schalen en te centraliseren. Het is een functie die niet voor niets een “service center” wordt genoemd.

De analogie met de elektriciteitsbranche is in de loop van de jaren al tot vervelens toe getrokken. In het begin had iedere fabriek die van stoom overging op elektriciteit zijn eigen opwekking georganiseerd – er was tenslotte ook geen openbaar stoomnetwerk waarvan gebruik gemaakt kon worden – maar toen de elektriciteitsnetwerken opkwamen en voldoende betrouwbaar werden kwamen er al snel veel goedkopere, gespecialiseerde, gecentraliseerde fabrieken voor in de plaats. Talloze visionairs hebben de IT-functie binnen bedrijven een zelfde toekomst voorspeld – zeker sinds de opkomst van het internet als betrouwbaar en alom beschikbaar informatienetwerk. Er is immers geen technische beperking meer om gebruik te gaan maken van veel efficiëntere centrale voorzieningen? [1]

De IT-functie heeft echter ook dat andere gezicht. Het gezicht van innovatie en vernieuwing van de bedrijfsvoering, Het gezicht van het verhogen van de productiviteit en het vergroten van de concurrentiekracht. Het gezicht van het samen bouwen aan een betere toekomst. Dat gezicht dat de meeste archITecten zo lief is vraagt om een fundamenteel andere benadering dan de nutsvoorziening. Dat gezicht vraagt om een hechte verankering van de IT functie in de strategie van een organisatie. En daar speelt een heel andere dynamiek. Daar is het zaak om innovatie te voeden met technologie. En dan is het ook nodig om tijdig nieuwe technologie te zaaien en tot wasdom te brengen zodat er geoogst kan worden als de tijd rijp is. En het spel van de goede technologie op het juiste moment zaaien vraagt een heel andere benadering dan die je van een “service provider” mag verwachten. [2]

Stroom is gewoon stroom, maar IT is als het goed is meer dan alleen maar een betrouwbare informatiestroom. En die meerwaarde komt meestal niet toevallig tot stand. “De IT” is in zekere zin een samenvoeging van een informatielaboratorium en een informatiefabriek (wie herinnert zich nog de kreet “electronic data processing”?). Het is op de keper beschouwd niet echt logisch om die twee functies in één organisatieonderdeel onder te brengen. Het is wat mij betreft zelfs onlogisch om op twee zulke uiteenlopende verantwoordelijkheden één label te plakken, IT. Ik zie dan ook weinig toekomst voor de IT-as-we-know-it; de IT als holistische eenheid van nutsvoorziening en strategic differentiator. De toekomst zal leren hoe zich dat gaat ontwikkelen.

De uitdaging voor de architect

Het begrip alignment is anno 2008 volstrekt achterhaald. Het is zoooh nineties. Alignment betekent dat Business en IT liefst in hetzelfde tempo in dezelfde richting moeten marcheren. Dûh. Dat is na tien jaar Landelijk Architectuur Congres toch al lang een vanzelfsprekendheid, nietwaar? We zijn er toch zo langzamerhand wel eens aan toe dat we echt samen optrekken, samen lachen, samen huilen en eindelijk eens stoppen met structureel over elkaar te zaniken.

Het leveren van IT services is zo langzamerhand business as usual en kan in principe als een utility afgenomen worden. Het tegenargument dat de beschikbaarheid van IT-diensten tegenwoordig zo cruciaal is voor het functioneren van een bedrijf dat het niet aan derden kan worden overgelaten is daarbij niet erg relevant. Datzelfde geldt immers ook voor de telefoon, de elektriciteit en de staatsveiligheid. Gewoon je werk foutloos doen is bij al dat soort zaken de minimumnorm en hoewel iedereen begrijpt dat zulke werkzaamheden geld kosten beleeft niemand vreugde aan het betalen van de rekening. Pech. Je kunt het een ondankbare taak noemen, en zo voelt het misschien ook vaak, maar dan is ook goed om er even bij stil te staan wanneer je zelf voor het laatst van dankbaarheid hebt getuigd dat je een telefoonverbinding kreeg toen je iemand wilde bellen of toen er gewoon benzine uit de pomp kwam. Een nieuwe auto kopen is leuk, benzine tanken is een noodzakelijk kwaad en betalen voor een noodzakelijk kwaad stemt doorgaans niet tot overdreven dankbaarheid. Het heeft totaal geen zin om erover te zaniken, zo zitten mensen nou eenmaal in elkaar.

Voor dat andere onderdeel van de IT-functie, het ontwikkelen van nieuwe toepassingen, ligt dat een slag genuanceerder. Zeker, ook hier wordt veel te veel gezanikt. Denk maar aan al die IT-ers die zich beklagen over de kwaliteit van de requirements waarmee ze moeten werken, en niet de fun willen inzien van het ontwikkelen in onzekerheid. De soms autistische zucht naar zekerheden die in de praktijk nou eenmaal niet bestaan roept op zijn beurt weer allerlei irritaties op en voor je het weet is ook hier het gezanik niet van de lucht. Bijzonder spijtig, want de wereld verandert nou eenmaal, de omstandigheden veranderen continue, inzichten veranderen van tijd tot tijd – dat is gewoon een fact of life. Het is dan ook betrekkelijk zonde van je energie om op zoek te gaan naar een schuldige, laat staan om je beklag daarover te doen.

Ik heb het gevoel dat archITecten, juist als ze door 'de business' als waardevolle partner gezien willen worden, zich moeten bewijzen in onzekere omstandigheden. Dat ze het lef moeten hebben om te participeren in samenwerkingsstructuren waarin er vanuit verschillende disciplines maar onder een gedeelde verantwoordelijk wordt gewerkt. Noem het bijvoorbeeld een innovatiestudio. Maar vermijd in elk geval het stigma IT.

Wat onze discipline nodig heeft is een symbiose tussen “de business” en “de IT”, althans dat gedeelte van “de IT” dat intiem met “de business” zou moeten zijn. Dat zou naar mijn smaak veel beter beschrijven wat er nodig is, dan het sleets geworden begrip alignment. Architecten zouden daar als erkende bruggenbouwers bij uitstek een rol in kunnen spelen. Het bieden van een gezonde voedingsbodem voor innovatie hoeft geen ondankbare missie te zijn. Maar het vereist wel meer dan alleen wederzijds respect. Het vereist teamwork.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 7^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.

[1] Zie bijvoorbeeld: Nicholas Carr: “The End of Corporate Computing”; MIT Sloan Management Review, Spring 2005.
[2] Zie bijvoorbeeld: Don Tapscott: “The Engine That Drives Success”; CIO Magazine, May 2004.

Think Better

Nederland compromisland. Het is misschien wel het cultuuraspect dat ons het meest onderscheidt van andere Westerse landen. We hebben de neiging om ieder conflict uit te polderen totdat iedereen zich bij een voorstel neer kan leggen. Andere landen doen dat vaak anders. In plaats van tijdrovende overlegstructuren wordt er een machtsspelletje gespeeld en bepaalt de winnaar wat er wel of niet gebeurt. In beide gevallen zijn er meer verliezers dan winnaars. Volgens Steven Covey zou dan fundamenteel anders moeten. We zouden moeten streven naar oplossingen met alleen maar winnaars. Een droom van een wereldvreemde idealist? Of een wegwijzer naar productief denken?

Think “Win-Win”

Stephen Covey – volgens Ben Tiggelaar één van de tien meest invloedrijke management denkers aller tijden – is waarschijnlijk het bekendst van zijn populaire boek de “The 7 Habits of Highly Effective People” [1]. Eén van die effectieve habits is het uitgaan van “Win-Win”-oplossingen. Als enterprise architect prikkelt dat op z'n minst mijn nieuwsgierigheid. Maar al te vaak betekent het rekening houden met allerhande concerns van verschillende stakeholders in de praktijk dat er uiteindelijk vage compromissen gesloten worden – maar al te vaak een geval van “Loose-Loose” – of dat één van de stakeholders zijn macht gebruikt om zijn zin door te drukken – een typische “Win-Loose”-oplossing. Oké, er is een oplossing, maar de kans is aanwezig dat het verlies dat de andere stakeholders hebben geleden zich vroeger of later tegen de “winnaar” gaat keren.

Covey leert dat dit helemaal niet zo hoeft te zijn. Als je écht goed luistert naar alle stakeholders, als je je verdiept in hun ware beweegredenen, als je als het ware in de huid van de stakeholders kruipt, dan lukt het eigenlijk altijd om een superieure oplossing te bedenken die voor alle partijen goed uitwerkt. Als je maar met een positieve mindset naar het probleem kijkt. Zou het nou niet mooi zijn als alle archITecten op zo'n manier zouden denken en werken?

Neem nou het probleem van het broeikaseffect. Dat is bepaald een ingewikkeld probleem met vele facetten. Het is bekend dat runderen, via de methaangassen die ze produceren, voor een aanzienlijk deel aan het broeikaseffect bijdragen. Deze bijdrage vormt een groeiend probleem – vooral ook vanwege de groeiende wereldbevolking en omdat de nieuw verworven welvaart in de opkomende economieën de vraag naar vlees en melkproducten omhoog stuwt. Nou zou je natuurlijk kunnen voorstellen om het vlees te rantsoeneren – het al dan niet op basis van vrijwilligheid verminderen van de vraag. Maar dat is een typische Win-Lose oplossing. Het komt het milieu ten goede – en dus indirect ook aan de mensheid – maar het vraagt wel een zeker offer van de carnivore medemens.

Er wordt ook aan een technologische oplossing gewerkt. Die houdt in dat alle dieren voortaan hun hele leven op stal moeten blijven en dat de methaangassen met behulp van nieuwe technische hulpmiddelen uitgefilterd moeten worden uit de lucht die de stal verlaat. De hoop is dat de meerkosten van het isoleren van de stallen en het scheiden van het methaangas gecompenseerd kunnen worden door het verkopen van het biogas. Er wordt dan uiteindelijk wel CO₂ geproduceerd, maar dat geldt toch als duurzaam (het komt immers indirect uit het gras dat de koeien eten – en dat heeft het CO₂ weer direct uit de lucht gehaald) en CO₂ is bovendien een aanzienlijk minder potent broeikasgas dan methaan. Het grote voordeel van deze oplossing is dat het milieuprobleem wordt aangepakt. Tegelijkertijd kunt je jezelf afvragen of het vanuit het oogpunt van dierenwelzijn wel zo verantwoord is. Bovendien, al die lege weiden zijn landschappelijk gezien niet bepaald fraai. Dus ook dit geen Win-Win-oplossing zoals Covey dat propageert.

Er zit nog een mogelijke oplossing in de pijplijn. Wetenschappers zijn namelijk bezig om vlees – of in elk geval iets dat er sterk op lijkt – in een laboratorium te gaan produceren. Het gaat om gekweekte weefsels, waar geen dier aan te pas komt. Kweekvlees. Reageerbuisworst. Hartstikke diervriendelijk, dat neem ik tenminste aan, maar het roept bij 'het publiek' wel allerlei 'emoties' op. Wetenschappers zelf noemen het proces tissue engineering [2] en ook dat klinkt niet bepaald haute cuisine. Het schijnt dat het op laboratoriumschaal al behoorlijk begint te lukken om een eetbare worst te draaien, maar het is op dit moment nog te vroeg om te kunnen voorspellen of het proces betaalbaar op te schalen is en of consumenten vrijwillig bereid zullen zijn om hun natuurlijke labje (oops: lapje) vlees ervoor in te ruilen. Dus dit alternatief lijkt in elk geval op korte termijn nog geen haalbare kaart.

Wat dan wel? Gewoon afwachten tot er zich een nieuwe oplossing aandient? Of gaat de wal dan het schip keren? Hoe lang kan het milieu de groeiende belasting nog aan? Zouden we toch moeten streven naar een Win-Win oplossingen die we op korte termijn kunnen inzetten? Maar bestaat er wel een Win-Win oplossing voor zo'n ingewikkeld probleem? Moeten we er ons niet gewoon bij neerleggen dat er voor sommige problemen geen echt bevredigende oplossingen bestaan? Maar Covey heeft ons toch voorgehouden dat er als je maar goed luistert en nadenkt altijd wel een Win-Win oplossing te bedenken is?

'Down under' hebben ze een origineel idee ontwikkeld. Zij hebben bedacht dat niet alle dieren die als vlees kunnen dienen methaan als bijproduct produceren. Dat is typisch iets van herkauwers. Australië heeft kangoeroes. Die zijn smakelijk, voedzaam en komen in grote hoeveelheden voor. Ze zijn bovendien heel makkelijk in de kost. Er is maar één klein probleempje. Ze laten zich niet zo makkelijk als vee houden. Ze springen namelijk nogal makkelijk weg, dus daar moet nog iets op bedacht worden. Maar verder zijn het gewoon ideale vleesbronnen. Dat ik daar zelf niet opgekomen ben... De hoogste tijd dus, om al die schapenweilanden om te ploegen en her in te richten voor grootschalige kangoeroefarms. Daar kan toch geen zinnig mens iets op tegen hebben? Dat is toch zeker en vast een “Win-Win”-oplossing?

Gedachtenvoedsel

Architecten hebben voortdurend te maken met het zoeken van een optimale oplossing voor een ingewikkeld probleem met vele facetten en vaak tegenstrijdige belangen. Dat is hun core business. Het leerzame van de spiegel die Covey ons voorhoudt is dat we niet onmiddellijk genoegen te nemen met de eisen zoals die worden geformuleerd door de stakeholders, maar ons moeten verdiepen in de achterliggende beweegredenen om erachter te komen wat iemand drijft. Want pas dan kunnen we een oplossing bedenken die alle stakeholders kan overtuigen. Ik vind dat een fascinerende gedachte. Stakeholders hebben altijd ergens een gemeenschappelijk belang. Een vleeseter wil ook een leefbare wereld aan zijn kinderen nalaten. En een Chief Security Officer is er zeker ook bij gebaat dat zijn organisatie blijft bestaan. Een goed beheerst beveiligingsrisico kan dus ook voor hem een betere optie zijn dan een maximaal beveiligde oplossing die de exploitatiekosten zodanig opdrijft dat zijn bedrijf niet meer concurrerend kan opereren.

De cruciale vraag is natuurlijk hoe je tot creatieve, innovatieve Win-Win-oplossingen komt. Hoe bedenk je iets nieuws, orgineels, baanbrekends dat bovendien overtuigt? Je kunt je wel trainen om beter te worden in luisteren naar stakeholders, maar daarmee alleen ben je er nog niet.

Ik heb een suggestie die je hierbij zou kunnen helpen. Het bedenken van creatieve oplossingen voor ingewikkelde problemen is namelijk het thema van het boek “Think Better” [3]. Hierin beschrijft Tim Hurson een aanpak voor “productive thinking”. Dit is volgens hem een “skill anyone can learn”. Het draait om brainstormen, maar dan wel op een goede manier. Hij noemt dat “Blowing your mind with ideas”.

Het “productive thinking model” wordt in dit boek uitgebreid beschreven als krachtig hulpmiddel voor het ontwikkelen van goede ideeën. Het model onderscheidt 6 stappen:

1. What's Going on?

2. What's Success?

3. What's the Question?

4. Generate Answers

5. Forge the Solution

6. Align Resources

Merk op dat de helft van de stappen over de probleemstelling gaat. Dat is geen toeval. Hurson haalt Peter Drucker aan (nog zo eentje uit de top-10 van Ben Tiggelaar) om dat te onderstrepen:

“The most serious mistakes are not being made as a result of wrong answers. The truly dangerous thing is asking the wrong question.”

Het boek is meeslepend geschreven en staat vol concrete en praktische tips en “food for thought”. Het heeft dan ook alles in zich om een klassieker te worden.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 11de in een reeks die op dit weblog gepubliceerd zal worden.

[1] Stephen Covey: “The 7 Habits of Highly Effective People”. Free Press, 1989.
[2] Liesbeth Koenen: “Jonge Akademielid dr. Carlijn Bouten - ‘Straks ben ik de eerste moeder die kan zeggen: ja, vlees komt uit de fabriek’”. KNAW, Akademie Nieuws, april 2005.
[3] Tim Hurson: “Think Better – An Innovator's Guide to Productive Thinking”. McGraw-Hill, 2008.

Retro-architectuur

Wanneer wordt uw legacysysteem antiek? Zou het dan een collectors item zijn? Kun je daar als architect anno 2008 misschien nog wat van leren? Het moet wel een goed systeem zijn, anders had het tenslotte nooit de status van legacy bereikt. Verdient het misschien vanuit een cultureel perspectief zelfs wel bescherming? Bestaat er überhaupt zoiets als cultureel erf-eh-'ware'?

Common Sense

De vraag naar de bescherming van klassieke informatiesystemen is serieuzer dan hij misschien op het eerste gezicht lijkt. Volgens een oproep op Via Nova Architectura gaat het NK ICT Architectuur dit jaar een poging doen om architectuurbeschrijvingen van oudere IT-systemen te beoordelen. Kennelijk is de gedachte dat vroeger alles niet per definitie slechter was dan vandaag. Dat we als architecten best iets kunnen leren van de inzichten van onze voorgangers – of uit onze jeugd, for that matter. Een sympathieke gedachte, toch?

Dat zou wel eens het begin van een trend kunnen zijn. Een trend van hernieuwde belangstelling voor architectuurprincipes uit de IT-oudheid. Voor je het weet wordt dit misschien wel een serieuze stroming in de IT architectuur – het virtueel classicisme. Binnen de korste keren raakt de post-moderne iPhone weer achterhaald en gaan we massaal terug naar de pure schoonheid van terminals. Rust en stilte als de essentie van het schone [1]. Retro-architectuur als nieuwste hype.

Het is goed om er eens over na te denken wat voor waardevols het verleden heeft opgeleverd. Valt er nog pure kunst te ontdekken tussen de legacy en de overige kitsch? Waar gaan uw gedachten dan in eerste instantie naar uit? Het goede oude Wordperfect 4.2 misschien? Of de Apple Macintosh Classic? Of denkt u juist aan SAP v2? Het legendarische Wang Computer System? Leisure Suit Larry in the Land of the Lounge Lizards? Of toch nog eerder VMS?

Het zijn stuk voor stuk voorbeelden van in die tijd baanbrekende, en dus voorbeeldige computertoepassingen. Er zijn ongetwijfeld nog zat voorbeelden aan toe te voegen. En toch... toch overheerst bij zo'n revival bij mij vooral het gevoel van sentimentele, nostalgische

Flauwekul!

Er zijn zonder twijfel oude softwaresystemen die het goed zouden doen als curiosa in een techniekmuseum. Echter, zulke systemen waren oorspronkelijk nooit bedoeld om te bewonderen, ze waren er eerst en vooral om te gebruiken! En het is de vraag of de gebruiker van vandaag de dag nog uit de voeten zou kunnen met de oplossingen van destijds. Hoe krijg je Google Earth bijvoorbeeld voor elkaar op een monochrome tekstterminal?

Er is al lange tijd veel belangstelling voor primitieve kunst en oude architectuur. Vertaald in onze context zou je voor primitieve architectuur misschien moeten teruggrijpen op de situatie van – zeg – de tijd van voor Windows95. Als je daar serieus aan terugdenkt, de terminals en de primitieve PC-applicaties, dan komt bij mij toch eerst en vooral de kwalificatie 'oogkleppenarchitectuur' op. Denk maar even mee. Destijds was het ´normaal´ dat iedere PC-applicatie zijn eigen drivers meeleverde. Kocht je een nieuwe printer, dan had je met de orginele installatiediskette(!) en enig geluk de nieuwe printer na enige tijd aan de praat. En dat voor iedere applicatie apart. Het was ook volstrekt normaal dat iedere applicatie-ontwerper zijn geheel eigen keuzes voor het indelen van de functietoetsen had gemaakt. Gebruikte je meer dan één applicatie, dan moest je voortdurend omschakelen. Sterker nog, als je een terminalapplicatie gebruikte, dan had je kans op een andere toetsenbordindeling dan bij een PC-applicatie. Zelfs de tekenset was nog niet gestandaardiseerd. Het was feitelijk één grote chaos. Het is niet voor niets dat de cost of ownership op een gegeven moment helemaal uit de hand liep.

Tegenwoordig denken we liever in platformen – of het nou om een games console gaat, of om de iPhone, het concurrerende LiMo, of simpelweg om Java of Windows. Platformen bieden standaard services en hebben veel van de functies van traditionele applicaties overgenomen en gestandaardiseerd. Platformen hebben het grote voordeel dat ze de gebruiker en de beheerder consistentie bieden over applicaties heen. Dat maakt ze goedkoper en gebruikersvriendelijke. En omdat platformen steeds rijker worden, wordt het ook makkelijker om in korte tijd krachtige applicaties te ontwikkelen. Kijk maar naar de stortvloed aan applicaties die in enkele weken tijd voor de iPhone is uitgebracht.

Gegeven de middelen die moderne archITecten ter beschikking staan – van technische aspecten als geheugencapaciteit, bandbreedte, processorsnelheid en opslagcapaciteit tot zaken als het internet als universele communicatieinfrastructuur en de rijke frameworks voor het snel ontwikkelen van indrukwekkende applicaties – is het niet meer dan logisch dat er vandaag de dag heel andere architectuurkeuzes worden gemaakt dan vroeger. Er kunnen tegenwoordig dingen die vroeger domweg ondenkbaar waren. Monochrome terminals waren geen architectuurkeuze, kleurenschermen waren simpelweg te duur – laat staan dat er rekening werd gehouden met het gebruik van touchschermen. Internet stond op z´n best in de kinderschoenen en het world wide web moest nog bedacht worden. Het realtime inzicht geven in de actuele voorraadstatus bij het online verwerken van bestellingen kwam nog bij niemand op. En zo kan ik nog wel even doorgaan.

Veel architectuurkeuzes worden tegenwoordig – en terecht – op het niveau van platformen gedaan. Het is steeds belangrijker om te investeren in een slimme verzameling enterprise services – van CRM-service tot productcatalogus. Dat betekent dus ook dat het werk van de architect principieel is veranderd.

Dus eh, leerzaam? Je gaat toch ook niet een poosje in een eenkamer plaggenhut wonen om te leren hoe je de kamers van een modern hotel moet verbeteren?

Ik zou als architect vooral veel tijd investeren in het bijblijven bij de hedendaagse ontwikkelingen. Dat kost al tijd zat. Het bruist momenteel werkelijk van de innovaties. CEP, RIA, BPM, SaaS, het semantische web – het is maar een greep uit de vele, vele innovatiegebieden. En een beetje architect zorgt ervoor dat hij toch op z'n minst de hype van de echte waarde weet te onderscheiden!

Mocht je dan nog tijd over hebben, bezoek dan gerust eens het tehuis voor bejaarde computers (dat bestaat echt!). Dat is een leuk uitje en voor velen vast een feest van herkenning. Amusante nostalgie. Maar het is naar mijn mening vakmatig gezien toch vele malen interessanter voor cultuurhistorici dan voor archITecten.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 6^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.

[1] Zie: http://nl.wikipedia.org/wiki/Classicisme.

Vloeibare relaties

SQL is ongetwijfeld één van de baanbrekende standaarden van de software-industrie. De officiële standaard dateert uit 1986; inmiddels is SQL:2006 alweer de zesde versie. En SQL is springlevend. Het is zonder meer knap om in een industrie die zo in beweging is een standaard te ontwikkelen die al zo lang zo algemeen wordt gebruikt. Toch heb ik de indruk dat er een tot op heden onbenut verbeterpotentieel verborgen zit in deze populaire standaard. Het is de hoogste tijd voor een

Zoektocht door de tijd

SQL is sterk verbonden met het relationele model van wijlen Edgar Codd. Deze legendarische Britse wetenschapper publiceerde in 1969 al een artikel onder de titel "A Relational Model of Data for Large Shared Data Banks" [1] waarin de theoretische basis werd gelegd voor de relationele databases van vandaag de dag.

SQL is primair nog steeds een querytaal. Er zullen maar weinig IT-ers fronsen bij de aanblik van een statement als

SELECT *
FROM Medewerker
WHERE Salaris > 10.000
ORDER BY Geboortedatum;

Het relationele model is gebaseerd op tabellen, zoals de tabel “Medewerker” in het bovenstaande voorbeeld, en de relaties tussen tabellen, bijvoorbeeld tussen “Medewerker” en “Afdeling”. De tabellen representeren de entiteiten die in een bepaald probleemdomein relevant zijn. Een bedrijf heeft vestigingen en vestigingen hebben medewerkers. De relatie tussen een medewerker en een vestiging noemen we in het dagelijks leven een dienstverband. Zo'n dienstverband kun je als een aparte entiteit modelleren. Helaas is er niet voor alle relaties tussen entiteiten een ingeburgerd begrip voorhanden. Het is dan ook niet echt gebruikelijk om zulke relaties als een entiteit te onderkennen.

Integrity Constraints zijn formele regels die erop gericht zijn om de consistentie tussen data in verschillende tabellen te bewaken. Stel dat een vestiging wordt gesloten; dan ligt het voor de hand dat er ook geen medewerkers meer in dienst zijn bij die betreffende vestiging. Met een constraint kun je voorkomen dat er medewerkers in de database voorkomen die een relatie (i.c. dienstverband) hebben met een vestiging die niet meer bestaat. Net zo goed kun je met zo'n constraint bewaken dat een valuta, bijvoorbeeld de gulden, niet verwijderd mag worden zolang er nog facturen in de database voorkomen die in guldens zijn opgesteld.

Tot zover gesneden koek. Appeltje eitje. Kind kan de was doen. Toch meen ik een fundamentele beperking in het relationele model op het spoor te zijn. En nog wel eentje die in heel veel systemen tot nodeloze complexiteit leidt of tot een vervelende beperking van de functionaliteit.

Wat mij namelijk al vele jaren verbaast is het ontbreken van het concept van tijdgebonden relaties in het relationele model – en vooral het gebrek aan discussie daarover. Het lijkt een impliciete aanname dat relaties tussen entiteiten altijd vast zijn. Toch zie ik in de praktijk heel veel relaties die je eerder vloeibaar zou kunnen noemen. Een paar voorbeelden.

• Een bedrijf heeft gedurende een bepaalde periode een zekere vestiging

• Een medewerker heeft gedurende een bepaalde periode een dienstverband met een vestiging van een bedrijf

• Een medewerker heeft gedurende een bepaalde periode een bepaald salaris

En als je je er eenmaal bewust van bent, dan zie je ineens overal dit soort tijdgebonden relaties.

• Een artikel heeft gedurende een bepaalde periode een prijs

• Een artikel heeft ook gedurende een bepaalde periode een leverancier

• Een artikel is gedurende een bepaalde periode in een assortimentsgroep ingedeeld.

Iedereen die wel eens te maken heeft gehad met het fenomeen terugwerkende kracht, of juist vooruitwerkende kracht, zal hoogstwaarschijnlijk tegen soortgelijke relaties zijn aangelopen. Wellicht dat hij of zij zich nog herinnert dat het best lastig is om dit soort relaties goed te modelleren. Ik ken zelfs mensen die spontaan in de stress schieten bij het horen van het woord peildatum.

Nu is het op zich binnen het relationele model best te doen om een relatie tussen twee entiteiten tijdgebonden te maken. Wat je kunt doen is – in plaats van een enkelvoudige relatie tussen twee entiteiten – een driehoeksrelatie modelleren, waarbij in één entiteit de tijdvakken vastliggen die voor de relatie tussen de twee andere entiteiten gelden. Dus zoiets als in bijgaande afbeelding.

Er zit wel een klein nadeel aan zo'n constructie. Eenvoudige queries vertalen zich in SQL al snel in een behoorlijk ingewikkelde syntax met joins tussen de tabellen en conditionele where-clauses om af te testen of de begindatum van het dienstverband wel in het verleden ligt en de einddatum van het dienstverband ofwel nog niet is ingevuld, ofwel tenminste in de toekomst ligt. En gaat het nog maar om de simpele vraag naar een lijst met medewerkers per vestiging op een bepaald moment in de tijd. Zodra het iets ingewikkelder wordt, bijvoorbeeld de leverancier van een artikel (tijdvak 1) in een assortimentsgroep (tijdvak 2) per filiaal (tijdvak 3) op een bepaald moment in de tijd, dan heb je al te maken met drie verschillende tijdvakken, en evenzovele relatie-entiteiten, en explodeert een SQL query al snel tot tot een lengte die niet meer op een A4-tje past.

Zou het nou niet mogelijk zijn om SQL net iets slimmer te maken, om dit soort veel voorkomende relaties beter te ondersteunen? Zou het concept van tijdsnuggere relaties eigenlijk geen pijler onder het relationele model moeten zijn?

Om over te peinzen

Het is niet zo moeilijk om te bedenken hoe een tijdsnuggere SQL query er ongeveer uit zou moeten zien. Je zou al een eind in de richting kunnen komen met

SELECT *
FROM Medewerker
ON Datum
WHERE Salaris > 10.000
ORDER BY Geboortedatum;

Het is ook niet zo moeilijk om je voor te stellen dat een query preprocessor zo'n query automatisch zou kunnen expanderen naar een geldige SQL query met bijbehorende where clauses. En als we dan toch bezig zijn, dan weet ik er nog wel een paar. Neem nou de lijst met medewerkers uit het afgelopen jaar per filiaal

SELECT Medewerker.naam
FROM Filiaal, Medewerker
DURING (20070801; 20080731)
GROUP BY Filiaal;^*

Het kan toch niet zo moeilijk zijn om uit een dergelijke syntax eenduidig de conclusie te trekken dat het alleen om medewerkers gaat die in de opgegeven periode voor een filiaal hebben gewerkt? Of neem de lijst met omzet per maand van alle filialen die gedurende de gehele afgelopen 12 maanden omzet hebben gemaakt – de zogenaamde vergelijkbare omzet.

SELECT SUM (Omzet.bedrag)
FROM Filiaal, Omzet
DURING ALL (20070801; 20080731)
WHERE Omzet.datum >= 20070801
AND Omzet.datum <>^*

Deze is al een stukje lastiger te verwerken, omdat “ergens” de kennis vast moet liggen dat de during clause in dit geval ziet op het tijdvak dat het filiaal binnen het bedrijf actief was – dus iets betekent als

WHERE Filiaal.Startdatum <= 20070801 AND ( Filiaal.Einddatum >= 20080731
OR Filiaal.Einddatum = NULL)

En omdat dit nog relatief simpele voorbeelden zijn, zal het nog best het nodige denkwerk vereisen om een syntax te bedenken die in alle gevallen werkt. Toch ben ik er heilig van overtuigd dat er voor dit soort logische relaties ook een logische notatie te bedenken moet zijn. En dat het tijdvakconcept tot een standaard construct in relationele databases kan worden verheven. Het is wat mij betreft de hoogste tijd dat daar eens een degelijk proefschrift aan wordt gewijd.

Trouwens, als je er even over piekert, dan valt er op dit gebied nog veel meer te automatiseren. Stel je voert in dat een medewerker vanaf 1 januari een hoger salaris krijgt. Een slimme computer zou dan begrijpen dat dit automatisch betekent dat het lopende salaristijdvak moet worden afgesloten op 31 december – dit soort salarissen sluiten elkaar immers uit. Op dezelfde manier zou je kunnen bedenken dat als een medewerker benoemd wordt tot productmanager van een productgroep, deze rol voor de huidige medewerker ophoudt. Of als een artikel vanaf een bepaalde datum in een bepaalde assortimentsgroep valt, het niet meer in de huidige groep thuishoort. Ik zie dus veel potentie voor een automatisch gegenereerde tijdvakconstraint.

Zo'n automatisme geldt overigens niet voor alle relaties – niet alle relaties zijn mutually exclusive. Eén artikel kan op één moment in de tijd misschien best meerdere leveranciers hebben, net zo goed als één medewerker op één moment in de tijd best voor twee verschillende afdelingen kan werken. Aan de andere kant, een filiaal waar de laatste medewerker uit dienst gaat kan hoogstwaarschijnlijk gesloten worden, net zo goed als een artikel dat zijn laatste leverancier verliest best uit het assortiment genomen kan worden (of vice versa) en zo goed als voor een assortimentsgroep die wordt afgesloten alle tijdvakken van artikelen die aan die groep zijn gekoppeld best automatisch beëindigd zouden kunnen worden. In deze laatste gevallen zie ik nog een ander patroon, namelijk dat van de subperiode. Je kunt een algemene regel bedenken dat de periode van een dienstverband altijd moet vallen binnen de periode dat het organisatieonderdeel waarmee het wordt aangegaan bestaat. Of dat een prijs van een artikel alleen maar loopt binnen het tijdvak dat een artikel in het assortiment zit. Ook dergelijke tijdvakconstraints, die bij een UPDATE of een INSERT het leven aanzienlijk zouden kunnen vergemakkelijken, zouden relatief eenvoudig uit een tijdsnugger datamodel te genereren kunnen zijn. Maar dan moet er ook nog wel even een tijdsnuggere modelleertaal bedacht worden...

Mocht je door dit pleidooi geïnspireerd zijn geraakt, dan weet ik alvast een prikkelende stelling voor je proefschrift.

Het is de hoogste tijd dat de tijd dat SQL de tijd niet in de gaten had tot de verleden tijd gaat behoren.

Hora est.

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 8^ste in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

^* Deze voorbeelden zijn bewust gesimplificeerd.

[1] Codd, E.F: "A Relational Model of Data for Large Shared Data Banks"; Communications of the ACM 13 (6): 377–387, 1970.