Architectuur voor de Ambachtsman

In de wereld van de IT doen hypes het altijd goed. Het bouwen van een systeem is nog steeds een langdurige affaire. En het resultaat van menige inspanning is uiteindelijk toch niet helemaal geworden wat opdrachtgevers of makers voor ogen hadden. Elke tool of methodologie die sneller en/of beter resultaat belooft wordt omarmd. Sommigen zijn blijvertjes, anderen verdwijnen na een tijdje weer uit het IT vocabulaire.

Net als veel andere SDN’ers ben ook ik een kleine zelfstandige. Ik werk in mijn eentje en probeer een ambachtsman te zijn. Iemand die applicaties in elkaar timmert, schroeft, plakt en praat. Door de jaren heen heb ik het een en ander voorbij zien komen. Aan de ene kant gereedschappen als Clipper, Delphi en Visual Studio, en aan de andere kant werkwijzes als UDF’s, OOP, DBF’s en SQL. En bouwtekeningen geschreven in vulpen, SDM, cascade-modellen, TO’s, functiepunten-analyse, use-cases, enzovoort. Veel van die kreten waren ooit buzzwords, sommigen zijn inmiddels al weer een herinnering. Andere werden onderdeel van algemeen IT jargon. In dit verhaaltje wil ik iets dieper ingaan op twee hedendaagse buzzword’s : architectuur (het thema van dit nummer) en extreme programming. Wat ik er over wil zeggen is niet meer dan een ietwat provocerend gebrachte eigen mening, en beetje in de trant van “opa vertelt”. Maar het ene buzzword begrijp ik, het andere niet.

Twee visies op architectuur

Het begrip architectuur komt uit de wereld van de bouwkunde. Daar zie je twee stromen, de bouwkundigen versus de architecten. Haal ze vooral niet door elkaar, de architect is vaak beledigd als je hem bouwkundige noemt en andersom. Het verschil begint al met de opleiding, een bouwkundige heeft de Technische Hogeschool doorlopen en zal niet nalaten het belang van de technische kant te benadrukken. Een architect is in de eerste plaats vaak bezig met de “beleving” van zijn bouwwerk door de gebruiker. Hoe ervaart die het als die (voor de eerste keer) door de voordeur naar binnen stapt en hoe praktisch is het gebouw in alledaags gebruik? Dit resulteert vaak in fantastische schetsen met vage poppetjes, futuristische strijkijzers met wieltjes en plastic bonzai begroeiing. Je moet er niet aan denken dat dat letterlijk gerealiseerd zou gaan worden.

Net als in de bouw zie je ook in de software deze twee visies op architectuur. Aan de ene kant de ontwerper die vooral bezig is met de look-and-feel van een applicatie. Daarbij wordt hij vaak niet gehinderd door voldoende kennis van zaken over wat wel en niet realiseerbaar is. Aan de andere kant heb je de techneuten die gericht zijn op een technische beschrijving van wat er in zit, daarbij niet gehinderd door enig besef van het beperkte technische inzicht van de uiteindelijke gebruiker van het systeem.

Maar beide visies zijn belangrijk. Als een gebouw er niet uit ziet of op de verkeerde plek staat, komen er geen bezoekers. Als een software systeem er niet uit ziet, of alleen te gebruiken is na het passeren van drie totaal verschillende toegangscontroles, wordt het niet gebruikt. In de bouw kunnen de gevolgen van een technisch verkeerde visie rampzalig zijn. Je kan een prachtig balkon ontwerpen maar als het niet goed vast zit valt het naar beneden. Met bewoners en al, zoals hier in Nederland tot ieders schrik niet zo lang geleden gebeurde. Parijs kreeg een nieuw vliegveld met een zeer indrukwekkende vertrekhal. Helaas stortte die na een paar maanden letterlijk in.

Een van de hoofdrollen in de klassieker “Asterix en Cleopatra” wordt gespeeld door de architect Tekenis. De Egyptische piramides zijn wonderen van bouwen. Beide visies op architectuur zijn hier goed ingevuld. Ze zijn nog steeds zeer indrukwekkend en ze trotseren ongeschonden de eeuwen. 2000 Jaar later bakt Tekenis er wat minder van. Het levert een leuk verhaal op, maar er zit een verwijzing naar de actualiteit in. Weer 2000 later jaar (rond 1990) is er in Egypte een wet aangenomen die de architect ook aansprakelijk stelt als zijn bouwwerk na oplevering instort.

Een veranderende wereld

De architectuur van de bouw heeft een ontwikkeling van eeuwen achter de rug en het gaat dus nog steeds geregeld fout. In de IT is architectuur een relatief nieuw begrip. In de IT gaat heel veel fout. In de bouw kunnen we in principe alles maken wat we nodig hebben, maar soms lijken nieuwe ontwikkelingen eerder gestuurd door het feit dat het nieuw is dan door behoefte. In de IT is nog steeds een schreeuwende vraag naar structuren om betere producten te maken.

In de IT veranderen beide visies op architectuur. Dat we overspoeld worden door technische innovaties is een open deur maar ook de gebruikersbeleving van IT verandert snel. In de allereerste plaats door het internet. Niet zozeer doordat nu alles met alles verbonden is, maar mijns inziens in de eerste plaats door webbrowsers. Een webapplicatie zit fundamenteel anders in elkaar als een Windows, DOS of Linux applicatie. Die start je op waarna je via menu’s en knoppenbalken er door heen banjert. Denk maar aan Word of Excel. Een webapplicatie is anders. Je tikt een URL in en je belandt op een of andere webpagina. Elke website heeft meestal wel een home pagina van waaruit je naar de verschillende delen wordt gestuurd. Maar die hoef je niet te gebruiken: als je de juiste URL weet kan je meteen naar de plek van bestemming. Hyperlinks maken het van hot naar her springen helemaal makkelijk. Gebruikers zijn dol op hyperlinks, ze klikken de naam van de klant aan en komen meteen op een detailpagina met al zijn gegevens.

Een webapplicatie is een web van pagina’s dat door een eindeloos aantal hyperlinks met elkaar verbonden is. Een equivalent hiervan in de bouwwereld is moeilijk te vinden. Een hele serie overzichtelijk ruimtes is wel te realiseren, maar comfortabele korte gangen om al die verbindingen te maken … dat wordt wel erg lastig. Een klassieke applicatie is als een klassiek kantoorgebouw. Je komt de hal binnen, neemt de lift naar een verdieping en zoekt daar naar de kamer waar je moet zijn. Als je naar een andere kamer wil moet je eerst weer naar de lift (hoofdmenu).

We gaan bouwen

Maar wat de architecten ook verzinnen, uiteindelijk komt het terecht bij de bouwvakker/klusjesman die het moet gaan maken. Als zelfstandig ambachtsman moet je nu zelf je bouwmaterialen kiezen. Je hebt een keuze. Je kan zelf een boom omhakken, daar planken van zagen en daar een deur van timmeren. Je kunt ook de planken bij de groothandel halen en daar een deur van maken. Of je gaat naar de bouwmarkt en koopt een kant en klare deur. In softwaretermen ga je afwegen welke functionaliteit je helemaal met de hand gaat coderen, voor welke functionaliteit je de standaard libraries van je favoriete tool gaat gebruiken en welke functionaliteit je in gaat kopen.

Al de bouwstenen moeten aan drie eisen voldoen:

• Ze moeten betrouwbaar zijn.
  Als een bout breekt, stort het dak in. Als een regelmatig voorkomende uitzondering niet goed afgehandeld wordt, verziekt je bouwsteen het hele systeem.
• Ze moeten een simpele interface hebben.
  Als je drie speciale hoekijzers en linksdraaiende schroeven nodig hebt om die ene mooie balk te monteren, is dat niet handig. Als je 20 properties moet zetten en ook nog 5 parameters mee moet geven om een e-mailtje te versturen, dan nodigt dat niet uit om de bouwsteen daadwerkelijk te gebruiken.
• Ze moeten goed te combineren zijn.
  In de bouw klik je uit een beperkt assortiment stekkers, armaturen en rails een complete verlichting in elkaar. In de IT assembleer je uit een aantal SQL-componenten, een database connectie en een XML interface één component die het gegevensbeheer van je klanten regelt.

Het eerste punt brengt me op het belang van goed gereedschap. Foutafhandeling is een aardig criterium om dit te illustreren. In .NET en Delphi is de exception-handling dik in orde, maar als je naar een taal als VbScript kijkt, dan wordt het ineens heel erg moeilijk. In dit architectuurnummer staat een artikel over Exceptions door Harry Maes. Aanrader!

Het tweede en derde punt hebben naast de functionele kant (welke properties, methodes en parameters zijn er?) ook een infrastructurele kant. Als de interface van een bouwsteen breed erkende specificaties zoals COM en XML volgt, dan past de bouwsteen aan veel en veel meer andere bouwstenen.

Are you Xperienced ?

Dit klinkt allemaal heel mooi. In een ideale wereld zouden we alleen nog maar componenten als Lego blokjes aan en in elkaar hoeven te zetten om een systeem te bouwen. In de praktijk komt er natuurlijk iets meer bij kijken. Je moet als klusjesman verloopstukjes gaan maken en als je echt mee wil doen moet je ook zelf je bouwsteentjes maken.

Het daadwerkelijk schrijven van code brengt me op het andere buzzword: Extreme Programming. Je hoort en leest erg veel over deze aanpak van programmeren. Om er eens wat dieper in te duiken ben ik “Extreme  Programming Adventures in C#” gaan lezen, uitgegeven door Microsoft Press, een uitgeverij die meestal erg goede boeken uitgeeft. Dit boek beviel me een stuk minder, zo dadelijk meer.

Extreme programming (XP) is onder andere geboren uit een frustratie die mij bekend voorkomt. Als je een systeem moet bouwen krijg je dikwijls een dik ontwerp toegestuurd. Bladzijde aan bladzijde wordt gepoogd het complete systeem te beschrijven. Veel van de tekst en schema’s zijn vaak open deuren. Ze beschrijven op drie verschillende wijzen hoe het menu in elkaar zit, een keer als lijstje van items, een keer als screenshot en een keer in pseudo code. Dat laatste dan ook nog eens in een dialect waar VbScript zich voor zou schamen. Door al die noeste arbeid komt de ontwerper niet toe aan de details. In een systeem dat bedoeld is om complexe regelgeving te testen ontbreken in het ontwerp de criteria voor de tests, met als gevolg dat de applicatie er dan wel uitziet zoals ontworpen, maar niet wordt geaccepteerd door de gebruiker omdat het niet de beoogde uitvoer oplevert.

Extreme programming benadert een systeem stapje voor stapje. Eerst wordt een kort verhaaltje gemaakt wat één feature van het uiteindelijk systeem beschrijft. Vervolgens wordt dat gebouwd en getest. Essentieel is dat daar minstens drie mensen bij betrokken zijn. Twee programmeurs die samen de code schrijven: de ene klopt en de andere geeft doorlopend commentaar. Alle code die ze schrijven wordt met unit testing op orde gebracht en gehouden. De derde persoon is een gebruiker. Als alle drie personen het er over eens zijn dat het stapje werkt, kan er met het volgende stapje begonnen worden.

Als eenmansbedrijf is pair-programering (met z’n 2-en dus) lastig. Met nieuwsgroepen en blogs kom je een eindje in de richting. Maar ik zou persoonlijk helemaal gek worden als er constant iemand hardop mee gaat zitten denken. Veel betrokkenheid van de gebruiker is altijd goed, mits de gebruiker kennis van zaken heeft. Hij moet eenduidig het gewenste beschrijven in een taal die de techneuten begrijpen. Ook ‘overbetrokkenheid’ van de gebruiker zal menigeen bekend voorkomen: de gebruiker wordt te enthousiast en gaat eindeloze rijen van feautures verzinnen. Gezien de werkwijze van XP moet dat kunnen.

En nou heb ik bijna het hele XP-boek en mijn eerste bezwaren beschreven. Het zijn bijna 500 pagina’s, maar naar mijn smaak kletsen ze maar wat af. In de loop van de hoofdstukken wordt een XML-editortje gebouwd, en al gaande leert de auteur C# en .NET kennen. Een goed gevoed mens die op tijd rust neemt presteert beter, maar om in elk hoofdstuk te lezen in welk restaurant ze nou weer hebben zitten werken gaat vervelen. De stijl van het boek probeert luchtig en verhalend te zijn. Maar een goed codeschrijver maakt nog geen goede verhalenverteller, de bedoelde grappen werken op een gegeven moment ook contraproductief.

Het beschreven project wordt feature voor feature vanuit het niets gebouwd. Door zo te werken loop je het risico te leven in de waan van de dag. Als je geen zicht hebt op later te realiseren features, loop je het risico een implementatie te bouwen die zich later tegen je keert. In het XP verhaal staat een disclaimer waarin gewaarschuwd wordt dat een XP project op die manier uit de hand kan lopen. Zelf ken ik een voorbeeld van een database programma dat perfect met platte tabellen om kan gaan. Toen er op een later moment koppelingen tussen tabellen moesten komen - het werd een echte database - bleek een aantal basis keuzes niet erg gelukkig. Maar daar was toen niets meer aan te doen.

De hap-snap benadering in het boek maakt het ook een erg matig leerboek voor C#/.NET. De auteur probeert het je al gaande eigen te laten maken, maar op een gegeven moment is alleen maar duidelijk dat .NET zeer uitgebreid is waarin veel zaken op verschillende manieren kunnen worden opgelost. Het gaat heel erg in de breedte, maar enige structuur zit er niet in. Je zou kunnen zeggen dat de architectuur ontbreekt.

Dat brengt me op mijn grootste bedenking bij XP: het is alleen geschikt voor ervaren programmeurs. Wat mij betreft noemen ze het Experienced Programmers. Zo iemand hoort verder te kijken dan de ene feature waar die op dat moment mee bezig is. Hij moet zien hoe zijn bouwsteen in het geheel moet gaan passen. Volgens mij noemt menig programmeur zich daarom tegenwoordig software architect.