IT-projekter kan vise sig succesfulde, når de er i udviklingsfasen, men leverancerne skal sættes i drift kan det betyde at problemstillinger opstår, som betyder at IT-projekterne går fra succes til fejl. Fejl, som opstår som led af skiftet fra projektet til drift, kan undgås ved at der fra start af IT-projektet anvendes standarder for, hvordan kildekoden skal struktureres, hvilke biblioteker som skal anvendes, hvilken hardware som kan anvendes, og hvilke API’er som skal anvendes.

Standarder skal være formuleret før projektet sættes i gang,og standarderne vil, hvis de ikke er vedligeholdt, sande til. Det er nødvendigt at vedligeholde standarderne og det kan kun gøres effektivt, hvis der findes en formel proces for det. Processen involverer en enterprisearkitekt, en applikationsarkitekt, en ledende programmør, systemudviklere og lignende. Enterprisearkitekten skal jævnligt have kontakt med applikationsarkitekten og den ledende programmør for at finde frem til om den måde som man i projekterne arbejder med har ændret sig i forhold til den gældende standard.

For at understøtte at den tekniske udviklingsstandard tager sit udgangspunkt i de forhold som gør sig gældende for organisationen, så vil det give god mening at arbejde med en tilgangsvinkel at gøre brug af de kompetencer som enterprisearkitektur teamet råder over.

Enterprisearkitektur teamet vil i mange organisationer råde over kompetencer som blandt andet dækker over skabelse af overblik, analysering af sammenhænge og udarbejdelse af målbilleder for organisationen, hvilket også vil resulterer i input til, hvilke standarder som fremadrettet skal være på plads. Flere og flere organisationer oplever tilmed at de applikationer som udvikles hos dem skal kunne udveksle informationer og de skal kunne anvende hinandens funktioner på en måde så data kan omformes til informationer som kan bruges på tværs af organisationen og organisationens samarbejdspartnere.

Enterprisearkitektur teamet kan ligeledes være med til at indsamle informationer om standarden, arkivere standarden et sted, hvor andre interessenter kan genfinde den og ikke mindst eksponerer standarden i de situationer, hvor det kan vise sig nødvendigt at anvende den eller ændre den.

Det er med andre ord økonomisk at anvende enterprisearkitekterne til at hjælpe med udarbejdelsen af de tekniske udviklingsstandarder, vedligeholde de tekniske udviklingsstandarder og hjælpe med at udbrede kendskabet til de eksisterende udviklingsstandarder.

Månedlig proces

Standarder sander til, hvis de ikke vedligeholdes. Det betyder at standarderne jævnligt skal vurderes og evalueres. Standarderne kan ligeledes have stor indflydelse på forskellige projekter som afvikles i organisationen. Derfor kan det med fordel vise sig nødvendig at inddrage de kompetencer som enterprisearkitektur funktionen råder over. Det vil sige at en enterprisearkitekt skal deltage i vurderingen af standarderne.

Mike Rollings fra Gartner, som jeg har haft en samtale med, har den holdning at udviklingsstandarderne skal evalueres ud fra princippet om, at enterprisearkitekten ofte skal have kontakt med udviklingsteams og projektteams for at sikre at standarderne er opdaterede og at de forskellige lokale beslutningstagere er bekendt med standarden.

Enterprisearkitekten kan bidrage med et strukturalistisk syn på standardens kvalitet, og enterprisearkitekten ved, hvordan de forskellige standarder kan indsamles, organiseres og eksponeres fx igennem de rammeværker som enterprisearkitektur funktionen anvender og de værktøjer som understøtter rammeværkerne. Hvis en standard ikke vises så er den ikke noget værd.

Lokal indsats

Det er nødvendigt at de enkelte teams samarbejder om at vedligeholde den tekniske udviklingsstand, og det er nødvendigt at de lokale beslutningstagere arbejder aktivt på at evaluere det arbejde som udføres på projektet og den tekniske udviklingsstand.

Det er ligeledes nødvendigt at det bliver påvist hvem det er som ikke overholder den tekniske udviklingsstandard, og hvem som ikke gør, da denne information utvivlsomt vil hjælpe projektlederne og teamlederne med at kunne identificere, hvornår og hvordan problemstillingerne opstår. Det handler dog om at styre igennem konsensus og det handler om at få overbevist de rigtige teamdeltagere og teamdeltagere og at arbejdet vil udføres bedre og skabe større værdi for organisationen, hvis standarden overholdes. I denne henseende vil enterprisearkitektur funktionen kun kunne rådgive teamlederne og projektlederne.

Det handler med andre ord om at have den rette kultur. Kulturen kommer kun på plads ved at teamlederne og projektlederne aktivt arbejder på at få sat gang i den rette kultur og anvender de rette værktøjer til det. Det betyder også at teamlederne skal lave de rigtige tilvalg og fravalg, hvilket har indflydelse på, hvem som deltager på de forskellige projekter og hvordan de skal deltage.

Konklusion

Enterprisearkitektur funktionen kan bidrage med stor værdi i situationer, hvor der skal arbejdes med standarder. Værdien består af at der findes interessenter på enterprisearkitektur teamet som ofte har stor viden om, hvordan en god standard skal skrives (hvilket er temmelig væsentligt), og hvordan standarden hænger sammen med de andre dele af organisationen.

Standarder skal udarbejdes sammen med dem som skal bruge standarderne, da standarderne skal afspejle de forhold som den skal anvendes i og fordi der skal være en konsensus mellem interessenterne (dem som skal bruge standarden) om at det er den rette fremgangsmåde. Det kræver to ting af organisationen. Først og fremmest så skal der anvendes en tilgangsvinkel som understøtter at der tages ressourcer fra de forskellige team og projekter til at kunne deltage i at udarbejde standarderne. Herefter skal der afsættes tid til at det arbejde som udføres bliver evalueret ud fra standarden.

I arbejdet med at formulere standarder bør enterprisearkitekten kun have en rådgivende rolle. Han eller hun kan ikke gå i gang med at skrive standarden for de forskellige interessenter fordi det kan virke som værende at enterprisearkitektur funktionen dermed tager ejerskabet for standarden. Dette kan virke kontraproduktivt, da teamlederne, projektlederne og de medarbejdere som skal udarbejde løsninger som lever op til standarden at de også føler ejerskab over det arbejde som skal udarbejdes.