Enterprisearkitektur programmer kan med tiden gå hen og sande til. Et typisk eksempel vil være, når en ny it-direktør bliver ansat og vedkommende ikke har haft kendskab til enterprisearkitektur som koncept eller vedkommende ønsker informationer omhandlende andre emner eller andre problemstillinger, som it-afdelingen eller hele organisationen arbejder ud fra.

I disse tilfælde kan det vise sig nødvendigt at chefarkitekten arbejder for at tilpasse enterprisearkitektur programmet.

Planlægning og afgrænsning

Der findes en række interessante perspektiver som bør tages i betragtning. Perspektiverne bør tages i betragtning:

1. Hvad efterspørger de forskellige interessenter?
2. Hvem efterspørger hvad?
3. Hvad kan leveres?
4. Hvad bør prioriteres?

Ydermere bør chefarkitekten arbejde med at få defineret, hvordan sit enterprisearkitektur bør være konstrueret. Vil chefarkitekten arbejde med et enterprisearkitektur program der primært fokuserer på en proces der fokuserer på udviklingsprocessen i stedet for it-landskabet og standarder? Eller bør fokus være på en større proces hvor en række forskellige artefakter som på sin vis vil kunne understøtte de behov og ønsker som interessenterne har i organisationen?

Med et fokus på processen for at skabe enterprisearkitektur bør en række afgrænsninger tages. Derfor bør chefarkitekten identificere bestemte områder der kan vise sig at skabe værdi og dermed gøre enterprisearkitektur programmet relevant.

Dynamisk arkitektur

Dynamisk arkitektur (Wagter et al 2005) er en fremgangsmåde, hvor der er ganske få enterprisearkitekterne ansatte som arbejder med specifikke opgaver som de forskellige interessenter efterspørger. De modeller der viser sig relevante bliver opbevaret i et såkaldt EA bibliotek, hvor de så kan findes frem igen, hvis de viser sig relevante.

Modellerne indgår blandt andet i at kunne understøtte rammerne for udvikling af projekter. Projekterne kan på sigt medføre nogle dokumenter der kan eller bør tages i betragtning på sigt.

Fokus for enterprisearkitektur programmet er dog at understøtte behov for udvikling af it-systemer og processer i organisationen. Enterprisearkitektur programmet er i den forbindelse også afgrænset set i forhold til to forskellige former for udvikling, som enterprisearkitektur programmet ikke anvendes til. Den ene af disse er hastig udvikling på grund af behov for at matche konkurrenterne (offensiv strategi) og den anden type udvikling omhandler den defensive strategi. Ifølge Wagter et al (2005) så vil den defensive strategi typisk være underlagt visionen og den offensive strategi hører under målsætninger.

Der kan typisk være nogle problemstillinger med kun at understøtte en ”pull” strategi og i den forbindelse kan andre rammeværker så som IDEA-rammeværket, EA³ kube-rammeværket eller TOGAF. Det er især et fokus på at kunne påvirke den rette form for udvikling som organisationens interessenter udtrykker behov for kan blive opbygget.

Investeringsdrevet arkitektur

IDEA – rammeværket (Investment Driven Enterprise Architecture) fokuserer på tre overordnede temaer der hver især giver et indtryk af hvilke artefakter der bør udarbejdes. De tre temaer omhandler investeringerne foretaget i fortiden, investeringer der foretages her nu (samtiden) og investeringer der vil foretages i fremtiden.

Selvsagt så giver det mest mening for et enterprisearkitektur program at fokuserer på de fremtidige investeringer, da det er disse områder, hvor enterprisearkitektur programmet har mulighed for at påvirke organisationens udvikling.

De tre artefakter som Anupindi & Coady (2011) omtaler i IDEA-rammeværket omtaler er application roadmaps, technology roadmaps og technology standards.

De fastlagte artefakter kan anvendes sammen enterprisearkitektur program der primært har anvendt en ”pull” strategi. Årsagen hertil skyldes at enterprisearkitektur programmet bør kunne vise de interessenter, hvad de kan bruge enterprisearkitektur programmet til på sigt, da det som tidligere nævnt kan ske at en eller flere nye beslutningstagere kommer til organisationen, og som ikke forstår de muligheder, som de har til rådighed.

Hvor ligger skillelinjen

Hvornår bliver det et nødvendigt at arbejde med at præsentere ”push” elementer? Det kan det blive meget tideligt i arbejdet med et enterprisearkitektur programmet, da fokus på udviklingen af enterprisearkitektur programmet påvirker henholdsvis interessenterne, og det der forventes at enterprisearkitektur programmet skal levere.

Balancen er derfor et personligt skøn som chefarkitekten gør sig, når han taler med de andre beslutningstagere. Artefakterne fra for eksempel IDEA-rammeværket kan bruges at introducere de overordnede rammer som enterprisearkitektur programmet bør være bygget op omkring og understøtte værdiskabelse for interessenterne. Primært vil værdiskabelsen være til at finde inden for it-afdelingens domæne så som teknologistrategien, standarder og application roadmaps. Det handler om fremtiden og hvordan enterprisearkitektur programmet kan understøtte organisationen fremad rettet.

Kilder

Anupindi, N.V. & Coady, G.A., 2011. Enterprise Architecture Turnaround, Trafford Publishing.
Wagter, R. et al., 2005. Dynamic Enterprise Architecture: How to Make It Work 1st ed., Wiley.