Der findes en masse gode grunde for et enterprisearkitektur program at arbejde med projekter og projektlignende organisationer. Et par af de vigtigste grunde er at det bliver muligt at kunne drage beslutningstagernes opmærksomhed i retning af de resultater som et projekt leder med sig og at det er muligt at vise at de artefakter som enterprisearkitektur funktionen har udarbejdet bliver omsat i praksis.

Der findes også nogle fundamentale problemstillinger ved at arbejde med en projekt-lignende tilgang til enterprisearkitektur eller projekt-arkitektur. Hvis beslutningstagerne overdriver fremgangsmåden i forhold til projekter, så vil enterprisearkitekterne simpelthen ikke have mulighed for at kunne udarbejde de artefakter som er nødvendige for at enterprisearkitektur programmet kommer til at fungere. En anden problemstilling ved at arbejde med en projektlignende tilgang til enterprisearkitektur er, at enterprisearkitekterne vil være spredt udover projekterne og der i den forbindelse vil være problemstillinger med at få dem til at dele viden med hinanden. Derfor vil det kræve mere arbejde med at få styr på begreber som videndeling for, at enterprisearkitekterne kan leverer varen.

Projekt-arkitektur er kendetegnet ved at der findes en række projektlignende dokumenter som skal håndteres og at nogle af disse dokumenter dør samtidigt med at projektet dør og nogle af disse dokumenter skal bringes videre i forhold til at understøtte de behov som enterprisearkitekterne for at analysere de forskellige forretningsenheder (lines of business) set i forhold til implementering af nye informationsteknologier, processer, produkter eller strategier.

Den store udfordring som findes for arbejdet med en projekt-arkitektur er at finde frem til de rette PID, altså det som kaldes for project independent documents, som skal bruges for at kunne ophøje dem til artefakter som kan bruges i konsekvensanalyser. Når de forskellige PID er identificeret og informationerne som de indeholder er omdannet til at kunne anvendes i generelle artefakter, så vil de kunne bruges i forhold til at kunne skabe den fremtidige enterprisearkitektur.

For at PID’erne og de relevante artefakter kan bruges på sigt, så kræver det at der findes et centralt bibliotek, hvor PID’erne kan gemmes, hvor flere enterprisearkitekter kan tilgå PID’erne med henblik på at blive klogere på deres indhold. I de fleste virksomheder vil det være muligt at anvende intranettet eller et EA værktøj til at håndtere informationerne.

Eksempler på PID

Der findes mange bud på ”Project Independent Documents” som kan bruges til at skabe artefakter med:

•       Oversigt over IT-løsningens forventede livscyklus.
•       Business cases.
•       Trusselsvurderinger for it-løsningen.
•       Løsningsarkitektur beskrivelser.
•       Procesautomatiseringer.

Omdannelsen

PID’erne kan som før nævnt bruges til at udarbejde artefakter efter, men det kræver at en eller flere enterprisearkitekter ofte arbejder med at omdanne disse projekter til artefakter. PID’erne kan vise sig at være udarbejdet af mange forskellige profiler som hver især har hver deres faglige baggrund og det hat stor betydning for om de er i stand til at kunne udarbejde PID’erne så de kan anbendudarbejde PID’å de kan anvendes som artefakter. Derfor kan det vise sig i umodne organisationer at man ved anvendelsen af en projekt-arkitektur vil opleve at en række ressourcer skal investeres i at bringe PID’erne op til et niveau, hvor de kan genanvendes til at skabe artefakter.

Konklusion

En projekt orienteret tilgang til enterprisearkitektur kan for mange fremstå som værende den letteste og mest elegante måde at arbejde med enterprisearkitektur på, men det kan samtidigt vise sig at være ret krævende, hvis enterprisearkitektur programmet forventes at modnes med henblik på at få bedre styr på organisationens anvendelse af informationsteknologier.