I har brug for en enterprise arkitekt, når beslutninger i én enhed jævnligt rammer systemer og data i en anden, og ingen kan overskue det samlede billede. Det gælder typisk ved flere selskaber på delvis fælles systemer, under et flerårigt program eller efter opkøb, hvor to landskaber skal mødes. Rollen kan være en fast stilling, en deltidsopgave hos en senior i IT eller en person udefra i en periode. Den bør placeres tæt på IT’s øverste leder og have adgang til forretningslederne. Den får kun virkning, hvis et arkitekturråd har mandat til at sige nej til noget bestemt.
Rollen i korte træk
En enterprise arkitekt holder kortet over forretning, data og systemer, som det er forklaret i enterprise arkitektur for en direktion, og oversætter det til råd om de konkrete sager. Personen skal kunne tale med en økonomidirektør om processer og med en driftschef om platforme, og det er den kombination, der gør rollen svær at besætte.
I virksomheder, der laver software, findes en anden slags arkitekt, som står for det indre af produktet. De beslutninger om arkitektur, der er dyre at ændre, er et emne for den læser. Her taler vi om den person, der overskuer alle de systemer, virksomheden køber og forvalter.
Hvornår rollen betaler sig
Stil fire spørgsmål. Jo flere ja, jo stærkere er sagen.
- Har I sager, hvor et projekt først sent opdager, at det ramte noget i en anden enhed?
- Har I flere systemer til samme opgave, fordi ingen har set dem under ét?
- Står I foran et stort valg, fx fælles ERP, samling af koncernens systemer eller flytning til cloud?
- Bruger jeres dygtigste IT-folk meget tid på at svare på, hvordan tingene hænger sammen?
Svarer I ja til de første to, men har kun et lille landskab, kan IT-chefen eller en senior tage rollen ved siden af sit arbejde. Svarer I ja til alle fire og har flere selskaber, er en fast rolle på sin plads. Betalingen viser sig i det, der ikke sker: de projekter, der undgår en dyr omvej, og de systemer, der ikke bliver købt to gange. Det er svært at måle, og det skal I sige højt, når sagen lægges frem.
Fast stilling, deltid eller udefra
Fast stilling passer, når landskabet er stort og ændrer sig løbende. Fordelen er kendskabet til forretningen, der vokser med årene. Risikoen er, at én person bliver det eneste sted, hvor overblikket findes.
Delt opgave passer, når behovet er der, men ikke fylder en hel uge. Her skal opgaven stå i personens mål, for ellers taber den til det daglige, hver gang der er travlt.
Udefra i en periode passer, når et stort valg skal træffes, eller et kort skal bygges første gang. Aftal fra starten, hvem der overtager kortene. En ekstern, der holder alt i sit eget hoved eller sit eget værktøj, efterlader jer med en ny afhængighed.
Hvad I selv skal kunne på længere sigt, hører med i spørgsmålet om, hvad I selv skal kunne. Mange vil holde arkitektrollen inde, fordi den rummer forståelsen af hele virksomheden.
Hvor rollen skal placeres
Rollen placeres bedst direkte under CIO’en eller IT-chefen. Ligger den under udvikling eller drift, bliver den set som en del af dén afdeling, og den kan få svært ved at rådgive på tværs. I en koncern skal det afgøres, om arkitekten arbejder for koncernen eller for et selskab, og det følger af jeres valg om fælles eller lokalt IT.
To forbindelser er vigtigere end boksen på organisationsdiagrammet. Den ene går til forretningslederne, som arkitekten skal have direkte adgang til. Den anden går til porteføljerådet, hvor arkitekten skal være med, når projekter vurderes, så konsekvenserne er kendt før godkendelsen.
Hvad et arkitekturråd må sige nej til
Et arkitekturråd er et mindre forum, hvor arkitekten og udvalgte ledere fra IT og forretningen vurderer sager, der bryder med principperne. Rådet er kun noget værd, hvis det er klart, hvad det må. Skriv mandatet ned, og hold det kort.
Rådet kan med rimelighed sige nej til:
- et nyt system, der gentager et, I allerede har, uden en begrundelse,
- en løsning, der lægger forretningskritiske data uden for de aftalte steder,
- en integration, der går uden om de fælles principper,
- en teknologi uden nogen til at drive den.
Rådet bør lade forretningens valg stå, altså om projektet skal laves, og hvornår. Det hører til i porteføljerådet. Og der skal være en udvej. Kan et projekt ikke acceptere et nej, går sagen til CIO’en eller til direktionen, hvor den afgøres, med en begrundelse. Mødes rådet for sjældent, bliver det en flaskehals, så sæt en frist for svar.
Hvad I gør nu
Tag de fire spørgsmål på næste møde i IT-ledergruppen. Peg derefter på den person, der allerede gør noget af arbejdet, for en sådan findes næsten altid. Giv vedkommende opgaven officielt, og lad den første leverance være et kort til den største beslutning, I står foran.
Det skal I lade være med
- At ansætte, før I ved, hvad rollen skal afgøre · en arkitekt uden sag ender med at tegne for tegningens skyld.
- At lade arkitekturrådet godkende alt · det bremser, og de små sager kan klares af dem, der laver dem.
- At kræve en bestemt certificering · evnen til at få en ledergruppe til at bruge kortet tæller mere.
Det skal I kræve af dem, der leder IT
- ☐ Et skriftligt mandat for rollen og for arkitekturrådet.
- ☐ En ankevej og en frist for svar, når rådet siger nej.
- ☐ En navngiven stedfortræder, så overblikket ikke sidder i én person.
- ☐ Kort, der ligger i virksomhedens egne systemer og kan overdrages.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Organisering af IT-afdelingen · Applikationsporteføljen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
