Enterprise arkitektur er et vitalt fundament for udviklingen af en it-strategi (Hvidbog om it-arkitektur). Uden kendskab til organisationens arkitektur vil det ikke være muligt at få formuleret en it-strategi der rent faktisk kan afhjælpe nogle af de systemiske problemstillinger som organisationerne kan have.

Enterprise It-arkitektur

Ifølge John Gøtze, en af forfatterne til grønbogen og hvidbogen for it-arkitektur, skyldes anvendelsen af navnet it-arkitektur (i stedet for enterprise arkitektur) at den daværende videnskabsminister ikke ville ligge navn til noget der var for omfattende, hvormed navnet måtte justeres IT Arkitektur. It-arkitektur bør dog læses som Enterprise IT Arkitektur (EITA), men de to bøger er begge bygget op omkring et fokus på it. Ovenstående oplysning stammer fra en forelæsning John Gøtze afholdte på IT Universitet i København tilbage i 2010.

It-arkitektur omhandler formuleringen af opbygningen af applikationer, systemer og platforme og sammenhængene mellem dem. Fokus for et enterprise (it) arkitektur program understøtter en reel udvikling af flere dele end organisationens applikationsudvikling. Applikationslandskabet centralt, og fokus på applikationslandskabet kan medføre hurtigere udvikling samt en mere effektiv brug.  Dette af spejles i citatet nedenfor.

”IT-arkitektur beskriver den grundlæggende organisering af et eller flere IT-systemer, herunder principper for systemernes design og udvikling og for deres indbyrdes sammenhæng.” – Hvidbogen om it-arkitektur (2003, s.6).

Hvidbogen om enterprise arkitektur kommer ind på, at enterprise arkitektur programmet reelt leverer information til beslutningstagerne, når de vel at mærke skal blive enige om at der skal udarbejdes en ”afstandsanalyse”. Afstandsanalysen har til formål at identificere, hvor organisationen befinder sig (as-is situationen), og samtidigt give beslutningstagerne valide informationer om, hvordan organisationen kan udvikle sin it-arkitektur for at fremme omstillingen af organisationen til det stade, som beslutningstagerne vil have at organisationen opnår (det der kaldes for to-be arkitektur). I citatet nedenfor fremgår det at enterprise (it) arkitektur kan bruges med forskellige optikker som for eksempel kvalitetsforbedring, omkostningsreduktion og optimering.

”IT-arkitektur er et velegnet redskab til at sikre en fælles ramme med henblik på kvalitetsforbedring, ressourceoptimering og omkostningsreduktion.” – Hvidbogen om it-arkitektur (2003, s.20).

Enterprise arkitektur programmet er ikke et simpelt lineær-projekt, hvormed alle problemer er løst efter et projekt er sat i gang og implementeret.

”Arkitekturen bliver til i en kompleks proces, der på ét niveau går fra vision til implementering, drift og evaluering. Processen er langt fra lineær, ligesom det er en misforståelse at se processen som en, der går fra punkt A til punkt B. IT-arkitektur er en kontinuerlig proces, der har til formål at sikre en løbende forbedring af IT-anvendelsens værdi.” – Hvidbogen om it-arkitektur (2003, s.37).

Enterprise arkitektur som koncept kan bruges til mere end blot at skabe overblik over it-afdelingen, og i udgangspunktet vil det være muligt at få behandlet de forskellige forretningsenheder i forhold til at dokumentere de faktiske forhold og kunne levere de nødvendige artefakter der viser sig nødvendige i forhold til at kunne understøtte en form informeret ledelse.

”Både strategiprocessen og implementeringsprocessen er cykliske forløb, som systematisk bringer IT anvendelsen på linje med de forretningsmæssige mål.” – Hvidbogen om it-arkitektur (2003, s.36).

Doucet et al (2009) arbejder med en antagelse om at enterprise arkitektur programmet sættes i gang for at servicere it-afdelingen. Formålet er ed at få styr på problemstillingerne i it-arkitekturen. Eksempler kunne være at få sat styr på, hvor mange applikationer der findes i organisationen.

I forbindelse med at få styr på organisationens applikationslandskab, så giver det mening for chefarkitekten at få sat styr på de beslutningsmæssige grundlag for, hvordan fremtidige applikationer skal indkøbes. Konkret vil der være tale om, at organisationen principper udformes som specifikke huskeregler således det bliver muligt for beslutningstagerne at træffe beslutninger der ikke direkte er destruktive for organisationens enterprise arkitektur.

I citatet nedenfor fremgår det at arkitektur processen blandt andet omhandler udarbejdelsen af principper og når det kommer til arbejdet kommer til arbejdet med formulering af principperne. Principperne der formuleres har betydning for udviklingen af it-arkitekturen.

”I arkitekturprocessen formulerer man de konceptuelle arkitekturprincipper, som styrer valget og organiseringen af IT løsningerne. En nøglefaktor er at beskrive de ønskede – eller påtvungne – forretningsmæssige ændringer, som IT skal understøtte.”  – Hvidbogen om it-arkitektur (2003, s.16).

Enterprise arkitektur funktionen (og programmet) kan være med til at sikre at de data der findes i organisationens it-systemer (databaser osv.) kan udveksles med hinanden, hvis enterprise arkitektur funktionen vel at mærke får muligheden for formulere standarder samt at de ansvarlige mellemledere håndhæver standarderne. Standardisering er en taktik og en strategi der kræver mange forskellige profiler der kan tage stilling til problemstillinger i forhold til, hvad de enkelte standarder kommer til at omhandle. Det kræver ressourcer, handlekraft og tillid mellemparterne der indgå i en sådan et udvalg. Standardisering kan dog vise sig at være en nødvendighed både i forhold til forretningsprocesser og i forhold til it-udvikling og det gør ikke problemstillingen mindre på nogen måde. Hvidbogen om IT-arkitektur omtaler der skal udvælges og fastlægges en centralt udvalg (komité) der fastlægger standarderne (læs citatet nedenfor), men det er som sådan ikke nok blot at udvælge standarderne, siden der skal være et fokus på undersøgelse om udviklingen overholder standarderne og sikring af at kontrollen og udbedringen forefindes. Dermed skal komitéen have delegeret ressourcer, ansvar og magt.

”Den tekniske standardisering bør tage udgangspunkt i internationale, åbne standarder eller i mangel heraf de facto standarder. Det vil være en central opgave for komitéen at udarbejde en oversigt over standarder med anbefalinger om deres anvendelse.” – Hvidbogen om it-arkitektur (2003, s.18) .

Arkitektur strategien går ud på at opstille et fora for dialog. Dialogen omhandler at skabe forståelse mellem beslutningstagerne i de forskellige forretningsenheder og beslutningstagerne i it-afdelingen til at tale sammen og finde frem til, hvilken retning som organisationen skal tage. Dialogen bruges til at skabe tillid mellem partnerne og arkitektur-strategien bør fokusere på at prioritere strategiske it-baserede forretningsprojekter (ibf-projekter). Dialogen bør i længden understøttes af et fælles prioriteringsværktøj, hvilket vil sige en model eller matrice som de forskellige beslutningstagere er uddannet i at anvende. Denne stadie kan først opnås der findes en hvis grad af tillid mellem beslutningspartnerne, men situationen kan variere meget fra organisation til organisation og de mennesker der udgør beslutningstagerne. Ifølge Hvidbogen om IT-Arkitektur er dialogen vigtig, da det er her de forskellige beslutningstagere er i stand til at kunne kommunikere i de samme rammer.

”Et centralt led i IT-arkitektur-processen er den dialog, hvor forvaltningsforståelse og teknologiforståelse mødes.” – Hvidbogen om IT-arkitektur (2003, s.45) .

Den strategiske dialog er vigtig, men det kræver at flere forskellige mekanismer er på plads i organisationen. Typisk vil det på et tidligt modenhedsniveau være et it-governance råd der tog sig af disse nødvendigheder.

Med udgangspunkt i fundament-arkitekturen og med et specifikt fokus på it-arkitekturen. Typisk vil det betyde at enterprise arkitektur funktionen vil komme til at fokusere på applikationslandskabet.

For at enterprise arkitektur programmet kan være med til at levere de informationer der er med til at forandre noget så kræver det en strategi og det kræver fokus og prioritering.

Arkitektur-strategiens rolle

Arkitektur-strategien er et fundament i den gode it-strategi, da arkitektur-strategien omhandler, hvordan organisationen vil skabe overblik over sin nuværende situation (skabe as-is billedet), finde muligheder og skabe værdi igennem forandringerne (to-be situationen). It-strategien bør formuleres på et informeret grundlag, da strategien ellers med en stor sandsynlighed ikke vil kunne understøtte reelle forandringer for organisationen.

“IT-arkitekturens opgave er at organisere det overordnede design af IT systemerne på en måde, så værdien af IT-investeringerne bliver maksimeret, målt med forretningens definition af værdien” – Hvidbogen om IT-arkitektur (2003, s. 44)

Brian Burke og Betsy Burton (2012) argumenterer for at der findes fem niveauer for artefakter. De fem niveauer har stor betydning for, hvilken service som enterprise arkitektur funktionen levere.

Enterprise arkitektur funktionen anvender rammeværker. Rammeværker indeholder typisk en til flere metoder til identificering af artefakter. I udgangspunktet definerer rammeværkerne også hvilke artefakter der bør prioriteres for at fremgangsmåden bliver overholdt.

Rammeværkerne udleder typisk artefakter der kan kategoriseres inden for følgende fem elementer:

1)     Applikationer

2)     Netværk (og andre typer infrastruktur)

3)     Forretningsprocesser

4)     Strategier og taktiker

5)     Principper og standarder.

Artefakterne bør i udgangspunkt vise sandheden, altså virkeligheden som den anskues (gerne fra flere forskellige interessenters synspunkter) og anvende de forskellige artefakter til at skabe overblik. Informationerne der udgør de forskellige artefakter udgør vigtig information der kan bruges i forhold til at understøtte planlægning der bør fremgå i it-strategien.

Typiske spørgsmål som kan besvares, hvis enterprise arkitektur funktionen arbejder ud fra en prioritering, hvor fokus er på at undersøge applikationer, databaser, databasestrukturer og datahåndtering:

1. Er vores applikationer tidssvarende?
2. Kan vores databaser opgraderes?
3. Hvor finder vi vores data? Er vores data gode nok i forhold til at vi kan implementere en BI-løsning?
4. Hvor stor en risiko er der med vores nu værende løsninger?

Et enterprise arkitektur program bør indeholde en hvis grad af dokumentation for, at enterprise arkitektur programmet kan producere artefakter der understøtter informeret ledelse. På den anden side bør fokus for enterprise arkitektur programmet ikke blive at dokumentere organisationens enterprise arkitektur i alle dens facetter. Det er nødvendigt for chefarkitekten at prioritere, hvilke opgaver som enterprise arkitektur programmet skal være med til at løse.

Hvis enterprise arkitektur programmet er bygget op omkring fremgangsmåden kendt som Dynamic Architecture (forkortet DYA) er det ultimative selekteringskriterium for om en model eller et initiativ sættes i gang er om der er findes et behov for det i organisationen. Efterspørger individer eller grupper i organisationen de specifikke informationer? Hvis informationerne eller løsningerne ikke efterspørgeres så bør modellen eller initiativet ikke prioriteres.

Prioritering

For at enterprise arkitektur programmet kan udarbejde relevante artefakter så kræver det at enterprise arkitektur funktionen prioritere benhårdt. Prioriteringen afhænger meget fra organisation til organisation og hvilket stadie som enterprise arkitektur programmet er på. Det handler om at prioritere for at levere løsninger og information som sikre at beslutningstagerne kan træffe beslutninger baseret på informeret ledelse. Informeret ledelse er grundlaget for at de fleste organisationer og virksomheder er i stand til at opnå konkurrencemæssige fordele.

Informeret ledelse blive rigtig vigtig set i forhold til gap-analysen, da den er med til at producere en del af den information der er vigtig set i forhold identificering og prioritering af de rette projekter.

”Gap-analysen beskriver hvordan de eksisterende løsninger, metoder og organisation passer med de konceptuelle arkitekturprincipper.” – Hvidbogen om it-arkitektur (2003, s.39) .

Prioriteringen bør være baseret på, hvad der på sigt vil skabe den største værdi for organisationen.

Værdi

Værdi er subjektivt og afhænger af aftagerens præferencer. I en organisation er der ofte mange forskellige typer aftagere, og deres forståelse af begrebet værdi kan direkte være modsatrettet.

Jeg kan huske en sådan situation fra en case, som jeg arbejdede med under mit studie, hvor topledelsen havde opbygget nogle it-styrings mekanismer der ville forstærke deres greb om it-projekter der ville få tildelt ressourcer. Ideen var at begrænse de forskellige forretningsenheders muligheder for at udvikle egne it-løsninger, og i stedet fokusere på at udvikle ”enterprise” relaterede løsninger på koncernniveau. Værdi fastsættelsen mellem koncernen (især ledelsen) og de forskellige forretningsenheder var direkte modstridende, og forretningsenhederne følte det som en negativ indgriben i deres arbejde.

I sådan en situation ville det ikke være muligt for enterprise arkitektur programmet at skabe værdi for alle parter og der ville nok være en situation for de enkelte forretningsenheder vil opleve en mindsket tilfredshed med enterprise arkitektur funktionen. Chefarkitekten bør derfor være i stand til at identificere interessenterne til enterprise arkitektur funktionen så de er i stand til at kunne indfri løfter til de interessenter der med tiden vil have stor indflydelse på enterprise arkitektur programmet.

Der skal skabes værdi, og værdi er i den hensigt, at beslutningstagerne synes at de artefakter (planer, taktiker, råd og vejledning osv.) understøtter løsninger på de problemstillinger som de sidder inde med.

Lapkin & Papegaaij (Gartner Group) understøtter denne antagelse (2010), hvor begrebet ”forretningsværdi” bliver omtalt, som værende det vigtigste paradigme for de forskellige parter, men i realiteten vil chefarkitekten og enterprise arkitekten opnå langt større resultater, hvis de rette interessenter bliver identificeret og enterprise arkitektur funktionen er i stand til at imødekomme deres problemstillinger.

Rollen som arkitektur-strategien spiller er central i forhold til hvilken retning som enterprise arkitektur programmet tager. Med udgangspunkt i OIO EA rammeværket så findes der en række forskellige steder, hvor chefarkitekten kan vælge at tage sit udgangspunkt i. Andre rammeværker opdeles i forskellige lag. De forskellige lag er bygget op omkring at tage hensyn til forretningsarkitekturen så som strategien, produkt  og forretningsprocesser og det giver god mening at starte med at udarbejde artefakter der kan relatere sig til at identificere værdi.

Konklusion

Arkitektur-strategien er en nødvendighed at have styr på set i forhold til at chefarkitekten sammen med enterprise arkitekterne er med til at udarbejde artefakter der til sammen udgør de forskellige dele af det samlede billede som organisationens beslutningstagere kan gøre brug af i forhold til at træffe beslutningerne.

Arkitektur-strategien bør arbejde med forskellige former med artefakter og typisk vil der være tale et fokus på applikationslandskabet så som hvilke platforme, applikationer og informationssystemer, som organisationen råder over.

Det er en vigtig del af den samlede it-strategi (typisk vil der findes referencer til arkitektur-strategien fra it-strategien), da arkitektur-strategien identificere hvilke dele organisationen enterprise arkitektur der undersøges og hvordan de kan undersøges.

Arkitektur-strategien bør fokusere på en benhård prioritering for at sikre at den rette mængde og type information bliver overleveret til beslutningstagerne. Det handler om at sikre at den information der er til stede er så relevant og skaber så meget værdi som muligt.

Kilder

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.

Arbejdsgruppe om IT-arkitektur i regi af det Koordinerende Informationsudvalg. Hvidbog om IT-arkitektur, 2003.