Soms heb je van die momenten dat je je serieus afvraagt of je nu oud begint te worden of dat je dit nu moet benoemen als ervaring. Recent overkwam me dit na een uitgebreide discussie over component based development met een aantal ontwikkelaars en testautomatiseerders. (Lees verder)
Het was in het begin van de jaren negentig dat ik in de eerste architectuur discussie verzeild raakt over lagenmodellen of logische tiers binnen een applicatie/component. Hele heftige discussies over de hoeveelheid tiers/lagen waaruit een applicatie nu eigenlijk moest bestaan en hoe dit gerealiseerd moest worden. Dit was nog in de tijd van grote mainframes, met IDMS DB/DC en CICS/DB2 als respectievelijk de transactiemonitor en het database management systeem. De programmeertaal was dominant COBOL.
Het algemene gevoel was dat de applicatie moest worden opgebouwd uit tenminste drie lagen: de gebruikersschermen, de bedrijfslogica en de database access logica. Maar al gauw was dat niet genoeg. Het debat ging over dat het eigenlijk 5 lagen moesten zijn: het scherm, de gebruikerstaak/besturingslaag voor de interactie, de bedrijfslogica, de database ontkoppelingslaag en de data-access laag. Want, zo was de argumentatie, dan kun je nog meer ontkoppelen en potentieel hergebruiken. Als (de volgorde in) het proces wijzigt, dan hoef je dit alleen op te lossen in de besturingslaag tussen bedrijfslogica en het scherm. Eindeloze discussies over voor- en nadelen, vaak gevoerd door en met coördinerend technisch ontwerpers. Gelukkig kenden we toen nog niet het woord architect. En toch waren we al wel met architectuur bezig.....
Veel werd er in dit tijd geëxperimenteerd met realisatie van dit soort ontwerp modellen. En elke keer bleek het niet eenvoudig om dit soort isolatielagen te bouwen omdat die inherent ook weer een bepaalde complexiteit met zich mee brachten. Isolatie voor verandering krijg je niet gratis!
Een paar jaren later, veranderde de discussie subtiel naar hoe nu om te gaan met componenten. Op welk niveau moet je nu eigenlijk koppelen/integreren. En hoe groot is een component en wat is de granulariteit nu eigenlijk en hoe groot moet een interface zijn. Sommigen zagen dit zo ongeveer op het niveau van de individuele COBOL module, anderen zagen duidelijk interface modules die voor andere componenten de interface waren naar functionaliteit. Over die interfaces (meer logisch van aard) daar moest je het eigenlijk over hebben.
In de jaren die volgden werden min of meer dezelfde discussies gevolgd, door dezelfde en/of andere mensen. Want de wereld veranderde:
De laatste discussie die ik voerde speelde zich af in een C# .NET ontwikkelomgeving. Over tiers die beschouwd werden als componenten, contracten op het niveau van individuele classes om herbruikbaarheid te bevorderen en isolatie te vergroten. Granulariteit op het verkeerde niveau!.
l'Histoire se répète.
History repeats itself
Wat er was, zal er altijd weer zijn, wat er is gedaan, zal altijd weer worden gedaan. Er is niets nieuws onder de zon. (Spreuken 1:9)
In een vakgebied zo jong als het onze en met technologie wisselingen in de snelheid van de afgelopen decennia, is het misschien wel logisch dat dit gebeurd. Maar af en toe bekruipt me het gevoel dat ik oud wordt. Of zou dit nu ervaring zijn? Ik weet het niet, de tijd zal het leren.