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.
