Enterprise arkitektur, på engelsk enterprise architecture, er faget, der tegner og vedligeholder kortet over, hvordan virksomhedens forretning, data og systemer hænger sammen, og hvordan det skal se ud om nogle år. Direktionen skal bruge kortet til én ting: at gøre store beslutninger billigere, fordi konsekvenserne kan ses, før pengene er brugt. Ved et ERP-skift, et opkøb eller en samling af systemer på tværs af selskaber viser kortet, hvad der bliver ramt. Faget giver mest værdi, hvor flere enheder deler systemer og data. Står det alene som dokumentation, koster det uden at ændre noget.
Fra ord til sag
Ordet arkitektur får mange til at tænke på teknik, og det er en del af forklaringen på, at faget er svært at sælge internt. Sammenlign med en byplan. Den fortæller, hvor vejene går, hvad der må bygges hvor, og hvad der sker, hvis et kvarter skal rives ned. Den, der bygger ét hus, kan klare sig med en tegning af huset. Den, der har ansvaret for hele byen, må have planen.
Softwarearkitektur i et enkelt produkt er et andet fag og hører til virksomheder, der laver software. Her er emnet hele virksomhedens landskab af købte og egne systemer, som skal forvaltes.
De fire kort
Faget arbejder med fire lag, som kan forklares uden fagudtryk:
- Forretning. Hvad virksomheden skal kunne, fx at fakturere, planlægge produktion og håndtere reklamationer, og hvilke processer og enheder der gør det.
- Data. Hvilke oplysninger virksomheden lever af, fx kunder, varer og ordrer, og hvor sandheden om dem ligger.
- Applikationer. Hvilke systemer der understøtter hvad, hvem der ejer dem, og hvor de overlapper.
- Teknologi. De platforme, cloudtjenester og driftsmiljøer, systemerne kører på.
Det øverste lag kaldes også forretningsarkitektur, og ordet IT-arkitektur bruges mest om de to nederste. Kortene bliver først nyttige, når de lægges oven på hinanden. Det er koblingen, der viser, at en proces i salget afhænger af et gammelt system i et datterselskab, som kun én leverandør kender.
Den ene side af faget er nutiden, det vil sige kortet over, hvordan det ser ud i dag. Den anden er målbilledet, altså hvordan I vil have det om nogle år. Afstanden mellem de to er det, køreplanen skal lukke.
Hvad faget leverer
Ledelsen kan forlange konkrete resultater af arbejdet.
- Et overblik, som viser, hvor virksomheden har tre systemer til den samme opgave.
- Et grundlag for at afgøre, hvad der kan samles på tværs af selskaber.
- En konsekvensvurdering, før en stor beslutning træffes.
- Principper for nye systemer, så det samme problem ikke løses på flere måder.
- En fælles betegnelse for det, virksomheden kan, så forretning og IT taler om det samme.
Det sidste er mindre, end det lyder. Når alle i ledergruppen bruger samme ord for det, virksomheden skal kunne, bliver drøftelser om prioritering kortere.
Hvad direktionen skal bruge det til
Direktionens opgave er at stille de spørgsmål, kortene kan svare på. Tre situationer er særligt oplagte.
Før et stort program. Hvad bliver berørt ud over det, programmet selv nævner? Hvilke integrationer, rapporter og processer står for at falde? Et kort gør, at ERP-programmet begynder med et mere ærligt omfang.
Når koncernen skal samles. Hvad er ens på tværs af selskaberne, og hvad er forskelligt af gode grunde? Svaret er grundlaget for valget mellem fælles og lokalt.
Når et selskab kommer til. Efter overtagelsen viser kortene, hvor det nye selskab kan kobles på, og hvor der skal træffes valg.
Den gode prøve er, om I kan svare på et spørgsmål hurtigere med kortet end uden. Kan arkitekterne ikke svare på, hvad der sker, hvis et bestemt system lukker, er kortet ikke godt nok endnu.
Rammer og metoder
Den mest kendte ramme er TOGAF fra The Open Group, som organisationen selv kalder en metode og ramme for enterprise arkitektur. Den findes altså, og I vil møde navnet i stillingsopslag og tilbud. Direktionen behøver ikke at tage stilling til den. Spørg hellere, hvilke beslutninger arbejdet skal støtte, og lad metoden følge af det. En certificering hos en person siger noget om kendskab til rammen, men intet om, hvorvidt personen kan få en ledergruppe til at bruge kortet.
Sådan begynder I
Begynd med en konkret sag. Vælg den største beslutning, I står foran det næste år, og lav kun de kort, den kræver. Et kort over de vigtigste processer og systemer i de berørte enheder kan laves på kort tid med folk, I allerede har. Viser det sit værd, kan I udvide det.
Det store spørgsmål er bagefter, hvem der skal holde kortet ved lige. Det uddybes i har vi brug for en enterprise arkitekt. Et kort, der ikke vedligeholdes, er forældet hurtigere, end ledelsen regner med.
Det skal I lade være med
- At kortlægge alt, før noget bruges · arbejdet bliver aldrig færdigt, og tålmodigheden slipper op.
- At lade det hele ligge i et værktøj, kun arkitekterne åbner · kortet skal kunne vises på et ledermøde.
- At købe metoden i stedet for beslutningen · start med spørgsmålet, I skal have svar på.
Det skal I kræve af den eksterne
- ☐ En bestemt beslutning, arbejdet skal støtte, før det begynder.
- ☐ Kort, der kan læses af en forretningsleder uden fagordene.
- ☐ En plan for, hvem der vedligeholder kortene bagefter.
- ☐ Tydelig forskel på, hvad der er konstateret, og hvad der er forslag.
- ☐ Anbefalinger, der ikke er bundet til en bestemt leverandør eller et bestemt værktøj.
Kilder
- The Open Group: TOGAF Standard: organisationens egen beskrivelse af standarden, 10. udgave. Rammen er kun nævnt her.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Applikationsporteføljen · Legacy-systemer
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
