DyA som er forkortelsen for rammeværket kendt som Dynamic Architecture har en række fordele og ulemper set i forhold til anvendelsen af rammeværket men dette blogindlæg omhandler de tre største fordele og de tre største ulemper ved at anvende rammeværket.

Om rammeværket

DyA er bygget op omkring en antagelse om at den moderne organisation eller virksomhed er afhængig af informationsteknologi i en grad der gør at de to elementer ikke kan adskilles fra hinanden. Et af principperne som miljøet omkring Dynamic Architecture bygger sine ideer op omkring betragtningen af arkitektur (enterprise arkitektur) er vigtig, hvis informationsteknologi anskues som værende vigtig af organisationens beslutningstagere (DyA website, Accessed 2011). Wagter et al (200), forfatterne til bogen der beskriver rammeværket, omtaler at forretningsstrategien og it-strategien bør have et stort overlap med hinanden i en moderne organisation, og som jeg tidligere nævnte skal it anskues som værende vigtigt af organisationens beslutningstagere for at enterprise arkitektur kan sættes på agendaen.

Rammeværket definerer tre typer arkitekturer der er nødvendige at forholde sig til i rammeværket.

1. Forretningsarkitekturen,

2. Informationsarkitekturen,

3. Teknologiarkitekturen.

Alle tre arkitekturer nedarver forretningsmålene, og alle tre arkitekturer er forbundet med hinanden. Alle tre arkitekturer har det til fælles at principper er vigtige i forhold til arbejdet med rammeværket.

Rammeværket ligger vægt på at der ikke skal være et større enterprise arkitektur program end højst nødvendigt, og anerkender dermed at der findes en situation, hvor de forskellige organisationer operere i en situation, hvor knapkapacitet eksisterer, og hvormed der findes ganske få muligheder for at få adgang til de ressourcer der skal anvendes for at få mest muligt ud af enterprise arkitektur programmet.

De tre fordel

1. Rammeværket er overskueligt i sin originale form, og det virker ikke umuligt at kombinere rammeværket med artefakter fra andre typer rammeværk så som TOGAF version 9 eller Bernards EA3 kube rammeværk (EA3 Cube Framework).

2. Rammeværket er specialiseret i forhold til udvikling af it-baserede forretningsprojekter og rammeværket fokuserer på at projekter kan udvikles inden for rammerne af arkitekturen og uden for rammerne, når det vel at mærke giver mening. Hvis chefarkitekten mener det bliver en nødvendighed kan begrebet ”teknisk gæld” anvendes, hvilket placere ansvaret for drift og udvikling hos den eller de enheder der kræver projektet kørt uden om de principper, standarder og rammer som enterprise arkitekturen fastsætter.

3. Rammeværket er bygget op omkring at it bidrager med værdi til organisationen, og at enterprise arkitektur programmet kan være med til understøtte en beslutningsplatform som beslutningstagerne kan anvende til at træffe beslutninger på et informeret grundlag, men det kræver at informationsteknologi bliver taget seriøst.

De tre ulemper

1. Rammeværket er meget it-orienteret, hvilket kan være en svaghed i forhold til at få lederne fra forretningslederne til at støtte op om beslutningsplatformen, da de kan anskue enterprise arkitektur programmet som værende udelukkende værdiskabende for it-afdelingen. Det er negativt i forhold til at understøtte en beslutningsplatform der skal forestille at understøtte både it og forretning.

2. Rammeværket giver begrænset antal anvendelige eksempler på artefakter, hvilket betyder at chefarkitekten og enterprise arkitekterne bliver nød til at finde egne artefakter for at kunne illustrere, hvordan systemerne hænger sammen, hvilket betyder at artefakter fra andre rammeværker kan blive anvendt, men det øger kompleksitetsgraden.

3. Rammeværket har ikke nogen reel definition af, hvor mange principper der skal anvendes eller hvordan standarderne kvalitetssikres. Det medføre at udviklingen af principperne ikke nødvendigvis medføre de resultater som oprindeligt var tiltænkt. Det er i øvrigt et kritikpunkt der går igen i forhold til TOGAF version 9.

Konklusion

DyA kan anvendes, hvis enterprise arkitektur programmet er rettet mod at skabe bedre it-baserede forretningsprojekter og fokus er på at skabe et fundament for en beslutningsplatform der vel at mærke dækker it-afdelingen, og der måske med tiden kan komme til at dække forretningens synspunkter, men det kommer an på, hvordan chefarkitekten anskuer problemstillingerne at tilpasse rammeværket til den kontekst som organisationen er i.

Ydermere må det siges at en af kvaliteterne der anvendes i rammeværket er synet om at der ikke er behov for mere avanceret enterprise arkitektur program end absolut højest nødvendigt, hvilket kan vise sig at være en ganske fornuftig tanke, da organisationerne oftere og oftere oplever situationer, hvor knapkapacitet skal tages i betragtning, og ligeledes virker det som en ganske fornuftig ide at forretningsmålene placeret højest i hierarkiet, hvilket vel at mærke påvirker alle de andre dele af rammeværket og forhåbentlig også de andre dele i arkitekturen til at støtte op om forretningsmålene.

Den måde jeg vælger at anskue rammeværket DyA på så findes der flere fordele end ulemper ved ta anvende enterprise arkitektur programmet, hvis formålet er at gøre it-afdelinger mere effektive i forhold til at kunne levere projekterne hurtigere til en højere kvalitet, men præmissen om at enterprise arkitektur skal komme fra it-afdelingen tynger, efter min mening, rammeværket og gør at rammeværket kun delvist tilfredsstiller mit syn på, hvordan enterprise arkitektur kan og bør anvendes for at organisationerne kan opnå komparative fordele.