Hoe borg je nu eigenlijk architectuur?

Architectuur borgen kan net zo betrouwbaar zijn als een derdehands gehoord verhaal; iedereen die wel eens 'Ik hou van Holland' kijkt (soms is de afstandsbediening niet van mij) weet hoe betrouwbaar dat is!

Op software gebaseerde oplossingen worden bij voorkeur ontwikkeld onder architectuur. Architectuur is belangrijk, voornamelijk om aan non-functional requirements te kunnen voldoen. Om vanuit een enterprise architectuur (EA) een project onder architectuur te laten uitvoeren, is een PSA (project start architectuur) nodig. Een PSA wordt geschreven door een projectarchitect. Tot zover gaat alles op rolletjes.

Maar, hoe borg je de bedachte architectuur nu eigenlijk? Een projectarchitect is prima in staat om bijvoorbeeld een functioneel ontwerp (FO) te beoordelen op architectuuraspecten. Zo’n FO wordt geschreven door een functionele consultant die begrijpt hoe de business requirements en use cases omgezet kunnen worden in functionele eisen aan een systeem. Deze consultant moet dus in ieder geval de PSA gelezen hebben om zich te houden aan de architectuurrichtlijnen. Om de architectuur te borgen in het FO, moet dit FO dus ook altijd minimaal door een projectarchitect (formeel!) goedgekeurd worden, alvorens het vervolgtraject ingezet wordt. Dit zou dus ook allemaal prima moeten werken in de praktijk.

Moeilijker

Het wordt moeilijker naarmate we verder in het project terechtkomen. Na het FO volgt een technisch ontwerp (TO). Dit TO wordt veelal door een lead developer geschreven. De lead developer leest het FO, en hopelijk ook de PSA. Een lead developer is al veel meer een ’techneut’ dan de functionele consultant, en nog veel meer dan de architect. Het kan best zijn dat de PSA door hem zodanig wordt geïnterpreteerd dat er zaken in het TO terecht komen die al niet meer helemaal voldoen aan de principes opgesteld in de PSA.  Althans, volgens de interpretatie van de lead developer kan het prima kloppen. Hier begint er al iets van een probleem te ontstaan.

Eigenlijk zou de projectarchitect dus ook het TO volledig moeten kunnen beoordelen. Alleen de architect is hiervoor negen van de tien keer niet ’techneut genoeg’. Hier wordt dus soms het principe van ‘we beginnen elk vanaf een andere kant te graven en hopen dat we elkaar in het midden tegenkomen’ toegepast. Verre van ideaal.

De volgende fase in het project maakt het nog lastiger. De code wordt door een developer geschreven op basis van het TO. De code wordt vaak door een heel team geschreven, elk teamlid verantwoordelijk voor bepaalde (deel)functionaliteiten bij voorkeur in de vorm van componenten. De gemiddelde developer  is prima in staat om een TO te lezen en te interpreteren, is al wat minder goed in het begrijpen van FO’s en vind architectuur maar iets voor mensen met stropdassen in ivoren torens. Vaak bevat een TO ook niet volledig in detail alle informatie die nodig is om de oplossing te creëren. Daar komt het dus aan op de creativiteit van de developer. Dat is een gevaar. Verder ontwikkelt niemand meer oplossingen volledig zelf tot op de laatste regel code, maar wordt meestal gebruik gemaakt van één of meerdere frameworks zoals bijvoorbeeld het .Net Framework. En in een service oriented architecture (SOA) maakt men vaak gebruik van al bestaande services die eventueel zelfs niet eens in het eigen datacenter draaien.

Het is dus zaak dat de lead developer de code die geschreven is door de developers controleert. Altijd! Maar wie garandeert de lead developer dat bepaalde componenten uit een framework of de services geconsumeerd in de cloud wel voldoen aan de architectuurprincipes beschreven in de PSA? Soms is die informatie niet eens publiekelijk beschikbaar. Maar toch is dat wel relevant, want wat als dat éne component nu wel die rechtstreekse verbinding met een database maakt die volgens de architectuur ‘verboden’ is?

Mensenwerk

Architectuur kan waarschijnlijk redelijk geborgd worden in de meeste projecten, als het hele projectteam zijn best doet! We kunnen in een project zowel vanaf boven (vanuit de architect, functionele consultant en lead developer) als van onderaf (vanuit de functionele consultant, lead developer en developer) architectuur borgen. Vanaf boven kunnen controles op het geproduceerde FO, TO en de code worden gedaan. Van onderaf kan er tijdens het schrijven van FO, TO en code uitgegaan worden van de interpretatie op het desbetreffende niveau van de PSA. Maar, totdat architectuur in echte ‘rules’ kunnen worden geschreven die geautomatiseerd gecontroleerd kunnen worden op alle niveaus blijft het mensenwerk en vertrouwen op een goed samenwerkend team!