Sie sind auf Seite 1von 92

Enterprise-Architecture-

Management
IM_EAM, SS 2018, EAMgmt#SS18
Teil 7-2
Strategische IT-Planung

17.05.2018 IM_EAM, SS 2018, Teil 7-2 1


WIEDERHOLUNG TEIL 7-1

17.05.2018 IM_EAM, SS 2018, Teil 7-2 2


Was ist ein Geschäftsprozess?
17.05.2018 IM_EAM, SS 2018, Teil 7-2 3

Geschäftsprozesse bestehen aus einer Abfolge von zielgerichteten


Aktivitäten zur Umsetzung des Geschäftsmodells des Unternehmens.
Geschäftsprozesse leisten einen unmittelbaren Beitrag zur Wertschöpfung
oder unterstützen andere wertschöpfende Geschäftsprozesse.
Geschäftsprozesse haben einen definierten Anfang und ein definiertes Ende
mit einem klar festgelegten Ergebnis. In der Regel werden Geschäftsprozesse
mehrfach durchgeführt.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p493,
Bente, EAM Bebauungsplanung, 2015, p13
Begriff „Geschäftsprozess“
17.05.2018 IM_EAM, SS 2018, Teil 7-2 4

Für die Übersichtsbetrachtung in EAM genügt i.d.R. die Ebene 2

Quelle: Bente, EAM Bebauungsplanung, 2015, p16


Begriffsdefinitionen Business Capability
17.05.2018 IM_EAM, SS 2018, Teil 7-2 5

• Geschäftsfähigkeit (Capability) = wesentliche Fähigkeit des Unternehmens


• Startpunkt für die Betrachtung der Geschäftsarchitektur
Business Capability

A business capability defines the organization’s capacity to


Was successfully perform a unique business activity.
Capabilities:
Are the building blocks of the business,
represent stable business functions,
are unique and independent from each other,
are abstracted from the organizational model,
capture the business interests.
(Microsoft) (Forrest Research)

Wie

Geschäftsprozess
Wer Womit

Organisation IT Applikation
Business Capability vs. Prozess
17.05.2018 IM_EAM, SS 2018, Teil 7-2 6

Quelle: Bente, EAM Bebauungsplanung, 2015, p17


Business Capabilities im Zusammenhang
17.05.2018 IM_EAM, SS 2018, Teil 7-2 7

Quelle: Matthes EAM Foundations, sebis, 2016


Anwendungsportfolio und Anwendungsportfolio-
Management
17.05.2018 IM_EAM, SS 2018, Teil 7-2 8

• Ein Anwendungsportfolio ist die Menge aller in einem Unternehmen


vorhandenen „Software Assets“ (alias Anwendungen, alias Services)
• Asset Manager managen Ihre Portfolios so, dass der Gewinn (Return) zu
einem bestimmten, akzeptierten Risikoniveau maximiert wird

Quelle: Keller (2014)


Portfolio
17.05.2018 IM_EAM, SS 2018, Teil 7-2 9

Was ist ein Portfolio?


• In der Finanzwelt bezeichnet der Begriff Portfolio ein Bündel von
Investitionen, das im Besitz einer Institution oder eines Individuums ist.
• Dem Aufbau eines Portfolios geht in der Regel eine umfangreiche Analyse
voraus. Der Besitz eines Portfolios ist in der Regel Teil einer Strategie, die
Risiken finanzieller Investitionen durch Streuung zu senken.

Portfolio ist eine Menge von Besitztümern

Quelle: Keller (2014),


http://de.wikipedia.org/wiki/Portfolio
Anwendung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 10

Definition: Informationssystem (Synonyme: Applikation oder Anwendung)


• Ein Informationssystem ist eine logische Zusammenfassung von
Funktionalitäten, die der Anwender als technische oder fachliche Einheit
begreift. Es unterstützt im Allgemeinen zusammengehörige fachliche
Funktionen, die sich logisch und technisch abgrenzen lassen.

In den Zeiten von SOA, Microservices und von Multi-Channel-Applikationen fällt


es eher schwer den klassischen Applikationsbegriff zu verwenden. Dort wird man
also die Software nach „Services“ katalogisieren.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p495,
KELLER, Wolfgang, 2017. IT-Unternehmensarchitektur: von der Geschäftsstrategie zur optimalen IT-Unterstützung, p297
Beispiele Anwendungen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 11

• Anwendungen
– SAP BI (Operatives Controlling)
– ELSTER (Elektronische Steuererklärung)
– DATEV (Finanzverwaltung)
• Keine Anwendungen (keine Fachlichkeit)
– Datenbankmanagementsysteme (MS Access, Oracle etc.)
– Adobe Acrobat
– Betriebssysteme (Windows, Linux)
– Software zur Konvertierung von Dateiformaten
• Sonderfall
– MS Excel: Bietet selbst keinen fachlichen Mehrwert, kann aber durch Makros
als Plattform für Entwicklung und Betrieb für Anwendungen genutzt werden

Quelle: BOC Group | boc@boc-group.com


Bewertungskriterien für Anwendungen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 12

• Standardsoftware (ja/nein)
• Customising-Level
– Grad der Anpassung von Standardsoftware
• Strategische Bedeutung
– Anteil an der Zielerreichung der Organisation
– Unterstützung kritischer Geschäftsprozesse
– Wettbewerbsvorteile
• Geschäfts-Fitness
– (Subjektive) Qualität der Geschäftsprozessunterstützung
– Funktionaler Abdeckungsgrad
– Funktionale Überlappungen mit anderen Anwendungen
• Kosten-Fitness, d.h. Kosten im Vergleich zu Anwendungen vergleichbarer Fachlichkeit
– CAPEX: Capital Expenditure = Investitionskosten
– OPEX: Operational Expenditure = Pflege, Wartung (z.B. Total Cost of Ownership)
• IT-Fitness
– Verfügbarkeit, Wartbarkeit, Stabilität, Administrierbarkeit, Skalierbarkeit
– Insbesondere Homogenität und Standardisierungsgrad der verwendeten Technologien (SAGA-Konformität)
• Anzahl Nutzer
• Schutzbedarf der verwalteten Daten
– Verfügbarkeit, Vertraulichkeit, Integrität u.a.
• Integration mit anderen Anwendungen
– Enge oder lose Kopplung
– Einsatz von dedizierten Integrationstechnologien
Quelle: BOC Group | boc@boc-group.com
Verwendung der Landkarten für sog. Scorecards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 13

Definition „erwünschter“ Zustände, die man messen kann,


zum Beispiel
• Verfügbarkeit einer Anwendung
• Kosten / Transaktion
• diverse Metriken
– harte
– oder auch subjektiv eingeschätzte
und übertragen des Zustands auf eine
geeignet Darstellung des Portfolios

Quelle: Keller (2014)


Methoden der Portfolio-Analyse
17.05.2018 IM_EAM, SS 2018, Teil 7-2 14

• Beispiel für eine Marktwachstum-Marktanteil-Matrix. Die Fläche der Kreise


symbolisiert den Umsatz eines Geschäftsfelds. In einer solchen Matrix kann das
komplette Produktportfolio einer Firma eingetragen werden.
• Boston-Square-Produktportfoliomatrix übertragen auf ein Anwendungsportfolio

Quelle: KELLER, Wolfgang, 2017. IT-Unternehmensarchitektur: von der Geschäftsstrategie zur optimalen IT-Unterstützung, p97f
APM Zusammenfassung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 15

• APM ist ein permanenter Prozess. Man ist damit nie fertig!
• Man beschäftigt sich mit APM, um konkrete Fragen des Managements zu
beantworten und um Aktionen zu initiieren, mit denen man das
Anwendungs- und Serviceportfolio optimieren kann, zum Beispiel im
Bezug auf:
– Betriebskosten, Kundenzufriedenheit,
Strategic Fit, Zukunftssicherheit,
weitere ...
• Ein Anwendungshandbuch ist in jedem
Fall die Grundlage.
– Darauf aufbauend können Sie
Scorecards definieren
– und Portfolioanalysen durchführen.

Quelle: Keller (2014)


Anwendungsportfolio-Management
17.05.2018 IM_EAM, SS 2018, Teil 7-2 16

APM betrachtet die Anwendungen, die vorhanden sind ...

• APM hat keinen Begriff außer


„Anwendungen“ für das, was das
Geschäft in Zukunft zur optimalen
Unterstützung der Strategie benötigen
wird
• APM macht obsolete Anwendungen
nicht einfach sichtbar
• damit eher vergangenheits- als
zukunftsbezogen

Was nicht als Anwendung vorhanden ist, kann APM nicht betrachten!

Quelle: Keller, EAM - Capabilities (2014-05-22)


IT Bebauungsplanung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 17
Strategische Planung der IT-Landschaft
17.05.2018 IM_EAM, SS 2018, Teil 7-2 18

Ziel der strategischen Planung der IT-Landschaft ist es, die IT-Landschaft an
den Unternehmenszielen und geschäftlichen Erfordernissen auszurichten
und auf den ständigen Wandel des Unternehmens und des Marktumfelds
vorzubereiten.

Die strategische Planung der IT-Landschaft besteht im Wesentlichen aus der


Bebauungsplanung der IS-Landschaft und der technischen Standardisierung.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p338
IS-Bebauungsplanung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 19

Im Rahmen der IS-Bebauungsplanung werden ausgehend von den strategischen Vorgaben


und aktuellen Handlungsbedarfen („Pains“) die Soll-Landschaft und die IT-Roadmap zur
Umsetzung gesamthaft oder in Ausschnitten gestaltet.

Hierbei muss die Soll-Landschaft folgenden Bedingungen genügen:


• Ausrichtung am Geschäft
Die Soll-Landschaft muss die Unternehmensstrategie und die Geschäftsanforderungen
möglichst gut umsetzen.
• Beseitigung der „Pains“
Die bekannten Handlungsbedarfe und Optimierungspotenziale müssen beseitigt
beziehungsweise gehoben werden, um das Geschäft besser zu unterstützen.
• Vorbereitung und Ausrichtung der IT
Die Soll-Landschaft muss gleichzeitig zukunftssicher und flexibel veränderbar sein sowie
einen zuverlässigen und kostengünstigen Geschäftsbetrieb ermöglichen. Hierfür müssen u. a.
durch Standardisierung, IT-Konsolidierung und Serviceorientierung die Voraussetzungen in
der IT geschaffen werden.

Die IS-Bebauungsplanung ist ein komplexer kreativer Gestaltungsprozess. Verschiedene


Planungsszenarien werden erstellt, analysiert und bewertet.
Auf dieser Basis wird eine Empfehlung für die Soll-Landschaft und auch für die IT-Roadmap
gegeben.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p339
Ergebnisse der IS-Bebauungsplanung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 20

Eine Soll-Bebauung und die Roadmap zur Umsetzung bilden Zielvorgaben, die im
Rahmen von Projekten und Wartungsmaßnahmen umgesetzt werden müssen. Da
nicht alle Projekte bebauungsplankonform sind, müssen die Zielvorgaben zumindest in
der Regel jährlich in der Strategieentwicklung sowie im Kontext von großen Projekten
an die bestehenden neuen Ziele und Rahmenbedingungen angepasst werden
(„Moving Target“).

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p342f
Schrittweise Umsetzung der Soll-IS-Bebauung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 21

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p344
Prozess der IS-Bebauungsplanung nach Hanschke im
Überblick
17.05.2018 IM_EAM, SS 2018, Teil 7-2 22

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p343
IT-Zielbild gestalten
17.05.2018 IM_EAM, SS 2018, Teil 7-2 23

Die Gestaltung der Soll-IS-Bebauung ist ein iterativer Prozess aus Analyse und Gestaltung der IS-
Bebauung und deren Beziehungen. Die Unternehmens und IT-Ziele, die Geschäftsanforderungen
und die „Pains“ werden entlang der Unternehmensarchitektur in IT-relevante Aspekte
heruntergebrochen, bis die Aspekte für die Bebauungsplanung greifbar sind. Beispiele für IT-
relevante Aspekte sind Handlungsbedarf bei der Geschäftsprozessunterstützung
eines Prozesses wie z. B.
Automatisierung des Ablaufs oder
aber Optimierungspotenzial beim
Stammdatenmanagement bei
Kundendaten wie z. B.
Inkonsistenzen in Adressdaten
bei Geschäftspartnern.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p345
Analysemuster - R: Redundanzen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 24

Die Analysemuster dieser Kategorie liefern Anhaltspunkte für Redundanzen auf


funktionaler, Geschäftsprozess, Produkt und/oder organisatorischer Ebene sowie in
Bezug auf Geschäftsobjekte und technische Standards.
Redundanzen führen häufig zu erhöhten Kosten aufgrund mehrfacher
Wartungsgebühren oder erhöhtem Betreuungs-, Pflege- und Konsolidierungsaufwand.
Aus Redundanzen können Inkonsistenzen mit einer ggf. großen Tragweite resultieren.
Ein solcher Handlungsbedarf muss möglichst frühzeitig erkannt und beseitigt werden.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p336
Analysemuster - I: Inkonsistenzen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 25

Inkonsistenz bezeichnet einen Zustand, in dem zwei Elemente, die beide als gültig
angesehen werden, nicht miteinander vereinbar sind. Inkonsistenzen führen in der
Regel zu einem hohen Konsolidierungsaufwand. Inkonsistente Daten können zu
wirtschaftlichen oder Imageschäden führen. Ein Beispiel hierfür sind z. B.
unterschiedliche Preisdaten im Auftragsabwicklungssystem und im System beim
Händler vor Ort. Handlungsbedarf aus Inkonsistenzen muss möglichst frühzeitig
erkannt werden.
Inkonsistenzen können sowohl auf funktionaler als auch auf Datenebene vorliegen.
Die Muster dieser Kategorie liefern Anhaltspunkte für mögliche Inkonsistenzen in
funktionalen Zuordnungen oder aber für Dateninkonsistenzen aufgrund von
Redundanzen, Zyklen oder unterschiedlicher Datenaktualität.

Inkonsistenzen in der Funktionszuordnung


Daten-Inkonsistenzen

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p336
Analysemuster - O: Organisatorischer
Handlungsbedarf
17.05.2018 IM_EAM, SS 2018, Teil 7-2 26

Fehlende oder inkonsistente fachliche Verantwortlichkeiten für fachliche Domänen,


Geschäftsobjekte, Geschäftsprozesse, Produkte, fachliche Funktionen sowie
Informationssysteme, technische Bausteine oder Betriebsinfrastrukturelemente
können zu unnötigen organisatorischen Schnittstellen, Doppelarbeit oder
inkonsistenten Daten führen.
Die Muster dieser Kategorie liefern Anhaltspunkte für Auffälligkeiten in der
organisatorischen Zuordnung sowie fehlende oder inkonsistente Verantwortlichkeiten.
Verantwortlichkeiten können hierbei sowohl die fachliche als auch die technische
Verantwortung oder aber z. B. die Betriebs oder Supportverantwortung umfassen.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p336
Analysemuster - F: Umsetzung von
Geschäftsanforderungen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 27

Durch Anwendung der Muster dieser Kategorie können mögliche Ansatzpunkte zur Optimierung der IT-
Unterstützung des aktuellen und des zukünftigen Geschäfts identifiziert werden.
• Fachliche Abdeckungsanalyse zur Aufdeckung einer unzureichenden Business-Unterstützung
• Ermittlung des Integrationsbedarfs zur Optimierung der IT-Unterstützung, z. B. durch die Analyse
im Hinblick auf manuelle Schnittstellen, einen unzureichenden Automatisierungsgrad von
Schnittstellen oder Integrationslücken
• Müllanalyse zur Ermittlung unnötiger Elemente, z. B. Informationssysteme, die gar nicht benötigt
werden; durch eine Bereinigung des „Mülls“ wird ein enormes Einsparpotenzial erzielt.
• Cluster-Analyse zur Identifikation von fachlich eng zusammengehörigen Funktionen,
Geschäftsprozessen, Geschäftsobjekten und Geschäftseinheiten sowie Informationssystemen,
Betriebsinfrastruktureinheiten und Projekten. Dies ist eine Form der Abhängigkeitsanalyse.
• Datenabhängigkeitsanalyse zur Ermittlung der Informationssysteme, von denen andere
Informationssysteme eine hohe Datenabhängigkeit haben
• Compliance-Analyse zur Ermittlung des Umsetzungsgrads von gesetzlichen und freiwilligen
Auflagen, wie z. B. Solvency II, Basel II oder Sarbanes-Oxley Act
• Kritikalitätsanalyse zur Ermittlung der geschäftskritischen Geschäftsprozesse, Produkte, fachlichen
Funktionen, Geschäftsobjekte, Informationssysteme, technischen Bausteine und
Betriebsinfrastruktureinheiten
• Business-Zustandsanalyse zur Identifikation einer unzureichenden IT-Unterstützung von
Geschäftsprozessen, fachlichen Funktionen, Geschäftsobjekten und Produkten
• Ermittlung von potenziellen Sicherheitslücken
• Wirtschaftlichkeitsanalyse zur Ermittlung von potenziellen Anhaltspunkten für fehlende
Wirtschaftlichkeit
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p336
Analysemuster - T: Technische Handlungsbedarfe und
Optimierungspotenziale
17.05.2018 IM_EAM, SS 2018, Teil 7-2 28

Durch Vereinfachung und Erhöhung des Grads der Standardisierung, Homogenisierung und
Flexibilität der IT-Landschaft kann die Qualität der IT-Landschaft nachhaltig gesteigert
werden. Durch die Identifikation von technischem Handlungsbedarf lassen sich
Anhaltspunkte für die Optimierung finden.

• Blueprint-Cluster-Analyse zur Ermittlung der eng zusammengehörenden technischen


Bausteine, sogenannter Blueprint-Elemente
• Ermittlung des technischen Zustands im Hinblick auf das Risikomanagement
• Ermittlung der Standardkonformität der IS-Landschaft sowie Heterogenitätsanalyse zur
Identifikation von Optimierungspotenzial im Hinblick auf die Standardisierung und
Homogenisierung
• Ermittlung des Integrationsgrads von Informationssystemen im Hinblick auf die
Vereinheitlichung und Vereinfachung der Integration
• Identifikation von Anhaltspunkten für Abhängigkeiten bei Informationssystemen,
technischen Bausteinen, Betriebsinfrastruktureinheiten und Projekten
• Ermittlung der technischen Integrationsfähigkeit und der Flexibilität von
Informationssystemen im Hinblick auf die Anpassung an veränderte
Geschäftsanforderungen
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p337
Gestaltungsmuster - L: Identifikation von isolierten
Gestaltungsbausteinen („Lösungsideen“)
17.05.2018 IM_EAM, SS 2018, Teil 7-2 29

Finden von Lösungsideen für die im Rahmen der Analyse identifizierten IT-
Ansatzpunkte für einen Ausschnitt oder die gesamte IS-Landschaft
• Beseitigung von fachlichen Redundanzen in der Business-Unterstützung
• Auffüllen von Abdeckungslücken in der Business-Unterstützung
• Zerlegung von Informationssystemen entsprechend fachlicher Kriterien
(Entflechtung)
• Zusammenfassung von „fachlich nahen“ oder stark abhängigen
Informationssystemen
• Homogenisierung von Schnittstellen
• Ablösestrategie für Informationssysteme oder IS-Cluster
• Stammdaten-Konsolidierung

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p342f
Gestaltungsmuster - BT: Business-Transformationen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 30

Veränderungen der gesamten oder großer Anteile der IS-Landschaft aufgrund


einer Business-Transformation wie z. B. einer Fusion
• Zusammenführung von verschiedenen IT-Landschaften im Rahmen einer
Business Transformation aufgrund von z.B. Fusionen oder
Firmenübernahmen
• Aufspaltung einer IT-Landschaft z.B. bei einer gravierenden
Umstrukturierung aufgrund einer globalen Ausrichtung, der Verringerung
der Wertschöpfungsebene oder der Verlagerung von
Produktionsstandorten

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p342f
Gestaltungsmuster - K: Kosteneinsparung durch die
IT-Konsolidierung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 31

Kosteneinsparung durch Konsolidierung der technischen Basis von


Informationssystemen sowie der Betriebsinfrastruktur
• Konsolidierung der Betriebsinfrastruktur (u.a. Rechenzentren, Hardware
und Netze) durch z.B. das Zusammenlegen von verschiedenen
Informationssystemen auf die gleichen Betriebsinfrastruktureinheiten
oder aber durch die Zusammenlegung von Betriebsstandorten
• Harmonisierung der technischen Basis von Informationssystemen wie z.B.
Datenbanken oder die ERP-Basis

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p342f
IT-Umsetzung planen - Gestaltung der Roadmap
17.05.2018 IM_EAM, SS 2018, Teil 7-2 32

Die Soll-IS-Bebauung unterscheidet sich oft erheblich von der aktuellen Bebauung. Die
Lücke ist im Allgemeinen so groß, dass sie nicht in einem Schritt zu schließen ist.
Deshalb müssen im Rahmen der Gestaltung der Roadmap machbare und
überschaubare Umsetzungsschritte identifiziert werden.
Die Gestaltung der Roadmap erfolgt
auch in einem iterativen Prozess aus
Analyse und Gestaltung. Erster
Analyseschritt ist der Abgleich
zwischen der aktuellen und der
empfohlenen oder bereits
verabschiedeten SollISBebauung.
So werden die Deltas ersichtlich.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p347f
Erweiterte Analyse
17.05.2018 IM_EAM, SS 2018, Teil 7-2 33

Für die Analyse der Maßnahmen und Planungsszenarien können erneut die Standard-Analysemuster „R“, „I“,
„O“, „F“ und „T“ zur Aufdeckung von Handlungsbedarf und Optimierungspotenzial sowie Abhängigkeiten und
Auswirkungen herangezogen werden.

Die Bewertung erfolgt in der Regel zumindest bezüglich folgender Aspekte:


• Strategisches Alignment
Welchen Strategiebeitrag haben die Lösungsideen und Planungsszenarien (Strategiekonformität,
Strategiefit)?
Wie standardkonform sind die Lösungsideen und Planungsszenarien?
• Business Alignment
Welchen Wertbeitrag haben die Lösungsideen und Planungsszenarien?
Wie groß ist der Abdeckungsgrad der Geschäftsanforderungen?
• Kosten- und Nutzenanalyse
Welche Gesamtkosten stehen welchem Nutzen gegenüber?
Wo sind Kosten verborgen? Welche Altlasten sind aufzuräumen? Sind Umgehungslösungen, Umarbeiten
oder Ersatzleistungen notwendig?
• Technischer Zustand
Ist ein zuverlässiger und sicherer Geschäftsbetrieb sichergestellt?
Wie sieht der technische Gesundheitszustand aus?
• Risiken
Welche Risiken bestehen aktuell und welche Risiken bestehen bei der Umsetzung der Lösungsidee oder
dem Planungsszenario?
• Abhängigkeiten und Auswirkungen
Sind Lösungsideen oder Planungsszenarien miteinander kompatibel?

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p349
Gestaltungsmuster - M: Identifikation von Deltas,
Handlungsschwerpunkten und Maßnahmen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 34

Durch den Abgleich der aktuellen und der Soll-Bebauung sowie der
verschiedenen Planungsstände werden die Deltas ersichtlich sowie
Handlungsschwerpunkte und Maßnahmen ableitbar
• Abgleich zwischen verschiedenen Zuständen der Bebauung
• Delta-Analyse zur Identifikation von Handlungsschwerpunkten
• Identifikation von Maßnahmen und Analyse, Bewertung und ggf.
Bündelung der Maßnahmen

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p349
Gestaltungsmuster - E: Einführungsstrategie bei der
Ablösung von Kernsystemen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 35

In dieser Kategorie finden Sie Muster für die Ableitung der Plan-IS-Bebauung bei der Einführungsstrategie „Big
Bang“ und „Evolution“.

• „Big Bang“-Einführungsstrategie
Bei der „Big Bang“-Einführungsstrategie werden neue Soll-Informationssysteme in einem Schritt im
Allgemeinen einhergehend mit der Ablösung von Kernsystemen eingeführt. Das heißt, es findet eine
umfangreiche Erneuerung ohne Zwischenschritte statt.
Bewertung: Der „Big Bang“-Ansatz weist zwar eine hohe Komplexität und insofern ein hohes Risiko auf.
Eine gesamthafte Veränderung ist jedoch so am schnellsten möglich. Die Projektdauer ist aber häufig sehr
groß, was die Wahrscheinlichkeit von veränderten Rahmenbedingungen oder Geschäftsanforderungen
während der Projektlaufzeit erhöht. Der Erfolg einer „Big Bang“Einführung hängt vom Verstehen und
Managen der inhaltlichen Komplexität der Vorhaben sowie der Belastbarkeit der Organisation ab.

• „Evolutionäre“ Einführungsstrategie
Bei der schrittweisen Ablösung eines Kernsystems bzw. Einführung von Soll-Systemen werden das
Kernsystem und die Soll-Systeme entsprechend der vorgegebenen Soll-IS-Bebauung in funktionale Blöcke
zerlegt. Die Herauslösung bzw. Entwicklung der funktionalen Blöcke wird auf verschiedene machbare und
überschaubare Umsetzungsstufen verteilt.
Bei den ersten Stufen konzentriert man sich häufig auf großen Handlungsbedarf oder aber Bereiche mit
einem großen Wertbeitrag (Kriterien Dringlichkeit und Wichtigkeit).
Bewertung: Aufgrund der schrittweisen Umsetzung von handhabbaren Teilen sind die Umsetzungsdauer
und die Umsetzungsrisiken für jeden Schritt überschaubar. Geänderte Rahmenbedingungen können
spätestens im nächsten Umsetzungsschritt berücksichtigt werden. Die einzelnen Umsetzungsschritte
sollten nicht länger als ein Jahr dauern. Hierbei können jedoch sehr aufwendige Übergangslösungen
notwendig werden. Dies muss in der Gesamtbewertung berücksichtigt werden.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p350
Leitfaden für die IS-Bebauungsplanung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 36

Die IS-Bebauungsplanung ist eine komplexe Gestaltungsaktivität. Der


Leitfaden zeigt, wie dieser Prozess systematisch und nachvollziehbar
durchgeführt werden kann.

Die Schritte IV bis VIII werden iterativ durchgeführt, bis die Soll-IS-Bebauung
und die Roadmap zur Umsetzung so gestaltet sind, dass sie einem
Entscheidergremium vorgelegt werden können.

Gegebenenfalls können auch alternative Planungsszenarien mit einer


Empfehlung vorgelegt werden.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p352
Schritt-für-Schritt-Anleitung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 37

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p352
Beispiel zu IT-relevanten Aspekten
17.05.2018 IM_EAM, SS 2018, Teil 7-2 38

Nehmen wir an, wir verfolgen das Unternehmensziel, die Entwicklungszeiten


für ein neues Produkt zu reduzieren.
Ein Weg dafür kann sein, entlang der fachlichen Bebauung die verschiedenen
Geschäftsprozesse zu betrachten, die im Kontext der Produktentwicklung
stehen, um dort nach IT-relevanten Aspekten zu suchen. Betroffen können z.
B. die Geschäftsprozesse Produktentwicklung, Produkttest und Serienanlauf
sein.
Diese Geschäftsprozesse können dann weiter nach entwicklungszeiten-
relevanten Aspekten analysiert werden.
Hier könnten das Produktdatenmanagement, die Integration mit
Entwicklungspartnern oder aber die Integration mit den Produktionssystemen
Ansatzpunkte für die Reduktion der Entwicklungszeiten für ein neues Produkt
sein.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p354
Details Erstellen einer Roadmap
17.05.2018 IM_EAM, SS 2018, Teil 7-2 39

1. Ermitteln Sie die Deltas durch Abgleich zwischen der aktuellen Bebauung mit
den gegebenenfalls alternativen Planungsszenarien für die Soll-IS-Bebauung.
2. Ermitteln Sie aus den Deltas Handlungsschwerpunkte.
Die Zahl der Handlungsschwerpunkte sollte nicht größer als zehn sein.
3. Ermitteln Sie mögliche Maßnahmen zum Schließen der Lücken und
bestimmen Sie die Dringlichkeit der Maßnahmen durch den Abgleich mit
dem operativen Bedarf. Bestimmen Sie die inhaltlichen und zeitlichen
Abhängigkeiten zwischen den Maßnahmen.
4. Bündeln Sie die Maßnahmen oder deren Bestandteile zu
Maßnahmenbündeln und Planungsszenarien auf Basis der Ergebnisse der
Analyse und Bewertung der Maßnahmen.
Unter Berücksichtigung der Abhängigkeiten und der Bewertung der
Maßnahmen können alternative Maßnahmenbündel identifiziert werden: So
können z. B. Maßnahmenbündel entsprechend Dringlichkeit und Wichtigkeit
festgelegt werden.
5. Bewerten Sie die Maßnahmenbündel und Planungsszenarien.
Die resultierenden Maßnahmenbündel bzw. Planungsszenarien müssen einer
Bewertung und einer Abhängigkeitsanalyse unterzogen werden. So werden
einige Maßnahmenbündel bzw. Planungsszenarien frühzeitig aussortiert.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p354
Übung 7-5
17.05.2018 IM_EAM, SS 2018, Teil 7-2 40

Erstellen Sie eine IS-Bebauungsplanung für die THI mit der Vision 10000.
Die Roadmap soll mindestens eine Zwischenstufe aufweisen.
TEIL 7-2 - STRATEGISCHE IT-
PLANUNG

17.05.2018 IM_EAM, SS 2018, Teil 7-2 41


Strategische IT-Planung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 42

Was sind die zentralen Fragen?


• Welche Leistungsmerkmale soll die IT-Landschaft bereitstellen, um
Weiterentwicklung der Geschäftsfelder zu unterstützen?
• Welchen Anwendungen und Technologien stehen im Planungszeitraum im
Fokus und welche Bebauung ergibt sich daraus?
• Wie sollen Leistungsmerkmale unter Einsatz ausgewählter Technologien und
Beziehung von Leistungen innerhalb und außerhalb des Unternehmens
(Sourcing) erbracht werden?
• Welche IT-Prinzipen sollen in Bezug auf die IT-Landschaft beim Übergang IST
zum SOLL gelten?
• Welche Finanzplanung soll gelten (z.B. wie viel fließt in Projekte, Release und
Wartung)?
• Welche Investitionsstrategien sollen berücksichtig werden (z.B. Baseline für
Freeze/Sunset-Anwendungen)?
• Wie steht es mit dem Zustand der IT-Assets?

Quelle: Dern, Keller (2006-2010)


Strategische Planung der IT-Landschaft
17.05.2018 IM_EAM, SS 2018, Teil 7-2 43

Ziel der strategischen Planung der IT-Landschaft ist es, die IT-Landschaft an
den Unternehmenszielen und geschäftlichen Erfordernissen auszurichten
und auf den ständigen Wandel des Unternehmens und des Marktumfelds
vorzubereiten.

Die strategische Planung der IT-Landschaft besteht im Wesentlichen aus der


Bebauungsplanung der IS-Landschaft und der technischen Standardisierung.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p338
Inhalt
17.05.2018 IM_EAM, SS 2018, Teil 7-2 44

Teil 7-1
• Anwendungsportfolio-Management
• IT Bebauungsplanung
Teil 7-2
• IT Bebauungsplanung – weitere Ansätze
• Technologiemanagement
Weitere Ansätze
17.05.2018 IM_EAM, SS 2018, Teil 7-2 45
Strategische Bebauungsplanung nach Keller
17.05.2018 IM_EAM, SS 2018, Teil 7-2 46

Definition von Gernot Dern : Strategische IT-Planung


Systematische Aufstellung eines Maßnahmenplans und eines Regelwerks (Teil der IT-Governance) zur
Weiterentwicklung der IT-Landschaft auf Grundlage einer aus der Geschäftsplanung abgeleiteten Zielsituation
für die IT-Landschaft.

Der Ablauf entspricht gewöhnlichen IT-Vorhaben:


• Scoping
Umfang des Vorhabens definieren
• Analysis
Analyse und Bewertung des Istzustands
• Design
Erarbeitung von Lösungsvorschlägen und Abstimmung
• Plan Implementation
Einen Plan für die Umsetzung erstellen in Form von Maßnahmenvorschlägen

Quelle: KELLER, Wolfgang, 2017. IT-Unternehmensarchitektur: von der Geschäftsstrategie zur optimalen IT-Unterstützung, p104
Gernot Dern: Vorlesung IT Enterprise Architecture/Strategische IT-Planung, Hasso-Plattner-Institut, Potsdam 2008, http://www.hpi.uni-potsdam.de/hirschfeld/teaching/past/ itua08/index.html
Abbildung auf TOGAF Phasen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 47

Quelle: KELLER, Wolfgang, 2017. IT-Unternehmensarchitektur: von der Geschäftsstrategie zur optimalen IT-Unterstützung, p104
Strategische Bebauungsplanung nach BOC
17.05.2018 IM_EAM, SS 2018, Teil 7-2 48

Quelle: BOC Group, 2010


Strategische Bebauungsplanung nach iteratec
17.05.2018 IM_EAM, SS 2018, Teil 7-2 49

Quelle: iteratec GmbH, 2010


Portfolio von Business Capabilities
17.05.2018 IM_EAM, SS 2018, Teil 7-2 50

Ein Portfolio von Business Capabilities kann ähnlich mit Eigenschaften belegt
werden, wie ein Applikationsportfolio

Ähnliche Attribute findet man auch in Application Management Tools


• ist die Geschäftsfähigkeit „strategisch“ wichtig?
• ist die Geschäftsfähigkeit adäquat implementiert?
• wer sind die Kunden, die die Geschäftsfähigkeit nutzen?
• Welche Volumina von was werden zu welchen Kosten dort bearbeitet
• wie wird „Erfolg“ einer Geschäftsfähigkeit gemessen?
• wer ist der „Owner“ einer Geschäftsfähigkeit?

Bewertung und Messung analog APM oder Balanced Scorecard

Quelle: Keller, EAM - Capabilities (2014-05-22)


Using a business capability map to identify
EA demands
17.05.2018 IM_EAM, SS 2018, Teil 7-2 51

• Capability-based planning

Quelle: Matthes EAM Foundations, sebis, 2016


TOGAF Capability-Based Planning
17.05.2018 IM_EAM, SS 2018, Teil 7-2 52

TOGAF sieht Capabilities eher als horizontale Aspekte (Cross Cutting Concerns).
TOGAF enthält zwar auch eine Definition von Capabilities, die in etwa den
Definitionen von Microsoft und Forrester entspricht. In Kapitel 28 von TOGAF 9.2
werden Capabilities auf lediglich 6 Seiten als Planungsinstrument diskutiert und es
wird dort eher der horizontale Aspekt betont.

Quelle: Keller, EAM - Capabilities (2014-05-22),


TOGAF 9.2
TOGAF: Capability Dimensionen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 53

• Die Funktionen werden unter Berücksichtigung verschiedener Dimensionen


entwickelt und generiert, die die funktionalen Portfolios der Unternehmen
überspannen.
• Jede Organisation hat andere, aber ähnliche Dimensionen. Ein Beispielset
(basierend auf dem kanadischen Department of National Defense) könnte
Personal, Forschung und Entwicklung, Infrastruktur / Einrichtungen, Konzepte /
Prozesse, Informationsmanagement und Material umfassen. werden.

Quelle: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap28.html
TOGAF: Capability Increment Radar
17.05.2018 IM_EAM, SS 2018, Teil 7-2 54

• Es ist nützlich, die Capability in Capability Increments zu zerlegen, die


diskrete, sichtbare und quantifizierbare Ergebnisse liefern, sowie den
Fokus auf Übergangsarchitekturen und die Ergebnisse von zahlreichen
voneinander abhängigen Projekten zu legen.
• Diese Ergebnisse sind die kritischen Erfolgsfaktoren (CSFs)

Quelle: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap28.html
Beziehungen zwischen Capability-Based Planning, EA
und dem Projekt- / Portfoliomanagement
17.05.2018 IM_EAM, SS 2018, Teil 7-2 55

• Ziel ist, dass die strategische Ausrichtung des Unternehmens die Architekturvision in Phase A
antreibt, sowie die Unternehmensorganisation, die die Grundlage für die Erstellung von
Portfolios bildet.
• Im Mittelpunkt der Architekturdefinition (Phasen B, C und D) stehen spezifische Fähigkeiten,
die auf die Fertigstellung abzielen, und basierend auf den identifizierten Arbeitspaketen
werden Phase-E-Projekte konzipiert.
• Die Fähigkeitsinkremente sind die Treiber für die Übergangsarchitekturen (Phase E), die die
Projektinkremente strukturieren. Die tatsächliche Lieferung wird durch die Umsetzungs- und
Migrationspläne (Phase F) koordiniert.

Quelle: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap28.html
TOGAF: Capability-Based Planning
17.05.2018 IM_EAM, SS 2018, Teil 7-2 56

• Zusammenfassung
Capability-Based Planning ist ein vielseitiges Geschäftsplanungs-
Paradigma, das aus Sicht der Unternehmensarchitektur sehr nützlich ist.
Es hilft bei der Ausrichtung der IT auf das Geschäft und hilft IT-Architekten
bei der kontinuierlichen Schaffung von Geschäftswert.

Quelle: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap28.html
Hypothesenbasierter Ansatz nach Niemann
17.05.2018 IM_EAM, SS 2018, Teil 7-2 57

Um die Optimierungspotentiale zu analysieren und zu bewerten, empfiehlt es


sich zunächst, Hypothesen zu entwickeln und die für deren Untersuchung
erforderlichen Datenstrukturen und Sichten abzuleiten.

Scope
Hypothesen Zielarchitektur- Gaps
definieren und
verifizieren / szenarien analysieren,
Hypothesen zu Ist-Architektur
falsifizieren entwickeln, Roadmap
Optimierungs- analysieren
und Potentiale analysieren definieren und
potentialen
bewerten und bewerten steuern
bilden

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Analyseverfahren
17.05.2018 IM_EAM, SS 2018, Teil 7-2 58

Die Untersuchung einer Applikations- und Infrastrukturarchitektur im Hinblick


auf Schwachstellen und Optimierungspotentiale lässt sich in 9
Analysebereiche gliedern, denen Untersuchungshypothesen zugeordnet
werden.

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Typische Hypothesen zum Untersuchungsbereich
„Abdeckung“
17.05.2018 IM_EAM, SS 2018, Teil 7-2 59

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Typische Hypothesen zum Untersuchungsbereich
„Schnittstellen“
17.05.2018 IM_EAM, SS 2018, Teil 7-2 60

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Typische Hypothesen zum Untersuchungsbereich
„Heterogenität“
17.05.2018 IM_EAM, SS 2018, Teil 7-2 61

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Typische Hypothesen zum Untersuchungsbereich
„Konformität“
17.05.2018 IM_EAM, SS 2018, Teil 7-2 62

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Zusammenfassung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 63

• Die Hypothesenbildung erleichtert den Prozess insbesondere bei der


Analyse großer IT-Landschaften und kann den Umfang der erforderlichen
Datenerhebung deutlich reduzieren.
• Die Zuordnung von Analyseverfahren zu den priorisierten Hypothesen und
die anschließende Ableitung der erforderlichen Informationsstruktur
geben frühzeitig Aufschluss über zu erwartende Erhebungs- und
Pflegeaufwände.

Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Technologiemanagement
17.05.2018 IM_EAM, SS 2018, Teil 7-2 64
Technologiemanagement
17.05.2018 IM_EAM, SS 2018, Teil 7-2 65

• Im Technologiemanagement werden die technischen Standards, der


Blueprint, des Unternehmens festgelegt und kontinuierlich
weiterentwickelt.
• Neue technologische Entwicklungen werden im IT-
Innovationsmanagement im Hinblick auf ihre Einsetzbarkeit und
Auswirkungen im Unternehmen beobachtet, evaluiert, bewertet und
gegebenenfalls in den Blueprint aufgenommen.
• Der Lebenszyklus der technischen Bausteine wird gemanagt. Technische
Bausteine und deren Releases, die nicht mehr zukunftsfähig sind oder sich
im Einsatz nicht bewährt haben, werden abgelöst.
• So werden die Zukunftsfähigkeit und Tragfähigkeit von technischen
Standards sichergestellt.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p362
Übung 7-6
17.05.2018 IM_EAM, SS 2018, Teil 7-2 66

Welche Hilfsmittel seitens TOGAF kennen Sie bisher um Ihre


Technologie-Standards definieren zu können?
Blueprint
17.05.2018 IM_EAM, SS 2018, Teil 7-2 67

• Das Wort Blueprint rührt ursprünglich von einer Kopiertechnik (sog. Cyanotypie)
her, die im 19. Jahrhundert z. B. im Schiffbau verwendet wurde, um technische
Zeichnungen günstig zu kopieren, ohne sie von Hand abzeichnen zu müssen.
• Der Begriff Blueprint wird heute für ziemlich jede Art von »positiv belegtem Plan«
benutzt.

Definition:
• A blueprint is a type of paper
based reproduction usually of a
technical drawing documenting an
architecture or an engineering
design. More generally, the term
»blueprint« has come to be used
to refer to any detailed plan.

Quelle: KELLER, Wolfgang, 2017. IT-Unternehmensarchitektur: von der Geschäftsstrategie zur optimalen IT-Unterstützung, p282, http://en.wikipedia.org/wiki/File:LaBelle_Blueprint.jpg,
http://en.wikipedia.org/wiki/Blueprint
Aufgaben im Technologiemanagement
17.05.2018 IM_EAM, SS 2018, Teil 7-2 68

1. die Festlegung der für das Unternehmen relevanten


Kategorien von Standards, d. h. der technischen Domänen,
die „Fächer“ und „Schubladen“ des Blueprints,
2. die initiale Festlegung und kontinuierliche Weiterentwicklung
und Pflege der technischen Standards mit u. a. Lifecycle-
Management und
3. die Steuerung der Verbauung der technischen Standards.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p362
1. Festlegung der technischen Domänen des
Blueprints
17.05.2018 IM_EAM, SS 2018, Teil 7-2 69

• Für jeden Standardisierungsbedarf z. B. für Datenbanken wird


im Blueprint, auch technisches Referenzmodell (TRM)
genannt, eine Schublade, eine technische Domäne,
vorgesehen. „Der Griff in die richtige Schublade“ erleichtert
das Auffinden der zum Problemkontext passenden
technischen Bausteine.
• Grafisch wird das technische Referenzmodell durch
sogenannte „Cluster-Grafiken“ visualisiert.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p362
Beispiel Blueprint-Grafik
17.05.2018 IM_EAM, SS 2018, Teil 7-2 70

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p75
Detaillierte Definition der Technologiedomäne
17.05.2018 IM_EAM, SS 2018, Teil 7-2 71

Die Technologiedomäne ist das zentrale, technisch orientierte


Gliederungselement der Technologie- und Infrastrukturarchitektur
• Technologiedomänen sind hierarchische Gruppierungen von
Technologien, die dem gleichen (bzw. einem hinreichend ähnlichen) Zweck
dienen
• Zu einer Technologiedomäne (auf unterster Ebene) gehört eine definierte
Menge konkreter Technologien
• Technologiedomänen entstehen durch die vollständige Gliederung
benötigter Technologien in disjunkte technische Leistungsbereiche mit
gemeinsamen Merkmalen (Zweck, Mechanismen usw.)
• Technologiedomänen definieren eine logische Struktur, der physisch (zur
Realisierung von Applikationen und Ausführung auf konkreten
Infrastrukturelementen) eingesetzte Technologien bzw.
Infrastrukturelemente zugeordnet werden können
Ausprägungen der Technologie-Domänen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 72

• Die Technologiedomänen können als „Technology Portfolio“ betrachtet


werden
• Sie werden in einem EAM Tool gepflegt
• Beispiel für Technologiedomänen (Ebene 1)

Presentation Central Base Application


Components Components Components

Runtime Environment
Data Storage
Components

Operating Systems Network & Communication

Hardware
Schnittkriterien für Technologiedomänen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 73

Schnittkriterium Relevanz Erläuterung


Technologischer Ja Der Einsatzzweck einer Technologie ist das wesentliche Schnittkriterium. Handelt
Einsatzzweck es sich bei einer Technologie z.B. um einen Basisdienst (z.B. im Sinne eines
Betriebssystems) oder um einen technischen Mechanismus zur persistenten
Speicherung strukturierter Daten (z.B. Datenbankmanagementsystem) usw.
Technologisches Ja Dieses Kriterium ist eher ein sekundäres Kriterium zur weiteren Unterteilung
Wirkprinzip / (z.B. Persistenz-Mechanismus von Datenbanken wie relational, objekt-relational,
Funktionsweise hierarchisch, XML-Datenbank o.ä.)
Applikationen / Ja Dieses Kriterium ist nur in Fällen relevant, in denen Applikationen bzw. deren
Applikaitonsmodule Module rein technologisch oder funktional im Sinne eines IT-Bausteins
(Funktionsbaustein) definiert sind. Es ist weniger ein Schnittkriterium, sondern
eher ein Aspekt, mit dem weitere Technologien bzw. Domänen identifiziert
werden können.
Informationsobjekte Ja Dieses Kriterium ist nur dann relevant, wenn es rein technologisch oder
funktional im Sinne eines IT-Bausteins (Funktionsbaustein) definiert ist.
Geschäftsprozesse Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Wertschöpfungstiefe Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Organisationseinheiten Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Produkte und Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Geschäftsfelder
Kundensegmente Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Geographie (Standorte, Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Werke)
Technologie-Domänen und IT-Bausteine
17.05.2018 IM_EAM, SS 2018, Teil 7-2 74

IT-Bausteine lassen sich durch das Technologie-Domänenkonstrukt abbilden


class Bausteine

«Hierarchie» Technologie nutzt Infrastrukturkomponente


Technologie-Domäne umfasst
1 1..* * *

abgebildet auf abgebildet auf abgebildet auf


ist Ausprägung von ist Instanz von
IT-Baustein IT-Bausteinausprägung IT-Bausteininstanz
1 1..* 1 *

Oracle ORA-DB 1234

Datenbankmanagementsystem DB2 ORA-DB 5678


(DBMS)

MS SQL Serv er
MSSQL-DB 9876

JBoss
App-Serv er 4711

Application
Serv er Apache Tomcat

App-Serv er 0815
IBM WebSphere
Übung 7-7
17.05.2018 IM_EAM, SS 2018, Teil 7-2 75

Erstellen Sie eine Cluster-Grafik mit Domänen der Ebene 2 für


das gegebene Beispiel der Technologiedomänen (Ebene 1).
2. Initiale Festlegung und kontinuierliche Weiter-
entwicklung und Pflege der technischen Standards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 76

Für die initiale Befüllung des Blueprints sind folgenden


Aktivitäten notwendig:
1. Ermitteln Sie die aktuell genutzten technischen Bausteine
durch die Analyse der IS-Bebauung und der
Betriebsinfrastruktur.
2. Sammeln Sie Ihre Standardisierungsanforderungen
3. Bewerten Sie die Standardisierungsanforderungen
4. Entscheidung über die Standardisierungskandidaten z. B.
durch das Blueprint-Board
5. Umsetzung der Standardisierungsmaßnahmen entsprechend
der Entscheidung

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p364
Technische Standardisierung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 77

In Abhängigkeit von der strategischen Positionierung der IT im Gesamtunternehmen gibt es unterschiedliche


Motive für die technische Standardisierung

Kostenreduktion im IT-Basisbetrieb
• Nachhaltige Kostenreduktion durch Nutzung von Skaleneffekten, einer zentralen Verhandlungsmacht im
Einkauf und der Knowhow-Bündelung erzielen

Beherrschung und/oder Reduktion der IT-Komplexität


• IT-Komplexität durch Steigerung der technischen Qualität beherrschen (wiederholte Verwendung von
bewährten technischen Bausteinen)

Optimierung des Tagesgeschäfts


• Standardisierung von Methoden und Verfahren z. B. für die Administration und den Betrieb von
Anwendungen oder aber auch im fachlichen Kontext

IT strategisch ausrichten
• Tragfähige und zukunftssichere technische Standards vorgeben

Beitrag zur Weiterentwicklung des Geschäfts


• Festlegung von Standards, die Flexibilität fördern und Änderungen schneller durchführen lassen

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p17f
IT Standards = Prinzipien + Technologie-Vorgaben
17.05.2018 IM_EAM, SS 2018, Teil 7-2 78

Quelle: Bente, EAM Transformation, 2015, p48


Anforderungen an IT Standards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 79

• Erfüllung strategischer Anforderungen


– Trägt zu Gelingen oder Scheitern einer IT-Strategie bei
– Funktional: betrifft elementare Geschäftsprozesse oder -objekte (ERP-System)
– Nicht-funktional:
• Performanz oder Ausfallsicherheit
• Mandantenfähigkeit, Konfigurierbarkeit
• Integrierbarkeit, Schnittstellen
• Kosten
– TCO trägt substantiell zu IT-Gesamtkosten bei z.B. bei großen Middleware-
Plattformen, ERP-Systemen
• Rechtliche Risiken
– z.B. Open Source – Beispiel Hibernate
• Wirtschaftliche Risiken
– Insolvenz vs. Vendor Lock-In
Quelle: Bente, EAM Transformation, 2015, p53
Vor- und Nachteile durch Standardisierung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 80

Vorteile
• Rabatte durch Bündelung der Einkaufsvolumina
• geringerer Entwicklungsaufwand und Einsparung von Entwicklungskosten
• Verwendung bewährter Techniken
• vereinfachte Kommunikation zwischen Komponenten
Nachteile
• weniger Differenzierungsmöglichkeiten
• spezielle Anforderungen nicht genügend berücksichtigt
• weniger Gestaltungsspielraum
• Weiterentwicklungen erschwert
Bebauungssicht „Technologienutzung“
17.05.2018 IM_EAM, SS 2018, Teil 7-2 81

 Darstellung der in Applikationen verwendeten Technologien / IT-Komponenten

Verant wort ende


Unterteilung der Organisationseinheit  Audi DE Audi BE Audi HU VW
Technologien nach Phase Applikation 

App. 10

App. 11

App. 12

App. 13

App. 14

App. 15
ihres Lebenszyklus Gruppierung der Applikationen

App. 1

App. 2

App. 3

App. 4

App. 5

App. 6

App. 7

App. 8

App. 9
nach verantwortender OE
Lebenszyklus-
phase ↓ I T-Komponent e ↓

I nnovat ive Technologie 1 X Nut zung von Technologie m it


Technologie ggs. f raglichem Reif egrad
Technologie 2 X
Technologie 3 X X
Technologie 4 X X X
Ausgereif t e
Technologie 5 X X
Technologie
Technologie 6 X X X X X X X X X X X X
Technologie 7 X
Technologie 8 X
Vielf ach genut zt e Technologie
Auslauf ende
Technologie 9 X X
Technologie
Markierung
Technologie 10 von X X
Befunden
Technologie 11 bzw. X Applikat ion m it veralt et em
Veralt et e
Technologie
Indikatoren Technologie-Port f olio
Technologie 12 X
Bebauungssicht „Technologienutzung“ (Steckbrief)
17.05.2018 IM_EAM, SS 2018, Teil 7-2 82

Ausgangsfrage zur Bebauung Wesentliche Architekturelemente


• Welche Applikationen nutzen welche IT- • Applikation
Komponenten / Technologien? • IT-Komponente / Technologie
Zielsetzung / Nutzen • Schnittstelle
• Übersichtliche Darstellung des Typische Befunde
eingesetzten Technologie-Portfolios • Veraltete (oder auslaufende)
• Ermittlung von Handlungsbedarf Technologien
(Vereinheitlichung, Modernisierung usw.) • IT-Komponenten mit wenig interner /
Erweiterungen / Abwandlungen externe Technologie-Kompetenz
• Einbeziehen von Schnittstellen in die • Vielzahl unterschiedlicher Technologien
Technologie-Betrachtung für den gleichen Zweck
• Gruppierung der Technologien nach Steuerungsgrößen Menge und Granularität
anderen Merkmalen (z.B. Open-Source / • Gezielte Auswahl der Applikationen (z.B.
proprietär, Standard-Konformität, Beschränkung auf eine (Sub-)Domäne)
Technologie-Domäne, Grad an
vorhandener Technologie-Kompetenz) • Applikation vs. Applikationsmodul
• Gruppierung der Applikationen nach (Detaillierungsgrad)
anderen Merkmalen (z.B. Haupt-Domäne, • Gezielte Auswahl der IT-Komponenten
Geschäftskritikalität, Lebenszyklusphase (z.B. Beschränkung auf bestimmte
o.ä.) Technologie-Domäne(n))
Bebauungssicht „Technologienutzung“ (Darstellung 2)
17.05.2018 IM_EAM, SS 2018, Teil 7-2 83

 Darstellung der in Applikationen verwendeten Technologien / IT-Komponenten

Klassifizierung nach
Architekturschichten

Transparenz,
Transparenz, GradAktualität,
der Aktualität,
Konformität zum BoS
Standard-Konformität

Technologiedomäne

Matrixeinträge sind die IT-


Komponenten
Initiale Festlegung der technischen Standards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 84

• Nehmen Sie in den initialen Blueprint nur strategische


Vorgaben und bewährte Lösungen aus Ihrem Unternehmen
auf (Mischung aus Top-down- und Bottom-up-Vorgehen). So
können Sie die Weiterentwicklung strategisch ausrichten und
schaffen gleichzeitig Akzeptanz für die Vorgaben.
• Analysieren Sie alle technischen Domänen und legen Sie Ihre
Standards für Technologien wie z. B. JEE oder IT-Produkte wie
z. B. ORACLE 12.1 fest. Beschränken Sie sich dabei auf das
Sinnvolle und Notwendige, dessen Umsetzung auch möglich
und gleichzeitig angemessen ist. Einige Schubladen dürfen
durchaus auch leer bleiben, wenn aktuell noch kein Standard
sinnvoll festzulegen ist.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p364
Nutzengrad der technischen Standardisierung
17.05.2018 IM_EAM, SS 2018, Teil 7-2 85

Reifegrade
Einstieg „Black-Box“ „White-Box“
Kosteneinsparung
Nutzung von Skaleneffekten und einer zentralen
X X X
Verhandlungsmacht im Einkauf
Know-how-Bündelung X X X
Hohe technische Qualität
Wiederverwendung von bewahrten technischen „Black-Box“-
X X
Bausteinen
Standardisierung von „White-Box“-Standards X
Angemessene IT-Unterstützung (z. B. Flexibilität)
Referenzarchitekturen und Architekturmuster, die das Prinzip der
X
Service- und Komponentenorientierung unterstutzen
Standard-Middleware- und Schnittstellen/API-Lösungen
X X
wie z. B. ein Enterprise Service Bus
Zukunftssicherheit
Business- und IT-Innovationen (IT-Innovationsmanagement) X X
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p362
Beispiele für Technologieentscheidungen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 86

Meistens Vorgabe Eher Projektentscheidung


• Relationale Datenbank • Sourcecode-Management
• JEE Application Server • Entwicklungs-Umgebung
• UI Framework • Reporting-System
• Intranet-Plattform • Continuous Integration
• ESB Framework

• 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.

Quelle: Bente, EAM Transformation, 2015, p52


Kontinuierliche Weiterentwicklung der technischen
Standards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 87

Die Weiterentwicklung der technischen Standards erfolgt ausgerichtet


an der Unternehmens und IT-Strategie sowie den
Geschäftsanforderungen. Der Blueprint ist kontinuierlich an die
veränderte Situation anzupassen. Dabei helfen Ihnen folgende
Fragestellungen:
• Welche bestehenden technischen Standards sind noch
angemessen, tragfähig und zukunftsfähig?
• Für welche technischen Trends und Neuerungen sollten neue
technische Standards für das Unternehmen erstellt werden?
Welche bestehenden technischen Standards sollte man dafür
ablösen?
• Für welchen im Rahmen der Analyse der IS-Bebauung oder im
Rahmen der operativen Projektabwicklung identifizierten
Handlungsbedarf und für welche Optimierungspotenziale sollten
neue technische Standards erstellt oder bestehende verändert
werden?
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p364
Standardisierungsmaßnahmen
17.05.2018 IM_EAM, SS 2018, Teil 7-2 88

Durch die Umsetzung der verabschiedeten Standardisierungsmaßnahmen wird


der Blueprint weiterentwickelt. Beispiele für Standardisierungsmaßnahmen:
• Erstellung von Referenzarchitekturen oder Architekturmustern
• Evaluierung von IT-Kaufprodukten
Bei der Evaluierung von IT-Kaufprodukten werden die am Markt verfügbaren
IT-Kaufprodukte ermittelt, entsprechend den unternehmensspezifischen
Anforderungen bewertet, eine Vorauswahl getroffen und eine Empfehlung für
eines der IT-Kaufprodukte aus der Vorauswahl abgegeben.
• Erstellung von technischen Komponenten
Entsprechend den unternehmensspezifischen Anforderungen werden
technische Komponenten entwickelt oder angepasst bzw. konfiguriert.
• Bereitstellung von Migrationshilfestellungen
Wenn technische Standards, die in Informationssystemen oder Schnittstellen
verbaut wurden, auslaufen, müssen Hilfestellungen für die Migration z. B. auf
Nachfolgerbausteine gegeben werden. Dies kann z. B. ein Migrationskonzept,
ergänzt um Migrationsskripte, sein. Migrationshilfestellungen sind
insbesondere auch bei neuen Releases technischer Bausteine erforderlich.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p364
Wichtige Grundsätze für die Akzeptanz von
technischen Standards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 89

• Achten Sie auf die Angemessenheit, Tragfähigkeit, Zukunftsfähigkeit und


einfache Nutzbarkeit aller neuen oder veränderten technischen
Bausteine.
• Häufig werden technische Bausteine aus Best-Practices in Projekten unter
Mitwirkung der Softwarearchitekten aus der „Linie“ konsolidiert. Dies
erhöht zudem die Akzeptanz der technischen Standards.
• Kommunikation von neuen und veränderten technischen Standards
• Hilfsmittel für die Nutzung
Nur durch Hilfsmittel für die Nutzung wie z. B. ein Nutzungskonzept oder
Checklisten kann die bestimmungsgemäße Verbauung der technischen
Bausteine sichergestellt werden.
• Kontinuierliches Aufräumen
Sorgen Sie dafür, dass der Blueprint immer auf einem aktuellen Stand ist.
Im Rahmen der Pflege sind die bestehenden Standards kontinuierlich zu
überprüfen und nicht mehr relevante Standards als „abzulösen“ zu
markieren. Nur so bleiben die technischen Standards wartbar und nur so
realisieren Sie die angestrebte Kosteneinsparung.

Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p364
3. Steuerung der Verbauung der technischen
Standards
17.05.2018 IM_EAM, SS 2018, Teil 7-2 90

• Die besten technischen Standards helfen nicht, wenn sie nicht


verwendet werden. Nur durch die aktive Steuerung der
Verbauung können die mit dem Technologiemanagement
verbundenen Ziele erreicht werden. Es muss sichergestellt
werden, dass die festgelegten technischen Standards im
Rahmen der Projekte und Wartungsmaßnahmen sowie im
Betrieb eingehalten und abzulösende Standards auch wirklich
abgelöst werden.

• Durch die kontinuierliche Überwachung der Tragfähigkeit und


Zukunftsfähigkeit, der Kosten und des Nutzens sowie der
Häufigkeit des Einsatzes kann die Weiterentwicklung des
Blueprint wirkungsvoll gesteuert werden.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p366
Technologie-Standards: Typische Adaptionszeitpunkte
17.05.2018 IM_EAM, SS 2018, Teil 7-2 91

Kern-Technologien: Nicht zu früh an Bord nehmen, nicht zu lange behalten!

Quelle: Bente, EAM Transformation, 2015, p53,


https://de.wikipedia.org/wiki/Datei:Abb3_Technologietypen.png, Michel (1987) S. 67, Von Robert Orzanna - Eigenes Werk, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=46466161
Fragen zum Teil 7
17.05.2018 IM_EAM, SS 2018, Teil 7-2 92

• Was versteht man unter Anwendungsportfolio-Management?


• Welche Ergebnisse hat eine IS-Bebauungsplanung?
• Was ist der Zweck von Analysemuster?
• In welchen Bereichen der IS-Bebauungsplanung können
Gestaltungsmuster eingesetzt werden
• Was bedeutet Capability-Based Planning?
• Wieso können Hypothesen bei der Bebauungsplanung helfen?
• Welche Aufgaben gehören zum Technologiemanagement?
• Welche Vorteile ergeben sich durch die Standardisierung der Technik?
• Wie sind die Nachteile einer Standardisierung zu vermeiden?

Das könnte Ihnen auch gefallen