Overordnet set findes der økonomiske perspektiver der støtter op om anvendelsen af implementering og vedligeholdelse af et enterprisearkitektur program. Ifølge Doucet et al (2009) så er den mest udbredte form for enterprisearkitektur inden for rammerne eller domænet der kan kaldes for it-afdelingen. Fokus for enterprisearkitektur programmet er derfor at understøtte, hvad der traditionelt set antages som værende en støtteenhed.

Støtteenheder anskues ofte som værende omkostningscentrer, hvilket betyder at de forventninger, som resten af organisationen har, kan kategoriseres inden for den ramme at omkostningerne skal sænkes. Habib et al understøtter tanken om at enterprisearkitektur programmet kan bruges til at sænke omkostningerne hos it-afdelingen. Dette kommer til udtryk i citatet nedenfor:

“It [Enterprise Architecture] can increase visibility into total cost of ownership. Established enterprise architecture principles enables better control of the information systems / application inventory and management of systems / applications. Improves total cost of ownership visibility and has the potential to reduce overall costs” – Habib et al (2011).

Et enterprisearkitektur dog ikke omkostningsfrit. Chefarkitekten, enterprisearkitekterne, løsningsarkitekterne og informationsarkitekterne har krav på løn og de bruger i deres virke også en række forskellige værktøjer så som:

1. Computere og netværksinfrastruktur
2. Basal software som operativsystem, kontorprogrammer
3. Specialiseret software der kan bruges til at tegne, organisere og eksponere artefakterne.

Specialiseret software er som regel dyr sammenlignet med COTS software som de fleste større organisationer i forvejen har licensaftaler på, og specialiseret software kan være med til at øge omkostningerne for anvendelsen af enterprisearkitektur programmet. Set ud fra en større kontekst kan et enterprisearkitektur program på kortsigt være med til at øge omkostningerne for en organisation i form af at der allokeres mange ressourcer til identificering af artefakter, og det er først når artefakterne er indsamlet bliver muligt for organisationen at kunne arbejde planer for, hvordan organisationen kan udvikles (CIO Council, 2011), og hvordan synergier kan skabes på tværs af de afdelinger og teams der findes.

Dertil kan enterprisearkitektur programmet påføre en omkostning i form af at enterprisearkitektur programmet udsteder rammer og regler for, hvordan organisationen skal udvikles. Blandt de omkostninger som Garvey et al (2004, s. 102) har identificeret så er følgende kategorier typisk en del af EA igangsættelse (definition), EA udviklingsomkostninger, EA implementeringsomkostninger og vedligeholdelsesomkostninger, hvilket kaldes for EA livscyklus omkostninger i dokumentet.

Det kan være svært at afgøre, hvor stor en effekt som enterprisearkitektur programmet har siden der er tale om et program der understøtter udviklingen af en række forskellige projekter (eller initiativer) der er med til at understøtte de mål der findes for enterprisearkitektur programmet. Fordi der kan være en række forskellige interessenter involveret for hvert projekt kan det betyde at arbejdet med at identificere den rette størrelse af omkostningsreduktionen, som enterprisearkitektur programmet bidrager med fordi de forskellige interessenter ligeledes vil gøre krav på æren.

Der findes dog visse områder som enterprisearkitektur programmet kan være med til at optimere ved at begrænse indkøb af applikationer der yder den samme funktionalitet (genbrugbarhed), ensretning af udviklingsprojekter i organisationen, overholdelse af standarder og udvikling af et roadmap til håndtering af problemstillinger der relatere sig til livsomkostninger ved anskaffelse og implementering af applikationer. På sin vis kan enterprisearkitektur programmet kan påvirke større områder, hvor den økonomiske påvirkning først kan måles mange år frem i tiden. Det gør det svært for enterprisearkitektur funktionen at kunne påvise sin værdiskabelse.

Anupindi & Coady (2011) arbejder med en anskuelse om at enterprisearkitektur programmet arbejder med en fremgangsmåde, hvor vedkommende først og fremmest skal kunne styre sit programs eget budget samt kunne påvise at de forskellige arkitekter tilføre værdi til it-organisationen. Anupindi & Coady arbejder med en antagelse om at enterprisearkitektur primært findes i it-afdelingen og har til formål at understøtte udvikling af it-afdelingen. John Zachman, som oprindeligt udgav den første artikel der omhandlende enterprisearkitektur, mener ikke som sådan at enterprisearkitektur kan kvantificeres i forhold til omkostninger ved at kvantificere, hvor mange omkostninger som enterprisearkitektur programmet er med til at spare. Zachman (2001), arbejder derimod om med ideer om at enterprisearkitektur skal arbejde med er begreber som afstemning, integration, forandring og reduceret tid fra idé i et laboratorium (R&D til lancering på markedet (brugerne).

Dermed må det konstateres at omkostningsreduktion kan være en fin indgangsvinkel til organisationen begynder på at arbejde med at implementere enterprisearkitektur programmet, men på sigt så bør det være et mål for chefarkitekten at arbejde sig ind på at fokuserer på at skabe grobund for udvikling og for modning af organisationens evne til at håndtere udvikling og implementering af teknologi. Kvantificering af omkostningerne som enterprisearkitekturen kan påvirke kan virke utrolig svær at gennemføre, men i stedet for at fokusere på omkostningerne bør beslutningstagerne og chefarkitekten bør fokusere på ”capabilities” og de fremtidige omkostninger som enterprisearkitektur programmet kan være med til at forhindre som for eksempel ved at fjerne applikationer med redundante funktioner, services og processer samt forhindring af applikationer, processer og services bliver risici for organisationen.

Konklusion

Enterprisearkitektur medføre omkostninger i sin livscyklus (EA lifecycle), men samtidigt kan enterprisearkitektur programmet være med til at begrænse omkostninger der er relateret til udvælgelse af teknologier, implementering af applikationer, udvikling af teknologier og skrotning af teknologier. Fokus for arbejdet med enterprisearkitektur på fundament niveauet bør være på at få indflydelse og påvirke livscyklus på applikationerne. Dermed må et fokus være på roadmaps for processer, applikationer og services.

Kilder

Nagesh V. Anupindi and Gerard A. Coady, “Enterprise Architecture Turnaround”, 2011.

CIO Council, “A Common Approach to Federal Enterprise Architecture”, 2011.

Doucet et al, “Coherency Management: Architecting the Enterprise for Assurance, Alignment and Agility”, 2009.

Habib et al.,“Gaining Competitive Advantage – Aligning Enterprise Architecture with Business Value”, 2011.

Mitre Corporation, “Enterprise Architecture Body of Knowledge”, 2004.

John A. Zachman, “You Can’t Cost-Justify Architecture”, Zachman International, 2001.