Een architectuurplaat voor iedereen…

…maar zonder dozen en lijnen op een flipboard

Een van de eerste acties van Elon Musk toen hij Twitter had overgenomen, was het drastisch laten reviewen en schrappen van broncode (alsook afscheid nemen van een half leger developers, maar dat terzijde). Volgens hem is een groot gedeelte van de code van het 16 jaar oude social media-platform nutteloos. Zijn uitspraak stuitte op grote weerstand onder techneuten binnen en buiten Twitter.

Musk heeft in zijn korte tijd als eigenaar van Twitter al voor veel opschudding gezorgd en dubieuze keuzes gemaakt (en weer teruggedraaid). Maar toch zit er een kern van waarheid in zijn claim. Als je meer dan 10 jaar alleen maar blijft bouwen en uitbreiden op de oorspronkelijke architectuur, raak je de rode draad kwijt. Het is belangrijk regelmatig kritisch te kijken naar je IT-systemen en wat er wordt gebruikt, waarom het wordt gebruikt en je af te vragen of het nog steeds bijdraagt aan de business zoals het ooit bedoeld is. Maar ja, dan moet de architectuurplaat wel leesbaar en up-to-date zijn.

Goede voornemens

Het blijft een lastige relatie, architectuur en IT. Meestal wordt er in het begin een sterke architectuur uitgedacht en neergezet met het voornemen die goed bij te houden. In de loop der tijd worden er zinnige en minder zinnige dingen bijgebouwd. Die moeten ook vastgelegd worden in de architectuurplaat zodat we ten alle tijden kunnen raadplegen wat de status is.

Er zijn veel manieren om veranderingen in de architectuur bij te houden. Uit een kleine rondvraag onder techneuten kwam naar voren dat dit vooral gebeurt in bijvoorbeeld Visio, Word en PowerPoint. Opvallend genoeg zegt slechts een enkeling tools te gebruiken die ervoor bedoeld zijn, zoals Enterprise Architect.

Hoe komt dat toch, vraag ik mij af. Waarom zou je PowerPoint voor zoiets gebruiken? Dat is er helemaal niet voor bedoeld. Vaak komt het erop neer dat de meeste architectuurtools te complex zijn en software engineers zijn net mensen; liever lui dan moe. Ze kennen allemaal Unified Modeling Language (UML) maar bijna niemand gebruikt het.

Een wirwar van dozen en lijnen

Vraag iemand in de bouwsector om de architectuur van een gebouw visueel over te brengen en je krijgt blauwdrukken, plattegronden, dwarsdoorsneden en technische tekeningen. Vraag een softwareontwikkelaar om de architectuur van een IT-omgeving over te brengen en je krijgt een wirwar van kaders en lijnen, inconsistente kleurcoderingen en vormen, generieke terminologie en ontbrekende technologische keuzes. We hebben als beroepsgroep UML geïntroduceerd maar of dit een effectieve manier is om softwarearchitectuur te communiceren, is vaak niet relevant. UML is namelijk al het raam uitgegooid omdat teams de voorkeur geven aan simplistische ‘dozen en lijnen’-diagrammen. In PowerPoint bijvoorbeeld.

Zouden developers in de race naar agility het vermogen om visueel te communiceren zijn verloren? Buiten kijf staat dat UML te ingewikkeld is, te veel werk en bovenal is het ook gewoon lastig om alles continu bij te houden. Developers moeten dingen creëren. Wij willen bouwen. De business vraagt hier ook continu om, en snel een beetje.

OutSystems tools

k hoor je denken, ‘ja maar OutSystems is low-code. Daarmee is toch alles sneller, beter, gemakkelijker?’. In dit geval helaas niet. Natuurlijk hebben we AI Mentor Studio (het oude Architecture Dashboard) en Discovery, maar dat laat ons alleen het complexe gedeelte zien en niet de andere kant van het verhaal.

Een architectuurplaat moet niet alleen waardevol zijn voor de architect, ook een junior developer moet ermee kunnen lezen en schrijven. De Business Analist en stakeholders moeten hun businessprocessen erin herkennen en kunnen zien dat wat er gebouwd is, hout snijdt.

Er moet toch een betere oplossing zijn? Iets dat het midden houdt tussen de ingewikkelde industry standard tools en PowerPoint?

Meerdere doelgroepen aanspreken

Wij gingen op zoek naar een oplossing die we intern kunnen inzetten en die geschikt is voor onze klanten. We stuitten op het C4model. Dit is een model om je IT-landschap op een eenduidige en simpele manier weer te geven op een aantal niveaus van abstractie. Het inspireerde ons om de nieuwe tool Cool Model te ontwikkelen.

Deze tool moet het mogelijk maken de architectuur van een OutSystems softwarelandschap uit te lezen en te converteren naar een C4 model. Zo krijg je een visueel overzicht van bijvoorbeeld applicaties of databestanden (artefacten, de bekende ‘dozen’ uit de eerder genoemde diagrammen) en hoe die in verhouding staan tot elkaar.

Met een visualisatietool kunnen we vanuit Cool Model automatisch verschillende architectuurdiagrammen genereren. Hiermee bereiken we eenvoud en spreken we verschillende doelgroepen aan. Elke doelgroep krijgt te zien wat voor hen relevant is, van architect tot stakeholder.

Wat levert dit op? We automatiseren het monnikenwerk en houden minder handwerk over. Zo ontlasten we onze architecten, maar ook developers, testers, Product Owners en iedereen die betrokken is bij softwareontwikkeling. Dan kan iedereen zich concentreren op het werk dat ze leuk vinden en waar hun expertise en meerwaarde ligt.

Cool Model is nog in ontwikkeling maar kun je echt niet wachten en wil je meer weten? Stuur me een berichtje!

Origineel gepubliceerd door Joost Landgraf op LinkedIn op 8 december 2022.