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

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?

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.

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

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

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.

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

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.

Hovedet på sømmet :) Et stort 'Like' herfra.

// Jesper

Jeg mener at når vi snakker en 'Enterprise Arkitekt for IT', altså en EA'er i en IT kontekst

Den må du lige forklare, Jesper. Kan man være EA'er uden at det er i en IT-kontekst? I min optik handler enterprise arkitektur om at skabe sammenhæng mellem strategi, forretningsprocesser og IT.

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

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

..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