EA i backspegeln

Enterprise Architecture som disciplin har funnits i 20 år men ändå har kunskapsområdet inte riktigt kommit till praktisk användning och nytta ute i företagen. De EA-satsningar som gjorts har ofta landat bara i powerpoints och pärmar. Det är inte många företag som har ett kontinuerligt arkitektarbete som genomsyrar företaget. Slutsatsen måste bli att Enterprise Architecture-samhället inte har levererat. Man har inte lyckats hjälpa företagen med att få ordning på sin arkitektur.

I många organisationer finns det en kultur av misstro mellan it- och verksamhetspersonal. Ingen arkitektur eller metod kan överbrygga denna klyfta, såvida det inte finns ett genuint engagemang för förändring. Detta åtagande måste komma från den högsta nivån i organisationen. Metoder kan inte lösa människors problem; de kan bara ge en ram inom vilken dessa problem kan lösas.

Behovet av arkitektur

Att vi arkitekter inte har lyckats hjälpa företagen är ett problem, för det finns ett stort behov. Varje företag har ett behov av att arbeta med sin utveckling på en mer meningsfull nivå än den sloganmässiga. Det är vanligt att företag har problem med att hantera sin informationsresurs, sina processer och sin it-portfölj både som helhet för hela företaget och som helhet för en viss förmåga. Man behöver skapa en gemensam syn för hur information, process och it-lösning samverkar. Det räcker inte med att man har ett antal utvecklingsprojekt och ett projektkontor. Man behöver också ett gemensamt arkitekturarbete.

Som författaren till boken Chess and the Art of Enterprise Architecture, Gerben Wierda, skriver i sin blogg:

...
There has been no technological ‘silver bullet’ and also Enterprise Architecture as a discipline has so far largely failed to produce the intended results. This is also reflected by the fact that Enterprise Architecture initiatives seldom have a long life. They get reorganised a lot, and that is not because organisations are satisfied with their added value, right?
...

Olika modeller

I EA-skogen har man flera olika modeller tillhands för att beskriva sin organisation. Gemensamt för dessa är att man väljer att beskriva sin organisation, eller företag, i ett antal vyer. Arkitekturen hos en organisation kan beskrivas med olika modeller, begreppsmodell, klassmodell, processmodell, datamodell, etc, men det är mycket svårt att urskilja arkitekturen i denna helhet. Det är därför bättre att prata om arkitekturbeskrivningar, som är olika vyer av den bakomliggande arkitekturen.

Arkitektur kan beskrivas som ett sätt att hantera struktur och samverkan. En arkitektur är utformad för att stödja eller förhindra ett beteende. I arkitekturen ingår även metoder och strategier för att ta fram en arkitektur. Till arkitektur räknar vi både systemets funktioner ur ett nyttjande perspektiv och dess tekniska utformning.

Här följer en kortare översiktav olika EA modeller och de vyer som respektive modell fokuserar på.

Zachman

Vår EA:s urmoder. Zachman fokuserar på fem vyer:

  • Scope - som vänder sig till planeraren
  • System - med fokus på designers
  • Technology - med mottagare inom konstruktörer
  • Detail - med intressenter som underleverantörer som mottagare

De olika vyerna kan sedan beskrivas ur ett antal olika synvinklar:

  • Motivation/Why - Affärsmål, mål och resultat åtgärder i samband med varje funktion
  • Data/What - Högnivå informationsklasser, relaterade till varandras funktion
  • Function/How - Högnivå affärsfunktioner
  • Network/Where - Platser med anknytning till varje funktion
  • People/Who - Intressenter relaterade med varje funktion
  • Time/When - Cykler och händelser relaterade till respektive funktion

Min reflektion kan vara att det är en stor arbetsinsats att få fram beskrivningar över alla vyerna och synvinklarna. Time-to-market är lång. Ofta kan en viss holistisk världssyn vara bra att applicera på byggandet med Zachman, något som dock inte rekommenderas av Zachman och son.

En annan aspekt på Zachman är att det är en bra beskrivning av nuläge. Men jag har ännu inte stött på mekanismer i Zachman som stödjer framtagande av framtidsbeskrivningar och analyser av glapp mellan nu- och börläge.

Kan tänka mig att Zachman fungerar bäst när det kombineras med andra metodiker.

MODAF

En militärstandard som dock kan appliceras på andra sorters organisationer. MODAF har sex vyer i sin modell. Fyra av dessa, Strategi, Tjänster, Operation och System beskriver hur man styr och genomför olika verksamheter och vilka lösningar som man kan använda. För att klara av detta har man två vyer som spänner över de tidigare nämnda fyra, Anskaffning och Standards.

Har man en organisation som har många inblandade med många system som man behöver använda på olika sätt så kan MODAf vara en modell att beakta.

MODAF är inte lättviktig på något sätt så den passar sämre för mindre organisationer.

TOGAF

TOGAF fokuserar på fyra vyer Verksamhet, Applikation, Information/Data och Teknologi. Till detta finns en metod, eller en process, för hur man utvecklar och underhåller sin arkitektur, TOGAF ADM.

TOGAF har inte någon inbyggd funktionalitet för att bedöma om arkitekturen är bra. Man har en bra process för att i olika cykler ta fram arkitekturen. TOGAF är ett ramverk för aktiviteter och resultat. Den anger eller rekommenderar att vissa verksamheter och resultat kan användas vid utveckling av en arkitektur. Vad det inte beskriver är hur man tar fram detta.

Vad behöver vi?

Den springande punkten är att kunna kommunicera sin arkitektur. En EA-arkitektur ska kunna användas av hela organisationen.

Enligt Neil Rerup, President & Chief Architect at Enterprise Cyber Architects, så är det viktigaste kommunikation. Nedanstående bild visar enligt honom vad arkitektur handlar om:

Så här skriver Neil Rerup i en artikel på LinkedIn:


...
The Stakeholders don't change. The method of communicating can change but that doesn't affect the idea as long as the communication actually occurs. The method of creating an Architecture may change as long as the solution itself is still the same in the end. An Architecture is an idea made real. It's the realization of the different needs of the Stakeholders. It's not the methods associated with the practice of Architecture, it's the Architecture itself.
...

Vi har under de två senaste decennierna sett en våg av lättrörliga, involverande och iterativa arbetssätt. De har ersatt gamla planekonomiska strukturer både inom tillverkning och inom utveckling. Det kallas ibland Lean och Kanban, ibland Agile Development. Det är synsätt som har revolutionerat industrin och tjänsteproduktion och nu även tjänsteutveckling.

Tune in next time...

I nästa blogg kommer en recension av "Continuous Architecture" av Murat Erder (ISBN: 9780128032848). Innehåller denna beskrivning en universallösning som gör att vi arkitekter kan luta oss tillbaka?