Gastvortrag EAM Uni Potsdam

Transcription

Enterprise Architecture Management in der Praxis
Gastvortrag an der Universität Potsdam
Kai Eckert, 18.01.2016
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
© BOC Group | boc@boc-group.com
2
BOC Gruppe - Firmenprofil
Gründung & Struktur



Gründung im Jahr 1995
Spin-off der BPMS-Gruppe der Universität Wien
Heute mehr als 180 Mitarbeiter
3
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
4
BOC Management Office
Customer - Requirements
Management Domains
Software Products
Consulting
Software
Consulting
Education
Training
Standards & Leading Practises
Business Process
Management
ICS and
Risk Management
Enterprise Architecture
Management
5
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
6
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.
7
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
8
Warum benötigt man ein Verständnis von Architektur?
Winchester Mystery House
Quelle: http://stargazermercantile.com/wp-content/uploads/2013/03/winchester-across.png
9
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 ITKomponenten sowie deren Einordnung in die umgebende Organisation und
ihre Umwelt.
• Bestandteile einer IT-Architektur sind Anwendungen, Schnittstellen,
Technologien, Daten, u.v.m.
10
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 ITbezogen.
11
EAM vs. Stadtplanung
Eine Analogie
EAM
Mikro
Makro
Stadtplanung
Hausbau
Softwarearchitektur
12
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.
13
Unternehmensarchitekturmanagement
Business-IT-Alignment
Anforderungen
Unterstützung
Geschäftsarchitektur
IT-Architektur
14
Entwicklung von EAM Frameworks
Geschichte
Quelle: Wolfgang Keller, Vorlesung IT Enterprise Architecture, 2012, Hasso Plattner Institut
15
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.
16
What
How
Where
Who
When
Why
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
17
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
18
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
19
Die Komponenten von TOGAF
20
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
21
TOGAF
Bewertung

TOGAF





Vorteile




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
Umfassend
Methodisch
Hebt die Geschäftssicht bei IT-Projekten hervor (Top-down-Ansatz)
Nachteile


Komplex, dadurch Anpassung an die Organisation herausfordernd
Stark projektorientiert
22
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
…
23
ADOit-Metamodell (basierend auf TOGAF Core Metamodell)
24
ArchiMate am Beispiel
Quelle: Aktuelle Trends im EAM, Dr. Lutz Kirchner, Scape Consulting
25
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
26
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.
27
Treiber für die Einführung von UAM
Ausschnitt
Ziel
Compliance
Konsolidierung
Qualität
Produkte
Märkte
Merger
Sourcing
Projekte
Ausgangssituation
28
Erwarteter Nutzen von Unternehmensarchitekturmanagement

Kostenvorteile durch

Konsolidierung der IT-Infrastruktur


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





Reduktion der fachlichen Redundanzen in der Anwendungslandschaft
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
29
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




Höhere Flexibilität


Risikomanagement
Zertifizierungen
Sonstige gesetzliche Dokumentationspflichten (branchenabhängig)
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
…
30
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?
31
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?
32
des Zielbilds

Wie sieht das
zukünftige
Produktportfolio aus?
ADONIS

Welche Technologien ermöglichen
eine Differenzierung unserer Produkte
und Dienstleistungen am Markt?

Wo befinden sich die Customer Touchpoints
für eine optimierte Kundenbindung?
33
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?
34
Strategischer Einflussfaktoren
Demographischer
Wandel
„Digital
Disruption“
Mitbewerb
Markttrends
Mobile
Mindshift
Business
Demands
35
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.
36
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 ITKomponenten ermitteln zu können.
Ein erster Schritt dazu ist eine Abhängigkeitsanalyse in grafischer Form.
37
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
38
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
39
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.
40
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
…
41
Verantwortliche im Architekturmanagement
Typische Rollen und Gremien

Fachseitig




IT-seitig (Architektur)








Kunde und Nutzer (Customer)
Anforderer (Business Analyst)
Prozessverantwortlicher (Domain Manager)
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
42
Das Architecture Board
Aufgaben und Zusammensetzung

Ein Architecture Board setzt sich meist folgendermaßen zusammen:








Aufgaben des Boards





Leitender Unternehmensarchitekt
Leitender Lösungsarchitekt
Kundenseitiger Vertreter
Vertreter der Anwendungsverantwortlichen
IT-Betrieb
Externe Berater
Externe Dienstleister
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.
43
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





Keine Anwendungen (keine Fachlichkeit)





SAP BI (Operatives Controlling)
ELSTER (Elektronische Steuererklärung)
ELFE (Einheitliches länderübergreifendes Festsetzungsverfahren)
Paisy (Personalmanagement)
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
45
Bewertungskriterien für Anwendungen
Eine Auswahl (1)


Standardsoftware (ja/nein)
Customising-Level


Strategische Bedeutung




Grad der Anpassung von Standardsoftware
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
46
Bewertungskriterien für Anwendungen
Eine Auswahl (2)

Kosten-Fitness, d.h. Kosten im Vergleich zu Anwendungen vergleichbarer
Fachlichkeit



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


CAPEX: Capital Expenditure = Investitionskosten
OPEX: Operational Expenditure = Pflege, Wartung (z.B. Total Cost of Ownership)
Verfügbarkeit, Vertraulichkeit, Integrität u.a.
Integration mit anderen Anwendungen


Enge oder lose Kopplung
Einsatz von dedizierten Integrationstechnologien
47
Agenda
Über die BOC GmbH
EAM Grundlagen
EAM in der Praxis
Diskussion
48
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
© 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.
49

Gastvortrag EAM Uni Potsdam

Transcription

Similar documents

als PDF - Firmextra

Kant: Kritik der reinen Vernunft (1781)

AG-IZ - Identity Management Glossar - E

SAP Application Performance Management mit Compuware APM

Architektur, Methode, Prozess - Ein Business Analysis Framework

LMW05b - sebis

- Ostwürttemberg in Zahlen

Datei öffnen

Oracle Forms Migration Framework

Eisbrecher Nr. 56 - Bundesamt für Informatik und

PDF Broschüre/ Preise

Oberstufenzentren im Berufsfeld - Neue Adresse für Horde: horde

Kompetenzprofil