Fagrådet for Business and IT Alignment i Dansk IT håber, at anbefalingerne om enterprisearkitektur (på engelsk: Enterprise Architecture - EA) i denne artikel kan bidrage med inspiration og værdivækst i danske virksomheder og organisationer.

De otte anbefalinger om EA adresserer følgende områder: 

1. Forretningsforståelse og sammenhæng.
2. Skab kontekst for din opgave med en business operating model.
3. Skab forståelse for konteksten for rollen som EA og hjælp dine nøglemedspillere.
4. Opstil alternativer og lav beslutningsoplæg til ledelsen.
5. Teknologiforståelse og ny teknologianvendelse.
6. Arkitekturprincipper og reviewkoncept.
7. Løsningskomponenter - byg til organisationen. 
8. Arkitekturrepository og documentation.

1: Forretningsforståelse og sammenhæng 

Området mellem it-understøttelse og forretning er det mest interessante at kunne adressere som enterprisearkitekt, hvor det blandt andet er EA’ens rolle at kunne dokumentere forståelsen af forretningen. 

I praksis ses ofte, at dialogen mellem it og forretningen er baseret på brugen af de applikationer, som forretningen anvender. Derfor er det nødvendigt, at enterprisearkitekten kender både til de behov, der har udløst behovet for it-applikationen, men også kender til hvorfor netop denne applikation og teknologianvendelse er den, som it kan understøtte i en sammenhængende applikationsportefølje.
 
Med andre ord skal man som EA kende til, hvor og hvordan forretningen har dokumenteret sine behov (forretningsstrategier, use cases, rige billeder, user stories, user experience (UX), forretningsprocesser, forretningskapabiliteter og forretningsdata), og om de er blevet sat sammen i en forretningsmæssig forståelig sammenhæng, fx som et Business Canvas Diagram. Men mest af alt er det vigtigt med forståelse af forretningsstrategien, det nuværende behov og it-understøttelsen.

Interessen for forretningsforståelsen deles ofte med Business Relationship Managers (BRM), som har god indsigt i forretningens ønsker og krav i organisationen. I disse tilfælde bør EA’erne danne team med BRM’erne for at få informationerne fra forretningen og få sammenstillet disse i et dokument, som beskriver forretningsforståelsen. 

Denne samling af forretningsforståelse tjener som grundlag for at kunne identificere og beskrive forretningskapabiliteter eller, hvis disse allerede er identificeret, tjener forståelsen til at udbygge forretningskapabiliteter i praksis og danne grundlag for at kunne “mappe” fra forretningskapabiliteter til services og it-applikationer således, at systemejere kan identificere og involveres i fremtidige beslutninger.

Overordnet er anbefalingen: Dyrk forretningsforståelsen og få den dokumenteret sammen med forretningen i et passende dokumentationsformat - gerne i form af en model - som kan forstås og genbruges af andre end arkitekterne for efterfølgende at blive linket sammen med teknologianvendelse.

2: Skab kontekst for din opgave med en business operating model

Kontekst er “konge” - og kan være den lille forskel mellem succes eller fiasko. Når en virksomhed udvikler sig, så ændres konteksten omkring it-løsningerne sig også. Det sammen gør forholdet mellem den måde, it og forretningen arbejder sammen på. Det er derfor ikke ligegyldigt under hvilken kontekst, at et samarbejde etableres, og løsninger skabes.
 
Som EA skal du belyse og dokumentere den kontekst, som løsninger skabes under, og det kan du gøre på mange måder. Det vigtige er, at du skaber et overblik over de omgivelser, som løsningerne forventes at virke under, så både kravstillere og løsningsdesignere opnår en fælles forståelse for konteksten og sammen undgår, at der bliver lavet perfekte løsninger på de forkerte problemer. 
 
Udgangspunktet for en kontekstbeskrivelse er altid forretningen, og det kan fx være den operating model, som det pågældende forretningsområde opererer under eller ønsker at operere under. Processer og data er to af de vigtigste forretningsdele, som en kontekstbeskrivelse skal adressere ved at svare på:

a) i hvor stor grad skal processerne standardiseres inden for området og på tværs af områder?
b) i hvilken grad skal data integreres inden for området og med andre områder?

Overordnet er anbefalingen: En god forståelse for konteksten og områdets operating model vil hjælpe med en god alignment mellem forretningen og it, når der skal prioriteres, og når der skal tænkes nyt.
 

3: Skab forståelse for konteksten for rollen som EA og hjælp dine nøglemedspillere 

Som EA har du et sammenspil med andre nøgleroller i eller uden for it-organisationen, og du skal både vide, hvad de forventer af dig, samt passe på ikke at konkurrere med dem.
 
Lav en game plan og brug gerne flere rammeværker som referenceramme. For konteksten omkring forretnings- og it-samarbejdet kan du fx bruge ”Foundation for Execution” (MIT Sloan). Du kan bruge EA3 Cube (Bernard) for dokumentationsstrukturen og TOGAF (Open Group) til planlægning af din og arkitektteamets produktion. Rammeværkerne er din baggrundsviden og skal ikke vises eller sælges til andre. Lav din game plan som forberedelse til samarbejdet med de nøgleroller, som du spiller sammen med.
 
Det er en god start at påtage sig rollen som intern rådgiver eller konsulent for it-ledelsen og forretningsledelsen, hvor det er er muligt. Fx kan du vise, at du er god til at:

a)   skabe rammer (kontekst) om opgaverne i it-afdelingen.
b)   fremme (”sælge”) løsninger, der kan bruges i hele virksomheden.
c)   vurdere hvor der er sammenhængende eller modstridende interesser i krav og løsninger.
 
Overordnet er anbefalingen: Om du lykkes og opfattes som en succes, afhænger af de nøglepersoner, du har et sammenspil med, herunder it-ledelsen, forretningsudviklere/strateger, it-sikkerhedsansvarlige, business relationship-ansvarlige og lead arkitekter. Du skal ikke lave deres job – du skal hjælpe dem, og de skal forstå, hvad du laver.
 

4: Opstil alternativer og lav beslutningsoplæg til ledelsen

Som EA skal du ikke konkurrere med forretningsledelsen eller it-ledelsen; du skal rådgive begge parter. Opgaven med at tage beslutning om hvilken løsning, der passer bedst til virksomheden, skal du overlade til ledelsen og så påtage dig en rolle som den interne og betroede konsulent, der vurderer kvaliteten i løsningen.
 
Du kan objektivt tage afstand fra nogle løsninger og støtte andre løsninger, men det er vigtigt, at du altid laver en konsekvensvurdering af de valg, som skal tages. Ofte må du respektere, at valg også tages på baggrund af subjektive kriterier, fx at et kendskab til et system fra vigtige beslutningstagere kan veje tungere, end at andre systemer rent faktisk har et bedre match på funktionelle og ikke-funktionelle krav.
 
Et beslutningsoplæg indeholder ikke kun en løsning, som der skal siges ja eller nej til (husk at heller ikke er). Du skal som hovedregel lave tre alternativer, hvor spændvidden i dine bud rækker fra minimumsniveauet for en acceptabel kvalitet og til en nærmest perfekt løsning. Et sted i det løsningsrum kan ledelsen så finde den løsning, som med hensyn til tid, økonomi og politiske forhold (alt det, som ikke har med løsningens kvalitet at gøre) har det bedste match til det, man gerne vil opnå.  

Overordnet er anbefalingen: Dit beslutningsoplæg til ledelsen indeholder tre scenarier, som forholder sig til løsningens kvalitet, men overlader det til ledelsen at vælge scenarie på baggrund af din konsekvensvurdering samt politiske, økonomiske og tidsmæssige forhold.

5: Teknologiforståelse og ny teknologianvendelse

Der er mange personer i en virksomhed, der synes, at teknologi er spændende, og det er en stor fordel for en virksomhed, at medarbejderne både i arbejdstid og i fritid researcher på nye teknologier. Leverandørerne er også kendt for at kunne tage en god del af en medarbejders tid med gode salgsintroer og gratis formøder. 

Den tætte kobling mellem teknologi og buzzwords gør, at nye teknologier tit favner hele organisationen og kan smigre alle med de perspektiver og horisonter, der er for disse. Cloud, IoT, blockchain, AI osv. har vi alle hørt om de seneste år, og der har ikke manglet profetier og scenarier for udbyttet. Noget er blevet indfriet, og en del har vi stadig til gode, hvis det overhovedet kommer. Som EA skal du være god til at ryste den umiddelbar fascination af dig og dykke både to og tre niveauer dybere ned i teknologien end de fleste. Mens du i andre sammenhænge skal være den kraft, der afdækker teknologier, som ingen andre interesserer sig for. Der vil det ikke være fascinationen, som du skal prøve at tøjle, men nærmere skabe den.

Det er vigtigt, at du som del i indkøbs- eller udviklingsprocessen både betragter anvendelsen, dvs. behov og krav, nu og på længere sigt. Du skal forstå det bagvedliggende i teknologien, og sparring med forretningen vil være en god måde at gøre det på. Men husk at det sjældent er et forskningsprojekt, som du skal lave - du skal se teknologien i den brede sammenhæng. 

Overordnet er anbefalingen: Lav beslutningsoplæg om stort og småt i forhold til teknologien, der svarer på: "Hvorfor skal vi gå den vej og udnytte den teknologi?". Se hvad der ligger i teknologien, perspektivér det og lap en roadmap for, hvordan den udnyttes, og hvad der skal plads i virksomheden for, at det kan udnyttes. 

6: Arkitekturprincipper og reviewkoncept 

I stedet for at se dig selv vogte over arkitekturen kan du se principper og review som en del af de værktøjer, der findes for at hjælpe udviklere og arkitekter til at lave bedre kvalitet. 

De proaktive principper går tidligt ind og fortæller i korte træk - i form af overskrift, beskrivelse og implikation – om nogle af de rammer, der er for udviklingen. Det bringer gerne ro og regelmæssighed i udviklingen, når man har arbejdet med præcise formuleringer for principper. Det kan godt tage et par iterationer, og principper bør få mandat oppefra, da det har betydning for udviklingen og dermed virksomheden, at de følges.
 
På et senere tidspunkt i udviklingen kan du flere gange foretage et reaktivt arkitekturreview; en dialog hvor du meget gerne må rose arbejdet og komme med konstruktiv kritik. Har du allerede fortalt om principperne, vil det gøre dit review nemmere, da arkitekturen for det meste overholder principperne - og hvis ikke så vil godkendte principper gøre dit arbejde nemmere, da du jo bare er den "udøvende magt". Reviewydelsen skal ikke ses som en eksaminering, men mere som en læringsydelse, hvor du har fokuseret tid til at forklare arkitekturfundamentet til dine kollegaer. I praksis kan man opleve at reviewydelsen i nogen grad kan blive mindre relevant og efterspurgt, efterhånden som organisationen lærer de rammer, som du kommunikerer ved reviewet og mere benytter løbende sparring. Det er dog også fokuseret tid, hvor man som EA får indsigt i arkitektkollegaer og i organisationens udviklingskultur.
 
Du kan godt komme ud for, at ingen eller kun få principper er nedskrevet - også selv om arkitekturgruppen har diskuteret og er-næsten-landet på nogle formulerede principper. Det kan være frustrerende ikke at kunne pege på dem, men derfor kan du godt reviewe og forklare dit feedback til modtagerne af reviewet ud fra principperne. Nedskrevne principper alene giver sjældent den store effekt, og reviewet uden principper giver ikke fuldt udbytte. 

Overordnet er anbefalingen: Få både reviewydelsen og principper i spil sammen - så forstærker de to elementer hinanden. 

7: Løsningskomponenter - byg til organisationen 

Der er forskellige måder at få forretningskrav frembragt og dokumenteret på afhængigt af, hvordan man i virksomheden arbejder med projekter. 
Har man større kendte løsninger, hvor udfaldet af projektet kan forudsiges og er kendt, er der virksomheder, som fortsat bruger en vandfaldsmodel (analyse - design - byg), hvor det er i analysedelen, at forretningskrav bliver identificeret og dokumenteret. 

Arbejder man med mindre kendte områder eller har valgt, at projektmodellen hedder SCRUM, så arbejder man med user stories, time boxed og i sprints. 
 
Uanset projektmetoder er der et behov for at forstå og identificere processer, use cases, og andre forretningskrav. Det er ambitionen, at man skal kunne finde tidligeres projekters procesbeskrivelser, use cases, og forretningskrav for, at man kan genbruge disse i nye projekter. 

Det er derfor nødvendigt, at man som EA bidrager med at kunne samle de forskellige projekters løsningselementer, så som use cases og forretningskrav, på en ensartet måde og i et format, der er søgbart og sporbart. På den måde har nye udviklingsprojekter muligheder for at kunne genfinde tidligere krav, processer, løsningselementer og testdata i en form, som understøtter genbrug.

Det samme gør sig gældende for projekternes udarbejdelse af driftsdokumentation, som beskriver drift og vedligeholdelsessituationer, herunder backup og recovery, som er udsprunget af forretningsønsker og krav om Repair Time Object (RTO) og andre non-funktionelle krav.
 
Overordnet er anbefalingen: Brug projekterne til at opbygge dokumentationen af virksomhedens enterprise arkitektur.

8: Arkitekturrepository og dokumentation

Enterprisearkitekturen bidrager med at samle informationer i et format, der er søgbart og sporbart. 
Informationerne skal gøres tilgængelige i en database eller repositorystruktur, som gør, at alle elementer er søgbare, sporbare, kategoriserede og indgår i det samlede overblik over it-porteføljen, som it-afdelingen skal mestre. 

Her er EA’ens rolle at sikre, at repository er på plads og bliver holdt opdateret og genbrugt af den samlede trup af arkitekter, som udgøres blandt andet af EA’er, løsningsarkitekter, infrastrukturarkitekter, test managers og forretningsbidragsydere. 

Det er i denne sammenhæng, at der vokser et ønske om et fælles rammeværk til forståelse og understøttelse af EA-arbejdet med mulighed for at trække informationer ud af rammeværkets repository ud fra forskellige perspektiver (viewpoints) fra interessenterne, herunder forretning, it, løsningselementer og økonomi. 
 
Men dette ønske kan først opfyldes, efter at man i organisationen har opnået en fælles forståelse og nytteværdi-betragtning for EA-arbejdet på tværs af organisationen. 
 
Overordnet er anbefalingen: Start med en EA-nytteværdi-afklaring og -forståelse og udbyg derefter rammeværk (model/proces) og repository for dokumentationen.