Projekter som ikke er underlagt arkitektur udgør hver især risici for organisationen. Der findes to overordnede faktorer som påvirker udviklingen, men der findes projekter som bare er sat i gang uden arkitektur er involveret uden, at der findes en nærmere begrundelse. Disse projekter er nødvendige at kende til. Derudover kan organisationerne opnå fordele ved at skabe sig et overblik over hvor mange af deres projekter som er underlagt arkitektur, og hvor mange PSA’er som i den forbindelse er oprettet. PSA’erne oprettes i udgangspunktet kun, når et projekt er underlagt de rammer som organisationens enterprisearkitektur program kan leverer. Det som er endnu vigtigere at undersøge er, hvor mange projekter som står uden for arkitektur-rammerne.

Der findes dog også situationer, hvor det ikke vil være fordelagtigt at lade projekterne stå uden for arkitekturer. Wagter et al (2005) omtaler klassificeringsprocessen som værende den strategiske dialog, hvor beslutningstagerne bliver enige om, hvordan IT-projekterne kommer til at blive bedre.

De to faktorer som påvirker om projektet skal være uden for arkitektur er henholdsvis offensiv udvikling og defensiv udvikling. Klassificeringsprocessen er med til at vurdere om projekterne er underlagt en af de to faktorer som på kortsigt kan retfærdiggøre, at projektet skal stå uden for arkitekturprogrammet.

Offensiv udvikling er kendetegnet ved at organisationen skal have udviklet en IT-løsning hurtigt for at kunne vinde markedsandele.

Defensiv udvikling er kendetegnet ved at at organisationen skal tilpasse sig markedsforholdene, og det skal ske hurtigt for at organisationen kan fastholde markedsandele eller leve op til nye krav som myndighederne stiller.

Undersøgelse

Der findes situationer hvor hastighed i form af udvikling af projektet er vigtigt på kortsigt frem for nem og effektiv drift og vedligeholdelse.

For at identificere de projekter som står uden for de rammer som enterprisearkitektur programmet stiller til rådighed, så kan følgende fremgangsmåde vise sig anvendelig.

1. Få adgang til data om projekterne som findes i organisationens IT-projekt portefølje.

2. Gå i dialog med projektlederne.

3. Gå i dialog med projektejerne.

De tre ovenstående kilder er nødvendige for at kunne få adgang til informationer om projekterne og baggrunden for, hvorfor der findes projekter som udvikles uden for de rammer som enterprisearkitektur sætter.

Data fra de forskellige kilder kan bruges til at vurdere om projekterne er defensive eller offensive. I tilfælde af at der findes projekter som hverken er det ene eller det andet, så vil man med en hvis sandsynlighed være et behov for at undersøge, hvorfor de blev sat i gang uden om de rammer som enterprisearkitektur programmet sætter. Der kan være faktorer som har indflydelse på dette et eksempel herpå kunne være politiske situationer som så siden har vist sig at være en problemstilling som er blevet arvet.

Visualisering

De projekter som enterprisearkitekterne er i stand til at identificere ikke overholder de rammer som enterprisearkitektur programmet stiller. De projekter som ikke overholder rammerne skal udstilles så det er muligt at finde frem til beslutninger om, hvad der skal ske med projekterne fremadrettet.

Projekterne har forskellige interessenter og de kan have forskellige magtbaser som kan påvirke om projekterne har retten til at fravige enterprisearkitektur rammerne. Disse interessenter skal identificeres og det er kun muligt ved at visualisere projekterne som tilhører de to faktorer som påvirker behovet for anvendelsen af enterprisearkitektur rammerne så som projekter der enten tilhører defensive eller offensiv udvikling.

Når det er afklaret hvilke projekter som ikke er underlagt arkitektur på grund af de tilhører de to faktorer er udstillet skal de resterende projekter undersøges. Projekterne som ikke overholder de rammer som aftales skal udstilles så de rette interessenter kan engageres og den rette tilgangsvinkel til at nedbringe projekternes IT-gæld kan findes og roadmaps kan udarbejdes og kommunikeres til beslutningstagerne og projektgrupperne som skal varetage transformationen.

Visualiseringen kræver at de grafer som anvendes tydligt viser hvor de forskellige projekter kommer fra og hvor meget teknisk gæld det forventes at hvert projekt medfører. I den forbindelse kan et EA-værktøj vise sig anvendeligt at organisere og eksponerer informationen igennem.

Dialog

Det er vigtigt at beslutningstagerne bliver konfronteret i forhold til mængden af projekter som ikke er underlagt enterprisearkitektur programmets rammer. Det er især projekter som ikke har haft en bestemt henvisning til den ene eller begge faktorer som kan begrunde at projektet skal arbejde uden for.

Dialogen bør i udgangspunktet kun sættes i gang, når IT-afdelingen sammen med enterprisearkitektur funktionen har et informeret grundlag for at sætte gang i diskussionen, da beslutningstagerne i IT-afdelingen ellers vil opleve problemstillinger med at kunne argumentere for at forandring og ansvar skal placeres.

Ansvar betyder samtidigt at der skal følges op og dem som bliver holdt ansvarlige skal ligeledes evalueres. Dialogen skal bakkes op topledelsen og  beslutningstagerne i forretningsenhederne skal evalueres på, hvor megen IT-gæld de skaber på grund af at de projekter som de kræver gennemført ikke er underlagt arkitekturen.

IT-gæld

Begrebet IT-gæld omhandler at der er foretaget visse uhensigtsmæssigheder i designet og udviklingen af applikationen eller den bagvedliggende IT-infrastruktur.

IT-gæld kan vise sig at være helt fint, hvis de rette beslutningstagere er bekendt med, at IT-gælden findes og at det på sigt bliver aftalt, hvordan IT-gælden nedbringes eller alternativt, at beslutningstagerne acceptere, at IT-gælden vil medføre at de måske ikke vil være i stand til at kunne være nær så omstillingsparat, som hvis organisationen havde bedre styr på sin IT-udvikling og lavere IT-gæld.

Konklusion

Det er vigtigt at have kendskab til de projekter som ikke er underlagt arkitektur fordi de kan medfører større IT-gæld end nødvendigt. IT-gæld kan mindske organisationens evne til at omstille sig til de nye forudsætninger som nu engang findes for organisationen på markedet fordi IT-løsningerne i udgangspunktet skal omstilles til nye produkter, samarbejdspartnere, forretningsprocesser og juridiske forhold. IT-gæld gør det svært.

Den politiske dimission kan påvirke udfaldet om projekter som leder til forøgelse af IT-gælden kan underligges rammen eller de rette beslutningstagerne får ansvaret for at bringe projekterne på sporet og for drive den videre udvikling af projekterne, når de skal opgraderes på grund af teknologierne bliver en sikkerhedsmæssig problemstilling. Fokus for det videre arbejde med projekter som ubegrundet ikke lever op til de rammer som enterprisearkitektur programmet stiller til rådighed er at få bragt de vigtigste projekter inden for rammerne af enterprisearkitekturen. Ligeledes skal der gennemføres en strategisk kommunikationskampagne inde i selve organisationen for at få de rette beslutningstagere til at træffe de beslutninger som skal til for at få bragt organisationen på rette spor i forhold til at nye projekter bliver underlagt de rammer som enterprisearkitekturen understøtter.

Kilder

Wagter, Roel, Martin van den Berg, Joost Luijpers, and Marlies van Steenbergen. Dynamic Enterprise Architecture: How to Make It Work. 1st ed. Wiley, 2005.