Categorie: Denkstijlen die wel of niet helpen

ICT-architecten zijn  gericht op de toekomst en streven naar een mooi, geordend en flexibel landschap. Ontwerpers en ontwikkelaars vinden vooral het ontwikkelen van nieuwe systemen leuk, met nieuwe technologie en hulpmiddelen. En beslissers lijken technologie bijna per definitie oninteressant te vinden.

Deze ingrediënten vormen een potentieel gevaarlijke mix. Veel architecturen stralen minachting uit voor de bestaande informatievoorziening. Bestaande, werkende applicaties worden bestempeld als ‘legacy’ waar zo snel mogelijk afscheid van genomen moet worden.

Natuurlijk is er vaak van alles aan te merken op bestaande systemen. Maar ze werken wel: juist deze systemen houden de organisatie draaiende, al zijn er vaak jaren van pijnlijke ervaringen voor nodig geweest om ze zover te krijgen.

Met een nieuwe architectuur die, misschien, hopelijk, tegemoetkomt aan de huidige knelpunten, ben je er nog lang niet. Ook binnen die nieuwe architectuur zijn applicaties nodig van dezelfde omvang en complexiteit als de oude applicaties. En die zijn, ook met moderne middelen, niet zonder slag of stoot te realiseren. Het opnieuw specificeren en programmeren van de in de huidige systemen vervatte kennis leidt vaak tot grote, risicovolle projecten. Veel van de grote mislukkingen in de overheids-ICT vallen in deze categorie.

Een onwelkom bijeffect van ‘alles moet anders’-architecturen is dat ze zelf vervullend zijn. Omdat er iets nieuws wordt gemaakt, wordt onderhoud en doorontwikkeling van bestaande systemen stilgelegd. Die vertonen daarom steeds meer kenmerken van de legacysystemen waarvoor ze worden uitgemaakt en worden daarmee onterecht een extra motivatie om het eens helemaal opnieuw te gaan doen. Als de vernieuwing is mislukt, moeten de verwaarloosde systemen alsnog worden afgestoft.

Een realistische architectuur start bij wat er is en lost stelselmatig knelpunten op: meer evolutie dan revolutie. Een droombeeld kan helpen richting te geven aan alle individuele verbeterstappen, maar werkende systemen moeten daarbij worden gekoesterd.

Architecten houden van principes. Kernachtige, scherp geformuleerde uitspraken die richting geven aan de verdere uitwerking en evolutie van een systeem. Principes zijn nodig omdat architectuur gaat over de fundamentele organisatie en niet een volledig uitgewerkte blauwdruk kan bieden. Principes helpen de mensen op de bouwplaats om keuzes te maken tijdens de uitwerking en realisatie.

Principes moeten er daarom toe doen. Ze moeten ergens, bij iemand, pijn doen. Een voorbeeld uit de werkelijke wereld zijn de regels die de architect César Manrique heeft geformuleerd om het natuurlijke landschap van het eiland Lanzarote te behouden. Een van die regels verbiedt gebouwen met meer dan vier verdiepingen. Dat doet projectontwikkelaars pijn: zij willen graag grote toeristische complexen aanleggen.

ICT-architecten vinden dit soort harde uitspraken vaak lastig. Zeker meer technisch ingestoken kaders (“gij zult de servicebus gebruiken”) worden niet goed begrepen en leiden makkelijk tot conflicten. Veel ICT-principes zijn daarom van het kaliber “World peace”. Je kunt er niet tegen zijn, maar ze geven ook geen richting. Ze doen niemand pijn.

Kijk eens naar een van de eerste Noraprincipes: BP01 Afnemers krijgen de dienstverlening waar ze behoefte aan hebben. Tja. Stel we draaien het om: afnemers krijgen niet de dienstverlening waar ze behoefte aan hebben. Dat slaat natuurlijk nergens op – en de conclusie is dan ook dat het oorspronkelijke principe een open deur intrapt.

Principes zijn nuttig en nodig, maar het moeten er niet te veel zijn, ze moeten geen open deur intrappen en echt pijn doen.

Veel architectuurmethodes en referentiearchitecturen bevatten een of ander raamwerk. Een indeling in verschillende aandachtsgebieden bijvoorbeeld, vaak iets als bedrijf, informatie en techniek. Of een definitie van de verschillende soorten elementen waaruit een architectuur kan bestaan, zoals eisen, principes, processen, diensten, logische functies en gegevenselementen. Meestal een combinatie van beiden.

Zo’n raamwerk vergemakkelijkt het werk van een architect. Het helpt bijvoorbeeld discussies te structureren door telkens de nadruk te leggen op één duidelijk gedefinieerd perspectief. Een raamwerk helpt doelen, randvoorwaarden en oplossingen uit elkaar te halen. Mits goed gebruikt, kan een raamwerk helpen om de consistentie van het geheel te bewaken.

Raamwerken hebben ook een gevaar in zich. Het is moeilijk weerstand bieden aan de neiging om alle onderdelen in te vullen, om te beginnen linksboven in het raamwerk en pas te stoppen als je rechtsonder aangekomen bent en onderweg ieder vlakje volledig ingekleurd hebt. Dat is dan ook precies wat er in architectuurtrajecten te vaak gebeurt. Het raamwerk is een doel op zich geworden.

Dat is niet alleen verspilling van tijd, geld en intelligentie, het zorgt er ook voor dat veel belanghebbenden afhaken. Zij moeten input leveren over iets dat op dat moment helemaal geen issue is en geen waarde toevoegt, terwijl datgene waar ze naar op zoek zijn – een richtinggevend principe op een bepaald vlak, een keuze voor een bepaalde technologie – nog (lang) niet op de agenda staat.

Architectuur gaat altijd om essentie, zelden om compleetheid. Werk uit waaraan behoefte is, tot een niveau dat waarde toevoegt.

Architecten vallen vaak in de valkuil van genericiteit: er zijn vergelijkbare toepassingen nodig dus pakken we het efficiënt aan en beginnen met een generieke, herbruikbare basis.

Het is een verleidelijke redenering die projecten in grote problemen brengt. De veronderstelling is dat je vooraf, op papier, kunt bepalen wat generiek gemaakt moet worden, zo precies zelfs dat je er software voor kunt maken. “No one is that smart,” stelden Don Roberts en Ralph Johnson al in 1996. En de miljoenen verslindende doch gefaalde pogingen om een multi-wetsysteem of een multi-regelingensysteem te maken tonen dat aan.

Beginnen met het generieke leidt tot lange discussies over abstracte concepten. De oplossing wordt mooier en ambitieuzer, omdat er altijd iets te vinden is dat misschien óók nodig is. En ingewikkelder, omdat met allerlei uitzonderingssituaties rekening moet worden gehouden. Als er dan ontwikkeld wordt, blijkt altijd dat er alsnog dingen zijn waar niet aan gedacht was, zelfs rond fundamentele aannames.

De aloude rule of three stelt dat je ervaring nodig hebt om een generieke toepassing of een raamwerk te maken. Voordat je aan generalisatie begint, moet je tenminste drie concrete toepassingen hebben gemaakt. En zelfs dan is generiek altijd moeilijker. Er ontstaan meerdere niveaus van programmeren, configureren of zelfs genereren. Met elk niveau wordt de ondersteuning door ontwikkel- en testtools lastiger en kunnen minder ontwikkelaars de complexiteit aan. Eindgebruikers zien vooral de beperkingen van een oplossing die net niet goed past of ze raken teleurgesteld omdat veel inspanning nodig is om het generieke stuk “af” te maken.

Generiek klinkt efficiënt, maar het is complex.

Referentie: Don Roberts, Ralph Johnson: Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks. In: Proceedings of the Third Conference on Pattern Languages and Programming. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.8767&rep=rep1&type=pdf