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å abstraktionsniveauer, 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.
