Många ramverk för Enterprise Architecture (EA) upplevs som tungrodda och alltför omfattande och detta är ett av flera skäl som brukar anges till varför införande av EA misslyckas. Fenix Theuerkorn har inspirerats av Agile-rörelsens metoder för mjukvaruutveckling (SCRUM, XP, Crystal, DSDM m fl) när han formulerade ett eget ramverk för EA, *Lightweight Enterprise Architecture * (LEA).
LEA har ett minimum av dokument, en metod och en enkel terminologi som gör att en större publik kan nås, d v s att fler inom företaget eller organisationen kan ta del i arbetet med EA och därmed även skörda frukterna.
Författaren tar sin utgångspunkt i att den ökande komplexiteten i företags IT-miljö i praktiken gör det omöjlighet att ha en enhetlig syn på IT inom företaget. Heterogena miljöer är här för att stanna och kreativitet och anpassningsförmåga föds i mångfalden. Varje område inom företaget skall använda de verktyg som uppgiften kräver och i LEA söker man mer till att sätta gränser för vilka uppgifter som skall utföras, än att i detalj styra hur de utförs. I likhet med Agile-metoderna utgår man från att de som skall styras av EA är kompetenta nog att fatta egna beslut men kan behöva hjälp med helhetssynen och att behålla fokus på affärsnyttan.
Boken är uppdelad två sektioner och en omfattande appendix. Den första sektionen beskriver de vanligaste problemen med IT, varför EA behövs och vilka fördelar man kan förväntas uppnå genom att införa EA. Den andra sektionen behandlar LEA mer i detalj. Appendixen innehåller bl a ett fullödigt exempel på en konceptuell arkitektur enligt Open Applications Group Integration Specification (OAGIS). Syftet med exemplet är att konkret visa på vilken nivå den konceptuella arkitekturen förväntas ligga. Inget i LEA kräver att man använder just OAGIS. Mer om den konceptuella arkitekturen nedan.
Utöver en beskrivning av LEA innehåller boken även ett helt kapitel ägnat åt Dysfunctional Enterprise Architectures. Kapitlet skall läsas med glimten i ögat, men utöver underhållningsvärdet ger det en rad situationer att ge akt på. Ett annat kapitel innehåller diverse hot mot införandet av LEA, även dessa exempel är mycket underhållande och nyttiga.
EA enligt LEA
LEA delar upp EA i tre huvudområden (domains): Information Architecture, Application Architecture och Technical Architecture. Denna uppdelning är ganska vanlig men LEA omdefinerar termerna något.
Med Information Architecture (IA) avses människors interaktion med datorsystem, exempel på områden som innefattas av IA är processer, funktioner m m. Vanligen avses med IA definitioner av verksamhetsövergripande datastrukturer (typiskt kund, användare, faktura etc. Här avviker alltså LEA avsevärt från den gängse normen. (Frågan är om man inte borde ha valt ett annat ord för att undvika begreppsförvirring.)
Med Application Architecture avses hur individuella system hänger samman, vad de gör, vilka visioner de stöder etc. AA innefattar även definitioner av datastrukturer men med betoning på att man inte bör sträva efter företagsövergripande datastrukturer i enlighet med en mer traditionell IA. Författaren hävdar att traditionell IA är ett arv från en svunnen tid när systemen var få och resurser som minne och permanent lagring av data var dyrt. En av de vanligaste anledningarna till att EA misslyckas är att man av politiska och praktiska skäl inte lyckas ena företagat kring företagsövergripande definitioner av data. (Det här borde vara en av de mer kontroversiella ståndpunkterna av EA, men det är svårt att inte böja sig för det rent praktiska argumentet att det i verkligheten nästan är omöjligt att åstadkomma och underhålla en traditionell informationsarkitektur.)
Technical Architecture* (TA) betecknar främst fysisk hårdvara som servrar, switchar, nätverk m m men även hårt standardiserade tjänster som operativsystem och applikationsservrar.* Denna definition av TA stämmer väl överens med den i t ex TOGAF.
LEAs tre lager
Inom LEA skiktar man arkitekturen i tre lager som motsvarar tre olika synvinklar eller utsiktspunkter (views). Ur ledningens synvinkel är det den strategiska arkitekturen som är den mest intressanta, arkitekten själv jobbar huvudsakligen med den konceptuella arkitekturen och IT-projekt tar sin avstamp i utförandearkitekturen (executuion architecture)
Den strategiska arkitekturen formas huvudsakligen av ledningen självt. En av de viktigaste informationskällorna för den strategiska arkitekturen är den IT-strategi som företaget (eventuellt) har tagit fram vid ett tidigare tillfälle. Viktigt att notera är att det inte är arkitekten som ansvarar för innehållet i den strategiska arkitekturen, det gör ledningen. Arkitektens roll är att sammanställa och formulera ledningens vision och de principer utifrån vilka företaget skall satsa på IT.
För den konceptuella* arkitekturen ansvarar arkitekten. Det är här helhetssynen av företagets alla IT-system formuleras. Den konceptuella arkitekturen innefattar systemkartor på en hög nivå; det är endast övergripande funktion, beroenden och systemkontrakt som dokumenteras. Detaljerna i hur ett system fungerar lämnas till utförandearkitekturen.*
*Utförandearkitekturen eller kanske bättre *projektarkitekturen utgör det viktigaste styrdokumentet för ett projekt. Det innehåller de krav verksamheten har på projektet och de projektspecifika krav som kan formuleras utifrån de konceptuella och strategiska arkitekturerna. Den innehåller inte beskrivningar hur projektet skall lösa uppgifterna – fokus är på de externa kraven. Det skall således finas gott om utrymme för kreativitet i den projektspecifika lösningen. Arkitektens roll i projekten är mer som mentor och bollplank än som chef och hon deltar endast undantagsvis aktivt i projekten.
Sammanfattning
Sammanfattningsvis kan sägas att LEA är en välskriven bok med en intressant approach till EA.