Enterprise Architecture Management in der Praxisroi-analyzer.de/hp.nsf/0/a2873f075e0b16dcc1257ee200685956/$FILE... · der an der TOGAF-Spezifikation beteiligten Unternehmen sind IT-Dienstleister,

Enterprise Architecture Management in der Praxis

Gastvortrag an der Universität Potsdam

Kai Eckert, 18.01.2016

© BOC Group | [email protected] 2

Agenda

Über die BOC GmbH

EAM Grundlagen

EAM in der Praxis

Diskussion


Gründung & Struktur

Gründung im Jahr 1995

Spin-off der BPMS-Gruppe der Universität Wien

Heute mehr als 180 Mitarbeiter

BOC Gruppe - Firmenprofil


Das BOC Management Office

IT-based Management Solutions for Your Success!

• Strategie- und Performance-Management

• Balanced Scorecard

• Strategisches Controlling

• Maßnahmen-Management

• Prozessoptimierung und -steuerung

• Prozessportale / -dokumentation

• Risikomanagement und IKS

• Kollaboration

• Enterprise Architecture Management

• Service Management / ITIL / CoBIT

• IT Governance

• IT Risk Management


BOC Management Office

Customer - Requirements

Software Products Consulting Education

Management Domains

Consult ing S o f t w a r e T r a i n i n g

Business Process

Management Enterprise Architecture

Management

ICS and

Risk Management

Standards & Leading Practises


Agenda

Über die BOC GmbH

EAM Grundlagen

EAM in der Praxis

Diskussion


Einordnung des Begriffs „Architektur“

Was ist eine Architektur?

Eine Architektur beschreibt den Gesamtzusammenhang der erkenntnisrelevanten Objekte,

ihre Funktionen, Schnittstellen und Beziehungen.

Wozu benötigt man eine Architektur?

Ziel einer Architektur ist, sicherzustellen, dass ein System die gegebenen Anforderungen

erfüllt und bewährte Lösungen nicht wiederholt erfunden werden müssen.

Auch soll eine Architektur die Integrierbarkeit, Interoperabilität und die Austauschbarkeit

von Komponenten ermöglichen.

Letztlich fördert eine angemessen entworfene und dokumentierte Architektur die

Wiederverwendbarkeit ihrer Komponenten und die Robustheit ggü. Änderungen der

Anforderungen.


Warum benötigt man ein Verständnis von Architektur?

Winchester Mystery House

Quelle: http://i2.wp.com/99percentinvisible.org/wp-content/uploads/2015/04/Winchester_Mystery_House_San_Jose_CA_C31107.jpg


Warum benötigt man ein Verständnis von Architektur?

Winchester Mystery House

Quelle: http://stargazermercantile.com/wp-content/uploads/2013/03/winchester-across.png


Sinn und Zweck einer Unternehmensarchitektur

Was ist eine Unternehmensarchitektur?

• Eine Unternehmensarchitektur beschreibt das Zusammenwirken der

informationstechnischen (IT-Architektur) mit den betriebswirtschaftlichen

(Geschäftsarchitektur) Teilbereichen eines Unternehmens.

Was ist eine Geschäftsarchitektur?

• Die Geschäftsarchitektur betrachtet die Geschäftsprozesse und die

Geschäftsobjekte einer Organisation.

Was ist eine IT-Architektur?

• Die IT-Architektur beschreibt die Eigenschaften und Beziehungen von IT-

Komponenten sowie deren Einordnung in die umgebende Organisation und

ihre Umwelt.

• Bestandteile einer IT-Architektur sind Anwendungen, Schnittstellen,

Technologien, Daten, u.v.m.


Ausgewählte Inhalte einer Unternehmensarchitektur

Eine Unternehmensarchitektur beschreibt die informationstechnischen und

betriebswirtschaftlichen Gestaltungsobjekte eines Unternehmens und deren

Zusammenwirken. Die Objekte sind somit sowohl fachlicher Natur als auch IT-

bezogen.


EAM vs. Stadtplanung

Eine Analogie

Stadtplanung EAM

Mak

ro

Mik

ro

Hausbau Softwarearchitektur


Architekturmanagement

Was ist Architekturmanagement?

• Das Architekturmanagement plant, entwirft, pflegt, evaluiert und optimiert die

(Unternehmens-) Architektur mit dem Ziel der effektiven und effizienten

Umsetzung von (z.B. strategischen) Anforderungen.

Was ist IT-Architekturmanagement?

• Das IT-Architekturmanagement ist als Teilmenge des Architekturmanagements

zu sehen.

• Ziel ist vor allem der Abgleich der IT-Architektur mit der Geschäftsarchitektur.

(IT/Business Alignment)

Wie kann man eine Unternehmensarchitektur beschreiben?

• Textuell

• Grafisch, z.B. durch Modelle

Verschiedene Frameworks liefern einen Ansatz für Entwurf, Planung,

Implementierung und Wartung von Unternehmensarchitekturen.


Business-IT-Alignment

Anforderungen

Unterstützung

Geschäftsarchitektur IT-Architektur

Unternehmensarchitekturmanagement


Entwicklung von EAM Frameworks

Geschichte

Quelle: Wolfgang Keller, Vorlesung IT Enterprise Architecture, 2012, Hasso Plattner Institut


Zachman Enterprise Architecture Framework

Geschichte

John A. Zachman veröffentlichte im Jahre 1987 die erste Version seines

Vorschlags für ein Architektur-Framework.

1992 Erweiterung zusammen mit John F. Sowa zu der heute bekannten

Ausprägung.

Entwurfsziel: Bereitstellung von Beschreibungskonzepten, die geeignet sind,

die vielfältigen Schnittstellen von Komponenten eines Informationssystems

sowie deren Integration in die Organisation darzustellen.

Das Zachman Framework ist einer der ersten methodischen Ansätze des

Architekturmanagements.



Quelle: Sowa, J.F.; Zachman, J.A.: Extending and Formalizing the Framework for Information Systems Architecture. In: IBM Systems Journal. Vol. 31, No. 3, S. 590-616, 1992

What How Where Who When Why



Bewertung

Vorteile

Ganzheitlicher Beschreibungsansatz für das Architekturmanagement

Einführung von Sichten und Perspektiven

Integration von Business und IT

Nachteile

Sehr abstrakt

Enthält wenig verbindliche Aussagen über Vorgehen

Organisatorische Aspekte (Gremien, Rollen, Architekturprozesse) sind nicht Teil des

Frameworks


TOGAF

The Open Group Architecture Management Framework

TOGAF basiert auf dem Technical Architecture Framework for Information

Management (TAFIM) des Department of Defense (Verteidigungsministerium)

der Vereinigten Staaten von Amerika.

Es wird aktuell von der Open Group weiterentwickelt, einem Konsortium, dem

ca. 400 Unternehmen angehören, die ein gemeinsames Interesse an der

Schaffung herstellerunabhängiger Standards im IT-Bereich haben. Ein Großteil

der an der TOGAF-Spezifikation beteiligten Unternehmen sind IT-Dienstleister,

Technologie- und Beratungsunternehmen.

TOGAF wird aktuell in der Version 9.1 geführt.

Einzelpersonen können sich nach TOGAF

zertifizieren lassen (Foundation und Certified).

Unternehmen als Ganzen sind nicht

zertifizierbar.

Quelle: The Open Group,TOGAF Version 9, 2009, Abb. 1-1, S.4


Die Komponenten von TOGAF


TOGAF

Architecture Development Method (ADM)

Die ADM beinhaltet die links

stehenden Phasen, die vorgeben

sollen, wie ein architekturrelevantes

IT-Projekt inhaltlich zu strukturieren

ist.

Durch Views werden Sichten auf die

Architektur aus der Perspektive von

Stakeholdern (Viewpoints) in den

Phasen beschrieben.

Quelle: The Open Group,TOGAF Version 9, , 2009, Abb. 5-1, S.54


TOGAF

Bewertung

TOGAF

Ist anbieter-, werkzeug- und branchenneutral

Hat sich in der Praxis als De-facto-Standard etabliert

Werkzeuge und Personen können zertifiziert werden

Ist ein Framework (generisch) und muss auf die Organisation angepasst werden

Vorteile

Umfassend

Methodisch

Hebt die Geschäftssicht bei IT-Projekten hervor (Top-down-Ansatz)

Nachteile

Komplex, dadurch Anpassung an die Organisation herausfordernd

Stark projektorientiert


Notationen zur Abbildung von Unternehmensarchitekturen

Ansätze und Methoden zu UAM verwenden eine Vielzahl von

Modellierungssprachen.

Einige Beispiele sind:

UML, DFD, ERD für softwarenahe Beschreibungen

BPMN, EPK, BPMS für Geschäftsprozesse

Archimate, MEMO für Unternehmensarchitekturen

Die Wahl für eine Modellierungssprache ist abhängig von den folgenden

Faktoren:

Zielsetzung des UAM

Verwendeter UAM-Ansatz

Gewünschte Mächtigkeit der Sprache

Avisierte Werkzeugunterstützung

Persönliche Präferenzen

…


ADOit-Metamodell (basierend auf TOGAF Core Metamodell)


ArchiMate am Beispiel

Quelle: Aktuelle Trends im EAM, Dr. Lutz Kirchner, Scape Consulting


Agenda

Über die BOC GmbH

EAM Grundlagen

EAM in der Praxis

Diskussion


Warum Unternehmensarchitekturmanagement?

Gründe für Einführung

Ausgangspunkt bei der Einführung von UAM ist fast immer eine heterogene,

organisch gewachsene oder anorganisch erweiterte IT-Landschaft, deren

Effektivität und Effizienz hinsichtlich der Unterstützung der Geschäftsarchitektur

verbesserungswürdig ist.

Treiber für die Einführung von UAM ist oftmals weniger die Erkenntnis, dass

UAM alles besser machen würde, sondern die Not, die aus konkreten Projekten

heraus entsteht.


Treiber für die Einführung von UAM

Ausschnitt

Ziel

Ausgangssituation

Compliance

Märkte Sourcing

Produkte Merger

Qualität

Konsolidierung

Projekte


Erwarteter Nutzen von Unternehmensarchitekturmanagement

Kostenvorteile durch

Konsolidierung der IT-Infrastruktur

Reduktion der fachlichen Redundanzen in der Anwendungslandschaft

Bessere IT-Projektunterstützung durch

Erhöhte Transparenz über die Unternehmensarchitektur (Ist und Soll)

Synergieeffekte über die IT-Projekte hinweg auf Basis wiederverwendbarer und konsistenter

Architekturdokumentationen

Optimierte Geschäftsprozesse

Aufdecken der Beziehungen zwischen Geschäftsprozessen und IT

Möglichkeit des Alignments der IT zu den Geschäftsprozessen

Frühzeitige Berücksichtigung von geschäftsseitigen Anforderungen in der Architekturplanung

Erhöhung der Qualität der IT-Leistungen

Verbesserte Business Continuity

Kritische Bereiche in der IT-Architektur sowie deren Schutzbedarfe können leichter ermittelt werden

Auswirkungen von Ausfällen und Änderungen können bewertet werden


Erwarteter Nutzen von Unternehmensarchitekturmanagement

Unterstützung des Providermanagements

Outsourcing kann leichter initiiert und überwacht werden

Providerwechsel sind auf Basis einer umfassenden Dokumentation schneller zu realisieren

Nachweis der Einhaltung von Vorgaben (Compliance)

Unternehmensarchitektur als Basis für Audits

Risikomanagement

Zertifizierungen

Sonstige gesetzliche Dokumentationspflichten (branchenabhängig)

Höhere Flexibilität

Möglichkeit der Ausrichtung der IT-Architektur auf neue Produkte, neue Märkte und neue bzw.

geänderte Strategien durch Auswahl geeigneter Architekturparadigmen und Architekturprinzipien

…


Typische Fragen und Beweggründe betreffend …

der IT-Architektur

Welche Anwendungen sind durch

den Versionswechsel einer

Technologie betroffen?

Wo liegt das Einsparungspotenzial

in der IT-Landschaft?

In welchen Bereichen muss die

Qualität der IT gesteigert werden?



der Integration mit der Geschäftsarchitektur

Welche Prozesse sind

durch einen Ausfall der

IT betroffen?

Welche IT-Services

unterliegen einer

hohen Risikostufe?

Auf welche IT-Services

wirken sich die

Prozessoptimierungen aus?



des Zielbilds

ADONIS

Wie sieht das

zukünftige

Produktportfolio aus?

Welche Technologien ermöglichen

eine Differenzierung unserer Produkte

und Dienstleistungen am Markt?

Wo befinden sich die Customer Touchpoints

für eine optimierte Kundenbindung?



essentieller Fähigkeiten des Unternehmens

Geschäftsfähigkeit

Welche Fähigkeiten müssen wir dazu

aufbauen?

Wie muss unser Projektportfolio

gestaltet werden?

… und wie können wir sicherstellen,

dass wir auf dem richtigen Weg sind?



Strategischer Einflussfaktoren

Demographischer

Wandel

„Digital

Disruption“

Mitbewerb

Markttrends

Mobile

Mindshift

Business

Demands


Ausgewählte Techniken im Architekturmanagement

IT-Bebauungsplan

Ein IT-Bebauungsplan dokumentiert den aktuellen und geplanten Einsatz von

Anwendungen sowie ggf. von Technologien zur Unterstützung der

Geschäftsprozesse unter Berücksichtigung der Verortung (Verantwortung,

Installationsort).

Die o.g. Beziehungen werden in der Regel in Form einer Matrix dargestellt.

Eine solche Darstellung soll sicherstellen, dass in der Planung der IT-Bebauung

zu jeder Zeit eine ausreichende Geschäftsprozessunterstützung realisiert ist.



Business Impact Analyse

Bei einer Business Impact Analyse werden die Auswirkungen von

Geschäftsunterbrechungen untersucht, die Verfügbarkeitsanforderungen an die

Geschäftsprozesse und deren benötigten Ressourcen ermittelt und die

benötigten Wiederanlaufzeiten festgelegt. Aus: IT-Grundschutzkatalog, BSI, M 6.114 Erstellung eines Notfallkonzepts

Bezogen auf UAM bedeutet dies, dass die Abhängigkeiten zwischen IT und

Geschäftsprozessen bekannt sein müssen, um den Business Impact von IT-

Komponenten ermitteln zu können.

Ein erster Schritt dazu ist eine Abhängigkeitsanalyse in grafischer Form.



Roadmaps

Ausgehend von den Bewertungskriterien für Anwendungen werden die

Lebenszyklen und Roadmaps geplant.

Diese bilden einen zentralen Input für das Release Management und müssen

mit diesem abgestimmt werden.

Visualisierung: Gantt-Diagramme werden häufig für die Darstellung von

Projektplänen genutzt, eignen sich jedoch auch für die Darstellung von

Roadmaps oder Lebenszyklen.

Quelle: Wikipedia



Portfolios

Portfolio-Diagramme sind aufgrund Ihrer Einfachheit wichtige Kommunikationsinstrumente in

Richtung Management.

Sie eignen sich zur Gegenüberstellung nahezu beliebiger Sachverhalten (Zahlwerte, Aufzählungen)

und werden oft genutzt, um Technologie-, Anwendungs- oder Projektportfolios darzustellen.

Beispiel für ein Projektportfolio



Architekturprinzipien

Unter (IT-)Architekturprinzipien wird verstanden

Regeln für Gestaltung einer IT-Architektur

Werden idealerweise aus IT-Strategien und zugehörigen Zielen abgeleitet

Können i.d.R. mittels einer Ordinalskala (z.B. 1-5) gemessen werden

Dienen zur Überwachung und Steuerung einer IT-Architektur (Leitplanken)

Jegliche Änderung an einer Ist-Architektur (IT-Projekt) muss zu einer

Zielarchitektur führen, die mit den vereinbarten Architekturprinzipien konform

geht.

Wichtig ist, dass die Bewertung von Architekturprinzipien nicht als

Momentaufnahme geschieht, sondern auch der Definition und Bewertung von

Zielzuständen dienen kann. Somit kann aufgezeigt werden, wie Projekte die

Architektur im Zeitverlauf hinsichtlich der Architekturprinzipien verändern.



Architekturprinzipien

Abstrakte Architekturprinzipien

Wirtschaftlichkeit

Zuverlässigkeit

Wiederverwendung

Sicherheit

Benutzerfreundlichkeit

Standards

Homogenität

…

Abgeleitete Architekturprinzipien

Vornehmliche Nutzung von Open Source Software

Einhaltung von SOA-Prinzipien

Einsatz ISO 9241-konformer Anwendungen

…


Verantwortliche im Architekturmanagement

Typische Rollen und Gremien

Fachseitig

Kunde und Nutzer (Customer)

Anforderer (Business Analyst)

Prozessverantwortlicher (Domain Manager)

IT-seitig (Architektur)

Leitender IT-Architekt (Enterprise/Chief Architect)

IT-Architekt (Domain/IT Architect)

Datenverantwortlicher (Information Architect)

Infrastrukturverantwortlicher (Infrastructure/Technology Architect)

Lösungsarchitekten aus Projekten (Solution Architect)

Anwendungsverantwortlicher (Application Manager)

IT-Sicherheitsbeauftragter (IT Security Officer)

IT-seitig (Betrieb)

Change Manager

Incident Manager

Problem Manager

Service Catalogue Manager

Service Level Manager


Das Architecture Board

Aufgaben und Zusammensetzung

Ein Architecture Board setzt sich meist folgendermaßen zusammen:

Leitender Unternehmensarchitekt

Leitender Lösungsarchitekt

Kundenseitiger Vertreter

Vertreter der Anwendungsverantwortlichen

IT-Betrieb

Externe Berater

Externe Dienstleister

Aufgaben des Boards

Entwicklung von Richtlinien und Standards auf Basis der IT-Strategien

Ableitung konkreter Architekturvorgaben (Blueprints, Architekturprinzipien)

Überwachung von Projekten hinsichtlich der Einhaltung der vorgegebenen Regeln

Weiterentwicklung und Kommunikation der UAM-Methode

Die Teilnahme des Boards ist oft rotierend, d.h. einzelne Vertreter werden zyklisch ausgetauscht, um

einer Verengung des Horizonts entgegenzuwirken.


Häufiger Ausgangspunkt im Architekturmanagement

Anwendungsportfolio-Management

Es existiert in der Regel eine hohe Zahl an Anwendungen sowie fast ebenso

viele Anwendungsverantwortliche (technisch und fachlich).

Im Allgemeinen gibt es aber keine verlässlichen, zentral verfügbaren Daten über

die Unternehmensarchitektur im Hinblick auf:

- Funktionalität von Anwendungen und Services

- Geplante Lebensdauer von Anwendungen

- Verwendete Technologieparadigmen und Standards

- Systemsoftware (Betriebssysteme, Datenbanken, Protokolle, Entwicklungsumgebungen

etc.)

- Schnittstellen (i. d. R. deutlich mehr als Anzahl der Anwendungen)

- Technische Infrastruktur, auf der die Anwendungen betrieben werden

- Anforderungen an die IT-Architektur

- Laufende/geplante Projekte auf Anwendungen

44


Beispiele

Anwendungen

Anwendungen

SAP BI (Operatives Controlling)

ELSTER (Elektronische Steuererklärung)

ELFE (Einheitliches länderübergreifendes Festsetzungsverfahren)

Paisy (Personalmanagement)

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


Bewertungskriterien für Anwendungen

Eine Auswahl (1)

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


Bewertungskriterien für Anwendungen

Eine Auswahl (2)

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


Agenda

Über die BOC GmbH

EAM Grundlagen

EAM in der Praxis

Diskussion


© Copyright BOC AG, Wien 2010

Das BOC Management Office, sowie ADOscore, ADONIS, ADOlog und ADOit sind eingetragene Warenzeichen der BOC Gruppe. Alle anderen genannten Marken sind Eigentum der jeweiligen Hersteller.

Alle angeführten Inhalte sind urheberrechtlich geschützt. Alle Arten von Änderungen, Erweiterungen oder Beilagen sind nur nach vorherigem, schriftlichen Einverständnis der BOC Gruppe erlaubt.

Reproduktionen in jeder Form sind nur unter Angabe des Copyright-Vermerks erlaubt. Publikationen sowie Übersetzungen bedürfen des schriftlichen Einverständnisses der BOC Gruppe.

Kai Eckert

Management Consultant

BOC

Information

Technologies

Consulting GmbH

Naglerstraße 5

10245 Berlin

Tel: +49-30-22 69-2510

Fax: +49-30-22 69-2525

E-Mail: [email protected]

Documents

Enterprise Architecture Management in der Praxisroi-analyzer.de/hp.nsf/0/a2873f075e0b16dcc1257ee200685956/$FILE... · der an der TOGAF-Spezifikation beteiligten Unternehmen sind IT-Dienstleister,