Introduktion

Kært barn har mange navne. Ordet "IT-arkitekt" er en ofte brugt term, der dækker bredt. Vi har defineret seks mere specifikke arkitektroller for at kunne præcisere hvilke kompetencer, der er mest påkrævede i de enkelte aktiviteter i FDA. En "IT-arkitekt" kan således dække en eller flere (men sjældent alle!) af disse seks roller.

Mange organisationer - specielt offentlige - har slet ikke nogen medarbejdere med en titel hvor ordet arkitekt indgår i relation til IT og digitalisering. Typisk hedder det f.eks. IT-chef, konsulent, projektleder eller udvikler. I andre organisationer - specielt leverandørvirksomheder - har man f.eks. IT-arkitekter, solutionarkitekter eller sikkerhedsarkitekter. Man kunne således sagtens have defineret andre roller end de seks, vi beskriver her. Men vores formål har været at skabe en kobling til de bedst kendte arkitekt rammeværker. Ovennævnte eksempler vil typisk håndtere en eller flere af de seks roller, som vi har defineret. Omvendt har hver af de seks roller et medansvar for f.eks. at en løsning hænger sammen og at sikkerheden håndteres ordentligt.

De seks roller

Enterprise arkitekt – fokus på det proaktive i at vedligeholde enterprise arkitekturen, i at have overblikket over sammenhængende, og i at kunne inddrage dybere eksperter når nødvendigt.
Forretningsarkitekt - fokus på analyse, modellering og optimal proces understøttelse af forretningsprocesser.
Informationsarkitekt - fokus på informationsmodellering og databasestrukturer.
Applikationsarkitekt - fokus på applikationer og services.
Teknologiarkitekt - fokus på den teknologiske infrastruktur og de tekniske sider af databaserne og applikationerne.
Løsningsarkitekt - fokus på implementering af løsninger i organisationen.

Anvendelse

FDA beskriver ikke i hvor stort forhold de forskellige roller bør indgå, og hvorvidt rollerne kan kombineres – det er ikke sandsynligt at have en IT-arkitekt, der har alle seks roller, og omvendt kan det ikke forventes at enhver organisation har (mindst) seks arkitektårsværk ansat.

Det er vigtigt at fremhæve, at målet er at beskrive hvilke kompetencer, de forskellige roller forventes at have, og selvom du vil finde lidt vejledning om, hvad de forskellige roller kaldes, er det ikke målet at diskutere titler, konkrete jobprofiler eller normering af antal årsværk.

Behovet for rollerne afhænger af hvilke arkitektur projekt, som skal gennemføres. Hvis der kun er lidt brug for en given spidskompetence, er det værd at overveje at skaffe denne eksternt, hvorimod det giver god mening at besætte bærende roller i et arkitektur projekt med interne ressourcer.

Om rollebeskrivelserne

Hver rolle er beskrevet fuldstændigt systematisk og ens, med følgende punkter:

Beskrivelse – hvad er den pågældende arkitektrolles væsentligste opgaver i et enterprise arkitekturprojekt?
Kompetenceprofil – hvilke kompetencer vil den pågældende rolle typisk skulle have?
Gode råd – yderligere bemærkninger til hvem der typisk besætter rollen.

Tilgang

Rollerne er dannet ud fra forskellige kilder, herunder metoder (f.eks. TOGAF og FDA), litteratur og erfaring, som er fundet relevant for anvendelse i et enterprise arkitektur projekt.

De seks roller er vægtet ud fra to forretningsmæssige, seks generelle og tre tekniske kompetencer. Kompetenceniveauerne er vægtet på en 0-5 skala, hvor 1 er Ikke kendskab (ikke-relevant) og 5 er Ekspert (kræver spidskompetence). Vi har brugt halve vægte også, for at kunne være mere præcise i kompetencerne.

Sidst opdateret 2020-12-23 Advisoryboardet for Dansk IT Arkitektur Certificering.

Oversigt over kompetencer i relation til Dansk IT Architecture Competence Framework. Oversigten er opdelt i 11 dimensioner, som hver er kort beskrevet nedenfor. De elleve dimensioner falder i tre grupper:

Forretning/løsning: Her er der vægt på forretningsforståelsen, som et enterprise arkitektur projekt skal ende med at understøtte. Når vi anvender termen forretning, dækker dette også forvaltningsopgaver/ansvar.

Generiske kompetencer: Her er der vægt på de generelle kompetencer der er vigtige også i et enterprise arkitektur projekt.

Teknologi: Her er der vægt på viden om de it-discipliner der indgår i at designe den tekniske side af en enterprise arkitektur for organisationen.

Forretning/løsning

Kompetence

Delelementer i kompetencen

Strategi

Har bredt kendskab til specifikke tendenser og tiltag internt og eksternt inden for organisationens forretningsområder.

Kan overskue hvordan teknologi kan støtte forretningsmål og strategi på mellemlangt sigt.

Definerer it-governance og deltager i virksomhedens ledelse i at bruge it aktivt til at understøtte forretningen.

Forretningsdybde

Besidder bred forretningsviden indenfor organisationens ansvarsområder.
Har typisk detaljeret forretningsviden indenfor udvalgte forretningsområder.
Har stor erfaring med forretningsmodellering, såsom at opstille/konsolidere mål og strategier for forretningen, og linke disse til de processer og services der operationelt skal implementere disse.

Generiske kompetencer

Kompetence	Delelementer i kompetencen
Lederskab	Kan etablere partnerskaber med interessenter. Rejser debat om grundlæggende spørgsmål. Påvirker beslutningstagere og fungerer som mentor for andre projektdeltagere. Kan manøvrere i politiske organisationer. Besidder forhandlingsevner og diplomatiske evner. Behersker forandringsstyring.
Projektledelse	Traditionel projektledelse, herunder styring af ressourcer og rapportering, og håndtering af ændringsønsker og afvigelser fra planen. Behersker projektmetoder (f.eks. PRINCE2). Kan lede et team, skabe motivation og løse konflikter mellem projektdeltagere, og i forhold til andre interessenter. Har kompetencer indenfor systemudvikling og infrastrukturetablering.
Sikkerhed	Har erfaring og viden omkring indbygning af sikkerhed i applikationer som infrastruktur, på den for løsningen eller enterprise mest hensigtsmæssige måde, så evt. sikkerhedskrav bliver indbygget, det kan være jf. GDPR, DS484 eller en af ISO27K kravene
Kommunikation	Kan indholdsmæssigt formidle et indhold til forskellige modtagergrupper: tekniske emner til forretningssiden, og forretningsmæssige emner til tekniksiden, samt generel kommunikation til alle interessenter. Kan præsentationsmæssigt udarbejde klar og præcis dokumentation, præsentationer, mv. Besidder traditionelle kommunikationsdyder som at lytte og lede møder. Er i stand til at opsamle ønsker fra alle et projekts deltagere, og formidle disse videre til de rette ejere af disse.
Proces/ struktur	Kan indsamle krav – både tekniske og forretningsmæssige. Kan opsætte organisatoriske rammer for hvordan et enterprise arkitekturprojekt bedst realiseres, og involvere de rigtige interessenter. Styrer løbende på struktureret og sikker vis proces og taktik i forhold til projektmål, som løbende kan være under forandring.
Analyse	Kan analysere komplekse problemstillinger, og se sammenhænge og analysere hvordan beslutninger indenfor et område påvirker andre. Kan kommunikere kompleksitet på en forståelig måde til både forretningssiden og til teknisk orienterede personer. Har stor erfaring indenfor design og modellering. Kan koble it og forretning.

Teknologi

Kompetence	Delelementer i kompetencen
Teknologidybde	Besidder specialistviden indenfor to eller flere områder. Er kendt som ”førende ekspert” indenfor området - f.eks. Applikationsudvikling (Java, C# mv) , datawarehouse, XML, application frameworks, infrastruktur, drift, outsourcing, netværk. Er i stand til at overdrage sin viden fra et enterprise arkitekturprojekt til de der senere skal implementere dele af dette.
Applikationsviden/ Teknologibredde	Evner at overskue ”end-to-end” scenarier og anvende ”best practices” på disse. Evner at tænke i løsninger, både fra en teknisk vinkel og som en bruger vil opfatte en løsning. Behersker mange teknologier konceptuelt og forstår i hvilke scenarier en specifik teknologi har fordele og ulemper. Har et holistisk syn (både det vertikale og horisontale perspektiv) på applikationer.
Informations- og datamodellering	Har erfaring indenfor informationsmodellering og datamodellering – formentlig med erfaring som DBA eller forretningsprocesudvikling. Forstår sammenhængen mellem information og data, og hvordan logiske datamodeller realiseres med fysiske (tit distribuerede) databaser. Har kendskab til hvilke datastandarder der bør anvendes i konkrete situationer, for eksempel FDA-datastandarder.

Sidst opdateret 2020-12-23 Advisoryboardet for Dansk IT Arkitektur Certificering.

Arkitekturprofilværktøjet anvender en skala over kompetenceniveauer.

Definition af kompetenceniveauer:

1. Ingen kendskab

"...jeg har en helt generel forståelse for centrale begreber og kan forstå de vigtigste budskaber."

Betyder, at du inden for emnet kan forstå basisindhold og kommunikere meningsfyldt om emnet på et helt overordnet niveau.

2 Har kendskab til

"…jeg ved, hvad jeg skal gøre, men jeg har ikke de fornødne kompetencer til det."

Betyder at du inden for emnet kan forklare basisindhold, kommunikere meningsfyldt om emnet og arbejde under vejledning inden for området

3 Kan anvende

"…jeg gør det, jeg kan gøre, men det kræver en stor indsats af mig."

Betyder at du inden for emnet kan bruge teori i praksis, selvstændigt udføre rutineopgaver samt vejlede kollegaer i rutineopgaver.

4 Behersker

"…jeg gør det, jeg kan gøre, uden at det kræver en stor indsats af mig. I visse tilfælde kræver det en yderligere indsats"

Betyder at du inden for emnet kan udvælge og sammensætte en systematisk fremgangsmåde og identificere forbedringsmuligheder/ændringer

5 Er ekspert

"…jeg er det, jeg gør, og jeg har let ved det, det kommer til mig intuitivt"

Betyder at du inden for emnet kan udvælge og sammensætte komplekse problemer og kreative problemstillinger, kan kombinere og godkende mønstre inden for emnet samt rådgive kollegaer frit inden for emnet.

Sidst opdateret 2020-12-23 Advisoryboardet for Dansk IT Arkitektur Certificering .