Visma Blog Danmark

Brug EA rigtigt i dialogen med udviklingsteamet

Jeg har arbejdet med enterprise arkitektur gennem de seneste 10 år og har set både fejlslagne og succesrige EA programmer. Fælles for de positive EA historier er, at der har været et klart incitament til at starte på EA rejsen – ofte i form af et større moderniseringsprogram. F.eks. en ny lov, som vil stille nye store udfordringer til den eller de myndigheder, der skal udmønte den.  

De gange, hvor EA programmet er startet op på basis af en ‘fiks’ ide eller en arkitekt, der har set lyset, men hvor fokus primært har været EA i sig selv, har programmet meget mindre chance for succes (ret tæt på 0%).

Der er ingen tvivl om, at EA som disciplin og værktøj for en strategisk anvendelse af digitale værktøjer, kan være særdeles effektiv, så it og forretning bliver i stand til at forstå hinanden bedre).  Men det kræver en god portion mod, politisk manøvredygtighed, diplomatiske evner og pragmatik.

De fleste EA rammeværk skal dække bredt og være anvendelige i mange forskellige brancher og kan derfor virke omfattende. Samtidigt skal man holde sig for øje, at de ofte har deres udspring i store amerikanske virksomheder eller myndigheder. Så det gælder om at vælge omhyggeligt hvilke elementer, der er særligt brugbare i den situation man står i. Med andre ord: Tænk over hvilke elementer, der passer og følg ikke et rammeværk blindt.

Arbejder du som arkitekt, er du vant til at arbejde på flere abstraktionsniveauer og befinder dig lige så naturligt i en diskussion omkring services indenfor et forretningsområde, som i en diskussion om integrationsmønstre i en specifik løsning. Denne abstraktionsevne er det langt fra sikkert, at særligt mange andre i din interessentkreds er i besiddelse af. Derfor skal kommunikationen tilrettelægges nøje, så de ikke oplever, at du taler sort eller hen over hovedet på dem.

Netop det med at være opmærksom på abtraktionsniveauer, og vælge det rette til lejligheden, er noget, man som enterprise arkitekt altid skal være opmærksom på. Jeg har altid et Google map for mit indre øje:

Heldigvis understøtter de fleste EA rammeværk det at arbejde på forskellige abstraktionsniveauer, hvor f.eks. arkitekturprodukter kan placeres i en reol, alt efter hvilket detaljeringsniveau de befinder sig på.  Et typisk EA rammeværk består af en proces, hvor man dels skaber et overblik over den nuværende situation og sammenholder denne med, hvor virksomheden gerne vil bevæge sig hen (strategisk tema). Man lægger ofte ud med at definere nogle overordnede principper og en referencearkitektur, da dette er særdeles effektive værktøjer til at holde EA arbejdet på sporet.

De produkter, der kommer ud af procesarbejdet, bliver placeret og klassificeret i en arkitekturreol (f.eks OIO EA reolen, Zachman rammeværket, TOGAF Architecture repository, o.lign.). Nedenstående figur er en simplificeret oversigt over elementerne i et EA rammeværk og koblingen til de projekter, der skal anvende og implementere arkitekturen.

EA arbejdet og alle de producerede arkitekturprodukter er ingenting værd, hvis det ikke resulterer i konkrete løsninger, som giver værdi for forretningen. Det er i projekterne, at arkitekturen implementeres, så arkitekturprodukterne skal give mening for projektdeltagerne og især de løsningsarkitekter, der skal udstikke de strukturelle retningslinjer for en løsning.

Dette er første del af en serie på tre omhandlende enterprise arkitektur og agile udviklingsteams.

Jeg er CTO i Visma Sirius og har gennem en årrække beskæftiget mig med arkitekturdisciplinen - lige fra løsningsarkitektur til enterprise arkitektur, herunder fremherskende arkitekturmønstre og teknologimodeller. Indenfor de seneste år er jeg begyndt at interessere mig for, hvordan man får koblet arkitekturdimensionen til selve implementeringen i de enkelte projekter. Flere og flere tager den agile udviklingsmodel til sig og det er vigtigt ikke at glemme "klassiske" discipliner som arkitekturarbejdet og projektledelse. Jeg har 20 års erfaring i it branchen og har arbejdet med softwareudvikling, arkitektur, it ledelse, projektledelse og implementering af agile processer.
Vis kommentarerSkjul kommentarer

Skriv et svar

Din e-mailadresse vil ikke blive offentliggjort.Påkrævede felter er markeret *

*


fire × = 20

Disse HTML koder og attributter er tilladte: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>