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.

Peter Nørregaards billede
Peter Nørregaard er principal consultant hos PA Consulting Group. Peter blogger om koblingen mellem strategi, forretnings- og it-arkitektur og om hvordan it påvirker samfundet

Kommentarer (16)

Kristian Poulsen

Kære Peter

Du må endelig ikke tage dette personligt, men set fra min synsvinkel virker det i hvert fald som om at chef-arkitekter fra KMD / Kommune Holding er irriterende. (og undskyld hvis jeg generaliserer, min vi er nogle udenfor murerne der ikke kan se hvor grænserne går mellem KMS og Kommune Holding)

Jeg sidder her med et brev fra KMD vedrørende adressesnitfladen til KMDs krydsreferencesystem (KRR). Brevet er sendt til BBR myndigheden i de danske kommuner, og er dateret 31. marts 2008.
I brevet fremgår det at det at kommunerne fra 15. april 2008 skal lægge adressekoordinater ind i det nye BBR. Det fremgår også at kommunernes adgang til at lægge adressekoordinater ind via KMS Dataforsendelse eller RAP lukker pr 10. april 2008.

Problemet er ikke at kommunerne kun får et varsel på 7-8 hverdage til foretage de sidste indberetninger.

Problemet er ikke at den lovede 3-årige overgangsordning åbenbart ikke bliver til noget. En overgangsordning der skulle give systemleverandørerne tid til at implementere og teste op imod det nye interface.

Problemet er, at det nye interface ikke er til stede endnu, og det er især skræmmende når man i brevet læser at ’Der er endnu ikke en afklaring om, hvordan tilgangen til aflevering af adressekoordinater i det nye BBR, vil blive håndteret. KMD A/S er ikke bekendt med, hvornår en sådan adgang vil blive tilgængelig.’

Nu ved jeg jo ikke om det er en chef-arkitekt der har udtænkt dette, men det er efter min bedste mening sk… irriterende!

Udover at det er irriterende, så synes jeg at det er bekymrende at et centralt register omgås med en sådan form for lemfældighed.

Med venlig hilsen

Kristian

Peter Nørregaard

Det lyder da ikke godt - og det varsel er da helt ude i skoven! Nu tror jeg ikke at det er en chef-arkitekt der har udtænkt det så desværre kan det det ikke hjælpe med at svare på om de skal være irriterende.

Men mit råd må være at du tager fat i KL (som ud over at eje KMD også er en interesseorganisation for vores kunder) og hører om der er andre end dig der har problemer med det (og det er der jo nok) og går videre ad den vej.

Peter Nørregaard

Hehe, det viser jo den fare, der er ved at bruge analogier. Men rent faktisk holder analogien alligevel, for mens du kan sætte en dublo oven på en lego, kan du ikke sætte en lego oven på en doublo (så vidt jeg husker). Hvad siger du så? :-)

Peter Nørregaard

Det må jeg tage til efterretning (og ellers tage hjem og grave mit gamle lego frem for at dobbeltchecke).

Men når chef-arktekter bruger forkerte analogier, så må det da bidrage til at gøre dem irriterende. Det må jeg fortælle Claus Torp Jensen hvis jeg møder ham igen (hvilket ikke er sandsynligt da han snart rejser til en stor stilling hos IBM i USA)

Bryan Rasmussen

hvis 'en standard 2x4 eller 2x2 kan godt sættes ovenpå en Duplo. Det er det der gør Lego så genialt IMO. '

det må betyde at så langt du udveksler loosely typed XML beskeder uden inline DTD referencer, inclusions, eller bruge af xsi namespace over REST virker det hele.

Eller har jeg misforstået duplo/lego analogien? :)

Peter Nørregaard

Bryan, analogien blev brugt til noget andet i foredraget (det har jeg nok ikke skrevet klart nok): Nogle klodser er processer, andre klodser er services, en trejde slags klodser er dem fra dit CMDB. Pointen var at det ikke nødvendigvis gav mening at sætte klodser sammen på tværs af type :-)

Anders Østergaard Jensen

Version2s bloggere og skribenter bør under alle omstændigheder tage sig et mindre kursus i dansk. Selv om Enterprise er et engelsk ord, så bør man alligevel anvende tankstreg mellem et dansk og engelsk ord. Altså: Enterprise-arkitekter. Ikke enterprise arkitekter.

Thomas Ammitzbøll-bach

Det er en engelsk syge, der har ramt det danske skriftsprog i epidemisk grad.

Der er forskel på en "ringeklokke" og en "ringe klokke", og en "halvgod flaske vin" er ikke det samme som en "halv, god flaske vin".

En anden udansk angloterm: For nogle måneder siden hørte jeg i radioen en politiker, der mente, at vi skulle blive bedre til at "spotte" de svage elever i folkeskolen. Meget betænkeligt! Ikke alene er de stakkels elever svage, men de skal tilmed udsættes for spe og spot fra politisk hold.

Thomas

Jens Jakob Andersen

Hej Anders,

God pointe. Lidt ligesom svimming pøl eller svømme pool.

Hvis vi ser på en definition af ordet "Enterprise": i.flg Dictionary.com:

  1. a project undertaken or to be undertaken, esp. one that is important or difficult or that requires boldness or energy: To keep the peace is a difficult enterprise.
  2. a plan for such a project.
  3. participation or engagement in such projects: Our country was formed by the enterprise of resolute men and women.
  4. boldness or readiness in undertaking; adventurous spirit; ingenuity.
  5. a company organized for commercial purposes; business firm.
  6. (initial capital letter) Military. the first nuclear-powered U.S. aircraft carrier, commissioned in 1961, with a displacement of 89,000 tons (80,723 m ton) and eight reactors.

7. (initial capital letter, italics) U.S. Aerospace. the first space shuttle, used for atmospheric flight and landing tests.

Vi kan også læne os op af Martin Fowler - "Who needs an architect":
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

hvor han debatterer titlen og rollen.

Mit personlige bud på en dansk titel som giver mening, er "Forretnings- og IT-arkitekt" - det er den samlende perspektiv at enterprise-arkitekten bringer på banen?

Med gode hilsner

Jens Jakob

Peter Nørregaard

Fælles definitioner af roller er svær.

@Jens, dit forslag med at kalde enterprise-arkitekten for "Forretnings- og IT-arkitekt" bruger to termer som betyder noget andet allerede:
- IT-arkitekt bør IMHO ikke bruges som en betegnelse for en specifik rolle (i OO-termer bør det være en abstrakt klasse), se evt. http://www.version2.dk/artikel/6456)
- Forretningsarkitekt har OIO defineret som en arkitekt-rolle uden behov for dybere IT-indsigt: http://ea.oio.dk/arkitekter/roller/forretningsarkitekt/ og som derfor mere er ekspert i kundens forretning end i IT.

Ellers er diskussionen om arkitekten og hans (det er underligt nok altid en han) rolle interessant, synes jeg, og jeg læste din reference til Fowlers arbejde. Emnet kræver mere plads end der kan være i en kommentar – måske skriver jeg et egentlig blogindlæg om det på et tidspunkt.

Men en anden ting: kommentarerne har ind til nu ikke forholdt sig til selve emnet, nemlig om pointerne fra foredraget er rimelige (og om chef-arkitekter altid er irriterende). Hvad synes I?

Peter Nørregaard

@Anders og Thomas, jeg har fået et mail fra OIO efter jeg fortalte dem om jeres indvending. De havde sidste år spurgt Dansk Sprognævn og OIO skriver om svaret fra Dansk Sprognævn:
[citat]
De sanktionerede helt brugen af "enterprise arkitektur", "enterprise arkitekt" mv , ud fra det faktum, at "enterprise" er engelsk, og derfor et ord der står alene. Den samme regel kan fx også bruges når man taler om en EA reol eller en EA metode.
[/citat]

Log ind eller opret en konto for at skrive kommentarer

IT Businesses