Værdien af Enterprise Architecture

Måske skal man ikke nødvendigvis sætte lighedstegn mellem Enterprise Architecture og Enterprise Architect.

Jeg har altid haft det svært med denne opdeling mellem IT og forretning, som i øvrigt er mere åbenlys, når man deltager i internationale fora i forhold til hvor tit man nævner det her til lands.

Om man har brug for en eller flere dedikerede fuldtidsansatte arkitekter har jo også noget med forretningens størrelse at gøre – og her til lands har vi jo notorisk mange mindre forretninger, hvor man må gå mere pragmatisk til værks.

Men også i store organisationer tror jeg det er vigtigt at mennesker på ”forretningssiden” tænker på, kender og tager IT-arkitektur alvorligt når man designer processer, ligesom at det er vigtigt at ”IT-siden” har forretningens bedste og den samlede arkitektur for øje i alt man gør.

Så at advokere for EA er helt sikkert også et spørgsmål om at gøre emnet nemt tilgængeligt for både dem, der har deres daglige gang i forretningen og dem, som pisker rundt i IT-afdelingen.

Til daglig beskæftiger jeg mig med emnet datakvalitet – eller manglen på samme, som også er en udfordring, som skal løses af forretningssiden og IT-siden i fællesskab. Det er da heller ikke her løsningen alene at have en Data Quality Manager, men vedkommende kan måske løse op for problemet ved en nærmest folkeforførende metode – lidt a la Obama.

Værdien af disciplinen Enterprise Architecture afhænger selvsagt af forholdet mellem omkostningen og værdiskabelsen.

Her har EA-disciplinen et ufortjent dårligt ry som dyr og dokumentations-tung. Den er dog også beskrevet som ret rigid: Hvis vi forsøger at skabe en komplet dokumentation af en virksomhed og går i gang med Zachman fra en ende af, er vi sikre på at knække halsen. Zachman er, når den bliver taget på ordet, ret akademisk: 6 generiske spørgsmål (hvad, hvordan, hvor, hvem, hvornår og hvorfor) ganget ud på 6 teoretiske aktører. 6 * 6 = håbløst komplekst.

Som jeg har skrevet andetsteds[1] så tilstræber EA-metoder, med det modenhedsniveau de har i dag, snarere at være komplette end at være præcise. Ingen praktiserende arkitekt med realitetssans forsøger dog at udøve EA-discplinen med det formål at skabe en komplet EA-dokumentation.

En enterprise arkitekt med en rigid tilgang til EA-disciplinen (og specielt til EA-dokumentationen) er, for at svare på Renés spørgsmål, ikke sin løn værd.

René spørger: Kan en forretning gøre sig nogen forhåbninger om at forretningsideerne der løbende bliver genereret har mulighed for at blive it-realiseret og forankret i organisationen uden en Enterprise Architect?

Tja, svaret på dét er, at der er mange der kappes om at udgøre limen mellem forretning og it: Produktudviklere, produktansvarlige, forretningsansvarlige, mellemledere, projektledere, it-arkitekter og -chefer, senior-udviklere, studentermedhjælpere, you-name-it. Og de gør det måske udmærket i praksis, nogle gange er det mere held end forstand, andre gange fordi de rent faktisk har forståelse for essensen af EA. Så enterprise arkitekt-rollen varetages typisk i en eller anden form i dag, dog sjældent systematisk og med strategisk overblik.

Men der er en gevinst ved en professionelt skolet, metodestærk, pragmatisk, vidende, erfaren enterprise arkitekt med de rette personlige egenskaber. Sådan en arkitekt praktiserer EA-disciplinen efter en pragmatisk best-practise. Den får du her i kort form:

-> EA is a journey – start small, create buy in, pick low hanging fruits, prove profitability, go again.

Hvor stor er den gevinst? Nok større end de fleste forestiller sig, men djævelsk svær at sætte tal på. Er der nogen der har en business-case?

Hvis I tillader jer selv at

1) Glemme konceptet Enterprise Arkitekt som rolle/stilling  
2) Glemme Enterprise Arkitektur rammeværker (for mangel af et bedre ord) som TOGAF, Zachman, DoDaf, ...  

og herefter at filosofere imens I venter på en ny runde øl på Bopa (ikke kbh'ere: lokal bar som har lange serveringstider) over hvordan I vil styrke forbindelsen imellem forretningen (nærmere dens vision, mission, strategi, ...) og it for herigennem maksimere et firmas evne til at overleve, vækste, tjene penge til ejerne, ...

Vil I så genopfinde stillingen Enterprise Arkitekt, genopfinde TOGAF, klassifikationsrammeværktøjet som Zachman definerede, ... ?
Jeg tror personligt mere på en tilgang, som finder sit værdisæt i stærk kommunikation mellem alle stakeholders i firmaet, som er lean inspireret med dens value chain optimisation samt elementer som er kendt fra agile software development ala' deliver fast and often, process adaptability og team work. Jeg kan ikke rigtig finde en egentlig funktion i en sådan verden som skal hedde Enterprise Arkitekt og som har ansvaret for at teknikken implementerer forretningsvisionen. Jeg ser derimod en række roller med hver deres baggrund som, evt. via et rammeværk, er i stand til at bruge hinanden (kommunikation) til løbende at implementere de forandringer som virksomheden konstant skal bruge for at optimere dens forretningsmuligheder.

Lad Chaos Management møde teknikken om man så må sige.

Lars

Hej Lars
Mens jeg stod og ventede på øllet, kom jeg altså ikke længere end til, at det var da overordentlig "modigt" - i disse tider at foreslå chaos management :-)

Da jeg så gik hjem "halv" snaldret, havde jeg en ordentlig argumentationsstrøm til dig.
Nu hvor jeg er vågnet med ondt i håret, er jeg kommet frem til at min argumentationsstrøm nok i virkeligheden bare ville invitere til en ny argumentationsbølge (denne gang i min retning), og at jeg så skulle filosofere et andet sted, imens jeg ventede på en ny øl.

Hele denne proces for at nå til en form for fælles forståelse er lidt for smertefuld for mit hår, da jeg tror at gap'et i vores forskellige perspektiver er for stort. Derfor vil jeg holde mig tilbage - gad vide hvordan det var gået i en "chaos management/nøjes med at kommunikere organisation"?

Måske skulle vi så have sat nogle fælles rammer op hvorunder vores forskelligheder kunne mødes, og måske var der nogen som havde til opgave at sørge for at disse rammer blev udarbejdet og vedligeholdt...

Åh nej - nu begynder jeg igen, og jeg ikke engang på bar :-)
Mvh.
Simon

Dit indlæg har alt for længe fortjent svar fra mig – men jeg har været optaget af trivielle ting som opgaver, tilbudsskrivning og den slags.

Der er flere svar til dig. Hvis vi nu skulle starte fra scratch så ville vi nok heller ikke nå frem til et behov for CMMI, Prince2, RUP, TQM og meget mere. Én mand med den rette indstilling og viden ville kunne klare sig fint i en lille organisation uden nogen af disse ting.

Lige så snart opgaven er større og omgivelserne komplekse ser situationen imidlertid noget anderledes ud. Behovet for EA opstår når én applikation ikke længere understøtter dig i alle dine centrale processer. Behovet for EA opstår når én mand ikke længere kan overskue forretningen og it.

Dermed siger jeg også (og det er mit andet svar) at EA disciplinen ikke behøver at tages i brug som Den Store Pakke. Med fare for at gentage mig selv, så er opskriften "EA is a journey – start small, create buy in, pick low hanging fruits, prove profitability, go again."

I den korte form er EA noget du gør, når du oplever et problem eller en risiko: Beskriv as-is, to-be og hvordan du kommer fra as-is til to-be. EA giver dig gode råd (baseret på best practise) om hvordan du gennemtænker og udfører de tre trin med størst sandsynlighed for succes.

Det må du da have brug for, selv hvis din verden kan ligge i en nøddeskal? :-)

PS. Simon, jeg håber det går bedre med hovedet :-D

Det lyder til at øl og tænkning over de grundlæggende elementer i de ting vi beskæftiger os med kan til sammen give tømmermænd :) Spøg til side, jeg har et par gange forsøgt at skrive et svar som fyldestgørende beskriver hvad jeg egentlig mener, men hver gang stoppet efter 4. side. Så humlen bliver nok, at emnet egentlig ikke egner sig til at blive diskuteret på et web-forum som mest af alt beskæftiger sig med at diskutere Windows, Word, kvinder i it eller mangel på samme. Mit emne handler om:
dynamikkerne i konteksten man forsøger at bruge EA i,
hvornår de almindelige kendte EA teknikker er brugbare givet det faktum, at de ikke har patent på at kunne opfylde S + B + T eller de 1000vis andre måder at definere EA på, - i forbindelse her med
hvad er processen til at få forretningen til at gå op i en højere endhed med it,

Det altsammen under forudsætningen af man forholder sig til virkeligheden: at man ikke har en ledelse som er visionær, at de mangler viden om hvad man kan med it, at den mangler slagkraftig, at der er masser politik i organisationen, at organisationen er umoden i forhold til at kunne køre store EA projekter, at der kun er udført svagt (eller meget power point'agtigt) vision, mission, strategi arbejde og i bund og grund kan du ikke antage at ledelsen lige tager det store ansvar på deres kappe med hensyn til at gennemføre de organisatoriske ændringer som mange gange skal til for at kunne implementere S + B + T.

Jeg taler om, at nu sender vi alle dem hjem som kun kan flosker og som ikke rigtig kan komme ud over emnet "hvor vil verden være god hvis ledelsen blot forstod hvor meget værdi en Enterprise Arkitekt kan tilføre virksomheden" således at dem der er tilbage er dem som kan (meget vigtigt ord: kan) deltage i en modning af organisationskulturen m.m. med det formål at organisationen (herunder ledelsen) bliver i stand til at kunne udføre opgaven med at implementere S + B + T. Det er en meget kontekstafhængig opgave og en opgave som aldrig rigtig stopper. Det er en opgave som man nemt vil kunne undgå at skulle forholde sig til ved at fyre en anden kommentar: da alle firmaer er forskellige og har hver deres politiske miljø så kan man ikke rigtig sige noget om det. Tja, hvis man ser på agile verden så er der et kæmpe community omkring at danne mønstre om hvordan organisationer kan omdannes fra at være waterfall til at være agile og det uden at man tager udgangspunkt i at ledelsen har forstået det hele fra starten. Når floskelfolkene (jeg tænker ikke på nogen specielt her, blot masser af EA folk som jeg har diskuteret med) er gået hjem, så burde de folk som har evner inden for: kommunikation med forretningen, kommunikation med tekniske udviklere, politik i organisationer og leverance være tilbage. Leverance skyldes en anden "regel/floskel" som de fleste virksomheder lever efter: S x E = R, eller Strategi x Execution = Results. De folk er interessante at diskutere værdier, steps, tips og tricks med i forhold til den reelle opgave i den virkelige verden.... Anyway, som sagt emnet er ikke så nemt at diskutere her, så over-and-out-from-me..

Lars

Suk, jeg hader no-script til Firefox - den stopper lidt for meget... Her lidt omformateret.

Det lyder til at øl og tænkning over de grundlæggende elementer i de ting vi beskæftiger os med kan til sammen give tømmermænd :) Spøg til side, jeg har et par gange forsøgt at skrive et svar som fyldestgørende beskriver hvad jeg egentlig mener, men hver gang stoppet efter 4. side. Så humlen bliver nok, at emnet egentlig ikke egner sig til at blive diskuteret på et web-forum som mest af alt beskæftiger sig med at diskutere Windows, Word, kvinder i it eller mangel på samme.
Mit emne handler om:
dynamikkerne i konteksten man forsøger at bruge EA i,
hvornår de almindelige kendte EA teknikker er brugbare givet det faktum, at de ikke har patent på at kunne opfylde S + B + T eller de 1000vis andre måder at definere EA på,
hvad er processen til at få forretningen til at gå op i en højere endhed med it - hvis man nu føler at de alm. kendte teknikker ikke rækker,

For mig handler det om at forholde sig til virkeligheden:
at man ikke har en ledelse som er visionær,
at ledelsen mangler viden om hvad man kan med it,
at ledelsen mangler slagkraft,
at der er masser politik i organisationen,
at organisationen er umoden i forhold til at kunne køre store EA projekter,
at der kun er udført svagt (eller meget power point'agtigt) vision, mission, strategi arbejde

og i bund og grund kan du ikke antage, at ledelsen vil tage det store ansvar på deres kappe med hensyn til at gennemføre de organisatoriske ændringer, som mange gange skal til for at kunne implementere S + B + T.

Jeg taler om, at nu sender vi alle dem hjem, som kun kan flosker og som ikke rigtig kan komme ud over emnet "hvor vil verden være god hvis ledelsen blot forstod hvor meget værdi en Enterprise Arkitekt kan tilføre virksomheden". Altså der er kun dem tilbage som kan (meget vigtigt ord: kan) deltage i en modning af organisationskulturen m.m. med det formål at organisationen (herunder ledelsen) bliver i stand til at kunne udføre opgaven med at implementere S + B + T. For at kunne deltage så skal du have evner inden for:
kunne tale med forretningen,
kunne tale med tekniske udviklere,
kunne begærde sig i det politiske miljø i en organisation,
at levere.

At kunne levere er i mine øjne meget vigtigt eftersom at de fleste virksomheder lever efter en kendt floskel/regel: S x E = R, eller Strategy x Execution = Results. Så i min verden hvis man ikke forstår, at der skal leverancer for at kunne købe tillid til at udføre de opgaver som forbedrer skridt for skridt organisationens evner til at udføre kvalitetsarbejde når man ser forretningen sammen med it så forholder man sig ikke til virkeligheden.

Det er svært at komme til det punkt i diskussioner, hvor man er nået ud over de fleste standard sætninger som jeg kan finde i de alm. kendte bøger. Det er svært at komme til at diskutere hvordan, hvad, m.m. i forhold til den virkelige verden. Den diskussion har jeg reelt kun fundet på workshop orienteret konferencer f.eks. Wicsa.net eller når jeg mødes med kollegaer som har skulle arbejde i en S + B + T inden-fra-ud i en organisation.

Lars