1. Målmiljömetoden
1.1. Dialog
1.2. Målbild
1.2.1. IT-infrastruktur
1.2.1.1. Domänexpter
1.2.1.2. Taxonomi
1.2.2. Veksamhet
1.3. Målmiljöritning
1.3.1. Scenario
1.3.2. Effektmål
1.3.3. Perspektiv
2. Viktigaste frågan är alltd "Varför?"
2.1. Andra frågor
2.1.1. Vad?
2.1.2. Hur?
2.1.3. När?
2.1.4. Vem?
2.1.5. Var?
2.2. Vilket är effektmålet?
2.2.1. SMART
2.2.1.1. Specific
2.2.1.2. Measurable
2.2.1.3. Attainable
2.2.1.4. Realistic
2.2.1.5. Timely
3. Verksamhet vs. IT-avdelningen
3.1. IT "suger"
3.1.1. Verksamheten
3.1.1.1. Tar för lång tid
3.1.1.2. Kostar för mycket
3.1.1.3. Opålitligt
3.1.1.4. Går långsamt
3.1.1.5. IT lägger sig i allt
3.1.1.6. Förstår inte vad vi vill ha
3.1.1.7. Begränsar möjligheter
3.1.2. It-avdelningen
3.1.2.1. Verksamheten köper utan att tänka
3.1.2.2. Talar inte om vad de vill ha
3.1.2.3. Har orimliga krav på IT
3.1.2.4. Har ingen strategi
3.1.2.5. Ser inte till helheten
3.1.2.6. Förstår inte IT
4. Trade-offs
4.1. Automatation vs. Kollaboration
4.1.1. Automatation
4.1.1.1. Snabb
4.1.1.2. Förutsägbar
4.1.1.3. Mätbar
4.1.1.4. Faror
4.1.1.4.1. För sin egen skull
4.1.1.4.2. Hantera alla fall
4.1.1.4.3. Ingen payback
4.1.2. Kollaboration
4.1.2.1. Innovativ
4.1.2.2. Flexibel
4.1.2.3. Adaptiv
4.1.2.4. Faror
4.1.2.4.1. Samarbetsverktyg utan sammanhang
4.2. Innovation vs. Standardisering
4.3. Risk vs. Vinst
4.4. Säkerhet vs. Frihet
4.4.1. Säkert + Öppet = Dyrt
4.4.1.1. SOA
5. Arkitekturprinciper
5.1. Egenskaper
5.1.1. Möjligöra måluppfyllelse
5.1.2. Tidslösa
5.1.3. Flexibla
5.1.4. Konsistenta
5.1.5. Vägleda
5.1.6. Enkla och eleganta
6. Tjänsteorienterad arkitektur
6.1. Web Service API
6.2. Enterprise Service BUS
6.2.1. SOA
6.2.1.1. Web Services
6.2.2. Nackdelar
6.2.2.1. Sammanlänkar projekt
6.2.2.2. Kostnaden
6.2.2.3. Single Point of Failure
6.2.2.4. Minskad betydelse om alla har Web Service API
6.2.2.5. Kan ersättas av ETL
6.3. SOA
7. Nulägeskarta (Blueprint)
7.1. Inte arkitektens jobb att underhålla
7.2. Använd systemdokumentation
7.2.1. Ingen redundans
7.2.2. Sparar tid
7.2.3. Personalen ser sammanhanget
7.2.4. Använd arkitektverktyg i dokumentationsprocessen
7.3. Varför?
7.3.1. Se konsekvenser av förändringar
7.3.2. Kunskapsöverlämning
7.3.2.1. System byts ut för att ingen förstår dem
7.3.3. Genomlysning av olika perspektiv
7.3.4. Undvika dubbelarbete i projekt
7.3.4.1. Slippa utreda samma fråga om och om igen
7.3.5. Referens (support, drift och utbildning)
7.3.6. Underlag för IT och verksamhetsstrategi
8. Verktyg
8.1. Metod
8.1.1. Inhämta information
8.1.1.1. Modellera
8.1.1.1.1. Visualisera
8.2. TOGAF
9. Vanliga misstag
9.1. Fokusera bara på en domän (t.ex IT-arkitektur)
9.2. För komplext beskriven. Kort och enkel.
9.3. Arbetet med arkitektur pågår i ett stuprör
9.4. Styrning och efterlevnad är inte genomtänkt
9.5. Man tror på en lösning för allt
9.6. Jargong
10. Öppenhet
10.1. Förståelse
10.2. Tillit
11. Inducerade problem
11.1. Säkerhet
11.1.1. Samverkande system ger nya säkerhetsproblem
11.2. Distraherar personal
11.2.1. Tar tid från andra viktiga arbetsuppgifter
11.3. Arkitektur definerad men ingen bryr sig
11.3.1. Styrningen är svårare att införa än arkitekturen
11.4. Kostnaden för lösningen ökar
11.4.1. Väljer "enterprise-lösning" för enkla problem som inte kräver det
11.5. Lösningen sämre för slutanvändaren
11.5.1. Gemensamma lösningar blir ofta sämre på att lösa verksamhetsspecifika behov
11.6. Gemensamma lösningar för in beroenden mellan verksamheter
11.6.1. Krav på förändringar kan komma i konflikt
11.6.2. Tiden för en förändring passar inte alla
11.6.3. Krav på förändringar från olika verksamheter måste prioriteras mot varandra
11.7. Projekt försenas
11.7.1. Uppfyllnad av arkitekturkrav måste valideras