De voordelen van het vastleggen van (project) architectuur

In deze blog geef ik aan welke voordelen het vastleggen van een (project) architectuur heeft. Hoe simpel je die ook vastlegt. Ik doe het zelf vaak genoeg en met mij vele anderen: Iets niet vastleggen. Waarom? Zonder er onderzoek naar gedaan te hebben vermoed ik dat het heeft te maken met gewoonte, het niet zien van de noodzaak, “niemand leest het toch”, en de mooiste “daar heb ik geen tijd voor”.

De problematiek

Een voorbeeld als inleiding om de problematiek te schetsen. Een klant gaat een digitale transformatie traject in, het bedrijf gaat daardoor gebruik maken van de Microsoft 365 diensten. Een dergelijke verandering is gigantisch maar laten we ons nu voor de eenvoud alleen focussen op het technisch perspectief (om het klein te houden). De (technische) spullenboel die men nu heeft moet op de één of andere manier geplot worden op de Microsoft 365 diensten. Een traject dat een enorme impact heeft op de organisatie en jij en je team mogen dat gaan realiseren.

De puzzel

In de praktijk zie je vaak dat leden van het projectteam, elk met een eigen expertise, voortvarend aan de slag gaan en met de medewerkers uit de organisatie gaan praten. Vaak praten ze met een gemene deler (1 of 2 medewerkers van de klant die het haasje zijn en bij 9 van de 10 overleggen mogen aanschuiven) steeds aangevuld met medewerkers voor dat specifieke onderwerp.

Het gevolg is dat meerdere mensen een stukje van de puzzel ophalen waarbij we eigenlijk helemaal niet weten hoe de puzzel eruit komt te zien. Daarbij komt nog dat we meerdere puzzels moeten maken. De puzzel van de huidige situatie, de puzzel van de nieuwe situatie en de puzzel van de transitie.

Iemand moet ervoor zorgen dat we allemaal werken aan dezelfde puzzel. Alle betrokkenen, ofwel stakeholders, moeten vanuit hun perspectief naar de puzzel kunnen kijken en daar hun waarheid uit op kunnen maken. Met andere woorden “What’s in it for me?”

De voordelen

“What’s in it for me?” is gedeeltelijk het antwoord op de vraag: waarom moet je architectuur vastleggen. Er is namelijk nog een andere kant van het verhaal: het behouden van het overkoepelende overzicht. Passen alle puzzelstukjes wel aan elkaar? Wat doen we met die fileshare?

Door de architectuur als centrale blauwdruk voor je project op te nemen en deze steeds terug laat komen bouw je samen met het team, waar ook de klant lid van is, de hele puzzel in elkaar. Het zorgt voor duidelijkheid doordat je visualiseert wat je in hoofd hebt zitten.

Een voorbeeld hiervan is wanneer iemand besluit om de verbinding naar de RDS omgeving te verbreken dat diegene ook ziet dat vervolgens de toegang tot de fileshares (of andere componenten) verbroken wordt. Wanneer je de architectuur niet hebt vastgelegd moet  de consultant vragen gaan stellen aan iemand anders die hopelijk het juiste antwoord weet. Dat kost tijd en geld.

Hieruit volgen weer een aantal voordelen:

• het besparen van tijd (en geld)
• verhogen van de algehele kwaliteit
• begripsvorming

De 3 stappen.

Het draait volgens mij maar om één ding: duidelijkheid, dit moet je creëren. Mijn advies: volg de volgende 3 stappen.

Stap 1: Maak afspraken!

Of we het nu hebben over het vastleggen van requirements, projecttaken, architectuur componenten of iets anders het begint of staat met het maken van afspraken: als projectteam leggen we alle architectuur componenten vast. Het high-level niveau leggen we vast in PowerPoint. Het low-level niveau leggen we vast in Microsoft Visio. Beide documenten bewaren we in Microsoft Teams. Suzan is verantwoordelijk voor de kwaliteit van het Microsoft Visio document en Trevor is verantwoordelijk voor de PowerPoint slides.

Er is nu in elk geval afgesproken dat we de architectuur vastleggen, waar we dat doen en wie er verantwoordelijk is. Wat we nog niet hebben afgesproken zijn de details.

Stap 2: De doelgroep bepaalt de keuze van de tool

Als we al gaan ontwerpen is het belangrijk om na te denken wie dit ontwerp gaat gebruiken. PowerPoint klinkt misschien vreemd om een High Level Design in vast te leggen maar het is een goed middel om te overleggen aan je stakeholders – zei moeten het immers begrijpen.

Wanneer je ontwerp gebruikt wordt om een high-end security oplossing daadwerkelijk te implementeren en het écht gaat om de nitty-gritty details dan is PowerPoint waarschijnlijk niet zo’n goede oplossing.

Mijn advies: selecteer de tool die de taal van je doelgroep spreekt. Gelijk hebben is iets anders dan gelijk krijgen!

Stap 3: Afspreken welke taal we spreken in ons ontwerp!

Los van de tools die we gebruiken, gaat het allemaal gemakkelijker als we ook dezelfde taal spreken (en schrijven) bínnen die tools. Het afspreken van de taal is dan ook de volgende stap die ik adviseer. Dat is ook belangrijk voor de tool die we gaan gebruiken, de tool moet de taal namelijk wel op de één of andere manier ondersteunen. Belangrijk is dat je de juiste taal koppelt aan de juiste doelgroep/stakeholder, niet iedereen spreekt immers dezelfde taal.

Resultaat

Door gezamenlijk de architectuur vast te leggen volgens de 3 simpele stappen ‘zie’ je de architectuur. We hebben het niet meer over vage concepten als een “CRM Applicatie” of een “Document management systeem” oplossing maar, afhankelijk van je stakeholder, communiceren we nu in de juiste taal en met de juiste tools.

Conclusie

In deze blog hebben we gezien dat het vastleggen van je (project) architectuur niet moeilijk is wanneer je de 3 stappen volgt. Ook hebben we verschillende voordelen gezien, namelijk:

• Samen werken aan een gezamenlijke oplossing;
• Iedereen kijkt naar dezelfde waarheid in de juiste taal;
• Verhogen van het team gevoel: What’s in it for me?;
• Besparen van tijd en geld;
• Verhogen van de algehele kwaliteit van het project.

Het vastleggen van je (project) architectuur gaat je helpen de kwaliteit van je werk te verhogen en te vergemakkelijken. Het helpt als praatplaat en om te brainstormen. Een architectuur die je gezamenlijk vastlegt wordt onderdeel van het team en helpt om duidelijkheid te verschaffen.

In volgende blogs ga ik verder in op de combinatie taal en tool en op de vraag of architectuur vertragend werkt of juist als versneller werkt.