Har vi nogensinde hørt om en arkitekturplan, der har ligget fortrinligt i skuffen, eller en begrebsmodel, som der stadig hænger på ét af kontorerne – stor og imponerende, men som ikke anvendes i de nye projekter? Ja, det har vi desværre oplevet alt for tit. Det kan der være flere grunde til. Min personlige statistik siger mig også, at der er en vis sammenhæng mellem ”støvsamlere” og rapporter, der er lavet af et konsulentfirma – og ikke af organisationen selv. Men det er ikke hele forklaringen, tror jeg.
Det klassiske enterprise arkitektur projekt bliver gerne afsluttet med aktiviteter, der skal sikre, at governance bliver etableret, f.eks. som udtrykt i TOGAF 9’s ADMs sidste faser: Phase G: Implementation Governance og Phase H: Architecture Change Management. Det er rigtigt fint og nyttigt, men i praksis kan man ikke vente til afslutningen af et EA forløb. Ja, ja, jeg ved det godt. EA arbejdet afsluttes aldrig. Det er ideelt set en vedvarende proces – et iterativt forløb. Men hvornår og hvordan opbygger man governance succesfuldt?
Problemet er også, at den type organisation og kompetencer, der kræves for at opbygge en enterprise arkitektur ikke er de samme, som der kræves for at vedligeholde den. Problemet er, at organisationen ikke er forberedt til at anvende arkitekturarbejdet, når det er færdigt – først langt senere. Helt pragmatisk er de første bevillinger til EA arbejdet ofte simpelthen brugt op, når governance skal etableres!
Hvad hvis vi vender det hele på hovedet?
Men hvad hvis vi vender det hele på hovedet? Hvad hvis vi starter med Governance? Altså starter med at gøre os klart, hvad vi skal bruge arkitekturarbejdet til, hvem der har fornøjelse af det og fremfor alt: Hvordan opbygger vi de processer og den organisation, der skal til for faktisk at realisere det forventede udbyttet af arkitekturen?
Derefter sætter vi organisationen til at udøve governance – på ingenting!
Det lyder fjollet, men konkret kan det sagtens lade sig gøre. Vi samler de rette mennesker og formulere processerne, så ansvar og arbejdsopgaver er klare. Vi sørger for, at projekterne får besøg af arkitekterne – og at ledelsesprocesserne er fungerende. Så først derefter producerer vi den arkitekturafklaring, som disse fora og processer konkret har brug for. Og så udvider vi i den takt, der er brug for.
Som min kollega Rasmus Ranmar skriver i vores ydelsesbeskrivelse om arkitekturgovernance:
”Vi tror derfor på først at fokusere på at indlære governancemekanismerne i organisationen – herefter at udvide med flere detaljer og kontrolmekanismer.”
Knap så ekstremt kan man med fordel begynde governanceprocessen lidt senere i forhold til arkitekturudviklingen, så det er de allerførste resultater af arkitekturarbejdet, som anvendes og vedligeholdes.
Alt dette har nogle rigtig spændende implikationer. For det første sikres, at alle resultater bliver udnyttet hurtigt af organisationen. Vi får hurtigt feed-back fra virkeligheden, og dette sikre at omfanget af arkitekturarbejdet hele tiden er tilpasset organisationens formåen – at arbejdet kan bruges til noget. Derudover påbegyndes den langsomme proces med tilpasning af organisationen i tide. Governance kan på denne måde ikke glemmes i bevillingerne til EA arbejdet – vi bruger simpelthen pengene til en hel proces, der inkluderer governance.
Det kan man da kalde smart eller måske endda en Lean EA proces!
