Top CIOs: Her er de vigtigste kompetencer for din næste enterprise arkitekt

Af 13

Den bedste enterprise arkitekt er ikke den med mest træning i EA metode. En kandidat med fremragende soft skills, som bliver trænet på jobbet i forretningsindsigt, vil kunne have succes, forudsat vedkommende har et tilstrækkeligt fundament af teknisk viden og EA-kompetencer.

Større virksomheder vil have nytte af en god enterprise arkitekt. Den gode enterprise arkitekt kan hjælpe CIOen med at lykkes i sin rolle.

Enterprise arkitektur (EA) er efterhånden et modent felt med etablerede metoder, mange erfaringer og en del forskning. Ross og Weill har i bogen Enterprise Architecture as Strategy slået fast, at EA er nøglen til at realisere virksomhedens strategi.

Herhjemme har feltstudier fra bl.a. Peter Andersen, Århus Universitet, vist arkitektens vigtige rolle i den digitale transformation i flere store danske virksomheder, herunder LEGO.

Det har imidlertid været svært for en CIO at vide, hvornår den rette kandidat til jobbet som enterprise arkitekt stod foran ham. EA-feltets mest udbredte rammeværk, TOGAF, lister ikke mindre end 76 kompetencer, som en arkitekt skal have.

Det gør ikke opgaven nemmere, når vi hertil lægger, at universiteter og certificerings-organer udklækker mange, som lægge billet ind på en stilling som enterprise arkitekt.

Historikken spiller også ind på CIOens overvejelser. Flere større virksomheder har igennem 00’erne haft EA-programmer, som dengang, på trods af arkitekternes formelle EA-kompetencer – med tilhørende høje lønninger – ikke levede op til CIOens forventninger.

Hvad skal en CIO lægge vægt på hos sin nye enterprise arkitekt?

Devoteam har interviewet en række af landets bedste CIOs om netop dette spørgsmål. Vi har interviewet topledere, som har været kåret til årets CIO inden for de sidste 5 år og flere kandidater fra feltet til Årets CIO 2017.

Før vi præsenterer nedenstående, er det værd at notere sig, at virksomheder er forskellige, og det er kravene til den optimale sammensætning af kompetencer for EAen også. Der ud over kan der være andre ønskelige kompetencer hos EAen som eksempelvis (teknisk)projektledelse, end dem som fremgår nedenfor.

Nedenstående anbefalinger skal derfor tilpasses den enkelte virksomhed.

Feltet af CIOs blev bedt om at anbefale de vigtigste af følgende kompetencer:

  • Forretningsmæssig indsigt
  • Teknisk forståelse
  • Kompetencer inden for EA-metode
  • Soft skills.

Der var stor enighed om, at de vigtigste kompetencer for at lykkes som enterprise arkitekt er soft skills.

Udtrykket til trods behøver soft skills ikke nødvendigvis at være bløde. ‘Arkitekten skal have røv i bukserne, og skal turde være besværlig’ som en top CIO fortalte os. Ikke en klassisk soft skill men bestemt en vigtig egenskab, hvis det kræves for at lykkes i virksomhedens kultur.

Derefter tilføjede han '… og så skal han da også have evnen at indgå et kompromis', hvormed vi atter er ovre i de klassiske soft skills.

Udtrykket 'røv i bukserne og turde være besværlig' afspejler evnen til at være vedholdene og svær at kue i en organisation, hvor firmakulturen har et højt konfliktniveau i sig selv eller hvor der blot er (evt. kraftige) modstridende interesser mellem hvad EA-sponsoren vil have og hvad linje-ledelsen vil.

Det kan fx være tilfældet, hvor der er en indbygget konflikt mellem en dagsorden om centralisering og konsolidering versus den daglige autonomi i de forskellige forretningsenheder, eksempelvis i en mission om at indføre en datadrevet organisation eller at it-indkøb skal foregå efter bestemte retningslinjer.

Kompetencer i to klasser

På baggrund af dialogerne med de udvalgte top CIOs har vi arrangeret kompetencerne i to klasser: Differentierende og nødvendige. Baseret på vores erfaringer har vi tilføjet, hvorvidt kompetencerne er lette eller svære at tilegne sig.

Illustration: Peter Nørregaard

Klasserne for enterprise arkitektens kompetencer er opstillet med inspiration fra Herzbergs to-faktor teori:

  • Differentierende kompetencer: Soft skills og forretningsindsigt. Et højt niveau inden for disse kompetencer gør stor forskel på, hvor meget succes kandidaten kan opnå.
  • Nødvendige kompetencer: Teknisk forståelse og EA metode. Forudsætninger for at kunne bestride jobbet; uden disse kan personen ikke lykkes. De skal dog kun være til stede i nødvendigt omfang – hvis en kandidat behersker en af de nødvendige kompetencer dobbelt så godt som en anden kandidat, er det ikke tegn på at vedkommende vil lykkes bedre. I stedet afhænger det af kandidaternes differentierede kompetencer.

På den anden led i figuren har vi skelnet mellem, hvorvidt en kompetence er lettere eller sværere at tilegne sig i det omfang, det er nødvendigt for at fungere som enterprise arkitekt.

Det er altså ikke en vurdering af, om kandidaten kan lære at mestre kompetencen til perfektion, men om kandidaten vil kunne lære at beherske kompetencen godt nok til at udfylde rollen.

Nogle soft skills kan trænes

Som nævnt ovenfor er soft skills et bredt begreb. Personlighed, personlige præferencer og matchet med kulturen i virksomheden og teamet er traditionelt blandt det sværeste for en person at justere. Sådanne faktorer er tæt forbundet med kandidatens personlighed, som vitterlig er svær at ændre på.

Modsat er der dog også et helt sæt af soft-skills i form af adfærdsmønstre og kommunikations- og dialogteknikker, som kan trænes op.

Som konsulenter kan vi på basis af egne erfaringer anbefale flere af de klassiske konsulent-værktøjer. Nogle gange kan kortvarig træning i eksempelvis præsentationsteknik, dialogteknik og konflikthåndtering således gøre en stor forskel. Derfor skal virksomheden huske at vurdere, om en kandidat eventuelt kan opkvalificeres inden for soft skills.

Når de nødvendige kompetencer er til stede, så lad de differentierende gøre udslaget.

EA er nøglen til at realisere virksomhedens strategi, ikke mindst i en tid med digital transformation. Derfor er det afgørende at finde den rette enterprise arkitekt til opgaven.

På basis af modellen præsenteret her, skal CIOen dog være opmærksom på ikke at lade sig overbevise af en potentiel kandidats formelle kompetencer inden for EA alene. At kandidaten har tillært sig formelle EA-kompetencer tyder på, at vedkommende har den rette helhedsorienterede tilgang til faget, men kompetence-sættet for den næste arkitekt skal vurderes i bredere sammenhæng.

I litteraturen om EA findes der roller for enterprise arkitekter uden krav til teknisk forståelse. I praksis, bakket op af resultaterne fra CIO-interviews, er teknisk forståelse dog ofte helt nødvendig, fx i form af en teknisk kandidatgrad suppleret med nogle års erfaring.

En kandidatgrad er indikator på, at man får en arkitekt uden en ‘fra hånden til munden’-tilgang til arkitektur.

For at sikre sig en enterprise arkitekt som vil kunne lykkes i jobbet, skal CIO’en derfor lægge hovedvægten sin vurdering på ovennævnte soft skills, herunder det kulturelle match mellem kandidatens personlighed og hvad der kræves i rollen, samt lysten til at tilegne sig forretningsindsigt.

Baggrund: CIOs som er blevet interviewet i forbindelse med denne artikel:

Kandidater til årets CIO 2017:

Claus Thomsen, Lundbeck

Kenneth Messerschmidt, Top-Toy

Årets CIO:

2017: Torben Kjær, Rambøll

2016: Morten Gade Christensen, Energinet (nu: Bankdata)

2015: Torben Ruberg, Falck

2014: Claus Hagen Nielsen, COWI (nu: Sitecore)

2013: Jens Hartmann, Grundfos.

Edit 2018-01-17: Listen over CIOs var ukomplet, den blev opdateret.

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mads Hjorth

Godt at se flere der betragter it-udvikling som en videnskab baseret på evidens fra praksis. Ivar Jacobson er også nået langt i den retning.

Men hvori består den tekniske forståelse. Den ligger nok et sted mellem kompiler teknik og beregning af beton-broer.

Jeg tror det minder lidt om materiale lære hos en traditionel bygningsarkitekt. Altså evnen til at kunne vurdere cirka hvor meget kode der indgår i en funktion. Og som i andre fag udvikler teknikken sig også. Ting der kostede mange timers arbejde tidligere kan nu løses af generelle og eksisterende værktøjer.

Forståelse af programmering som håndværk?

Thomas Watts

Enig i Mads' spørgsmål... det er så sindssygt bredt formuleret, og er nok den største kilde til forvirring når man taler med virksomheder om rollen.

Skal man decideret kunne kode en integration, eller skal man "blot" forstå hvad sådan en fætter er, hvor man bør benytte hvilke former, og ca. hvad det kræver at udvikle?

Jeg oplever, at mange forventer at en EA decideret kan lave DB udvikling, og slet ikke kan forstå min holdning til at det ikke er nødvendigt. En bonus, måske, men nødvendigt, nej.

Peter Sjoelin

Hej Mads,

Du har nogle gode betragtninger.

Jeg vil nu mene, det handler om organisationens strategiske processer og om resultaterne af strategiplanlægningen eller scenarieplanlægning også giver mening og kan lade sig gøre, som det fx er en af konklusionerne som Simon et al (2014) i artiklen "Enterprise architecture management and its role in corporate strategic management" når frem til.

Kendskabet til det teknologiske lag er vigtigt, men det afhænger i den grad også af, hvad den enkelte organisation vil opnå ved at arbejde med enterprisearkitektur.

Mvh.
Peter

Peter Sjoelin

Hej Thomas,

Det er en fin betragtning. Det niveau inden for systemudvikling du beskriver, vurderer jeg nok passe fint på en applikationsarktiekt, systemarkitekt eller en løsningsarkitekt. Du har ret i at der nok er noget forskel mellem enterprisearkitekt rollen og det som nogle organisationer forventer.

Mvh.
Peter Flemming Teunissen Sjølin
EnterpriseArkitekten.com

Claus Juul

Det har imidlertid været svært for en CIO at vide, hvornår den rette kandidat til jobbet som enterprise arkitekt stod foran ham

Det er vel også lige meget, hvis ikke ledelsen reelt er commitet til EA.

Det handler vel dybest set, som alle andre jobs, at finde en kandidat der passer ind både fagligt og socialt. Det nytter ikke noget at have en ambitiøs Enterprise Arktitekt , hvis virksomheden ikke er klar til det niveau af Enterprise arkitektur som enterprise arkitekten ønsker/stræber efter.

Jesper Frimann

Det er en rigtig OK artikel Peter. Jeg er enig i langt de fleste ting du skriver, men har dog (surprise) et par kommentarer.

1) Mht. Forretningsindsigt.

Det kan være svært, eller næsten umuligt at finde en EA'er med lige netop forretnings indsigt i den/det specifikke forretningsområde virksomheden beskæftiger sig med. Derfor er det IMHO vigtigt, at man ikke stirrer sig blind på det her område, men måske mere ser på om en kandidat evner at sætte sig ind i området. Og hvis man så har en gruppe af EA'ere så kan 'the new guy (m/k)' lære det løbende.

2) Consulting skills.
Det er IMHO også vigtigt at en EA'er er rigtig rigtig god til at analysere. Det nytter ikke, at man har en EA der ikke formår at analysere, gennemskue, vægte og prioritere vigtigheden af de indput, som han/hun får. Og få det ned på skrift. Desuden er det lidt et must at en EA'er kan skabe og skrive rapporter, standarder, forskellige deliverables og artefakter. Det er ikke nok kun at kunne powerpointe, selv om det også er noget man skal kunne, sammen med præsentations skills.

3) Erfaring.
Der er bare ikke nogen substitut for erfaring. Sådan noget som en Junior EA'er findes ikke. Jo der findes superMænd (m/k), som i en tidlig alder kan udfylde en EA rolle. Men så er de jo ikke Junior EA'ere, men bare super dygtige undtagelser, der bekræfter reglen.
En EA'er bør heller ikke have et 'smalt' CV, hvor vedkommende har tilegnet sig al sin erfaring inden for et snævert område. En bred erfaring er bare noget, der giver gode EA*ere. Og hvorfor Versatilister ofte bliver rigtig gode EA'ere.
(https://en.wikipedia.org/wiki/Versatilist)

4) Størknet.

En EA'er skal helst ikke være størknet. Altså typen der ikke kan udvikle sig. Det betyder ikke, at man skal sortere ældre mere erfarne folk fra, der er masser af 60+ år arkitekter, der så absolut er mere kreative, lyttende og villige til at udvide deres horisont end yngre kollegaer. Hvis man har en gruppe af EA'ere, så kan det dog være en stor fordel, at have nogle EA'ere der er lidt mere 'satte'. For at få en god dynamik i EA gruppen.

5) Soft skills.
Jeg er meget enig i det du skriver om at de 'soft skills' er vigtige. Igen så er kommunikation vigtigt, og man skal helst kunne snakke med alle. Selvfølgelig, hvis man har en EA gruppe, så kan man slippe afsted med at mixe tingene lidt op, så længe gruppen fungere som en helhed.

6) Baggrund
Jeg mener at når vi snakker en 'Enterprise Arkitekt for IT', altså en EA'er i en IT kontekst, så er det også vigtigt at personen hovedsaglig er en person med en baggrund IT, helst en IT-arkitekt. Ja, der findes da folk med baggrund som 'Managers', Projektledere m.v. som er fremragende EA'ere. Men de er altså undtagelserne. De folk jeg kender med en sådan baggrund, der har kunne udfylde en EA rolle, har så som reglen en IT-uddannelse og/eller en solid IT baggrund.

7) Rekrutering.
Når man skal finde en EA'er, så skal man sku ikke lade HR bruge samme procedure, som når man ansætter en Standard 1B kodekarl (m/k). HR vil ofte sortere mange rigtig gode kandidater fra, netop fordi gode EA'ere som regel er lidt specielle. Man kan med fordel bruge lidt samme metode som man bruger til at finde gode chefer der skal sidde højere i pyramiden. Det kunne f.eks. være gennem et executive rekturerings bureau eller ved at bruge 'netværket'. Hvis man endelige bruger de normale kanaler, så tag heller 4 for mange til samtale end 1 for lidt.

// Jesper

Jesper Frimann

Ja, det vil jeg sige at man godt kan. Alt efter hvilken definition af EA man bekender sig til.
Wikipedia beskriver det faktisk meget godt i den første definition de bruger:

Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."[1]

Practitioners of enterprise architecture, enterprise architects, are responsible for performing the analysis of business structure and processes and are often called upon to draw conclusions from the information collected to address the goals of enterprise architecture: effectiveness, efficiency, agility, and durability.

Fra: https://en.m.wikipedia.org/wiki/Enterprise_architecture

Rent praktisk, er der også nogen af de store IT firmaer der har en eller flere Arkitekt roller, hvor der ingen krav om it viden er.

Personlig mener jeg ikke det giver praktisk mening at snakke EA andet end i en IT kontekst. For Så er det noget andet end EA.....hvis det kan lade sig gøre... altså nu er EA jo det hele :)

// Jesper

Jakub Nielsen

Hvis vi snakker om Enterprise IT Architecture ja, men hvis det er hele enterprisen så er det roadmaps for alle forrretnings-transformations-aspekter, ikke blot IT-transformationer, der er arbejdsområdet. I så fald giver det ikke mening at sætte en EA ned under en CIO - en rolle hvis relevans ofte bliver diskuteret. Jeg vil forvente en EA kommer fra forretningen og blandt andet arbejde sammen med Enterprise IT Arkitekter, for at bringe IT-orienterede transformationer ind i enterprise transformationerne

Peter Nørregaard Blogger

Tak for kommentarer!

@Jacub, det er rigtigt at mange diskuterer EA'ens teoretiske placering, men hånden på hjertet og i praksis har vi vel endnu til gode at se EA-funktioner som ikke er forankret under en CIO. Eller hvad?

@Jesper og @Claus, jeg er helt enig i, at der skal være et match mellem ambitioner og råderum for en arkitekt. Her tror jeg mange, måske særligt nyuddannede, arkitekter skal være bedre til at fokuserer på hvad sponsoren (fx CIO) har af succes-kriterier snarere end hvad lærerbogen siger ambitionen bør være. Først når værdien af indsatsen er klar, kan egne større ambitioner (måske) realiseres. @Jesper skriver, at der ikke findes noget som hedder en junior EA - lidt provokerende men måske ikke så langt fra realiteterne.

@Mads og @Thomas, vi kan fortolke meget på svarene jeg fik. Det er naturligvis forskelligt hvad teknisk forståelse er fra organisation til organisation. Hovedpointen her er, at den blot skal være tilstrækkelig (også åbent for fortolkning) men også, at det er et bredt området som kræver noget erfaring at kunne mestre tilstrækkeligt. Derfor, hvis arbejdsgiveren kræver DB-udvikling så er det ikke en EA-stilling. "Kode som håndværk" er en god indsigt at have for de fleste, vil jeg mene. Forretningsindsigt er noget, man bør kunne lære på jobbet.

Også tak til @Peter og @Jesper for supplerende information om potentielt nødvendige kompetencer.

Faktisk tror jeg ikke denne opstilling kun gælder for EA. Jeg tror vi fint kunne erstatte EA metode med *Projektledelsesmetode", fx.

Jesper Frimann

..at der ikke findes noget som hedder en junior EA - lidt provokerende men måske ikke så langt fra realiteterne.

Det jeg mener er, at en Junior EA'er defacto er en Senior [Solution| Domain | ..] Arkitekt der vælger at tage skridtet 'bagud', kigge bredere og træde ind på øretævernes holdeplads nemlig EA rollen.
Så ja..derfor er der, IMHO, ikke noget der hedder en Junior EA'er. For at kunne udfylde en EA rolle skal du have været igennem et modnings forløb.
Lidt som du ikke kan gå direkte fra at være løjtnant til at blive Oberst.

Faktisk tror jeg ikke denne opstilling kun gælder for EA. Jeg tror vi fint kunne erstatte EA metode med *Projektledelsesmetode", fx.

Det er jeg ikke helt enig i, jeg vil mene, at EA er mere favnende end Projektledelse. Selvfølgelig er der overlap, men jeg vil sige, at projektledelses fokus er/bør være praktisk at få eksekveret (I samarbejde med EA), det som bør/skal komme fra EA.

Hvis du ser på f.eks. TOGAF's liste af deliverables, så er da der et overlap med PRINCE2's products. Men en EA indeholder altså ret meget mere end projektledelse.
En EA'er kan fungere som Projektleder, det er f.eks. et prereq i f.eks. OpenGroup certificeringer, men en projektleder skal ikke kunne lave arkitektur. Så ja.. igen vi er ikke langt fra hinanden :)

// Jesper

Log ind eller Opret konto for at kommentere
Tip redaktionen