Heeft Agile Architectuur nodig om succesvol te zijn?
Op een recente Agile conferentie opende een van de sprekers zijn toespraak met de woorden: ” Agile zonder plan is slechts chaos”. Agile zonder effectieve architectuur zal uiteindelijk leiden tot chaos, vooral wanneer organisaties proberen hun Agile werkwijzen zonder enig referentiekader te schalen.
Als architecten proberen we allemaal te werken met gedeeltelijk bepaalde beperkingen, die in hun aard klantgericht, financieel, regulerend, technisch of concurrerend kunnen zijn. Terwijl agile werkwijzen van oudsher beperkt zijn tot softwareontwikkeling, staan bedrijven, vooral grote ondernemingen, onder grote druk om agile werkwijzen te gebruiken om traditionele bedrijfsfuncties te beheren. Deze nieuwe trend wordt eufemistisch “Nieuwe Manieren van Werken” genoemd. De voordelen van het gebruik van agile practices zijn talrijk, met het fundamentele voordeel dat bedrijven agile practices zien als een manier om betere resultaten te leveren aan hun klanten en belanghebbenden – sneller, efficiënter, continu en consistenter. Dit kan alleen werken als basiselementen van de bedrijfsarchitectuur worden gedefinieerd en er een raamwerk wordt voorzien dat agile procedures ondersteunt.
Het gebruik van een als ouderwets ervaren architectonisch kader, zoals TOGAF®, lijkt in direct contrast te staan met het agile en compacte perspectief op de wereld. Het is zeer gedetailleerd met tal van kaders, technieken en sjablonen die beschreven worden in een vrij steriele handleiding van bijna 700 pagina’s. Het is een zeer gedetailleerde beschrijving van de verschillende frameworks, technieken en sjablonen. Dit past niet goed bij de behendige focus op het bevoordelen van werkende software boven documentatie.
Er is een cultureel verschil hier, net als al het andere. Agile zet zich in voor ongehinderde teams en bevordert directe samenwerking, terwijl de wereld TOGAF ziet als architectuur boards en zorgvuldig geïndexeerde document archieven.
Het is belangrijk op te merken dat TOGAF de leveringsobjecten vastlegt die toch al in een grote organisatie worden gemaakt en nodig zijn, ongeacht of ze als onderdeel van een framework worden uitgevoerd. Bedrijven moeten allemaal een soort architectonische visie hebben die aansluit bij een bedrijfsstrategie. Ze moeten hun capaciteiten en applicatieportfolio volgen, kostenberekeningen uitvoeren, architecturale beslissingen nemen, onnodige herhalingen beperken, onnodige herhalingen beperken, gemeenschappelijke overeenstemming over hoe te werk te gaan mogelijk maken, en ervoor zorgen dat beslissingen eerlijk en transparant zijn. Tegelijkertijd kunnen TOGAF-artefacten zoals lijsten, matrices en modellen worden hergebruikt in andere organisaties, zoals kwaliteitsmanagement, bedrijfsprocesmanagement, ISO-certificeringsdocumentatie, enz. Nieuwe benaderingen in low-code applicatie-ontwikkeling zoals APPIAN maken direct hergebruik van BPMN 2.0-modellen mogelijk – gemaakt tijdens bijvoorbeeld architectuurwerk – voor de agile ontwikkeling van applicaties met minimale programmeer inspanning.
TOGAF is geen rigide frame dat strikt moet worden gevolgd. Het is eerder bedoeld om de beroepsbeoefenaars actief aan te moedigen om het kader aan te passen en te modificeren aan de omstandigheden. Dit betekent dat de verschillende onderdelen van TOGAF kunnen worden aangepast en toegepast op een agile ontwikkeling. Velen geloven dat TOGAF een waterval benadering impliceert – en dat is niet helemaal waar.
SAFe
De meeste agile frameworks die Scrum voor grote organisaties proberen te implementeren hebben altijd een placeholder voor architectuur. Het belangrijkste verschil is dat ze de nadruk leggen op samenwerking, eenvoud en decentraal bestuur. Dit kan in zijn volle omvang plaatsvinden in de capability architecture in het kader van de strategische en gesegmenteerde architectuur.
Het SAFe (Scaled Agile Framework) framework heeft het meest bijgedragen aan het identificeren van de rol van architectuur in een agile omgeving. Zoals met alle dingen rond Agile, gaat het om het creëren van een consistente waarde, en architectuur is niet anders.
De Architecture Domains in Safe zijn dezelfde als de Architecture Domains in TOGAF, wat de opdracht sterk vereenvoudigt. SAFe definieert twee verschillende elementen van architectuur.
Emergent Design
Emergent Design vormt de technische basis voor de ontwikkeling en geleidelijke implementatie van initiatieven. Het helpt ontwerpers en architecten te reageren op veranderende behoeften van klanten en belanghebbenden om ervoor te zorgen dat het initiatief waarde blijft creëren. Op dit niveau zien SAFe-beoefenaars architectuur als een gezamenlijke en interactieve oefening die het ontwerpelement kan creëren.
Intentional Architecture
Intentional Architecture is een meer gestructureerde aanpak en sluit beter aan bij wat velen de traditionele architectuur zouden noemen, d.w.z. een reeks gedefinieerde en geplande architecturale initiatieven die ontworpen zijn om de prestaties en bruikbaarheid van het initiatief te ondersteunen en te verbeteren. Inderdaad, Intentional Architecture is een duidelijk besef dat we allemaal binnen bepaalde beperkingen moeten werken, zoals de keuze van de architecturale richtlijnen, het technologieplatform, het financiële budget, enz. Als deze beperkingen kunnen worden geïdentificeerd en geïntegreerd in het initiatief, neemt de kans toe dat het initiatief succesvol zal zijn en waarde zal opleveren, of dat de resultaten zullen leiden tot architectonische aanpassingen als onderdeel van Architecture Change Management.
SAFe beoefenaars beweren dat door het in evenwicht brengen van nieuw ontwerp en intentionaliteit, agile praktijken kunnen worden geschaald om oplossingen op enterprise-niveau te leveren. In SAFe is deze combinatie gerelateerd aan de Architectural Runway, die de technische basis vormt voor het creëren van bedrijfswaarde, die volledig in overeenstemming is met de traditionele opvattingen over architectuur.
De sleutel tot het succes van deze aanpak ligt in het abstractieniveau waarop de balans tussen Enterprise Architectuur, Emergent Design en Intentional Architecture plaatsvindt.
Zelfs in een wendbare wereld blijft de rol van de architect een sleutelfunctie behouden. Opleiding en, indien nodig, certificering in een van de kaders, zoals TOGAF, is zinvol en effectief. Sommige architecten moeten ook kennis, vaardigheden en ervaring hebben op het gebied van Agile, SAFe en SCRUM. Alle teamleden moeten begrijpen hoe enterprise architectuur en Agile in elkaar passen.
Het vermogen om samen te werken is een van de belangrijkste vaardigheden die hier nodig zijn. Architecten moeten in staat zijn om productief samen te werken met Agile teams om snelle en lokale ondersteuning te bieden bij de toepassing van Emergent Design, en tegelijkertijd Agile teams te helpen bij het identificeren en beheren van de beperkingen die door Intentional Architecture worden gedefinieerd. Een van de belangrijkste kenmerken van Agile Practices is het feit dat Agile-teams worden aangemoedigd om voortdurend feedback te geven aan hun stakeholders. Bij het ontwikkelen van nieuwe ontwerpen kunnen architecten deze informatie gebruiken om Intentional Architecture aan te passen en te ontwikkelen om ervoor te zorgen dat de algemene architectuur van de organisatie op de middellange tot lange termijn evolueert met de organisatie.
In het volgende deel van deze serie gaan we dieper in op hoe TOGAF en agile elkaar kunnen versterken.
