Dette blogindlæg tager sit afsæt i den føderale regerings fremgangsmåde til håndtering af enterprisearkitektur.

I dokumentet (The Common Approach to Federal Enterprise Architecture) omhandlende Amerikas Forenede Staters føderale regerings fremgangsmåde til håndtering til enterprisearkitektur, og hvordan en enterprisearkitektur bør anskues. Den samlede fremgangsmåde er bygget op omkring en model der minder meget om Bernards EA³ kube (Bernard 2005) og benytter sågar en navnekonvention på artefakterne der ligger meget tæt op ad Bernards rammeværk fra starten af årtusindet.

I fremgangsmåden anvendes der et perspektiv der definere forskellige domæner for, hvordan en organisations enterprisearkitektur kan opdeles. Fremgangsmåden nævner dog samtidigt områder  som standarder & configuration management, Configuration & Asset Management, Program & Program Management, Capital Planning & Portfolio Management  og Security & Privacy.

Elementer

Dertil findes der otte elementer der udgør rammeværket. Et af disse elementer udpeger en metode som bør anvendes sammen med Federal Enterprise Architecture (FEA) rammeværket.

Det første element omhandler styring (governance), styring er et element der egentlig udgør en stor del af rammeværket set med de muligheder der omtales i forhold til håndtering af rammerne af enterprisearkitektur rammeværket. Kuben der udgør organisationens  (der på mange måder minder om Scott Bernards EA³ kube). Fremgangsmåden arbejder med en antagelse om at begrebet ”integrated governance” kan opnås. Fremgangsmåden omhandler blandt andet processerne der er relateret til porteføljestyring og investeringsledelse, performance-styring, operating miljø der er en kombination mellem forretning og informationsteknologi.

Styringsdelen af fremgangsmåden en del af den overordnede fremgangsmåde. Metoden har til hensigt at understøtte udarbejdelse af handlingsrettede artefakter (artefakter der bruges af ledelsen til at træffe beslutninger ud fra jf. Definitionen i FEA-2).

Det andet element omhandler principper, der ifølge fremgangsmåden er opbygget omkring principper. Principperne har en række forskellige former for dele af organisationens struktur og i det overordnede miljø eller økosystem, som organisationen arbejder ud fra.

Principper kan kategoriseres inden for otte kategorier, hvis enterprisearkitekten arbejder meget stringent ud fra metoden:

• Fremtidssikring
• Investeringsstøtte
• Delte services
• Interoperabilitet standarder
• Adgang til information
• Sikkerhed og privatliv
• Teknologi adoptering.

Det tredje element omhandler metoden; og metoden der ligger til grundlag for fremgangsmåden er bygget op omkring et behov om, at enterprisearkitekten er med til at understøtte planlægning der også ligger uden for begrebet enterprisearkitektur. Enterprisearkitektur anvendes typisk kun inden for it-afdelingens rammer til at understøtte it-udvikling, men der findes i sagens natur også en verden uden for it-afdelingen som stiller krav til overholdelse af lovgivning og en fremadrettet udvikling af organisationernes processer og teknologier.

Metoden, der kaldes for ”Collaborative Planning Method”, består af to dele. Den første del kaldes organisering og planlægning (Organize and Plan). Den anden del omhandler implementering og måling (Implement and Measure).

Alt i alt omtaler dokumentet at der findes fem faser. Den første fase kaldes for identificering og validering, den anden fase kaldes for forskning (undersøgelse) og indflydelse og den sidste fase i den første del kaldes for definering og planlægning.  Den fjerde fase kaldes for investering og eksekvering og den sidste (femte) fase kaldes for udføre og måling.

Enterprisearkitekten spiller forskellige roller i de forskellige faser og faserne har stor betydning og mulighed for at påvirke de forskellige interessenter der findes til dem. Det er ikke uden betydning, hvordan enterprisearkitekten understøtter samarbejde mellem de forskellige individer der eksisterer.

Den første fase har betydning for at enterprisearkitekten en rolle der understøtter samarbejde på tværs af forskellige ledertyper og interessenter så de samarbejder om at identificere, validere og prioritere en fælles vision.

I den anden fase spiller enterprisearkitekten undersøgelses og forskningsmæssig rolle, hvor vedkommende undersøger om der findes andre organisationer der har været i en lignende situation, som værtsorganisationen, hvortil enterprisearkitekten vurderer om værtsorganisationen. Resultaterne bør fremlægges ledelsen således en mulighed for it – og forretningsudvikling hænger sammen.

Den tredje fase  at enterprisearkitekten begynder med at arbejde med de forskellige former for analyser der understøtter en ”integreret plan der understøtter et roadmap”  (s.20) der understøtter arkitekturens udvikling. Planen bør være handlingsorienteret så en række initiativer kan sættes i gang.

Den fjerde fase omhandler at enterprisearkitekten spiller en rolle, hvor han er i stand til at dele information med de forskellige beslutningstagere inden for områder som indkøb, finans og risici fordi det har stor betydning at de også forstår planerne og deres sammenhænge.

Den femte fase påvirker enterprisearkitektens rolle ved at indsamle og organisere information om ”udførelsen” (performance) og anvende informationen i den fremtidige planlægning.

Det fjerde element omhandler værktøjer, hvor fremgangsmåden anvender ideer der omhandler at der bør anendes værktøjer der understøtter, at EA biblioteket (depotet) bliver eksponeret til interessenterne i resten af organisatioenn. Dokumentet ligger vægt på at de forskellige artefakter er tilgængelige online. Ydermere beskrives det som en god idé at værktøjet der understøtter perspektiver der viser ledelsesperspektivet, sikkerhed, design af applikationer og infrastruktur.

Det femte element omhandler standarder, der i forhold til fremgangsmåden beskrives som værende en del af fremgangsmåden for at enterprisearkitektur artefakterne kan genanvendes på andre niveauer eller hos andre organisationer. Afsnittet omtaler ligeledes arbejdet med at få skabt en referencearkitektur. Referencearkitekturen bruges til at forklare hvad bør gøres i bestemte tilfælde fx i forhold til udviklingen af en proces eller udviklingen af en applikation.

Det sjette element omhandler anvendelse (eller brug), hvor fokus er på at sætte sit præg på at organisationerne så kræver det at enterprisearkitekturens position anskues som værende autoritativt.

Det syvende element omhandler rapportering omhandler at artefakterne kan bruges at skabe ledelsesinformation set i forhold til at kunne identificere ”capabilities”. Ideerne om ”capabilities” omhandler at enterprisearkitektur programmet kan bruges til at se de komplette billede af organisationens tilstand, og samtidigt kan enterprisearkitektur programmet bruges til at skabe et overblik over, hvad der kan gøres (hvilke projekter der bør sættes i gang) for at få organisationen til at virke bedre.

Det ottende element omhandler revision, hvilket vil sige at enterprise arkitektur programmet bruges til at undersøge om organisationens enterprisearkitektur lever op til de krav der er stillet til organisationen. Ligeledes kan enterprisearkitektur programmets metoder bruges til at undersøge om værdiskabes, om data er korrekte og om de rette metoder anvendes (s. 25).

Lagdeling af enterprisearkitekturen

Fremgangsmåden som dokumentet ”The Common Approach to Enterprise Architecture” omtaler er en bygget op omkring de lag der også er til at finde Bernards EA³ kube, og lagene er beskrevet nedenfor.

Det første lag omhandler strategi (strategic plans). Disse planer bruges til at give organisationen retning, og det giver naturligvis mening at disse planer er formuleret på et informeret grundlag, hvormed planerne kan implementeres og understøtte forandring. Det andet lag er bygget op omkring forretningsforståelse (business activities) og udgør en række artefakter der understøtter samlingen og organisering af viden derom. Det tredje lag er bygget op omkring data og information (data and information). Det fjerde lag er bygget op omkring systemer og applikationer (systems and applications). Det femte lag er bygget op omkring netværk og infrastruktur (Networks and infrastructure) og baseres sig primært på den hardware og den underliggende infrastruktur som anvendes i organisationen. Der findes ligeledes en fem domæner der har interesse.

Domænerne

Der findes fire domæner der anvendes i rammeværket på kuben nævnes de i følgende rækkefølge:

1)    Standards & Configurgation Management

2)    Configuration & Asset Management

3)    Program & Program Management

4)    Capital & Portfolio Management

5)    Security & Privacy.

Analyse

Fremgangsmåden viser at ”The Common Approach to Federal Enterprise Architecture” tager utrolig meget fokus at enterprisearkitektur programmet bruges til at forandre hele organisationen ud fra en samling af planer og koordinering med de forskellige typer interessenter. Alene tanken om at enterprisearkitektur programmet kan få den indflydelse og at organisationer kan ændres (afstemmes med) ud fra et sæt regler principper og tilsvarende kontrol af overholdelsen bør, efter min mening, sættes i samme skole som Enterprise Engineering, hvilket skyldes ønsket om Integrated Governance. Det virker til at den oprindelige tanke bag fremgangsmåden og rammeværket har været at enterprisearkitektur programmet kan forandrer organisationen radikalt ved at kunne opstille en strategi for forandring og at de forskellige interessenter i organisationen udvikler sig efter strategien. Enterprisearkitektur programmet påvirker dermed ikke alene de ”tekniske dele” inden for it-området. Fremgangsmåden omtaler den eller rettere de budgetkriser som føderalregeringen står overfor og selve målsætningen med rammeværket er at opnå enterprise roadmaps som har til formål at kunne anvende de ressourcer der stilles til rådighed på en bedre måde (s.3) set i forhold til at kunne indfri de behov, som organisationerne i den offentlige sektor står overfor: Brug færre penge, men lever større resultater.

Fremgangsmåden er bygget op omkring at en række forskellige dele af planlægningen bliver behandlet set i forhold til enterprisearkitektur programmet, hvilket har til formål at kunne understøtte ”integreret” ledelse (Integrated Governance), hvormed begreber som investering, adoptering af teknologi, procesforandring, programledelse og evaluering af de forskellige initiativer som mellemledelsen og topledelsen sætter i gang.

Forfatterne til fremgangsmåden har på sin vis taget højde for at enterprisearkitektur programmet og chefarkitekten ikke kan være ansvarlig for alt, og på sin vis kun kan påvirke beslutningstagerne. På det område er den nye føderale fremgangsmåde til anvendelse af enterprisearkitektur utrolig ambitiøs, men samtidigt stiller det også en række krav som for eksempel at de forskellige interessenter er interesseret i at høre, hvilke muligheder de har, og at de har blot en smule tillid til det som enterprisearkitekterne, informationsarkitekterne og løsningsarkitekterne udarbejder.

I kraft af at enterprisearkitektur programmet oftest vil være at understøtte it-afdelingen  (Doucet et al 2009) vil det også kræve at der findes tillid til det arbejde som it-afdelingen udføre, hvilket er en afhængighed der ikke nævnes i fremgangsmåden. I en skandinavisk kontekst vil det kræve at der også findes de rette sociale relationer mellem beslutningstagerne, it-direktøren og chefarkitekten.

Fremgangsmåden foreskriver der identificeres og udarbejdes artefakter. Artefakterne bruges sidenhen til udarbejdelse af planer for udvikling af organisationen som for eksempel processer, informationssystemer og det underliggende tekniske fundament.

Konklusion

Fremgangsmåden er opbygget omkring et behov for at der findes en fælles fremgangsmåde for at implementere og udføre enterprisearkitektur. Fremgangsmåden er på mange måder inspirerende, og metoden foreskriver en slags proces (faser) der understøtter udviklingen af enterprisearkitektur programmet, men i udgangspunktet fremhæves FEA-2 som værende fremgangsmåden. Det er dog foruroligende at fremgangsmåden er til at finde inden for skolen Enterprise Engineering og ikke som sådan er procesorienteret. Målet med fremgangsmåden er at producere ledelsesinformation der skal bruges til at opnå ”integreret ledelse” (Integrated Governance). Det betyder at chefarkitekten og enterprisearkitekten har til opgave at påvirke en lang række forskellige interessenter for at få dem til at arbejde sammen for at få organisationen til at arbejde i samme retning.

”Integreret ledelse” er et ambitiøst mål, men det er urealistisk at antage at ”integreret ledelse” kan opnås i en umoden arkitektur og modenhedsprocessen kan være utrolig lang set i forhold til

Det er min antagelse at metoden vil være svær at implementere under danske forhold, på trods af en fælles fremgangsmåde for anvendelsen af OIO EA i den offentlige sektor vil kunne understøtte en større og mere produktiv anvendelse.

Kilder

Bernard, Scott, A. An Introduction To Enterprise Architecture: Second Edition. 2nd ed. AuthorHouse, 2005.

Doucet, Gary, John Gøtze, Pallab Saha, and Scott Bernard. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance. International Enterprise Architecture Institute, 2009.

The CIO Council. The Common Approach to Federal Enterprise Architecture, 2012, http://www.cio.gov/documents/Common_Approach_to_Federal_EA.pdf, Accessed 9^th of September 2012.