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?

Peter Nørregaards billede
Peter Nørregaard er principal consultant hos PA Consulting Group. Peter blogger om koblingen mellem strategi, forretnings- og it-arkitektur og om hvordan it påvirker samfundet

Kommentarer (9)

Lars Rossen

Lad mig starte bag fra: Ja invester i EA lederne; men sørg for at det er leder egenskaberne der komme it højsædet! En EA med all Togaf certificeringerne og som kan dokumentere sine drømme i ArchiMate er intet værd hvis han ikke kan kommunikere med folk der ikke forstår disse sprog og metoder. Dette leder mig til råd 9: Brug et værktøj…. Jeg er for så vidt ikke uenig i dette, i min gruppe i Hewlett Packard Enterprise og i standard organisationen The Open Group hvor jeg leder arbejdet for at lave en generisk to-be arkitektur for fagområdet IT (www.it4it.org) anvender vi Sparx EA og vi anvender ArchiMate som sprog. Men det er blot for at få det formelle på plads, den egentlige diskussion foretages med folk der ikke er trænet i de formelle metoder til arkitektur. Derfor opfandt vi en meget simplificeret notation med kun 3 symboler (Cirkel box og en linie) som er enkel at tegne på white boards, og i ppt og som kan bruges til kommunikation med ledere og software arkitekter som ikke har nogen interesse i at lære nuancerne i ArchiMate.
Med andre ord, jeg ville foretrække at man erstattede råd 9 med et råd om at vælge et sprog som kan bruges til dokumentation og kommunikation. Jeg foreslår at tage et kik på IT4IT hvor vi havde en del fokus på dette.

Bjørn Anker-Møller

Det er jo genkendelsens glæde (eller i hvert fald genkendelse!) man føler ved læsning af de ti gode råd. Men stadig en nyttig diskussion.

Jeg ville helt klart sætte rådet "hold det enkelt" op som nummer 1. Forstå hvilken målgruppe du kommunikerer med og tilpas din kommunikation. Et tilpasset og forenklet "rich picture" lavet i Powerpoint slår kommunikationsmæssigt ofte de forkromede værktøjers output, især når der skal kommunikeres uden for IT.

Så ville jeg sætte "tænk værdi!" ind som nummer 2. Stop op med passende mellemrum og tænk over benefits og værdi af det du er i gang med. Jeg er ikke så meget ude efter "the elevator pitch" (om den generelle berettigelse af EA) som en konkret vurdering af det arbejde du er i gang med. As-is arkitekturer er et rigtig godt anvendelsesområde for den vurdering…

På min top 3 ligger også rådet "få beskidte fingre". Hvis du bliver spurgt om din holdning til en konkret teknisk problemstilling i et projekt, så giv dig tid til at tage dig af det. Du har ikke glæde af at lade EA blive en elfenbenstårn-funktion (ligesom gamle dages metodeafdelinger), og når du også viser din generelle IT-faglighed får du respekt og bedre samarbejde med dine kolleger i IT - som jo er dem, der skal realisere værdien i din enterprise-arkitektur.

Jesper Frimann

Organiser EA efter hvordan resten af organisationen er opdelt.
Her skal man passe på. Organisation enheder har det med at overvurdere deres egen betydning. Derfor kan man hurtig komme til at se, at hver lille underdirektør har sin egen enterprise architect for IT. At hver forretnings enhed har en ditto, i stedet for en enterprise architect for business. Så der skal være en faglig grund til at skille en EA funktion op i forskellige dele.

Gør det klart hvem som er ansvarlig for beslutninger som påvirker enterprise arkitketuren.
Det er jo meget en firma kultur ting. I de store 'gamle' IT selskaber er der tit et fagligt hierarki, der har formel autoritet til at kunne stå imod kortsigtede 'tis i bukserne' tiltag. Men i 'mindre' virksomheder med en anden kultur, er der behov for en ledelsesmæssig opbakning.

EA-afdelingen skal arbejde tæt sammen med både forretningen og it.
Ja, derfor er et arkitekt netværk, på tværs af forretningen et must.

Hold strategi-relaterede og operationelle opgaver adskilte.
Enig. Det kan hurtigt gå galt. Jeg arbejde på et tidspunkt et sted hvor 80% af 'EA gruppens' arbejde skulle være operationelle opgaver. 20% finansiering til EA arbejde..... Seee det var ikke noget der virkede.

Giv EA-funktionen retten til at godkende eller afvise visse større initiativer.
Jup. det hænger meget sammen med 2, typisk vil det være et Architectural review board der sidder med selve autoriteten til at vende tommelfingeren ned. Men et sådan board skal jo også have nogle rådgivere :)

Sikr ansvaret for de forskellige elementer af EA er samlet i én gruppe
Det spiller jo lidt imod 1'eren. Men i det mindste er det vigtigt at der er samarbejde mellem forskellige EA grupper, og at disse ikke er 'imod' hinanden.

Virksomheden bør analysere og måle effekterne af EA.
Tja ja.. good luck. problemet med at måle er at man behøver en baseline (Uden EA altså) og det vil jeg ikke anbefale. Man kan måle pre EA og så EA.. men pas nu på med at fifle når man nu har indført EA.

Hold det simpelt (og kommuniker)
Jup. Man skal ikke undervurdere værdien af, som arkitekt at tage Kansas tøjet på, eller Jakkesættet (tm) og snakke med andre på deres premisser.

Brug ét værktøj til at styre alle arkitekturens elementer.
Det lyder fristende, og vi hvor jeg arbejder i dag, bruger samme værktøjer som Lars Rossen herover. Men den går bare som regel ikke i virkeligheden, altså one Tool to rule them all.
Der vil være underleverandører der bruger andre tools. Der vil være folk der har brug for viden, dokumenter m.m. fra dit system, som ikke er arkitekter.. Du vil have legacy/Kunders arkitektur, hvor man ikke ønsker at bruge penge på opbygge tingene i et enkelt Tool. Så baser din 'core' på et værktøj.. men vær parat til at gå på kompromis.

Invester i EA lederne.
Hvis du er i en EA funktion bør du per definition være den rigtige person.

// Jesper

Simon Pape

Jeg er ganske enig i #1.
Hos BEC, hvor jeg arbejder, har vi i en årrække organiseret vores EA-funktion til at følge forretningsområderne - vi har fire overordnede forretningsdomæner og følgeligt har vi fire EA'ere (som vi kalder domænearkitekter). Hver EA'er arbejder tæt sammen med udviklingschefen og løsningsarkitekterne inden for et domæne, og vi søger at sikre sammenhæng på tværs af organisationen bl.a. ved at EA'erne løbende taler sammen.
Ud over domæneansvaret har hver EA'er også nogle tværorganisatoriske ansvarsområder - f.eks. ligger datawarehouse og BI hos mig.

Vi oplever fortsat stor efterspørgsel på vores hjælp fra organisationen, så det er jo ikke så ringe endda ... :-)

Peter Nørregaard Blogger

Tak for kommentaren, Lars. Og uden det skal begynde at lyde som moralen i Klodshans, så vinder Klodshans (kommunikatør som taler til interessenternes hjerte) i praksis over den kloge storebror som kan TOGAF forfra og bagfra.

Interessant om IT4IT kan lette kommunikationen med forretningen og andre, det vil jeg overveje at se nærmere på. Ellers ved jeg at @Bjørns forslag om et rich picture i PowerPoint hvert fald har fungeret for mig og sikkert ikke er et dårligt sted at starte.

PS - linket til http://it4it.org/ giver en tom side - er http://www.opengroup.org/IT4IT ikke bedre?

Peter Nørregaard Blogger

Jeg er principielt helt enig i din betragtning, Palle: Vi burde kunne forklare værdien af EA i en organisation og det kan vi også til et vist niveau - men at eftervise den uden skyggen af tvivl er en anden sag. Som McKinsey, Henley og jeg (uden sammenligning i øvrigt) ser det, er det ikke nemt i praksis. Se råd 7 ovenfor. Eller se @Jespers kommenter med "Tja, ja, good luck!".

Hvis vi skal komme værdien af en god EA nærmere, så betragt dette citat fra en studie på Stanford University om The Productivity Paradox (om hvorfor investeringer i IT ikke ser ud til at betale sig mere end de gør):

While recent number make it clear that IT does, on the whole, increase productivity, there are plenty of mistakes that can turn IT into an epic failure of a type that is difficult to accomplish with more traditional captial investments.

Jeg er overvist om at den egentlige værdi af EA ligger i at undgå nogle af disse fejl og mindske risikoen for "epic failures"

Peter Nørregaard Blogger

@Bjørn, @Jesper, @Simon og jer som jeg allerede har svaret direkte: Jeg er glad for at I havde lyst til at spille med og dele erfaringerne. Det er stof til eftertanke når I udfordrer nogle af mine vurderinger af rådene.

Det er godt at høre at EA-arbejdet kan være værdsat, @Simon. Efterspørgsel fra organisationen er vist en ret god indikator for det.

Log ind eller opret en konto for at skrive kommentarer