IASA – böcker och handböcker

En av Iasa:s uppgifter är att ta fram och utveckla det intellektuella kapitalet inom arkitekturområdet. Detta gör vi genom att tex;

Ordna möten
Ta fram rekommendationer om tex arkitektroller
Certifiera arkitekter
Bedriva utbildningar
Skriva böcker

Under 2014 stöttade vi en bok om IT-arkitektur, och 2015 tog vi fram en handbok om Arkitekturell förmåga. Vill du vara med om att ta fram 2016 års handbok? Vad ska den handla om? Arbetet innebär att du ingår i en grupp som tex träffas en gång per månad för att diskutera utkast till texter samt att samtala om de erfarenheter gruppen har inom området. Om du har frågor eller vill vara med att ta fram 2016 års handbok skicka då ett epost till per-erik.padron@perago.se med förslag till tema för handboken. Resultatet från arbetet kommer att presenteras i handbok eller i en kortare PM.

Några idéer till tema är;

Att kommunicera arkitektur
Att organisera arkitektur
Att arbeta med referensarkitektur
Hur kvalitetssäkrar man arkitektur
….

Recensioner av andra böcker.

Nedan så hittar ni en genomgång av aktuellt material som handlar om IT arkitektur. Ett speciellt tack till Peter Tallungs för ett stort antal intressanta recensioner.

1. Översiktliga kurser och böcker inom arkitekturområdet

Det finns böcker och kurser som ger en introduktion eller översikt till arkitektarbete. En sådan kurs eller bok ger dig en grund att stå, genom att måla upp området och ge dig tips på hur du skall gå vidare.

1.1. Enterprise Arkitektur (EA)

Bok: Jeanne W. Ross, Peter Weill, David Robertson: Enterprise Architecture as Strategy, 2006, ISBN 1-59139-839-8

Recension: Behöver alla företag satsa på samma saker för att få ett bra IT-stöd? Detta är en viktig fråga för alla arkitekter, och min gissning är att de flesta arkitekter skulle besvara den frågan med ett ”Nej”. Men varför skall företagen satsa på olika saker, och vad bör de satsa på? Författarna som arbetar på MIT har studerat ett stort antal företag och deras sätt att arbeta med IT. De klassificerar foretag utifrån 1) mogenhetsgrad och 2) behov av att standardisera sina processer och integrera sitt data. Klassificeringen gör det möjligt att rekommendera vad ett företag bör satsa på som ett nästa steg i sin utveckling. En röd tråd genom boken är att företag måste lära sig om sin bransch och hur de vill konkurrera på sina marknader innan de kan mogna. Vad företagets arkitekter bör fokusera på varierar starkt beroende på var i lärandeprocessen företaget befinner sig.
/Herbjörn Wilhelmsen

Bok: Peter Weill, Jeanne W. Ross: IT Savvy, 2009, ISBN 978-1-4221-8101-0

Recension: Författarna som skrev Enterprise Architecture as Strategy har arbetat vidare med sin kartläggning av företag och deras sätt att arbeta med IT. Mycket av innehållet i denna bok liknar den förra boken, men den är skriven mer för affärsfolk än arkitekter. Boken visar intressant nog på att antalet företag i de mer mogna kategorierna är betydligt mindre än det som redovisades i den förra boken. Detta för att flera företag kartlagts och mer data samlats in. Författarna har dessutom inkluderat ett antal frågor som kan användas för att klassificera företag. Som arkiktekt kan du ha stor nytta av att veta mer om hur företagsledare tänker på IT och vässa dina argument för hur företag kan få ut mer nytta av sitt IT-stöd.
/Herbjörn Wilhelmsen

1.2. Affärsarkitektur

Kurs: Dataföreningen Kompetens: Certifierad affärsarkitekt, 12 dagar

1.3. Verksamhetsarkitektur

Kurs: Dataföreningen Kompetens, Certifierad verksamhetsarkitekt, 10 dagar

Recension: Kursen ger en bra introduktion till och översikt över området, och till arbetstekniker som informationsmodellering och processmodellering.
/Peter Tallungs

1.4. IT-arkitektur

Kurs: Dataföreningen Kompetens, Certifierad IT-arkitekt, 12 dagar
Onlinekurs: Software Architecture for Business Agility, 2xSundblad Academy
Kurs: Certifierad mjukvaruarkitekt, med specialinriktning Microsoft-teknologier (sammanlagt 10 dagar i klassrum, ovanstående online-kurser, samt hemuppgift som skall försvaras inför panel)

2. Ledarskap och kommunikation

En arkitekt är en ledare, facilitator och en kommunikatör. Det är sidor av det dagliga arbetet som mer än något annan påverkar hur du lyckas i längden, i ditt arbete, med dina mål och med ditt liv. Visst finns det födda ledare men de är alldeles för få. Vi andra får gå på kurs, läsa böcker och träna vår förmåga på familj och på arbetskamrater. Och det går faktiskt riktigt bra att utvecklas som gruppmedlem och som ledare, med inspiration och träning.

2.1. Ledarskap allmänt

Kurs: Utveckling Grupp Ledare (UGL), 5 dagar, internat
En UGL-kurs är en tuff internatkurs som utvecklar dig som medarbetare och som ledare. Den gör dig uppmärksam på vad som händer med dig själv, med personerna i din omgivning och med gruppen.

Recension: Jag och många med mig upplever sin UGL-kurs som en omskakande och inspirerande upplevelse. Jag vet inget annat (på så kort tid och som kan köpas för pengar) som kan ge en sådan kick framåt i ens personliga utveckling. /Peter Tallungs

Bok: Michael Abrashoff: It’s your ship 2002, ISBN 0-446-52911-7

Recension: Det här är en inspirationskälla för mig, som jag ofta återvänder till. Captain Abrashoff berättar om sin tid som fartygschef på jagaren USS Benfold. Med energi, mod, empati och respekt för individerna får han den nerslitna besättningen att ta ansvar för sina arbetsuppgifter, med glädje och deltagande. På så sätt uppfinner han sitt ”Grassroot leadership” som påminner mycket om Toyota Way och blir en managementguru. En spännande och insiktsfull bok.
/Peter Tallungs

2.2. Workshopledning

Arbete i workshop är en viktig grundteknik för en arkitekt. Inget annat arbetssätt ger så snabba framsteg och en så effektiv förankring av resultatet. Men arbetssättet kräver kunskap och erfarenhet av ledaren.

Kurs: Astrakan: Facilitering av effektiva möten – workshopledning, 2 dagar
Kurs: Astrakan: Fördjupningskurs i facilitering, 3 dagar

2.3. Kommunikation och förhandling

En arkitekt behöver kommunicera muntligt och skriftligt med olika intressenter med olika bakgrund och inriktningar. En arkitekt behöver framföra en ståndpunkt, ta strid när det går och förhandla när det behövs. Retorik hjälper dig att argumentera och att genomskåda och bemöta andra talare.

Bok: Göran Hägg: Praktisk retorik,
Bok: Göran Hägg: Retorik idag, 2004 ISBN 91-46-18341-8
Bok: Roger Fisher, Daniel Shapiro: Beyond reason: Using emotions as you negotiate, 2005, ISBN 0-14-303778-1

Recension: Som arkitekt är det lätt hänt att basera all sin kommunikation med berörda intressenter på fakta och logiska resonemang. Att resonera logiskt räcker dock inte alltid till när man ställs inför intressekonflikter eftersom känslor spelar en mycket viktig roll i utfallet av alla förhandlingar. Att identifiera sina egna och andras emotioner är dock svårt. Att ändra sitt beteende utifrån hur man upplever sina egna och andras emotioner är inte bara svårt, det kan dessutom bli mycket förvirrande för andra. I Beyond reason berättar författarna om hur man genom att fokusera på några viktiga mänskliga behov kan hantera och reglera både sina egna och andras emotioner så att en förhandling kan leda till ett bra beslut för båda parter. Författarna, som är lärare på Harvard och arbetat som medlare, skriver på ett personligt och öppet sätt om flera känsliga lägen de själva varit med om och hur de löste dessa.
/Herbjörn Wilhelmsen

2.4. Analytisk design

En arkitekt kommunicerar med ritningar, kartor, diagram och andra grafiska medel. Grafiska uttrycksformer är inte bara till för att kommunicera utan är även analysverktyg; de hjälper dig och gruppen att tydligt se sammanhang och att lösa problem, det som kallas att modellera.

Bok: Edward Tufte: The Visual Display of Quantitative Information, 1983, 2001,
ISBN 0-9613921-4-2
Bok: Edward Tufte: Envisioning Information, 1990, ISBN 0-9613921-1-8
Bok: Edward Tufte: Visual Explanations: images and Quantities, Evidence and Narrative, 1997, ISBN 0-9613921-2-6
Bok: Edward Tufte: Beutiful Evidence, 2006, ISBN 0-9613921-7-7

Recension: Edward Tuftes fyra böcker är inspirerande för en som kommunicerar med olika kartor och grafer hela dagarna. Genom att göra riktigt bra diagram kan du få en organisation att se sin verksamhet och sin it. Det kan du bygga en karriär på!
/Peter Tallungs

2.5. Modellering allmänt

En arkitekt behöver modellera intressenter, verksamhetsobjekt, information, processer, mål, användningsfall, komponenter, tjänster, risker med mera. Oftast sker modelleringen i workshop. Detta är en av arkitektens grundläggande arbetsmetoder.

Kurs: Astrakan: Modellering och modelleringsledning, 2 dagar
Kurs: Astrakan: Högre kurs i modelleringsledning, 5 dagar

Recension: Detta är Astrakans flaggskepp, en högre kurs för erfarna verksamhetsutvecklare och arkitekter som vill fördjupa sitt kunnande inom modellering och modelleringsledning. En grand tour genom Astrakans samlade kunskap och erfarenhet.
/Peter Tallungs

2.6. Förändringsledning

Arkitektens arbete handlar ofta om att leda människor i förändring. Det är inte bara verksamhet och it som förändras; mer ofta än inte har organisationen inte haft ett strukturerat arkitekturarbete. Då behöver man leda ett införande av ett strukturerat arbetssätt i arkitekturarbetet. På andra ställen har man en alltför stelbent arkitektgruppering, långt från de dagliga leveranserna. Arkitektgruppen hindrar organisationen att reagera snabbt på möjligheter och förändringar i omvärlden. Då måste arkitekten inspirera och leda en förändring mot ett mera lättrörligt arbetssätt.

Bok: Peter M Senge: The Fifth Discipline, 1990, ISBN 0-385-46988-8

Recension: Insiktsfullt om hur man bygger en lärande organisation. /Peter Tallungs

2.7. Pedagogik

En arkitekt är nästan alltid mentor och coach till andra, både till andra arkitekter och till it-personal och verksamhetsfolk. Att kunna inspirera, lära ut till och utveckla personer är därmed en förmåga som behövs.

3. Projektstyrning och systemutvecklingsmetod

Det finns två orsaker till att projektstyrning och systemutvecklingsmetod är viktiga kompetensområden för en arkitekt. För det första leder en arkitekt ofta projekt, både företagsövergripande arkitekturprojekt och speciella lösningsprojekt, som teknisk projektledare.
För det andra behöver en företagsarkitekt arbeta nära leveransprojekten och behöver därmed förstå arbetssätt och mekanismer i ett sådant. De senaste åren har vi sett ett kraftigt uppsving för lättrörliga synsätt inom projektstyrning och systemutvecklingsmetod. Det är viktigt för en arkitekt att inte bara hänga med i den utvecklingen utan även driva den i organisationen. Arkitekter måste med alla medel undvika ett tungrott och byråkratiskt arbetssätt för att i stället leverera resultat tidigt och ofta, och att arbeta nära leveransprojekten.

En grundlig förståelse för tankarna och erfarenheterna inom Lean Software Development och Agile Software Development hjälper till. Även utvecklingen inom effektstyrning mot ett lättrörligt synsätt med användare i fokus bör vara väl känd.

3.1. Projektstyrning allmänt

Bok: Mary Poppendieck, Tom Poppendieck: Lean Software Development, 2003,
ISBN 0-321-15078-3
Bok: Mary Poppendieck, Tom Poppendieck: Implementing Lean Software Development, 2007, ISBN 0-321-43738-1

Recension: Lean Production med rötter i Toyota gick som en våg över världen och rationaliserade tillverkningsindustrin på 80-talet. Ledtider kunde kortas, spill reduceras och värdeflödet maximeras. Strax efter tillämpades idéerna på industriföretagens utvecklingsavdelningar, som Lean Product Development med liknande vinster. Mary Poppendieck fann under sin tid på 3M hur samma synsätt kunde översättas till systemutveckling. Det var det som blev Lean Software Development, ett synsätt som i långa drag överensstämmer med Agile Software Development, men kommer från ett helt annat håll. Mary och Tom Poppendieks böcker ger sann insikt i hur utvecklingsarbete bör bedrivas idag. /Peter Tallungs

3.2. Projektstyrning specifika metoder

Bok: Ken Schwaber, Mike Beedle: Agile Software Development with Scrum, 2002,
ISBN 0-13-067634-9
Bok: Ken Schwaber: Agile Project Management with Scrum, 2003, ISBN 0-201-69969-6

Recension: Projektstyrningsmetoden Scrum har spritt sig på bred front i företagen. Scrum är metoden som har ytterligt få komponenter. Endast det absolut nödvändiga är med och man fokuserar maximalt på detta. Styrkan med Scrum är att arbetssättet är enkelt att tillämpa och anpassa till olika situationer och ger en tydlig fokus på vad som behöver göras just nu i projektet. Ken Schwaber och Mike Beedle kan konsten att lyfta fram det viktiga. /Peter Tallungs

3.3. Systemutvecklingsmetod allmänt

Bok: Alistair Cockburn: Agile Software Development, ISBN 0-201-69969-6
Recension: Alistair Cockburn diskuterar insiktsfullt vad den rika kommunikationen har för betydelse i ett utvecklingsarbete. /Peter Tallungs
Bok: Andrew Hunt, David Thomas: The Pragmatic Programmer, 1999, ISBN 0-201-61622-X
Bok: Kent Beck: Extreme Programming Explained, 1999, ISBN 201-61641-6

3.4. Systemutvecklingsmetod specifika metoder

Recension: Det här var den första bok som skrevs om någon Agile-metod. Kent Beck sade ungefär motsatsen till det som utgjorde det förhärskande synsättet på varje punkt på den tiden. Och han gjorde det med en demagogisk vältalighet. Sedan dess har inget varit sig likt. Idag tycker majoriteten av metodförespråkare att han hade rätt – även om han ibland har fått ta tillbaka några av sina mest radikala uttalanden. /Peter Tallungs

Bok: Henrik Kniberg: Scrum and XP from the trenches, 2007, ISBN 978-1-4303-2264-1

3.5. Kravarbete

Bok: Alistair Cockburn: Writing Effective Use Cases, 2001, ISBN 0201702258
Bok: Mike Cohn: User Stories Applied, 2004, ISBN 0321205685

3.6. Effektstyrning av IT-projekt

Bok: Ingrid Ottersten, Mijo Balic: Effektstyrning av IT, 2004, ISBN 91-47-07450-7

Recension: Den här boken är ett kvanthopp framåt vad gäller synen på effektstyrning av IT. Vi har här den saknade länken mellan effektstyrning av it-projekt, användbarhet, kravarbete och arkitektur. Det är därmed i mina ögon en av grundbultarna inom det moderna synsättet på systemutveckling som håller på att växa fram. Trots att boken har en teoretisk inriktning, hjälper den oss att på ett effektivt sätt koppla samman projektets effektmål med det dagliga arbetet i projektet. /Peter Tallungs

4. Verksamhetsanalys och verksamhetsutveckling

En arkitekt arbetar med verksamhetsutveckling med inslag av it. Därmed behöver en arkitekt kunna analysera verksamheten ur olika aspekter.

Flera av de här rekommenderade böckerna återkommer under rubriken Programvarudesign och programvaruarkitektur. Orsaken är följande. De kunskaper och färdigheter som behövs för analys och design av verksamheten överlappar till sina centrala delar med de kunskaper och färdigheter som behövs för design av programvaran. En central del av programvaran utgörs av en så kallad domänmodell, det vill säga är en modell av den verksamhet som programvaran stödjer eller är en del av. Domänmodellen kan återfinnas i programkoden som klasser, attribut och metoder eller i databasstrukturen som tabeller och kolumner.

4.1. Verksamhetsanalys och verksamhetsutveckling allmänt

Bok: Martin Fowler: UML Distilled, 3rd ed 2004, ISBN 0321193687

Recension: Martin Fowlers tunna bok var den första som skrevs om UML och är fortfarande den enda riktigt läsbara boken om ämnet. /Peter Tallungs

4.2. Informationsperspektivet

Kurs: Astrakan: Avancerad begreppsanalys med modellering, 2 dagar

Recension: I allt analysarbete, särskilt vid informationsanalys är språket och begreppsanalys viktigt. Astrakans kurs bygger på gedigen grund från Stockholms universitet och forskningsinstitutet Sics. Jag vet inget annat sätt att tillägna sig denna nödvändiga kunskap. /Peter Tallungs

Bok: Graeme Simsion, Graham Witt: Data Modeling Essentials, 2005, 3rd ed,
ISBN 0-12-644551-6

Recension: Det här är kanske den enda riktigt bra boken om informationsmodellering som man kan sätta i händerna på en nybörjare. Den passar även den som har kommit längre. Graeme Simsion är en australiensare som har doktorerat på att informationsmodellering bäst förstås som design och inte som analys. /Peter Tallungs

Bok: Eric Evans: Domain-Driven Design, 2004, ISBN 0-321-12521-5

Recension: Eric Evans bok beskriver egentligen arbetet med design av programkod, närmare bestämt den del av programkoden som utgör domänmodellen. Det vill säga att den avbildar verksamheten och därmed utgör det gemensamma språket mellan alla intressenter i projektet. På grund av det ovan sagda, om det täta sambandet mellan design av kod och analys och design av verksamhet, är nästan allt i Eric Evans bok i lika hög grad tillämpligt på verksamhetsanalys.

På så sätt har en programmeringsbok kommit att bli det viktigaste och mest insiktsfulla arbetet om verksamhetsanalys som har skrivits under senare år. Synd bara att endast programmerare läser den. Jag anbefaller den som obligatorisk läsning till alla som håller på med någon form av informationsmodellering, vare sig det gäller konceptuella modeller, databasmodeller eller objektorienterad programkod.
/Peter Tallungs

Bok: Martin Fowler: Analysis Patterns, 1997, ISBN 0-201-89542-0

Recension: Det här är en direkt föregångare till Eric Evans bok, på det sätt att den handlar om design av domänmodellen i programkoden. På samma sätt är den tillämplig på verksamhetsmodellering. Det är mer eller mindre en katalog av informationsmodellmönster med resonemang om mönster. Den är lite mera tungläst än Eric Evans bok och handlar mera om mönster än om designarbetet. Enligt min åsikt har vi här den viktigaste katalogen av mönster för informationsmodellering.
/Peter Tallungs

Bok: Terry Halpin: Information Modeling and Relational Databases , 2001,
ISBN 1-55860-672-6

Recension: Terry Halpin försöker i denna bok övertyga oss om att modelleringsspråket Object Role Modelling är det bästa modelleringsspråket för konceptuell modellering. På den vägen tar han med oss på en drygt 700-sidig Grand Tour genom snart sagt varje modelleringsspråk. En guldgruva för den som verkligen vill tränga djupare i språk och syntax. Men knappast en första läsning för dig som bara vill bli bättre verksamhetsanalytiker.

Object Role Modelling är ett så kallt faktabaserat modelleringsspråk. Det mappar mera direkt mot språkliga utsagor än de vanliga modelleringsspråken som Entity Relationship Modelling och klassmodeller i UML. De senare förutsätter från början att vi kan avgöra vad som skall avbildas som en klass/entitet och vad som skall vara attribut.
/Peter Tallungs

4.3. Regelperspektivet

Verksamhetsregler är ett eftersatt kapitel inom verksamhetsanalys. Det beror kanske på att vi till skillnad mot information och processer har saknat en stabil teoretisk grund för området. Numera finns det en sådan grund genom de arbeten som Business Rulles Group och andra har gjort. Så nu finns inget som hindrar att vi tar fram praktiska arbetssätt för att hantera verksamhetens regler.

Bok: Dave Macomb: Semantics in Business Systems, 2004, ISBN 1-55860-917-2

Recension: Dave McComb målar upp huvuddragen i den ”semantiska revolutionen” som står för dörren, ja som man kan påstå redan är i full gång. Denna omvälvning handlar inte bara om verksamhetsregler, men de har ändå något av en huvudroll. Jag vill rekommendera denna snabblästa bok till alla som vill ha en orientering om semantik i terminologier, ontologier, informationsmodeller, metadata, verksamhetsregler, integration, web services och den semantiska webben.
/Peter Tallungs

Bok: Ronald G. Ross: Principles of the Business Rule Approach, 2003, ISBN 0-201-78893-4
Bok: Barbara von Halle: Business Rules Applied, 2001, ISBN 0-471-41293-7

Recension: Det här är två böcker från de två främsta företrädarna av Business Rules Group. Tillsammans lägger de en grund för regelperspektivet.
/Peter Tallungs

4.4. Processperspektivet

Processperspektivet har varit i förgrunden i många år nu inom verksamhetsanalys och verksamhetsutveckling, kanske på bekostnad av de övriga perspektiven. Icke desto mindre är det ett viktigt perspektiv som behövs för att trimma värdekedjor och minska spill.

Kurs: Astrakan: Verksamhetsutveckling med processer – processutveckling, 3 dagar

Recension: Astrakan lägger särskild vikt vid att en avbildad process opererar på en och samma verksamhetsobjekt. Därmed har man ett effektivt sätt att verkligen identifiera verksamhetens stabila processer. Annars blir det gärna ett antal aktiviteter som råkar göras i följd på grund av tillfälliga omständigheter. Därmed vill jag varmt rekommendera den här kursen.
/Peter Tallungs

4.5. Det funktionella perspektivet

Ett sätt att analysera och beskriva en verksamhet genom att dela ner den i komponenter som var och en har en specifik funktion. På det sättet koncentrerar sig man på vad verksamheten gör utan att ta särskild hänsyn till hur detta utförs eller värdeflöde. Det här är ett perspektiv som har fått stort intresse på senare tid, då man vill organisera både verksamhet och it för större flexibilitet än vad processperspektivet i sig självt medger. Många ramverk för verksamhetsarkitektur baseras på det funktionella perspektivet. Exempel:

Microsoft Services Business Architecture (tidigare känt som Motion) med sin Capability Mapping
IBM Component Business Modeling
Sogetis Dynamic Arcitecture

Inte minst SOA-ansatser från verksamhetshåll har lyft fram det funktionella perspektivet som centralt. Ett exempel är Steve Jones med sin Enterprise SOA Adoption Strategies.

5. Företagsövergripande programvaruarkitektur

En företags- eller verksamhetsarkitekt arbetar med den övergripande programvaruarkitekturen för en organisation eller en del av en organisation . Den kan ses som två delar. Den första handlar om de system där verksamheten opererar, de operativa tillämpningarna. Det är här affärshändelser, som ordrar, fakturor och betalningar registreras. Här läses och uppdateras enstaka databasposter åt gången. Den andra delen är de analytiska systemen, där verksamheten monitoreras och analyseras. Här sker inga uppdateringar men stora mängder tidsserier av data läses, aggregeras och analyseras.
Det finns förstås mellanformer, till exempel att man använt analytiska tekniker för operativt ändamål.

Det finns flera goda skäl för en arkitekt som är verksam inom operativa tillämpningar att ta en djupare titt över till andra sidan, Data Warehouse:

Analytiska tillämpningar blir allt viktigare och kan inte längre ses som en isolerad del av it-stödet.
Data Warehouse-arkitektur ger delvis andra designprinciper. Normalisering är inte längre naturgiven utan tvärtom ofta skadlig. En arkitekt som har sett den andra sidan får en större distans till sin egen värld och en bättre överblick (”För fisken finns inte vatten”).

5.1. Data Warehouse-arkitektur

Data Warehouse-arkitekturen skall vara en bas för organisationens analytiska tillämpningar, det vill säga de tillämpningar där användare behöver analysera större mängder data. Den vanligaste principen idag för en Data Warehouse-arkitektur är att man inte ställer krav på en gemensam normaliserad databas utan i stället låter organisationens olika data marts hållas samman genom att fakta i dem beskrivs av en generisk uppsättning konforma dimensioner. Man skulle kunna se en sådan arkitektur som motsvarigheten till en tjänstebaserad arkitektur för den operationella sidan. Det är samma mål man vill uppnå, en flexibel och utbyggbar arkitektur baserad på stabila komponenter. Det är Ralph Kimball som är upphovsmannen till den nya mera lättrörliga Data Warehouse-arkitekturen.

En arkitekt behöver tillägna sig kunskap om Data Warehouse-arkitektur av två orsaker. För det första blir analytiska tillämpningar allt viktigare för verksamheter. Att kunna

Bok: Ralph Kimball: The Data Warehouse Lifecycle Toolkit, 1998 ISBN 0-471-25547-5
Bok: Ralph Kimball: The Data Warehouse Toolkit, 2nd ed 2002 ISBN 0-471-20024-7

Recension: Ralph Kimballs båda böcker med förvillande lika namn överlappar varandra vilket gör att det räcker att läsa en av dem. I vilket fall som helst ger en bok av Kimball en utmärkt introduktion till Data Warehouse-världen.
/Peter Tallungs

Bok: Christopher Adamson, Michael Venerable: Data Warehouse Design Solutions, 1998 ISBN 0-471-25195-X

Recension: Det här är en bok som ger exempel på designmönster från olika typer av verksamheter. Genom att studera dessa bygger du snabbt upp en bred och djup förståelse för Data Warehouse-arkitektur
/Peter Tallungs

5.2. Tjänstebaserad arkitektur

Service-Oriented Architecture är det förhärskande arkitekturparadigmet idag för företagsövergripande programvaruarkitektur. Många vill se det inte bara som programvaruarkitektur utan även som verksamhetsarkitektur. Det vill säga att SOA inte bara säger hur du skall strukturera din it utan även hur du skall strukturera din verksamhet.

Bok: Thomas Erl: Service-Oriented Architecture, 2005, ISBN 0-13-185858-0
Bok: Thomas Erl: Principles of Service Design, 2008 ISBN 0-13-234482-3

Recension: Thomas Erls den ledande teoretikern om SOA skriver böcker som ger god ledning om hur man strukturerar sitt it-stöd som helhet och hur man designar sina tjänster. Däremot får man ingen ledning om det som detta bygger på, nämligen din verksamhetsarkitektur.
/Peter Tallungs

Bok: Nicolai M. Jousuttis: SOA in Practice, 2007, ISBN 0-596-52955-4

Recension: Nicolai Jousuttis har en välgörande fältmässig syn på SOA. Det han skriver grundar sig mer på faktisk erfarenhet från skarpa lägen än på teoretiskt resonerande. Ett välgörande komplement till Thomas Erl.
/Peter Tallungs

Bok: David A. Chappell: Enterprise Service Bus, ISBN 0-596-00675-6

Recension: Eftersom nyttan och faran med en Enterprise Service Bus är ett aktuellt ämne är det väl lika bra att gå till källan och se vad den ursprungliga tanken är. David Chappell har skrivit den enda bok om ESB.
/Peter Tallungs

6. Programvaruarkitektur och programvarudesign

6.1. Programvarudesign allmänt

Bok: Martin Fowler: UML Distilled, 3rd ed 2004, ISBN 0321193687

Recension: Martin Fowlers tunna bok var den första som skrevs om UML och är fortfarande den enda riktigt läsbara boken om ämnet. /Peter Tallungs

Bok: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design patterns, 1997, ISBN 0-201-63361-2

Recension: De fyra författarna, kända som ”Gang of Four” eller GoF var inte de som kom på idén med designmönster men det blev de som skrev den första boken i ämnet. Därmed blev boken och författarna mer eller mindre synonyma med idén. Idag har idéerna utvecklats och det finns en uppsjö böcker i ämnet men det är nog bra att börja med originalet. /Peter Tallungs

Bok: Martin Fowler: Refactoring, 1999, ISBN 0-201-485672

Recension: Första gången någon nämnde Refactoring var i Martin Fowlers UML Distilled från 1997.
1999 var det dags för en hel bok i ämnet. Refactoring är en nyckelteknik i den nya synen på systemutveckling, det som gör programvaran tålig och formbar i stället för hård och spröd.
Därför är det tråkigt att tekniken har blivit missförstådd som att den innebär att man måste sätta av tid till att städa i koden. Det är ungefär motsatsen till det som Fowler menade. Läs därför boken. När du har läst den, läs den igen!
/Peter Tallungs

Bok: Eric Evans: Domain-Driven Design, 2004, ISBN 0-321-12521-5

Recension: Det här är den viktigaste bok som har skrivits om systemutveckling under de senaste åren. Den beskriver arbetet med design av programkod, närmare bestämt den del av programkoden som utgör domänmodellen. Det vill säga att den avbildar verksamheten och därmed utgör det gemensamma språket mellan alla intressenter i projektet. Se även recension av samma bok under Verksamhetsanalys och verksamhetsutveckling.
/Peter Tallungs

Bok: Martin Fowler: Analysis Patterns, 1997, ISBN 0-201-89542-0

6.2. Databasdesign

Bok: Graeme Simsion, Graham Witt: Data Modeling Essentials, 2005, 3rd ed,
ISBN 0-12-644551-6

Recension: Det här är kanske den enda riktigt bra boken om informationsmodellering och databasdesign som man kan sätta i händerna på en nybörjare. Den passar även den som har kommit längre. /Peter Tallungs

6.3. Interaktionsdesign och användbarhet

Bok: Ingrid Ottersten, Johan Berndtsson: Användbarhet i praktiken, 2002,
ISBN 91-44-04122-5

Recension: Användbarhet handlar inte bara om att bygga applikationen rätt utan även om att bygga rätt applikation. Därmed är användbarhet och användbarhetsarbete en central uppgift för en arkitekt. Det finns ingen bättre guide till det området än denna bok.
/Peter Tallungs

7. Löpande hantering av verksamhet och IT

7.1. Hantering av informationsresursen

Många organisationer har en informationsresurs som håller låg kvalitet, är dåligt känd, är inte tillgänglig eller inte beskriven. Det är arkitektens ansvar att se till att informationsresursen säkras och utvecklas på bästa sätt. Det handlar om att få till roller, ägarskap och ansvar samt arbetssätt för att organisationen skall kunna ta kontroll över sin information.

Bok: Michael H. Bracket: Data Resource Quality, 2000, ISBN 0-201-71306-3

Recension: Det här är en tråkig bok. Michael Bracket listar en eländeskatalog; alla sätt som en organisation kan misshandla sin informationsresurs. Den är träaktigt skriven, mer en uppräkning än en berättande text. Ändå är det den boken som fick mig att böja se på verksamhetsarkitektur som ett område jag skulle vilja ägna mig åt på allvar. Så det måste väl vara en bra bok ändå?
/Peter Tallungs

9. Allmän design- och arkitekturteori

För den arkitekt som är intresserad av en djupare förståelse för design- och arkitekturarbete, och vill gå till källorna inom området. Det här är välkända och inflytelserika böcker om tänkande om design och arkitektur av allt från städer, bostadsområden, byggnader till vardagsföremål. De har inspirerat programvaruarkitekter och därmed påverkat vårt område, och fortsätter att göra så.

Bok: Christopher Alexander: The Timeless Way of Building, 1979, ISBN 0-19-50240-8
Bok: Christopher Alexander: A Pattern Language, 1977, ISBN 0-19-501919-9

Recension: Christopher Alexander har inspirerat många inom systemutvecklingsvärlden. Främst är han känd för Design Patterns, designmönster, en idé som upptäcktes av Kent Beck och togs över av honom och Ward Cunningham. Jag tror inte det finns någon annan person utanför it-världen som citeras lika ofta i arkitekturböcker. Det här är inspirerande böcker som verkligen får en att tänka djupare på vad arkitektur och design innebär.
/Peter Tallungs

Bok: Stewart Brand: How Buildings Learn, 1995, ISBN 0-670-83515-3

Recension: Steward Brand undersöker i den här boken hur byggnader fungerar över tiden, hur de anpassar sig till ändrad användning och nya behov, och formulerar lagar för detta.
Det intressanta är att tankarna kan mer eller mindre direkt överföras på it-system.
Därmed har vi fått intressanta och tankeväckande paralleller till vår disciplin. En mycket läsvärd bok.
/Peter Tallungs

Bok: Jane Jacobs: The Death and Life of Great American Cities, 1961, ISBN 0-679-74195-X

Recension: Du kanske undrar vad stadsplanering har med verksamhets- och it-arkitektur? Mer än man kan tro. En verksamhets- och it-arkitektur är ett byggt habitat på samma sätt som en stad. Många av de principer och tankar som brukar nämnas vid diskussioner om it- och verksamhetsarkitektur och arkitekturarbete har sitt ursprung från, eller är direkta paralleller till, tankar från stadsplanering. Jane Jacobs klassiker är en inspirerande bok för alla arkitekter.
/Peter Tallungs

Bok: Donald A Norman: The Design of Everyday Things, 1990, ISBN 0-262-64037-6

Recension: Det här är en designklassiker, som brukar läsas av systemvetare. Donald Norman får oss att se på vår omgivning med nya ögon. Vi blir varse om formgivningens betydelse.