IT-arkitektur

Get Started. It's Free
or sign up with your email address
Rocket clouds
IT-arkitektur by Mind Map: IT-arkitektur

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

12.3. SOA