7 gewoonten van zeer effectieve solution architecten

De solution architect is terug van weggeweest. Een kwart eeuw geleden had zij/hij nog een prominente plek binnen het software ontwikkel proces. De architect bepaalde (in een Software Architectuur Document) en controleerde (via de Architectuur Review Board) de kaders voor een project. En toen was er de opkomst van Agile, waar autonoom opererende teams, veel meer kleinschalig en kort cyclisch, hun applicaties vormden en in vorm hielden. Agile had een sterke focus op werkende software en op de korte termijn (move fast and break things). Architectuur ontstaat hier vooral vanzelf (emerging) in plaats van vooraf bedacht (intentional), en dat maakt de rol van de traditionele architect een stuk minder prominent.

Agile teams zijn ondertussen een enorm succes gebleken. De complexiteit, het belang en de omvang van het gemiddelde IT-landschap is sterk gegroeid en daarmee ook het aantal applicaties en bijbehorende teams. Deze (aanhoudende) groei maakt een volgende stap in de volwassenheid noodzakelijk, namelijk de stap van individuele Agile teams naar een geschaalde Agile organisatie waarbinnen de vele applicaties en teams onderling nauw en efficiënt met elkaar communiceren. Hier ligt een zeer belangrijke taak weggelegd voor de architect en dat maakt de rol belangrijker dan ooit maar ook anders dan we gewend waren.

In deze blog probeer ik deze nieuwe rol te duiden via zeven, onderling sterk verweven, gewoonten. De lijst is zeker niet compleet en ook niet wetenschappelijk onderzocht. Het is het resultaat van het lezen van stapels boeken en van een kwart eeuw ervaring in nationale en internationale (maatwerk) software ontwikkeltrajecten in diverse rollen en sectoren waarin ik van successen en fouten van mezelf en van anderen heb geprobeerd te leren.

#1 Stel de juiste vragen (en ben in staat de antwoorden te begrijpen)

Een architect heeft doorgaans en zogenaamd T-profiel. Je specialiseert je dan enige jaren op één terrein (bijvoorbeeld het ontwikkelen van software), om vervolgens breder uit te waaieren. Een breed kennisprofiel is voor de architect van groot belang om efficiënt te kunnen werken binnen een omvangrijk en complex IT-landschap en bijbehorend speelveld (zie #2). Maar dit betekent dat het onmogelijk is om van alle technologieën en thema’s alle details te kennen. Hiervoor is de samenwerking met diverse specialisten onmisbaar. De architect zal dan vooral in staat moeten zijn om de juiste vragen te stellen, aan de juiste specialisten, en de antwoorden te begrijpen. Op deze manier fungeert zij/hij als intermediair tussen de diverse experts en komt tot totaaloplossingen die de diverse deelgebieden overstijgen.

#2 Maak organisatiestructuur en werkprocessen onderdeel van de solution

Architecten zijn er in vele varianten. In de titel van deze blog heb ik bewust gekozen voor de term Solution Architect. De te realiseren oplossing is namelijk breder dan alleen IT of software. Deze oplossing staat in verbinding met zijn technische EN organisatorische omgeving en het bouwen is niet het eindpunt (traditionele project denken) maar slechts het begin van een traject van (langdurig) beheren en aanpassen.

De oplossing dient daarom zowel techniek, als organisatie en werkprocessen in beschouwing te nemen (de zogenaamde 3 P’s, Product, People and Processes). Dit kan er bijvoorbeeld toe leiden dat een technisch minder hoogwaardige oplossing de voorkeur krijgt vanwege een betere fit binnen de staande organisatie en haar werkprocessen. Het kan soms ook betekenen dat de introductie van specifieke technologie een organisatie-aanpassing noodzakelijk maakt – een aanpassing die daarmee in scope is van de oplossing, en dus deel van het ontwerp van de architect. Houd er ook rekening mee dat een IT-oplossing en de organisatie waarin deze wordt ondergebracht niet los van elkaar gezien kunnen worden. Oplossingen functioneren namelijk het beste binnen organisaties waarmee ze qua structuur in lijn zijn. En organisaties produceren vaak oplossingen wiens structuren de structuur van de organisatie weerspiegelen.

Kortom, een bredere blik is nodig. Dit sluit aan bij het T-profiel zoals uitgelegd bij #1, waar de architect in staat moet zijn om met de Processes en People experts binnen zijn domein te communiceren.

#3 Neem de context als uitgangspunt

Stel een architect een vraag en je zult standaard: “dat ligt eraan”, als antwoord terugkrijgen. Dit antwoord is niet erg origineel en proactief maar is vaak wel juist. De beste oplossing voor een probleem is namelijk niet alleen afhankelijk van het probleem maar ook van de situatie en omgeving waarbinnen het probleem moet worden opgelost en het doel dat je wilt bereiken. Van handmatige oplossingen en weggooi-spaghetti-applicaties tot de meest high-end producten, iets kan pas goed beoordeeld worden op zijn geschiktheid als we duidelijk begrijpen voor welk doel, situatie en omgeving de oplossing bedoeld is.

#4 Werk in korte cycli en zorg voor feedback loops

Ik ga hier geen discussie voeren over de voor-  en nadelen van Agile versus de Waterval, daar zijn genoeg artikelen over te vinden. Mijn ervaring is wel dat het in de praktijk doorgaans onmogelijk is om vooraf alle belangrijke requirements te voorzien en mitigeren. Al doende treden er altijd toch weer inzichten op die impact hebben op de beoogde oplossing. Het is daarom een goede gewoonte om dit gegeven te omarmen en gebruiken. Dit kun je doen door nadere analyse, experimenten, pilots, bèta’s, etc, etc. De beste benadering hangt af van situatie. Het Cynefin framework onderscheid vijf situaties met per situatie een aan te bevelen benadering.

Het gaat er uiteindelijk om dat je in staat bent om feedback te verzamelen, te leren en de inzichten te gebruiken om bij te sturen. Dit grijpt niet alleen in op je proces maar ook op het ontwerp van je software (product). In al zijn facetten (zie #2) dient je oplossing daarom zoveel mogelijk evolutionair te zijn.

Lees in dit artikel hoe je met de juiste dosis agile zorgt voor succesvolle software 

#5 Maak plannen en werk deze regelmatig bij

Plans are useless, planning is crucial! #5 is een variant op een mooie quote van Winston Churchill die ik ooit voorbij zag komen. Zeer toepasbaar voor een architect en sluit mooi ook aan bij #3 en #4. De architect is bezig met het bedenken van de beste oplossing voor een probleem in een bepaalde context en bedenkt hiervoor een plan. Op korte termijn geeft dit plan de richting en details die nodig zijn om de eerste delen van de oplossing te realiseren. De langere termijn is onzeker en dient te worden uitgewerkt met de inzichten die de komende tijd worden opgedaan. Het serieus nadenken over de langere termijn is echter nodig om de juiste richting mee te geven in het heden en voorbereid te zijn op de toekomst. Oftewel: kijk vooruit maar houd er rekening mee dat het beeld gaande weg zal gaan veranderen en zie dit als een continu proces (sliding window).

SAFe geeft hier invulling aan middels roadmapping. Aanvullende tip voor het opstellen van de roadmap: concentreer je als architect vooral op de zogenaamde invisibles (technische achterstalligheden en enablers). Voor de visibles (defecten en business functionaliteiten) is doorgaans namelijk al meer dan voldoende aandacht. Meer info over technical debt management? Lees de diverse boeken en artikelen over technical debt control van Philippe Kruchten.

#6 Gebruik design-patterns

Software ontwikkeling is natuurlijk een relatief jonge industrie. Toch zijn er ondertussen al aardig wat regels code geschreven en problemen opgelost. Conceptueel gezien zijn veel van de oplossingen uit het verleden prima bruikbaar voor het oplossen van problemen in het heden. Het denken in design-patterns (en anti-patterns) kan daarom enorm nuttig zijn bij het samenstellen van nieuwe oplossingen. Met design-patterns bedoel ik allerlei (deel)oplossingen, IT en non-IT, voor (deel)problemen die al eens door jezelf of je collega’s/voorgangers zijn opgelost. Begin dus niet te snel met een schone lei en ga op zoek naar (conceptueel) hergebruik. Houd er wel rekening mee dat situaties en omgevingen (#3) kunnen/zullen afwijken en dat de geschiedenis zich dus waarschijnlijk niet op precies dezelfde manier zal herhalen.

#7 Pas een just-in-time, just-enough benadering toe

Tot slot gewoonte #7. Deze gewoonte beschrijft naar mijn mening het meest fundamentele verschil tussen het traditionele en het moderne architectuurproces. De architect is verantwoordelijk voor het bedenken van oplossingen (3P’s, #2), (deels) opgebouwd uit design-patterns (#6), voor problemen binnen een bepaalde context (#3). Het proces is echter uitgesmeerd in de tijd (#5) en verdeeld in korte iteraties (#4). Voor oplossingen op korte termijn is er sprake van relatief veel details en van duidelijke keuzes en afspraken. Voor de langere termijn gaat het veel meer over richting en mogelijke alternatieven. Zijn er in een te vroeg stadium teveel details uitgewerkt en (dus) keuzes gemaakt dan ben je minder goed in staat de allerlaatste inzichten mee te nemen. Indien er te laat, te weinig, details zijn uitgewerkt dan zijn de teams niet optimaal in staat de oplossing te realiseren. Hoe beter de timing van de keuze en de bepaling van het juiste abstractieniveau, hoe beter de architect. Het gaat hier om het kwantificeren en balanceren van de cost-of-delay, die in de tijd alsmaar oploopt, ten opzichte van de risico’s door het maken van verkeerde keuzes die steeds kleiner worden omdat er steeds meer informatie beschikbaar komt om je beslissing op te baseren.

“There's an art of knowing when. Never try to guess. Toast until it smokes and then twenty seconds less.”  

- Piet Hein

Boekenlijst voor de architect

Als architect is het lezen van boeken een goede manier om, naast het werk in het veld, je kennis (T-profiel) in vorm te houden. In tegenstelling tot mijn vorige leven als software ontwikkelaar is het kennisgebied van een architect breed en niet zozeer gericht op allerlei details. Dit maakt het lezen een stuk prettiger. Tevens is de halfwaardetijd van de kennis vele malen langer waardoor je de kans hebt om je profiel over een langere tijd op en uit te bouwen. 

Hieronder daarom, verdeeld in vier categorieën, een lijst met mijn persoonlijke favorieten.

Ontwerp

E. Evans, Domain-Driven Design, 2003
G. Fairbanks, Just Enough Software Architecture, 2010
L. Bass, Software Architecture in Practice, 2012
P. Sadalage, NOSQL Distilled, 2012
S. Newman, Building Microservices, 2015
M. Keeling, Design It , 2017
N. Ford, Building Evolutionary Architectures, 2017

Design Patterns

M. Fowler, Pattern of Enterprise Application Architecture, 2002
G. Hohpe, Enterprise Integration Patterns, 2003
J. Kerievsky, Refactoring to Patterns, 2004
J. Nilsson, Applying Domain-Driven Design and Patterns, 2006

Voortbrengingsprocessen

M. Poppendieck, Implementing Lean Software Development, 2006
J. Humble, Continuous Delivery, 2010
J Davis, Effective DevOps, 2016
G. Kim, The DevOps Handbook, 2016
M. Nygard, Release It, 2018
P. Kruchten, Managing Technical Debt, 2019

(Zelf)Leiderschap en Teams

J. Kotter, Leiderschap bij verandering, 1997
S. Covey, The 7 Habits of Highly Effective People,  2001
M. Poppendieck, Leading Lean Software Development, 2009
A. Stellman, Beautiful Teams,  2009
E. Deming, The Essential, 2012
P. Jackson, Eleven Rings, 2015
L. Schaepkens,  10 miljoen jaar leiderschap, 2021

Ben je een ervaren architect met opmerkingen, aanmerkingen of aanvullingen? Of heb je de ambitie om je als architect (verder) te gaan ontwikkelingen en heb je hierover vragen en/of ideeën? Neem dan gerust contact met me op.