View
214
Download
0
Category
Preview:
Citation preview
Enterprise Architecture Management in der Praxis
Gastvortrag an der Universität Potsdam
Kai Eckert, 18.01.2016
© BOC Group | boc@boc-group.com 2
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
© BOC Group | boc@boc-group.com 3
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
© BOC Group | boc@boc-group.com 4
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 Group | boc@boc-group.com 5
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
© BOC Group | boc@boc-group.com 6
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
© BOC Group | boc@boc-group.com 7
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.
© BOC Group | boc@boc-group.com 8
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
© BOC Group | boc@boc-group.com 9
Warum benötigt man ein Verständnis von Architektur?
Winchester Mystery House
Quelle: http://stargazermercantile.com/wp-content/uploads/2013/03/winchester-across.png
© BOC Group | boc@boc-group.com 10
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.
© BOC Group | boc@boc-group.com 11
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.
© BOC Group | boc@boc-group.com 12
EAM vs. Stadtplanung
Eine Analogie
Stadtplanung EAM
Mak
ro
Mik
ro
Hausbau Softwarearchitektur
© BOC Group | boc@boc-group.com 13
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.
© BOC Group | boc@boc-group.com 14
Business-IT-Alignment
Anforderungen
Unterstützung
Geschäftsarchitektur IT-Architektur
Unternehmensarchitekturmanagement
© BOC Group | boc@boc-group.com 15
Entwicklung von EAM Frameworks
Geschichte
Quelle: Wolfgang Keller, Vorlesung IT Enterprise Architecture, 2012, Hasso Plattner Institut
© BOC Group | boc@boc-group.com 16
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.
© BOC Group | boc@boc-group.com 17
Zachman Enterprise Architecture Framework
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
© BOC Group | boc@boc-group.com 18
Zachman Enterprise Architecture Framework
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
© BOC Group | boc@boc-group.com 19
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
© BOC Group | boc@boc-group.com 21
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
© BOC Group | boc@boc-group.com 22
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
© BOC Group | boc@boc-group.com 23
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
…
© BOC Group | boc@boc-group.com 25
ArchiMate am Beispiel
Quelle: Aktuelle Trends im EAM, Dr. Lutz Kirchner, Scape Consulting
© BOC Group | boc@boc-group.com 26
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
© BOC Group | boc@boc-group.com 27
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.
© BOC Group | boc@boc-group.com 28
Treiber für die Einführung von UAM
Ausschnitt
Ziel
Ausgangssituation
Compliance
Märkte Sourcing
Produkte Merger
Qualität
Konsolidierung
Projekte
© BOC Group | boc@boc-group.com 29
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
© BOC Group | boc@boc-group.com 30
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
…
© BOC Group | boc@boc-group.com 31
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?
© BOC Group | boc@boc-group.com 32
Typische Fragen und Beweggründe betreffend …
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?
© BOC Group | boc@boc-group.com 33
Typische Fragen und Beweggründe betreffend …
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?
© BOC Group | boc@boc-group.com 34
Typische Fragen und Beweggründe betreffend …
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?
© BOC Group | boc@boc-group.com 35
Typische Fragen und Beweggründe betreffend …
Strategischer Einflussfaktoren
Demographischer
Wandel
„Digital
Disruption“
Mitbewerb
Markttrends
Mobile
Mindshift
Business
Demands
© BOC Group | boc@boc-group.com 36
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.
© BOC Group | boc@boc-group.com 37
Ausgewählte Techniken im Architekturmanagement
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.
© BOC Group | boc@boc-group.com 38
Ausgewählte Techniken im Architekturmanagement
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
© BOC Group | boc@boc-group.com 39
Ausgewählte Techniken im Architekturmanagement
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
© BOC Group | boc@boc-group.com 40
Ausgewählte Techniken im Architekturmanagement
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.
© BOC Group | boc@boc-group.com 41
Ausgewählte Techniken im Architekturmanagement
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
…
© BOC Group | boc@boc-group.com 42
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
© BOC Group | boc@boc-group.com 43
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.
© BOC Group | boc@boc-group.com 44
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
© BOC Group | boc@boc-group.com 45
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
© BOC Group | boc@boc-group.com 46
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
© BOC Group | boc@boc-group.com 47
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
© BOC Group | boc@boc-group.com 48
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
© BOC Group | boc@boc-group.com 49
© 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: kai.eckert@boc-de.com
Recommended