Agil udvikling og enterprise arkitektur – et godt match?

Hvis udviklingsenhederne arbejder efter en agil model, er enterprise arkitektur ofte lig med det der, i agile folkemunde, hedder BDUF (Big Design Up Front). I den agile verden er BDUF et fy-ord, no-go og antipattern, der direkte strider imod det agile manifest, og netop gør det særdeles vanskeligt, at respondere til ændringer.  For at gnide lidt mere salt i såret, så bliver ‘no-coding’ architects ofte mødt med hvidløgsranker og sølvkors, skulle de forvilde sig ind i et agilt warroom.

Så det gælder om at finde det rette abstraktionsniveau, der giver mening for det agile team. “Find det selv i vores reol” – er ikke jordens bedste scorereplik. På den anden side skal det pågældende team vide, at der er en verden udenfor, og det projekt de arbejder på skal sandsynligvis indgå i en sammenhæng af løsninger.

Ydermere er løsningerne ofte (altid, hvis man har indført et EA program) underlagt nogle retningslinjer, der kan være mere eller mindre restriktive. Samtidigt skal man være opmærksom på, at det ikke er alt, der er relevant for virksomhedens samlede arkitektur. En løsning vil altid bestå af en mængde funktionalitet der er unik for løsningen og ikke vil give mening at genanvende i andre sammenhænge.  At gøre en komponent genbrugelig er en væsentlig mere kostbar affære end blot at skulle bruge den i en enkelt løsning.

Og det er b.la. derfor det giver rigtig god mening for enterprise arkitekten og udviklingsteamet at arbejde tæt sammen om en fælles vision  for arkitekturen. Enterprise arkitekten har det store overblik, og teamet har de mere detaljerede mål for løsningen for øje, som illustreret her.

Begge parter kan have stor gavn af hinanden. Enterprise arkitekten kan vurdere, om løsningen indeholder de byggeblokke, der skal indgå i virksomhedens arkitekturlandskab, og kan pege på hvilke eksisterende byggeblokke der kan være relevante – eller ligefrem obligatoriske for løsningen.

Teamet kan derfor få tilført flere midler til at hærde fælles komponenter og måske er komponenten endda så omfattende, at der nedsættes et særskilt team til at udvikle denne. Dermed kan teamet fokusere endnu mere på det konkrete projekt.

Som Dean Leffingwell udtrykker det: “We must relegitimize the role and avoid a battle between agile teams and system architects, because all will be losers in that fight.”

Dette er anden del af en serie på tre omhandlende enterprise arkitektur og agile udviklingsteams.

Jeg er CTO i Visma Sirius og har gennem en årrække beskæftiget mig med arkitekturdisciplinen - lige fra løsningsarkitektur til enterprise arkitektur, herunder fremherskende arkitekturmønstre og teknologimodeller. Indenfor de seneste år er jeg begyndt at interessere mig for, hvordan man får koblet arkitekturdimensionen til selve implementeringen i de enkelte projekter. Flere og flere tager den agile udviklingsmodel til sig og det er vigtigt ikke at glemme "klassiske" discipliner som arkitekturarbejdet og projektledelse. Jeg har 20 års erfaring i it branchen og har arbejdet med softwareudvikling, arkitektur, it ledelse, projektledelse og implementering af agile processer.