Hvad er it-arkitektur? Lag, roller og forskelle

It-arkitektur er mere end en tegning af servere og netværk. Den dækker tre ting. Et kort over det, der findes: systemer, integrationer, data og platforme. Et sæt principper for, hvordan nye løsninger skal bygges, fx at kundedata kun må have én autoritativ kilde. Og de beslutninger, der er truffet undervejs, med begrundelse, så næste person kan forstå, hvorfor tingene ser ud, som de gør.

Den internationale standard for arkitekturbeskrivelser, ISO/IEC/IEEE 42010, siger det samme på en mere formel måde: arkitektur handler om de grundlæggende valg i et system og om at beskrive dem, så de kan bruges af dem, der skal træffe beslutninger.

It-arkitektur beskrives typisk i fire lag. Forretningslaget beskriver processer og kapabiliteter, altså det, virksomheden skal kunne. Datalaget beskriver, hvilke data der findes, hvor de ligger og hvem der ejer dem. Applikationslaget beskriver systemerne og hvordan de taler sammen. Teknologilaget beskriver infrastrukturen: cloud, netværk, servere og sikkerhed.

De fleste problemer opstår mellem lagene, ikke inde i dem. Et nyt system kan være teknisk fint, men skabe en ny kopi af kundedata, som ingen ejer. Lagene er de samme, som bruges i enterprise arkitektur. Vi har gennemgået dem i guiden til enterprise arkitektur.

Begreberne bliver ofte brugt i flæng, men de dækker forskellige niveauer.

Enterprise arkitektur ser på hele organisationen. Den kobler forretningsstrategien til systemlandskabet og afgør, hvilke kapabiliteter der skal styrkes og hvilke systemer der skal udfases.

Løsningsarkitektur ser på én løsning eller ét projekt. Den designer, hvordan netop den løsning skal bygges og integreres, inden for de rammer enterprise arkitekturen sætter.

Teknisk arkitektur ser på platforme og infrastruktur: cloud, netværk, sikkerhed og drift.

It-arkitektur bruges i daglig tale som paraplybegreb for det hele. Det er fint, så længe man ved, hvilket niveau man taler om. En løsningsarkitekt kan ikke løse et problem, der skyldes manglende enterprise arkitektur. Det gælder også omvendt.

Titlen it-arkitekt dækker flere specialer. Løsningsarkitekten designer konkrete løsninger og sidder typisk tæt på projekterne. Infrastruktur- og cloudarkitekten designer platformene. Sikkerhedsarkitekten sørger for, at sikkerhed er bygget ind og ikke sat på bagefter. Dataarkitekten designer datamodeller, dataplatforme og dataflow. Enterprise arkitekten holder sammen på helheden og taler både med ledelsen og med de øvrige arkitekter.

Fælles for dem er, at de træffer valg, der er dyre at lave om senere. Derfor er arkitektens vigtigste værktøj ikke tegneprogrammet. Det er evnen til at forklare konsekvenserne af et valg, før det bliver truffet.

Nogle tegn går igen i næsten alle organisationer, hvor arkitekturen har passet sig selv.

Der findes flere systemer, der gør det samme, fordi hver afdeling har købt sit eget. Integrationerne er bygget punkt til punkt, så en ændring ét sted giver fejl tre andre steder. Ingen kan på en uge lave en komplet liste over systemer og ejere. Nye løsninger tager længere tid end forventet, fordi det tager uger at finde ud af, hvad de skal kobles på. Og den tekniske gæld vokser, fordi ingen har mandat til at sige nej til en hurtig løsning.

Genkender I flere af dem, er det sjældent et teknisk problem. Det er et spørgsmål om styring af arkitekturen. Læs mere om Enterprise Architecture-rådgivning.

AI gør svagheder i it-arkitekturen synlige hurtigere end noget andet. En AI-løsning lever af data fra andre systemer og er kun så god som de data og integrationer, den bygger på. Samtidig kommer der AI ind via leverandørernes systemer, uden at nogen har besluttet det.

EU AI Act kræver desuden, at I kan sige, hvilke AI-systemer I har og hvad de bruges til. Uden et kort over systemlandskabet er det en skattejagt. Vi har beskrevet de fem typiske situationer i hvornår gør AI en enterprise arkitekt nødvendig?

Start med kortet over det, der findes, ikke med målarkitekturen. En flot tegning af fremtiden hjælper ikke, hvis ingen ved, hvor man står i dag. Et kort over systemer, data og ejere er ofte det mest værdifulde, en organisation får ud af arkitekturarbejdet.

Hold principperne få og konkrete. Ti principper, som alle kan huske og bruge i et projekt, slår halvtreds, som ingen har læst. "Kundedata har én autoritativ kilde" kan bruges til at sige nej. "Vi stræber efter fleksibilitet" kan ikke.

Dokumentér beslutningerne, ikke kun tegningerne. En kort note om, hvad der blev besluttet, hvorfor og hvilke alternativer der blev fravalgt, sparer måneder, når næste projekt står over for samme valg.

Og giv arkitekturen et mandat. En arkitekt, der kun kan rådgive, bliver forbigået, når det haster.

Har I arkitekter, der kender landskabet, er opgaven at give dem tid og mandat. Hjælp udefra giver mening, når I skal have et overblik hurtigt, når en arkitekturfunktion skal bygges op fra bunden eller når en stor ændring som et systemskift, en fusion eller AI kræver et blik, der ikke er en del af de interne alliancer. Læs mere om, hvad det kræver, på find en enterprise arkitekt.