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. Nulägeskarta (Blueprint)
3.1. Inte arkitektens jobb att underhålla
3.2. Använd systemdokumentation
3.2.1. Ingen redundans
3.2.2. Sparar tid
3.2.3. Personalen ser sammanhanget
3.2.4. Använd arkitektverktyg i dokumentationsprocessen
3.3. Varför?
3.3.1. Se konsekvenser av förändringar
3.3.2. Kunskapsöverlämning
3.3.2.1. System byts ut för att ingen förstår dem
3.3.3. Genomlysning av olika perspektiv
3.3.4. Undvika dubbelarbete i projekt
3.3.4.1. Slippa utreda samma fråga om och om igen
3.3.5. Referens (support, drift och utbildning)
3.3.6. Underlag för IT och verksamhetsstrategi
4. Verktyg
4.1. Metod
4.1.1. Inhämta information
4.1.1.1. Modellera
4.1.1.1.1. Visualisera
4.2. TOGAF
5. Vanliga misstag
5.1. Fokusera bara på en domän (t.ex IT-arkitektur)
5.2. För komplext beskriven. Kort och enkel.
5.3. Arbetet med arkitektur pågår i ett stuprör
5.4. Styrning och efterlevnad är inte genomtänkt
5.5. Man tror på en lösning för allt
5.6. Jargong
6. Öppenhet
6.1. Förståelse
6.2. Tillit
7. Inducerade problem
7.1. Säkerhet
7.1.1. Samverkande system ger nya säkerhetsproblem
7.2. Distraherar personal
7.2.1. Tar tid från andra viktiga arbetsuppgifter
7.3. Arkitektur definerad men ingen bryr sig
7.3.1. Styrningen är svårare att införa än arkitekturen
7.4. Kostnaden för lösningen ökar
7.4.1. Väljer "enterprise-lösning" för enkla problem som inte kräver det
7.5. Lösningen sämre för slutanvändaren
7.5.1. Gemensamma lösningar blir ofta sämre på att lösa verksamhetsspecifika behov
7.6. Gemensamma lösningar för in beroenden mellan verksamheter
7.6.1. Krav på förändringar kan komma i konflikt
7.6.2. Tiden för en förändring passar inte alla
7.6.3. Krav på förändringar från olika verksamheter måste prioriteras mot varandra
7.7. Projekt försenas
7.7.1. Uppfyllnad av arkitekturkrav måste valideras
8. Verksamhet vs. IT-avdelningen
8.1. IT "suger"
8.1.1. Verksamheten
8.1.1.1. Tar för lång tid
8.1.1.2. Kostar för mycket
8.1.1.3. Opålitligt
8.1.1.4. Går långsamt
8.1.1.5. IT lägger sig i allt
8.1.1.6. Förstår inte vad vi vill ha
8.1.1.7. Begränsar möjligheter
8.1.2. It-avdelningen
8.1.2.1. Verksamheten köper utan att tänka
8.1.2.2. Talar inte om vad de vill ha
8.1.2.3. Har orimliga krav på IT
8.1.2.4. Har ingen strategi
8.1.2.5. Ser inte till helheten
8.1.2.6. Förstår inte IT
9. Integrationsdiagram
10. Trade-offs
10.1. Automatation vs. Kollaboration
10.1.1. Automatation
10.1.1.1. Snabb
10.1.1.2. Förutsägbar
10.1.1.3. Mätbar
10.1.1.4. Faror
10.1.1.4.1. För sin egen skull
10.1.1.4.2. Hantera alla fall
10.1.1.4.3. Ingen payback
10.1.2. Kollaboration
10.1.2.1. Innovativ
10.1.2.2. Flexibel
10.1.2.3. Adaptiv
10.1.2.4. Faror
10.1.2.4.1. Samarbetsverktyg utan sammanhang
10.2. Innovation vs. Standardisering
10.3. Risk vs. Vinst
10.4. Säkerhet vs. Frihet
10.4.1. Säkert + Öppet = Dyrt
10.4.1.1. SOA
11. Arkitekturprinciper
11.1. Egenskaper
11.1.1. Möjligöra måluppfyllelse
11.1.2. Tidslösa
11.1.3. Flexibla
11.1.4. Konsistenta
11.1.5. Vägleda
11.1.6. Enkla och eleganta
12. Tjänsteorienterad arkitektur
12.1. Web Service API
12.2. Enterprise Service BUS
12.2.1. SOA
12.2.1.1. Web Services
12.2.2. Nackdelar
12.2.2.1. Sammanlänkar projekt
12.2.2.2. Kostnaden
12.2.2.3. Single Point of Failure
12.2.2.4. Minskad betydelse om alla har Web Service API
12.2.2.5. Kan ersättas av ETL