Den amerikanske føderal regering, har et CIO-råd der udgiver metoder, rammeværker og tekster om enterprisearkitektur. CIO-rådet har udgivet en ny metode omhandlende anvendelsen af enterprisearkitektur for de forskellige . Metoden er beskrevet i dokumentet ”The Common Approach to Federal Enterprise Architecture”.

Jeg har i et tidligere blogindlæg beskrevet og analyseret lagdelingen, komponenterne og domænerne i fremgangsmåden, og i dette blogindlæg vil jeg se på de artefakter der beskrives som værende en del af den dokumentation der bør være til stedet for at enterprisearkitektur programmet er i stand til at kunne producere og levere den nødvendige ledelsesinformation.

I dokumentet fremhæves det at rammeværket har betydning i form af at rammeværket definere målet for arkitekturen, og i den forbindelse definerer rammeværket de perspektiver der anvendes i forhold til at understøtte analyse, design, dokumentation og rapportering (s. 21).

Generelt set bruges den samme tilgang til identificering og organisering af artefakter som den der anvendes i Bernards EA³ Cube framework. Det vil sige at der findes artefakter for hvert lag i kuben. Disse kaldes i dokumentet for ”sub-architecture domains”. De forskellige underarkitekturer er beskrevet nedenfor:

• Strategisk domæne der omhandler de overordnede strategier der er lagt for organisationen.

• Forretningsservice domænet der er struktureret omkring forretningsprocesser, videnledelse, organigram og forretningsscenarier (business cases og alternativer).

• Data og Informationsdomæne omhandler videnledelse, plan for data kvalitet, data flow og en ”data ordbog”.

• Applikations domænet der er bygget op omkring hvordan de forskellige applikationer kommunikere med hinanden.

• Infrastruktur domænet omhandler hvordan de forskellige typer hardware, netværkskomponenter og servere hænger sammen.

• Sikkerhed domænet der omhandler procedure, systemer, hvem der har adgang til hvad og genskabelse af forretningsprocesser.

Hver af underarkitekturene har betydning i forhold til at kunne give enterprisearkitekterne mulighed for at kunne arbejde med at skabe overblik over de problemstillinger der end måtte findes i organisationen og udarbejde løsningsalternativer (eller scenarier), som organisationens beslutningstagere bruge til at få løst de problemstillinger som står i vejen for, at organisationen opnår sine strategiske mål.

Artefakterne

Artefakterne er i dokumentet kendt som kerne artefakter (s.27), hvilket må siges at være tale om at netop disse artefakter er ufravigelige. Det giver på sin vis god mening at enterprisearkitektur programmerne på tværs af den amerikanske føderal regering udarbejder visse typer artefakter der er nogenlunde ensartet i forhold til at de kan findes på tværs af institutioner og det dermed ligges et grundlag for at samarbejde og information kan udveksles. På sigt kan måske en benchmark finde sted mellem de forskellige arkitekturer for organisationer der behandler nogenlunde tilsvarende opgaver og ”best practices” kan udarbejdes.

Der findes seks kerne diagrammer der er nødvendige i forhold til udvikling af enterprisearkitektur programmet. Disse kerne diagrammer er obligatoriske (s. 26), hvilket skyldes at fremgangsmåden og artefakterne har til formål at kunne få de forskellige føderale organisationer til at samarbejde og dele information om hinanden. Kerne artefakterne er fra hver deres underarkitektur:

1. Diagram konceptuelt overblik (S-1),
2. Et konceptuelt overblik over processer (B-1),
3. Et konceptuelt overblik over den logiske data-model (D-1),
4. Diagram over applikationernes interface (A-1),
5. Et konceptuelt netværksdiagram (I-1),
6. En kontrol liste (SP-1).

Der findes ligeledes en række artefakter der er valgfrie at udarbejde. Det må være en antagelse at de valgfrie artefakter udelukkende har til formål at give en større overblik over den enkelte organisation, og vel også at understøtte en bedre mulighed for at kunne få indblik de reelle forhold der findes i de mange grene af føderale organisationer.

De valgfrie artefakter for den strategiske subarkitektur er den strategiske plan (navngivet S-2), et overblik over organisationens koncept (S-3), SWOT-analyse (S-4) og et performance measurement scorecard (S-5).

Underarkitekturen der arrangeret under det strategiske lag end den strategiske arkitektur er forretningsdomænet (s.28). Forretningsdomænet består af en ”operating plan” (B-2), forretningsservice katalog, organisationsdiagram og et artefakt kendt som ”use case narrative”. En operating plan (eller model) omhandler at vise, hvordan processer og teknologi spiller sammen for at kunne levere en ydelse eller vare til kunderne. Ross et al (2006, s.8) definerer en operating plan som værende måden hvor på forretningsprocesser standardiseres og den integration for at levere produkter og services til kunderne.

Dernæst kommer subarkitekturen dataarkitektur. Dataarkitekturen består af en række artefakter som videnledelses plan (D-2), plan for datakvalitet (D-3) data flow diagram (D-4), fysisk datamodel (D-5), CRUD matrix (D-6), State Transition Diagram (D-7), Sekvens diagram for begivenheder (D-8), Dataordbog (D-9) og objekt bibliotek (D-10).

Under dataarkitekturen findes underarkitekturen for applikationer. Applikations kommunikations diagram (A-2), Application Interface Matrix (A-3), Application Data Exchange Matrix (A-4), Application Service Matrix (A-5), Application Performance Matrix (A-6), System/Application Evolution Diagram (A-7), Enterprise Service Bus diagram (A-8), Vedligeholdelse procedure for applikationer (A-9), Inventarliste for applikationer (A-10) og en software licenser.

Subarkitekturen omhandlende infrastruktur i forhold til værtsorganisationens infrastruktur overblik for ”Concept of Operations” (I-2), profil for tekniske standarder (I-3), En forudsigelse for teknologi der har relevans for infrastrukturen (I-4), En oversigt over kabler (I-5), Oversigt over trådløse teknologier (I-6), overblik over ”server racks” og de forskellige serveres indhold (I-7), et diagram over serverrum eller datacentre der anvendes (I-8), Diagrammer over kabler i kabelskabe (I-9), Tilstedeværelses diagram (I-10), liste over inventar (I-11) og blåtryk for de bygninger som infrastrukturen findes i.

Den sidste subarkitektur der behandles i dokumentet omhandler sikkerhed omhandler sikkerhed og privatlivs plan (SP-2), Certificering og akkrediterings dokumentation (SP-3), monitorerings procedure (SP-4), Katastrofeplan for og det sidste artefakt omhandlende Kontinuitet af aktiviteter og processer (SP-6).

Fokus for anvendelse af artefakterne

Et Enterprise Roadmap omhandler performance forskelle (gaps), ressource allokering og behov, planlagte systemer, transformationsplaner og et fordelt fokus mellem den nuværende arkitektur, som arkitekturen skal beskrives og den fremtidige arkitektur (s. 35).

Ifølge dokumenter ”The Common Approach to Federal Enterprise Architecture”  kommer ind på at der bør være en transformations plan og en et perspektiv for hvert arkitektur projekt set i forhold til udviklingen af selve organisationens enterprisearkitektur.

Analyse

De forskellige artefakter er som sådan ikke defineret i dokumentet ”The Common Approach to Federal Enterprise Architecture”. Det er min antagelse at artefakterne er defineret bedre i rammeværket som den Amerikanske føderale regering anvender, hvilket er kendt som Federal Enterprise Architecture Framework version 1 (FEA-1). Jeg har dog haft tid til at se på FEA-1, hvortil jeg kan konstatere at der ikke findes konkrete eksempler på, hvordan de forskellige artefakter bør se ud eller hvilken fremgangsmåde der bør følges for at udarbejde dem. Den føderale fremgangsmåde for håndtering af enterprisearkitektur mangler en fremgangsmåde der understøtter artefakter der er udarbejdet på samme måde og tager hensyn til den eller de problemstillinger, som organisationerne udarbejder.

Jeg er af den holdning at det virke som en god ide at have en fælles metode for at arbejde ud fra en fælles metode, men det kræver at de forskellige artefakter bliver defineret og illustreret på en måde der gør det muligt for de enkelte enterprisearkitekter at udarbejde de forskellige artefakter.

Fokus for arbejdet med et enterprisearkitektur program er at understøtte planlægning, det der i dokumentet bliver omtalt for Enterprise Roadmap. I den forbindelse kommer dokumentet ind på at der findes en forskel mellem roadmap og transitionsplan. Ydermere bør enterprisearkitektur programmet understøtte at der kan skabes et perspektiv over de forskellige enterprisearkitektur projekter der er sat i værk. Det kan virke som en inspiration, men det kan også virke som en barriere for udvikling af den specifikke organisations enterprisearkitektur program. Det er en nødvendighed at få styr på, hvordan de forskellige artefakter skal udarbejdes og hvordan de indgår i en større kontekst. Den nuværende fremgangsmåde understøtter ikke denne udvikling og ligeledes må det siges, at FEA-1 vil ikke definere artefakterne eller måden hvorpå de skal udarbejdes, hvilket gør det svært at kunne sammenligne enterprisearkitektur.

Dokumentet og fremgangsmåden besidder en række interessante karakteristika som for eksempel ved at det er muligt for de forskellige organisationer er i stand at kunne samarbejde og dele viden omkring hvordan problemstillingerne kan løses og finde frem til ”best practices” og genbrug af løsninger mellem lignende organisationer og afdelinger. Fremgangsmåden understøtter kun delvist en deling af viden i det der ikke virker til at der findes et specielt bibliotek eller depot, hvor artefakterne kan deles på tværs af organisationerne.

Fremgangsmåden blev som nævnt i den første blogindlæg omkring fremgangsmåden, kan kategoriseres som værende en del af enterprisearkitektur skolen kendt som Enterprise Engineering, hvilket skeer igennem ved at enterprisearkitekten og chefarkitekten spiller en central rolle i forhold til at sikre sammenhæng mellem de beslutninger der berør it-afdelingen såvel som de beslutninger der ligger langt uden for, hvad der traditionelt vil tolkes som værende inden for it-afdelingens domæne.

Enterprise Engineering er et koncept der griber om sig fx i form af Hoogervorsts værk ”Enterprise Governance and Enterprise Engineering” der kobler opbygning og styring af organisationer ud fra de principper og metoder der er opbygget omkring enterprisearkitektur. I den kontekst kommer enterprisearkitektur programmet ind på at der opstilles rammerne for den retning som organisationen skal udvikles.

Konklusion

Der findes en masse grunde til at arbejde med en metode i forhold til udarbejdelse af artefakter og måden hvorpå de skal analyseres. Fremgangsmåden er, i forhold udviklingen af enterprisearkitektur programmet, en god idé. Den nuværende fremgangsmåde kan tolkes som det andet skridt i retning af en fælles enterprisearkitektur program fordi der nu findes et fælles rammeværk og hvad der minder om en fælles metode for, hvad enterprisearkitektur programmet bør bruges til. Det næste logiske skridt bør være fælles metoder for udarbejdelse af de forskellige artefakter, da det ellers vil være meget svært at kunne sammenlige de forskellige organisationers arkitekturer og ”performance”.

Kilder

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

Hoogervorst, Jan A. P. Enterprise Governance and Enterprise Engineering. Springer, 2009.

Ross, Jeanne W., Peter Weill, and David C. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. illustrated ed. Harvard Business School Press, 2006.