3. Enterprise-Architektur-Management (EAM) · • Transaktionssysteme Enterprise-Architektur-Team Strategische IT-Transformationen EA-Team muss ca. 3000 IT-Systeme sichten & bewerten

Grundlagen des strategischen ManagementsWahlpflichtfach, Informatik Bachelor, WS 2015

Prof. Dr.-Ing. Stefan Bente

3. Enterprise-Architektur-Management

(EAM)

3.3. Transformation der IT-Landschaft

Inhalt

WPF GSITM | 3.3. EAM Transformation | Prof. Dr. BenteWS 2015Bild: aboutpixel.de / Fensterfront

© Rüdiger Wittmann2

Bild: By Shinealight. (Own work.) [Public domain],

via Wikimedia Commons

Bild: Wikimedia, by Editorialmaster (Own work) [CC-BY-SA-3.0

(http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia

Commons

Transformation der IT-Landschaft

Strategische IT-Transformationen

EAM-Kennzahlen

Überwachung der IT-Landschaft

Prinzipien, Patterns und Bad Smells

IT-Standards

Strategische

IT-Transformationen

WPF GSITM | 3.3. EAM Transformation | Prof. Dr. BenteWS 2015 3


Bebauungsplanung, Transformation, IT-Standard


Istzustand der

IT-Landschaft

Sollzustand der

IT-Landschaft

Sorgt für „gute“, geschäftskonforme IT-LandschaftEAM

IT-Bebauungsplanung

kartiert Spezifiziert (gibt vor)

IT-Transformation

IT-Standards

direkte Steuerung durch

Transformationsprojekte

indirekte Steuerung

durch Regeln

1

2

3


Pfad von Bebauungsplanung zu Ist-Soll-Transformation


Istzustand der

IT-Landschaft

Sollzustand der

IT-Landschaft


IT-Bebauungsplanung


IT-Transformation

IT-Standards



indirekte Steuerung

durch Regeln

1

2

3

„Aufräumen“ nach großer Akquisition

oder Unternehmenszusammenschluss

Kostensparprogramm für die IT =>

Konsolidierungsprogramm

Bessere Geschäftsunterstützung

o Beispielsweise durch Umbau in Richtung

einer Service-orientierten Architektur (SOA)

Radikale strategische Neuausrichtung

o Filialwarenhaus wandelt sich zum Onlineshop

o Energieunternehmen stellt sich auf

veränderte Markt- und

Regulationsbedingungen ein

Geändertes Sourcingmodell verlangt

nach anderen IT-Strukturen


Es gibt verschiedene Gründe für Transformation



3 typische Transformationsmuster nach Fusion


Neubau Rosinenpicken Dampfwalze

Bei Zeitdruck & klaren Machtverhältnissen: am besten Dampfwalze.

Kann sehr lange dauern,

wird oft politisch gestoppt

Gefahr einer funktionalen

Obermenge der Altsysteme

Risiko endloser politischer

Diskussionen

Integrationskosten fressen

Funktionalitätsgewinn auf

Sehr schmerzhaft

Vorteil: Geht schnell

Klare Verhältnisse

Quelle: Wolfgang Keller: IT-Unternehmensarchitektur, ein Überblick (2006), S. 43ff. http://www.objectarchitects.biz/ResourcesDontDelete/2006-12-15PublicIT-Unternehmensarchitektur.pdf,

abgerufen 23.10.2014

http://www.objectarchitects.biz/ResourcesDontDelete/2006-12-15PublicIT-Unternehmensarchitektur.pdf


Entwicklung IST => SOLL mit komplexen Vorgaben


Ist-Zustand

Soll-Zustand

Vision vom Ziel-

Zustand

IT-TransformationIT-Transformation

IT-Transformation

ProjektProjekt

Projekt

Projekte und

Maßnahmen

zur Umsetzung

des Ziel-Zustands

Vorstand


Bsp.: Bank4Us, europaweit tätige Bank, 50,000 Mitarb.


In die Top 3 der europäischen

Privatkundenbanken vorstoßen!

Kosten um 20% senken!

CEO CIO

Chef-

Architekt

Leiter

IT Nord

Leiter

IT West... Leiter

Programm-

Management

...


CIO übersetzt die Konzernstrategie in eine IT-Strategie


CIO Chef-

Architekt

„20/20“-Strategie:

• 20% Einsparung

• 20% mehr Kundenzufriedenheit

Chef-

Architekt

Leiter

IT Nord

Leiter

IT West... Leiter

Programm-

Management

...


Wie kann das 20%-Einsparungsziel erreicht werden?


Chef-

ArchitektCIO

3000 Applikationen!

... davon 1/3

Legacy ...

... und redundant:

40 BI Tools!

25 Middleware-

Plattformen ...

„20% Einsparung?

Chef-

Architekt

„20% mehr Kunden-

zufriedenheit?

Chef-

Architekt

Leiter

IT Nord

Leiter

IT West... Leiter

Programm-

Management

...


Wie erreicht man 20%-Plus bei Kundenzufriedenheit?


CIO

Multichannel!

Self-Service!

Mehr Service-

Orientierung!

Euer Auftrag:

IT-Rationalisierungsprogramm

mit 20% Kostenersparnis planen!

Strategische Entwicklungsrichtung:

• Multichannel-Plattform

• Kunden-Self-Service

Enterprise-Architektur-Team


Für das EA-Team bedeutet dies Planungsarbeit


Chef-

Architekt

• Trading-Systeme

• Transaktionssysteme

Enterprise-Architektur-Team


EA-Team muss ca. 3000 IT-Systeme sichten & bewerten


Chef-

Architekt

• Kredit-Engines

• Zinsberechnung

• Reporting

...



Umsetzung von IT-Transformationen in fünf Schritten


Ist-Zustand

Soll-Zustand

Vision vom Ziel-

Zustand

IT-Transformation

Projekte und

Maßnahmen

zur Umsetzung

des Ziel-Zustands

ProjektProjekt

Projekt

Bewertungskriterien und

-Raster aufstellen (z.B. Kosten)A

Identifikation von Kandidaten

für die Transformation B

Soll-Architektur für die

Transformations-BereicheC

Gap-Analyse IST / SOLLD

Umsetzung in konkrete

TransformationsprojekteE




Bewertung durch Kennzahlen aus mehreren Quellen


Architekturqualität

Integrationkomplexi-

tät (Fan-In / Fan-Out)

…

Architektur

Gesamt-

Bewertung

Total cost of

ownership (TCO)

Entwicklungskosten

Wartungskosten

Lizenzkosten

Hostingkosten

Entwicklungsaufwand

…

IT-KostenrechnungIT-Kostenrechnung

Geschäfts-Kritikalität

Anzahl und Laufzeit

der Prozessschritte

Automatisierungsgrad

Anzahl Medienbrüche

…

Business Alignment

Anzahl / Schwere der

Tickets

Service-Level (Silber,

Gold, ...)

…

IT Service Mgmt.

Unterstützung von

Zielen der IT-Strategie

Technologische

Strategiekonformität

Konformität von

Lizenz & Sourcing

…

Strategie

BewertungA

Es empfiehlt sich, ausgewählte (= wichtige) Kennzahlen zu zwei

Kernkennzahlen zu aggregieren

Sinnvoll:

o Strategiebeitrag

o Geschäftlicher Wertbeitrag

Jeweils qualitativ, z.B. Skala 1 – 10

Die Zusammensetzung ist situativ und unternehmensspezifisch

unterschiedlich!

Strategiebeitrag kann sich beispielsweise wie folgt zusammensetzen:

Konformität mit Technologieroadmap

Qualität der Informationsarchitektur

Unterstützung von Zielen der IT-Strategie

o z.B. Unterstützung für umfassende Multichannel-Strategie (aus IT-Strategie)


Kennzahlen werden zu Kernkennzahlen aggregiert


BewertungA

Der Strategiebeitrag ist eher zukunftsorientiert

Der (geschäftliche) Wertbeitrag hingegen bemisst den heutigen

Wert eines IT-Systems für das Unternehmen

(Geschäftlicher) Wertbeitrag kann sich wie folgt zusammensetzen:

Geschäftswert

o Zuordnung zu Kern-, Support- oder Steuerungsprozess

o Geschäftswert der unterstützten Prozesse

o Nutzerzufriedenheit

o Beitrag zum Geschäftsprozess, funktionaler Umfang

o Time-to-Market (wie schnell an neue Anforderungen anpassbar)

geschäftliche Risiken

o Auswirkung des Ausfalls

o Gesamtaufwand bei Ersetzung (z.B. Größe der Nutzerbasis)


Neben Strategiebeitrag ist auch Wertbeitrag relevant


BewertungA


Ermittlung der Kernkennzahlen per Balanced Scorecard


ID Beschreibung Wichtung

(%)

Punkte

(1-10)

SB1 Das IT-System passt zur Technologie-Roadmap 30% 4

SB2 Das System hat eine gute Architektur-Qualität 30% 6

SB3 Das IT-System unterstützt das strategische IT-Ziel

„Multi-Channel-Angebote erweitern“20% 2

SB4 Das IT-System unterstützt das strategische IT-Ziel

„Kunden-Self-Service-Angebote schaffen“20% 5

Gesamtpunktzahl 4,4

Strategie-

beitrag

ID Beschreibung Wichtung

(%)

Punkte

(1-10)

WB1 System hat hohe Nutzerzufriedenheit 20% 4

WB2 System hat breite Nutzerbasis 40% 9

WB3 Schnelle Time-to-Market, d.h. fachliche Anforderungen

werden schnell umgesetzt20% 2

WB4 Funktionaler Umfang (vollständige Abdeckung des

Geschäftsprozesses durch das IT-System)20% 7

Gesamtpunktzahl 6,2

Wert-

beitrag

BewertungA



Zweiter von 5 Schritten in IT-Transformation …


Ist-Zustand

Soll-Zustand

Vision vom Ziel-

Zustand

IT-Transformation

Projekte und

Maßnahmen

zur Umsetzung

des Ziel-Zustands

ProjektProjekt

Projekt



Identifikation von Kandidaten

für die Transformation B

Soll-Architektur für die

Transformations-BereicheC

Gap-Analyse IST / SOLLD

Umsetzung in konkrete

TransformationsprojekteE

Strategiebeitrag

Wie gut passt das IT-

System in IT-Strategie?

Wertbeitrag

Welchen Geschäftswert

stellt IT-System dar?

Es fehlen noch:

Kosten des IT-Systems

Transformationsaufwand


Ward-Peppard-Diagramm: Werkzeug zur Klassifizierung


Quelle: nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture. Morgan Kaufmann, Boston

Stars Wild Cats

Cash Cows Poor Dogsniedrig

hoch

hoch niedrig

Strategie-

Beitrag

Wertbeitrag

Unwichtig

Supportfunktion

Gute Rationalisie-

rungskandidaten

IT-Kernsysteme

Rückgrat der IT

Nicht zukunfts-

sicher

Strategisch

Unterstützen

Kernprozesse

Gute Technologie-

Passung

Potential

Können wichtig

werden

Neue Geschäfts-

felder

Ward-Peppard-Diagramm

KandidatenB


Fan-In / Fan-Out: Maß für Integrations-Komplexität


Quellen:

Henry, S. & Kafura, D. (1981). Software Structure Metrics Based on Information Flow. IEEE Transactions on Software Engineering, Vol. SE-7, No. 5, September 1981

Winter, R (2006). Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage der Informationssystem-Architekturplanung. In: Schelp, J., Winter, R. (Editors):

Integrationsmanagement – Planung, Bewertung und Steuerung von Applikationslandschaften. Springer, Berlin, 1-30.

Zitiert nach nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture. Morgan Kaufmann, Boston

IT-

System

JMS Event

DB-Tabelle

Service-

Aufruf

Bereitgestellter Service A

Bereitgestellter Service B

DB-Tabelle

Globales Geschäftsobjekt

via Remote EJB Call

Inputs3 Outputs 4

Der FI/FO ist ein Kriterium für den Transformationsaufwand

(= Anzahl der neu zu bauenden Schnittstellen)

Fan-In / Fan-Out = 7

Zu beachten:

Einheitliche

Zählkriterien

nötig!

Z.B. Function-

Point-Methode

KandidatenB


EXKURS: Ist ein hoher oder ein niedriger FI/FO besser?


Quelle: Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture. Morgan Kaufmann, Boston

Ein mittlerer FI/FO-Wert ist für die Gesamt-IT-Landschaft optimal

CostsFI/FO durchgehend niedrig:

IT-Systeme sind groß

Bad Smell:

o wenig Modularität

o „Wartungshölle“

FI/FO durchgehend niedrig:

IT-Systeme sind feingranular

Viele Interfaces

Bad Smell:

o Hohe Interfacekosten

o „Integrationshölle“

KandidatenB


Ward-Peppard: Strategie-/Wertbeitrag, Kosten und FI/FO


Quelle: nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture. Morgan Kaufmann, Boston

Stars Wild Cats


hoch

hoch niedrig

Strategie-

Beitrag

Wertbeitrag


A

CB

D

E

GF

Strategiebeitrag

Wie gut passt das IT-

System in IT-Strategie?

Wertbeitrag

Welchen Geschäftswert

stellt IT-System dar?

Kosten des IT-Systems(TCO)

Transformationsaufwand(Fan-In / Fan-Out)

X X X

niedrig hoch

X X X

niedrig hoch

KandidatenB


Ward-Peppard: Strategie-/Wertbeitrag, Kosten und FI/FO


Stars Wild Cats


hoch

hoch niedrig

Strat.

Beitrag

Wertbeitrag


Order PickupTrans-

portDeli-very

GB 1 E C

GB 2 B

GB 3 G A D

GB 4

E

C

GB 5 A D

GB 6 C

+Bebauungsplanung, z.B. Prozessunterstützungskarte

Welche Ersetzungen sind Kandidaten für weitere Analyse?

A

CB

D

E

GF

KandidatenB

EAM-Kennzahlen


EAM-Kennzahlen

Die Auswahl möglicher EAM-Kennzahlen ist vielfältig


Quelle: Bock, S. (2015): Konzeption eines Kennzahlensystems für das

Architekturmanagement zur Bewertung der IT-Anwendungslandschaft

am Beispiel eines Versicherungskonzerns. Bachelorarbeit, FH Köln, im

Nachfolgenden mit [Bock] referenziert. S. 58.

EAM-Kennzahlen

Sechs Schritte zum EAM-Kennzahlensystem [Stutz]


I.1

Bewertungs-

grundlagen klären

I.2

Strategische Voraus-

setzungen prüfen

I.3

Ziele

operationalisieren

I.4

Kennzahlen

identifizieren

I.5

Kennzahlensystem

definieren

I.6

Kontinuierlichen

Einsatz sicherstellen

Quelle: Stutz, Matthias: Kennzahlen für

Unternehmensarchitekturen: Entwicklung einer Methode zum

Aufbau eines Kennzahlensystems für die wertorientierte

Steuerung der Veränderung von Unternehmensarchitekturen.

Kovac, Wiesbaden, 1. Auflage, 2009. ISBN 978-3-8300-4345-4.

Im Folgenden als [Stutz] referenziert. S. 133.

Auf der nachfolgenden Folie ist die Grafik noch einmal größer und

besser lesbar abgebildet.

EAM-Kennzahlen

Beispiel für Kennzahl "Zuverlässigkeit eines IT-Systems"


Quelle: [Bock], S. 72

Der EAM KPI Catalog fasst die

gebrächlichsten EAM-

Kennzahlen zusammen

o Empirischer Ansatz

o Keine "Empfehlungen"

KPI-Kennzahlen

Strategische Projekte

Prinzipien und Standards

Capabilities

Organisation und Prozesse

Business-IT-Alignment

Infrastruktur

EAM-Kennzahlen

Gebräuchliche EAM-Kennzahlen: EAM KPI Catalog


Bild / Quelle: Matthes, Florian, Ivan Monahov, Alexander Schneider, and Christopher

Schulz. “EAM KPI Catalog v1.0.” Accessed September 28, 2015.

https://wwwmatthes.in.tum.de/file/3zh2nzhd4qws/sebis-Public-

Website/Research/Enterprise-Architecture-Management/EAM-KPI-

Catalog/EAM%20KPI%20Catalog%20v%201.0.pdf. Abgerufen 22.09.2015.

Im weiteren referenziert als [sebis2].

Übersetzung durch den Vortragenden

KPI-Kennzahlen

o EAM-KPI-0020: IT-Prozesse unter KPI-Überwachung

Strategische Projekte

o EAM-KPI-0004: Kosten unvollständiger Change-Spezifikationen

o EAM-KPI-0016: Projektkonformität zu Zielarchitektur

o EAM-KPI-0017 / 18: Eingetretene Risiken

(vorab identifiziert / nicht identifiziert)

o EAM-KPI-0036: IT-Investitionen, die den geplanten Nutzen realisieren

Prinzipien und Standards

o EAM-KPI-0033: Standardkonformität fachlicher Applikationen

o EAM-KPI-0043: Architekturkonformität fachlicher Applikationen

EAM-Kennzahlen

Ausgewählte EAM-Kennzahlen (1)


Capabilities

o EAM-KPI-0030: Erfüllungsgrad Zielarchitektur der fachlichen Domäne

(business domain)

Organisation und Prozesse

o EAM-KPI-0024: Anzahl Mitarbeiter in strategischen Fokusbereichen

Business-IT-Alignment

o EAM-KPI-0046: IT-Continuity-Pläne für geschäftskrititsche Anwendungen

Infrastruktur

o EAM-KPI-0007: Eingehaltene SLAs

o EAM-KPI-0047: Dauer von unerwarteten Serviceunterbrechungen

EAM-Kennzahlen

Ausgewählte EAM-Kennzahlen (2)





Standards sind das "indirekte" Mittel der IT-Veränderung


Istzustand der

IT-Landschaft

Sollzustand der

IT-Landschaft


IT-Bebauungsplanung


IT-Transformation

IT-Standards



indirekte Steuerung

durch Regeln

1

2

3


Hat dieses Haus eine gute Architektur?


Bild:(c) Wikimedia, Mayqel

Ja, wenn:

… Dinge hängend

gelagert werden

müssen (z.B.

Feuerwehr-

schläuche)

… die Eigentums-

verhältnisse beim

Grundstück keine

andere Lösung

zuließen

… Hochwasser-

gefahr besteht

Nein, wenn:

… alte Menschen

oder kleine Kinder

darin wohnen sollen

… variables

Innenraumdesign

mit leicht verschieb-

baren Innenwänden

benötigt wird

… viel Licht

gebraucht wird (z.B.

Atelier)

Überwachung der IT-Landschaft:

Prinzipien, Patterns und

Bad Smells


Globale Prinzipien Lösungsspezifische Prinzipien

Überwachung der IT-Landschaft: Prinzipien, Patterns und Bad Smells

Architektur-Prinzipien: „konzeptioneller IT-Standard“


Globales

PrinzipGlobales

PrinzipGlobales

Prinzip

Lösungs-

PrinzipLösungs-

Prinzip

Lösungs-

PrinzipLösungs-

Prinzip

IT-

Strategie

Allgemeine

„Good

Practices“

Axiomatische

Grundlage

Gültig für alle Systeme einer IT-

Landschaft

Ergeben sich aus „Good

Practices“ oder den speziellen

Anforderungen der IT-Strategie

Konkretisierung eines

globalen Prinzips

Gültig nur für bestimmte IT-

Systeme (je nach deren

Anforderungen)


Architektur-Prinzipien folgen dem SMART-Prinzip


Übersetzung Das bedeutet:

S Spezifisch Prinzipien sind präzise definiert, nicht vage

M MessbarFrage nach Prinziperfüllung (ja/nein) ist klar

entscheidbar

A Angemessen Zu Natur und Umfang des Systems

passend, nicht komplexitätstreibend

R Realistisch Prinzipien sind umsetzbar

T Termin-unabhängig

Prinzipien sind so formuliert, dass eine

Einhaltung vom ersten Tag der

Spezifikation sinnvoll ist (Unterschied

zwischen Prinzip und Feature)

(*) Helmut Balzert: Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und Betrieb. Spektrum Akademischer Verlag, Heidlberg, 3. Auflage 2012


Patterns, Anti-Patterns und Bad Smells


Bild: Wikimedia, Paisleymuster.

Fotograf/Zeichner: Makemake, 2005.

http://upload.wikimedia.org/wikipedia/c

ommons/f/f5/Paisleymuster.jpg

(Design) Pattern

Wiederverwendbares

Lösungsmuster

Geht zurück auf

Christopher Alexander, der

1977 das Konzept einer

„Pattern Language“ für

Bauten formulierte (*)

Kent Beck und andere

überführten das Konzept

Ende der 1980er Jahre in

die Software (**)

Weitgehend akzeptiertes

Konzept in der SW-

Architektur

Quellen:

(*) C. Alexander et al.: A Pattern Language: Towns, Buildings, Construction (1977). Oxford

University Press

(**) ^ Beck, Kent; Ward Cunningham (September 1987). "Using Pattern Languages for Object-

Oriented Program". OOPSLA '87 workshop on Specification and Design for Object-Oriented

Programming. OOPSLA '87.

Anti-Pattern

Häufig anzutreffender,

schlecht geeigneter

Ansatz zur Lösung

eines typischen

Problems

Oft Ergebnis fehlender

oder missverstandener

Architektur

Bad Smell

Symptom in Architektur

oder Code, das auf ein

tieferliegendes Problem

hindeutet

http://upload.wikimedia.org/wikipedia/commons/f/f5/Paisleymuster.jpg


Prinzipien, (Anti-)Patterns, Bad Smells wirken zusammen


Leucht-

feuer Ich sehe den grünen Sektor =>

mein Schiff ist auf Kurs

Ich sehe den roten Sektor =>

falscher Kurs!

Architekturprinzip

Pattern Anti-Pattern,

„bad smell“

Prinzipien sind wie Leuchtfeuer,

Patterns und Anti-Patterns wie dessen Sektoren.


Eine Grillparty mit Freunden, und

Sie müssen für alle einkaufen.

Lösung: Jeder bringt sein Essen selbst mit

Mehmet isst kein

Schweinefleisch

Hubbi ist Vegetarier

Bogdan isst nur Bio

Alina liebt Bratwurst

Sabine mag nur diese

kleinen marinierten Hühnchenfilets, die kriegt man beim

Rewe in der Großmannstraße, und wenn da

nicht, dann auf jeden Fall beim Metzger Köhnmann in der Eifelstraße, das

findest du ganz leicht, einfach am Neumarkt die erste links und dann Bild: skypix, CC by 2.0,

https://www.flickr.com/photos/10213898

@N04/2670950668/in/photostream/

Englisch: „Separation of Concerns“

Eine Komponente ist für genau eine klar abgrenzbare

Aufgabe zuständig.

Vorteile:

Komponente muss seltener gewartet werden

o Es gibt "nur einen Grund" für Veränderungen

Kosteneffizientes Design

o Logik wird nicht doppelt implementiert

Architektur ist leicht verständlich

o … damit auch besser gegen Wildwuchs (unsinnige Erweiterungen) gefeit


Prinzip: Trennung von Zuständigkeiten



Pattern: Mehrschichtenarchitektur


Applikationsschicht

Web-Schicht

Daten-

Schicht

Webserver Caching CDN Gateways

App Server Integierte Stacks Search Messaging

Relational Big Data Stacks Analytics Memcache

Was ist das Problem?

Änderungsgründe:

o Neues Feature: Platzwahl

o Feature: Reservierung

o Feature: erst reservieren, dann

kaufen

o Feature: Warenkorb

o Feature: weitere Zahlsysteme


Anti-Pattern: Gott-Komponente (Konzertbuchungs-Portal)


Besser:

Auf Anfrage sucht die Komponente

zu einem gegebenen Konzert die

freien Plätze. Dann bietet sie dem

Nutzer an, dafür per Kreditkarte

Konzertkarten zu erwerben.

Verwaltung von freien

/ reservierten

Konzertplätzen

Kauftransaktion

(Warenkorb, …)

Zahlungsabwicklung

Der Katalog aus Prinzipien, Lösungsprinzipien, Pattern und Anti-

Pattern muss für jede Organisation individuell erstellt werden

Nachfolgend eine Sammlung sinnvoller Prinzipien


Prinzipien- und Pattern-Katalog (beispielhafte Auswahl)


Globales Prinzip Lösungs-Prinzip(ien) Pattern (Auswahl) Anti-Pattern / Bad

Smell (Auswahl)

1 Prinzipien haben Vorrang

2 Wirtschaftlichkeit Architektur folgt

Organisation

3 Entscheidungen müssen

fachlich begründet sein

Moderne / unmoderne

Technologien

4 Sicherheitsaspekte • Protokollierung und

Audit Trail

• Autorisierungsprüfung

des aufrufenden

Systems

Dedizierte Schnittstellen

für „kritische“ Zugriffe

5 Trennung von Zuständigkeiten • Mehrschichten-

architektur

• Gott-Komponente


Prinzipien- und Pattern-Katalog (beispielhafte Auswahl)


Globales Prinzip Lösungs-Prinzip(ien) Pattern (Auswahl) Anti-Pattern / Bad

Smell (Auswahl)

6 Konsistente, redundanzfreie

Datenverwaltung

• fachliches

Datenmodell für

zentrale

Geschäftsobjekte

• Duplizierung durch

„Komplettabzug“ der

Daten

• Parallele Implemen-

tierung desselben

Geschäftsobjekts

7 Interoperabilität & lose

Kopplung von Komponenten

und IT-Systemen

• Schnittstellen haben

einen Service-Kontrakt

• Schnittstellen nutzen

globale Geschäftsobjekte

• Lose Kopplung • Big Ball of Mud

• Stovepipe-Architektur

8 IT-Systeme sind selbst-

organisiert

Kompensation

9 Einfachkeit • Design for Reusabilty

• viele Technologie-

Lösungen kombiniert

10 Sichtbarkeit Kapselung

11 Konzeptionelle Integrität Fachliche Abläufe ziehen

sich viele verschiedene

Technologien

12 Standardkonformität „not invented here“

Überwachung der IT-Landschaft:

IT-Standards


Überwachung der IT-Landschaft: IT-Standards

IT Standards = Prinzipien + Technologie-Vorgaben


Globale Prinzipien

Globales

PrinzipGlobales

PrinzipGlobales

Prinzip

IT-

Strategie

Allgemeine

„Good

Practices“

Axiomatische

Grundlage

Datenbank-

Standards

Middleware-

StandardsUI-Standards …

Konkrete Technologie-Vorgaben

Kosten

Risiken

Lösungsspezifische Prinzipien

Lösungs-

PrinzipLösungs-

Prinzip

Lösungs-

PrinzipLösungs-

Prinzip


Jeff Bezos‘ Vorgabe zu Service Interfaces bei Amazon


Bild: Wikimedia, James Duncan Davidson

from Portland, USA (Etech05: Jeff),

http://commons.wikimedia.org/wiki/File%3A

Jeff_Bezos_2005.jpg

Quelle: Steve Yegge, zitiert nach

https://plus.google.com/+RipRowan/posts/e

VeouesvaVX (abgerufen 12.03.2014).

Übersetzung durch den Vortragenden.

1) Alle Teams warden ab jetzt ihre

Daten in Form von Service Interfaces

zur Verfügung stellen. (…)

3) Es wird keine andere Form von

Inter-Prozess-Kommunikation erlaubt

sein.(…)

4) Es ist egal, welche Technologie sie

benutzen. (…) Bezos interessiert das

nicht.

5) Alle Service Interfaces (…) müssen

externalisierbar sein.(…) Keine

Ausnahmen.

6) Jeder, der sich daran nicht halt,

wird gefeuert.

Erfüllung strategischer Anforderungen

o Trägt zu Gelingen oder Scheitern einer IT-Strategie bei

o Funktional: betrifft elementare Geschäftsprozesse oder -objekte (ERP-System)

o Nicht-funktional:

Performanz oder Ausfallsicherheit

Mandantenfähigkeit, Konfigurierbarkeit

Integrierbarkeit, Schnittstellen

Kosten

o TCO trägt substantiell zu IT-Gesamtkosten bei

o z.B. bei großen Middleware-Plattformen, ERP-Systemen

Rechtliche Risiken

o z.B. Open Source – Beispiel Hibernate

Wirtschaftliche Risiken

o Insolvenz vs. Vendor Lock-In


Welche Technologien für unternehmensweite Standards?


Bild: aboutpixel.de / Obstkorb © Jörg Freitag

Nun mal einige Beispiele …


Welche Technologie-Entscheidungen geben Sie vor?


Vorgabe Projektentscheidung

Relationale

Datenbank

JEE

Application

Server

Continuous

Integration

Framework

CRM

System

UI

Framework

Entwick-

lungs-

Umgebung

Reporting-

System

Intranet-

PlattformSourcecode-

ManagementESB

Es gibt ein Werkzeug zur Positionierung von Technologien.

Eher „Vorgabe“:

• Relationale Datenbank

• JEE Application Server

• UI Framework

• Intranet-Plattform

• ESB


Welche Technologie-Entscheidungen geben Sie vor?


Eher Projektentscheidung:

• Sourcecode-Management

• Entwicklungs-Umgebung

• Reporting-System

• Continuous Integration

Framework

Hinweis: insbesondere Sourcecode-Management, UI-Framework und Reporting

sind Grenzfälle. Auch Entwicklungsumgebung und CI-Framework werden von

manchen Unternehmen vorgegeben. Es gibt also keine „absolute“ Lösung.


Technologie-Standards: Typische Adaptionszeitpunkte


Basierend auf: Rogers, E. (1962) Diffusion of innovations. Free

Press, London, NY, USA.

Bild: Tungsten [Public domain], via Wikimedia Commons,

http://commons.wikimedia.org/wiki/File%3ADiffusionofideas.PNG

Kern-Technologien: Nicht zu früh an Bord nehmen,

nicht zu lange behalten!

Zukunfts-Technologie

Kern-Technologie

http://commons.wikimedia.org/wiki/File:Diffusionofideas.PNG

Zusammenfassung

für den Bereich EAM

(Foliensatz 3.1 – 3.3)


Was ist Enterprise-Architektur-Management (EAM)?

o Definition EAM mit den Aspekten

Anpassung der IT-Landschaft an strategische und geschäftliche Bedürfnisse

Kartierung der IT-Landschaft

Planung der Transformation IST => SOLL

Sicherstellung nachhaltiger IT-Strukturen

o Verschiedene mögliche Bezugsrahmen von EAM

Gegenstand und Methoden der IT-Architektur

o Gegenstand von IT-Architektur im Allgemeinen

Bauplan für ein IT-System, angemessene Dokumentation

Technische Führung / Anleitung bei Umsetzung

Management von Komplexität, Änderbarkeit, Qualität

Iterativer Verlauf („endet nie“)

o Zwei Dimensionen der Architekturbetrachtung

Detaillierung: Komponente – IT-System – IT-Landschaft

Gegenstand: Fachlich – Informationssystem – Technologie

Zusammenfassung: 3. Enterprise-Architektur-Management (EAM)

Was sollten Sie aus diesem Themenblock mitnehmen?


Bebauungsplanung der IT-Landschaft

o Zusammenhang "EAM – Bebauungsplanung – IT-Transformation –

IT-Standards"

EAM = treibende Kraft der Transformation IST => SOLL

Bebauungsplanung = Kartierung IST, Spezifikation SOLL

IT-Transformation = aktives Umgestaltungsprojekt IST => SOLL

IT-Standards = Regelwerk zur „allmählichen“ Annäherung an SOLL

o Typische Karten:

Prozesslandkarte, Cluster-Diagramm, Applikations-Roadmap,

Abhängigkeitsgraph

Ziel: Beschreibung, Aufdecken Redundanzen/Widersprüche, …

Zusammenfassung: 3. Enterprise-Architektur-Management (EAM)



Planung von IT-Transformationen

o Gründe für IT-Transformation:

Herstellung Strategiekonformität

Kostensparen

Konsolidierung nach Übernahme/Fusion

funktionaler Ausbau

…

o Muster nach Übernahme/Fusion: Neubau, Rosinenpicken, Dampfwalze

o Vorgehen:

Auswahlkriterien festlegen

Transformations-Kandidaten bestimmen

SOLL-Architektur spezifizieren

Gap-Analyse IST / SOLL

Konkrete(s) Transformationsprojekt(e)

Werkzeuge: Balanced Scorecard, Ward-Peppard-Diagramm, Prozesslandkarte

Zusammenfassung



3. Enterprise-Architektur-Management (EAM) · • Transaktionssysteme Enterprise-Architektur-Team Strategische IT-Transformationen EA-Team muss ca. 3000 IT-Systeme sichten & bewerten

Documents