10 gode (?) råd til at styrke din enterprise arkitektur i 2016
De fleste arkitekter kan gå dybt ind i at diskutere hvad enterprise arkitektur (EA) egentligt er, hvilket formål sådan en skal have, og hvordan man bedst arbejder med den. Næsten altid er diskussionen langvarig. Det kan derfor lyde underligt at kunne komme med gode, praktiske råd om hvordan en EA-funktion, sådan helt generelt, kan styrkes når nu definitionen af EA er så flydende.
Det afholder dog ikke alle fra at forsøge. For tiden florerer en undersøgelse lavet i samarbejde mellem Henley Business School og McKinsey. (Full disclosure: jeg har selv været på Henley hos professoren bag undersøgelsen men har ikke noget med konsulentfirmaet at gøre).
Undersøgelsen søger svar på en del interessante spørgsmål. For eksempel, hvorfor er EA funktionen sat i verdenen - her er svarmulighederne (a) for at drive besparelser, (b) sikre overholdelse af compliance, (c) for at opnå forretningsfordele eller (d) for at bedrive it-arkitektur. Eller hvad med spørgsmålet om hvad afdelingen bruger tiden på, hvor kategorierne er at (a) modellere as-is eller (b) to-be arkitekturer eller på at (c) få realiseret to-be arkitekturen). Du kan deltage i undersøgelsen her.
Allerede nu, før undersøgelsen er helt færdig, er der kommet de ti råd, som jeg lokkede med i overskriften på denne blog. Lad os springe ud i det og se på dem.
1. Organiser EA efter hvordan resten af organisationen er opdelt.
Er en EA funktion da ikke sat i verden for at skabe fællesskab og sammenhæng på tværs? Jo egentligt, men pointen er, at organisationen er opdelt i forretningsområder af en årsag, nemlig at det er er flere synergier internt i et forretningsområde end på tværs af forretningsområderne – ellers ville organiseringen se anderledes ud.
Rådet giver god mening. Flere virksomheder, fx DONG Energy, har eller er på vej til at organisere deres EA-funktion på netop den måde. EA funktionen fungerer da som et arkitekturfagligt fællesskab, og forsøger ikke at skabe et, måske kunstigt, forretningsfællesskab mellem meget forskellige forretningsområder. At det så kan svært at servicere 4-5 store forretningsområder med en EA funktion på måske 2-3 mand er et andet problem.
2. Gør det klart hvem som er ansvarlig for beslutninger som påvirker enterprise arkitketuren.
Her foreslår forfatterne chefarkitekten som den ansvarlige.
Principielt er det jo en god ide, men ikke uden problemer i praksis. Mens en chefarkitekt står på mål for en måske lidt besværlig og fordyrende - men i øvrigt fornuftig - arkitektur vil sponsoren af et multimillion kr. projekt, fx en vicedirektør, typisk gerne have driblet bolden igennem uden om alle forhindringer, inklusive arkitekter. Målt på antallet af stjerner på skulderen vil chefarkitekten komme i problemer. Den typiske konflikt mellem arkitektur-funktionens fokus på sammenhæng på længere sigt på den ene side og på den anden ønsker om hurtige løsninger, bliver ikke løst ved at lægge det tunge målmands-ansvar på arkitektens skuldre alene.
3. EA-afdelingen skal arbejde tæt sammen med både forretningen og it.
Eller med andre ord: EA-funktionen skal sikre sig ikke at blive for konceptuel og abstrakt i sit arbejde. For at forebygge isolationen og at sikre sig at forretningen kan leve med arkitekturen og at it-organisationen kan understøtte den skal der arbejdes tæt sammen med alle. Et sjældent godt råd.
4. Hold strategi-relaterede og operationelle opgaver adskilte.
Glem ikke det strategiske arbejde når næsen til dagligt er nede i plovfugen – ”not letting the urgent overwhelm the important”, siger forfatterne.
Rådet er som sådan fint og brugbart i mange af livets sammenhænge. Men det rammer nok ved siden af skiven her. Når det kommer til kritik af arkitektur-funktioner hører jeg typisk modsatte problem: En tendens til at beskytte sig mod praktiske opgaver, i hvert fald indtil man lige er færdig med vælge arkitekturværktøj, metamodel, arkitektur-servicekatalog og at modellere as-is situationen på tværs af virksomheden. Den slags forberedende arbejder tager månedsvis, hvis ikke årevis, og så tålmodige er sponsor eller andre interessenter sjældent. Det rigtige råd må være at skabe værdi – hver uge og på længere sigt.
5. Giv EA-funktionen retten til at godkende eller afvise visse større initiativer.
EA-funktionen har ikke nok gennemslagskraft i organisationen, hævder forfatterne. Politiker og vejledninger fra EA-funktionen bliver ikke implementeret af sig selv. Der skal mere til og derfor skal visse større beslutninger igennem EA-funktionen for at blive godkendt. Desuden kan de rette folk, som er svære at finde, først tiltrækkes hvis EA-funktionen har reel indflydelse.
Rådet er godt men der skal mere til end blot at være have rollen som gate-keeper (eller ledvogter som det måske burde hedde på dansk). Selv er jeg tilhænger af mottoet ”speak softly but carry a big stick” og retten til at afvise initiativer er jo altid rar at have i baghånden som kæp. Men selvom truslen om smæk med kæppen kan være nyttig, kommer man længere med dygtigt forarbejde og synlighed af værdien af EA-funktionen.
6: Sikr ansvaret for de forskellige elementer af EA er samlet i én gruppe
Særligt i større organisationer foregår der EA-arbejde flere steder uden et fornuftigt niveau af koordinering og prioritering. Ansvaret for og koordineringen af EA-arbejdet skal derfor ligge i én gruppe hvorimod udførelsen godt kan uddelegeres.
Det er et udmærket råd – selvom det kan være svært at formalisere hvad EA-arbejde egentligt er og den afgrænsning er jo en forudsætning for at kunne samle ansvaret. Måske er det en bedre fremgangsmåde at trække på sit netværk i organisationen for at holde sig orienteret om relevante aktiviteter.
7: Virksomheden bør analysere og måle effekterne af EA.
… men kan det ikke i praksis. I mangel af bedre foreslår forfatterne at effekten af at have en god EA måles på et lille projekt. På basis af den analyse burde effekten af EA på virksomheden som sådan kunne tilnærmes, siger de.
Rådet er som sådan godt da det er ønskværdigt at kunne se værdiskabelsen ved EA. Men anbefalingerne er uldne og jeg kan se en del problemer med fremgangsmåden. Særligt hvis vi forsøger at måle effekterne i kroner og øre bliver det problematisk, hvilket også Robert Kaplan er citeret for i en tidligere blog. Det skyldes, at EA i bedste fald skaber immaterielle aktiver men oftere består af aktiviteter som hjælper med, eller er katalysator for, at skabe immaterielle aktiver. Immaterielle aktiver kan være meget svære at måle effekten af.
8. Hold det simpelt (og kommuniker)
EA-arbejde er komplekst og kræver værktøjer og metoder for at kunne lykkes. Men det er ikke nyttigt at formidle kompleksitet på en kompleks eller model-tung måde. Arkitekterne er ikke gode nok til på en simpel måde at kommunikere om hvad de laver og bruger eksempelvis dobbelt så meget tid på at tale med leverandører som med ledelsen. Derfor skal arkitekterne lære at kommunikere effektivt og forståeligt med interessenterne, både i forretningsenhederne og især med ledelsen.
Dette råd er nok blandt de vigtigste og burde ikke henslæbe livet på en 8.plads.
9: Brug ét værktøj til at styre alle arkitekturens elementer.
Det kan der være noget om. Husk blot på at sådan et værktøj tager tid at lære godt og at putte data ind i. Og husk lige punkt 8 – hold det simpelt. Med god grund anbefaler metoden Dynamic Enterprise Architecture først at anskaffe sig sådant et arkitektur-værktøj når den grundlæggende modenhed er på plads.
10. Invester i EA lederne.
Helt bestemt. Burde være nr. 1. Den rigtige person med den middelmådige metode vinder hver gang over den middelmådige person med den rigtige metode.
Dette var rådene fra Henley Business School og McKinsey. Som du kan se, er de af blandet kvalitet men med små perler undervejs. Hvilke af rådene du ser som de bedste? Og kan du se nogle som mangler?
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
