Enterprise Architecture - does it really always fail?

Eller Chief Architects - are they really always annoying?

Manden på podiet var skarp, ingen tvivl om det - men også skarp på en irriterende måde når han stillede et spørgsmål til forsamlingen og sablede tilhørerens svar ned. Og irriterende når han afbrød et spørgsmål fra en tilhører halvvejs og begyndte at svare - uden rigtigt at have fået fat i essensen af spørgsmålet.

Vi var en forsamling på 25 enterprise arkitekter og andet godtfolk samlet fra universitetet, leverandører, konsulenter og kunder (sådan så det ud fra den email-liste der var blevet sendt rundt). Foredraget, Enterprise Architecture - does it really always fail var arrangeret af a|EA Danmark. Manden på podiet var Claus Torp Jensen, afgående chef-arkitekt fra Danske Bank, og han fortalte åbent og ligefremt om sine erfaringer med at bedrive arkitektur i banken i de sidste 5-6 år. Og han havde en række gode pointer som jeg (frit og tendentiøst) gengiver her:

Kast ikke opgaver over hegnet: De fleste udviklingsmetoder går galt i byen når de beskriver at noget skal overdrages fra forretning til IT. For dér går det oftest galt og viden og intentioner går tabt. Fx mente han at RUP startede for sent, sluttede for tidligt og ikke var dyb nok.

Hans løsning var i stedet at sætte forretningsudviklere sammen med IT-udviklere. Det skulle også hjælpe forretningsudviklerne til at tænke mere struktureret og med en længere tidshorisont. Et godt råd der er svært at efterleve for alle der bruger en IT-leverandør. Og EU-udbud, der dækker over de mest interessante projekter, er nærmest defineret ved at kaste opgaver (og ansvar) over hegnet den ene vej ved projektets start, og tilbage over hegnet når løsningen afleveres.

Test tidligt. Vi glemmer tit at teste kravene og ofte viser det sig, at krav ikke altid er lige fornuftige. Så test dine krav med samme nidkærhed som du tester resultatet og chancen for en succes bliver meget større. En test, der også glemmes for tit, er "Skaber dette her projekt i det hele taget værdi'". Det er rigtigt gode råd ' og umulige at efterleve for en leverandør som skal svare på et EU-udbud. Men vores kunder kan have store fordele ved at følge rådet når de laver udbudsmaterialet.

En enterprise arkitektur kunne beskrives som legoklodser ' og der er forskellige slags klodser, måske 4-5 forskellige slags, som kan sættes sammen indbyrdes men ikke på tværs af typer (som fx almindelige lego klodser og dublo). Interfaces mellem legoklodserne skal tages alvorligt ' og de interne interfaces bør tages lige så seriøst som de eksterne interfaces til andre leverandører.

Konkret havde han uddelegeret ansvaret for komponenter ud i mange små, selvkørende organisatoriske enheder. Konsekvensen var at projekter typisk gik på tværs af 4-7 små "fyrstedømmer" og at fastlæggelsen af funktionalitet, processer, interfaces mm. blev resultatet af forhandlinger mellem grupperne. Frem for "den bedste løsning" (som var en illusion) fik man i stedet "forhandlingsløsningen" ' målet var at opnå et resultat som blot var godt nok og som til gengæld virkede hurtigt. Det lyder på en måde sundt ' og er et stykke fra den verden, en typisk arkitekt prøver på at skabe.

Den underliggende viden i en enterprise skal være struktureret. Det er essentielt at vi er strukturerede i måden vi beskriver viden på. Til gengæld behøver vi ikke at være ensartede i måden vi fremskaffer viden på, eller ensartede i måden vi laver services på. Som jeg hørte det, mener Claus Torp at artefakterne er mere interessante end de processer, der skaber dem. Det giver god mening i min verden.

EA-projekter og -programmer fejler! Hvorfor? Fordi projekter og programmer slutter på et tidspunkt, hvilket en rigtig EA aldrig gør, og fordi forudsætningen for en god EA ikke er et spørgsmål om teknologi men i stedet om en god organisationskultur. 

Så hvordan indføres en enterprise arkitektur-tankegang så i en stor organisation? Ikke via kontrol, for det tager for meget tid. I stedet har hans tilgang været uddannelse, uddannelse, uddannelse og ved at netværke. Kulturdannelse er en svær opgave som tager lang tid og konstant pleje.

Men lad mig runde af med et svar på det interessante spørgsmål: Skal chef-arkitekter være irriterende? Mit bud er, at du som chef-arkitekt skal være mere frembrusende og "fremme i skoen" for at få gennemslagskraft, end det kræves af dig hvis du er udvikler eller løsnings-arkitekt. Det kræver en særlig personlighed at gennemføre organisatoriske og kulturelle ændringer og en evne til at overvinde modstand fra andre chefer på højt niveau som har spidse albuer. Om det bedst lykkes ved en usvigelig tiltro til egne evner eller om du vil bruge en anden strategi må være et spørgsmål om temperament.