enterprise architecture management - wi.uni-potsdam.de · hierarchische struktur der ea rollen 3...

Univ.-Prof. Dr.–Ing. habil. Norbert Gronau Lehrstuhlinhaber | Chairholder

August-Bebel-Str. 89 | 14482 Potsdam | Germany

Tel +49 331 977 3322Fax +49 331 977 3406

E-Mail [email protected] lswi.de

Lehrstuhl für Wirtschaftsinformatik Prozesse und SystemeUniversität Potsdam

Chair of Business Informatics Processes and SystemsUniversity of Potsdam

Enterprise Architecture Management Architekturen betrieblicher Anwendungssysteme

Enterprise Architecture Management Frameworks Ausgewählte Frameworks Vergleich von Frameworks

Quelle: BItkom 2011, Fachmann 1997

“Die Anforderung an die Unternehmens-IT lautet, die Komplexität des wirtschaftlichen Handelns widerzuspiegeln sowie die laufenden Veränderungen und Herausforderungen des Marktes zu berücksichtigen.”

Prof. August-Wilhelm Scheer, Präsident BITKOM

Enterprise Architectures zu beherrschen ist „[...] the determining factor, the factor that separates the winners from the losers […].“

John Zachman


Enterprise Architecture Definitionen

Quelle: BItkom 2011, Matthes 2011, S. 11

Enterprise Architecture bezeichnet „die der Gestaltung von Geschäftsprozessen und IT-Infrastruktur zugrunde liegende Logik, welche die Integrations- und Standardisierungsanforderungen an die Leistungsinfrastruktur des Unternehmens reektiert.“

Bitkom 2011

“An Enterprise Architecture (EA) is a set of business and engineering artifacts, including text and graphical documentation, that describes and guides the operation of an enterprise-wide system, including instructions for its life cycle operation, management, evolution, and maintenance. [...]”

Matthes 2011

Enterprise Architecture besteht aus 2 Komponenten

Bestandteile der Enterprise Architecture

Beschreibung des Zusammenspiels von Business (Prozessen) und IT im Unternehmen.

Vermittlerrolle und Unterstützer der Unternehmensziele

Business/ Prozesse ITEA

Quelle: BItkom 2011, S. 6

Vorteile Enterprise Architecture (1/2)

Quelle: nach Shah, Kourdi 2007, S. 37

EAM hilft ebenso dabei die Basis für SOA zu schaffen und verschiedene Geschäftsbereiche zu vernetzen. Somit stehen die einzelnen Vorteile nicht nur allein, sondern bedingen sich gegenseitig.

Vorteile für die IT Beschreibung

Komplexitätsmanagement Vereinfachung der Aufwandseinschätzung und Koordination von Projekten

Beaufsichtigung technischer Ressourcen Identifizierung und Vermeidung von Redundanzen

WissensmanagementManagement und Verbreitung von Wissen in Modulform zur Nutzung

auf allen Ebenen

IT VisibilityIT-Ressourcen und -Systeme sind besser an der Geschäftsstrategie

ausgerichtet und anpassungsfähig

Vorteile Enterprise Architecture (2/2)

EAM hilft ebenso dabei die Basis für SOA zu schaffen und verschiedene Geschäftsbereiche zu vernetzen. Somit stehen die einzelnen Vorteile nicht nur allein, sondern bedingen sich gegenseitig.

Vorteile fürden Betrieb Beschreibung

Reduzierung der Auswirkung von Mitarbeiterfluktuation

Erfassen des Wissens von Mitarbeitern und Beratern. Zur Verfügungsteilung von Geschäftslösungen durch

Drittorganisationen….

Schnellere Anpassungsfähigkeit

Ermöglicht die notwendige Wissensgenerierung für sich verändernde Systeme und das Hinzunehmen neuer Komponenten

operative Prozess Verbesserung

Versteht und moderiert Geschäftsprozesse. Überdenkt und passt Prozesse an.

EntscheidungsfindungAufgrund der Darstellung der Unternehmensschichten und -komponenten können Geschäfts-entscheidungen holistisch

getroffen werden

Quelle: nach Shah, Kourdi 2007, S. 37

Perspektive 2Organisationsstruktur

Perspektive 1EA Framework

Probleme und Herausforderungen

Nicht reaktiv zu Änderungen der Geschäftsstrategie Nachvollziehbarkeit

Eine sind nicht objektorientiert, Darstellung (UML) schwer Zu viele EAs und Theorien zur Auswahl Maintenance der EA wird oft nicht behandelt

Sicherstellung der Betrachtung versch. Perspektiven Sicherstellung der Konsolidierung versah. Stakeholder ist nicht immer gewährleistet

Vielen Modellen fehlen Bewertungsmethoden zur Sicherstellung der Unternehmensziele Schichtmodell für Große Unternehmen oft nicht ausreichend

Quelle: Vgl. Shah, Kourdi 2007, S. 40

Elemente des EAMGrundlegendes

EAM - Enterprise Architecture Management

Quelle: Vgl. Bitkom 2011, S. 25, Bucks et al 2007, S. 1

EAM dient als Modell zur Planung und Umsetzung von Geschäftsstrategien in wertschöpfende Infrastrukturen EAM Ausgestaltung wird von der Unternehmensstrategie geprägt

Ein standardisiertes Vorgehen Eine unternehmens- bzw. bereichsweit gemeinsame Sprache/Modell

eine definierte Organisationsstruktur mit Prozessen ein passendes Governance-Modell

EA management can be defined as "a continuous, iterative (and self maintaining) process seeking to improve the alignment of business and IT in an (virtual) enterprise.

Bucks et al 2007


Ausgewählte Definitionen zu Frameworks

Quelle: Chief Information Officers Council 1999, S. 6; U.S. Department of Defence 2007, S.1; Goikoetxea 2006, S. 3; Van Haren 2007, S. 5

Chief Information Officers Council 1999 “Framework is a logical structure for classifying and organizing complex information”

U.S. Department of Defence A framework “provides the guidance and rules for developing, representing, and understanding architectures.”

The Open Group: A Framework “is a tool which can be used for developing a broad range of different architectures. It describes a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It contains a set of tools and provides a common vocabulary. It also includes a list of recommended standards and compliant products that can be used to implement the building blocks.”

Die Grundabsichten eines (EA-) Rahmenwerkes sind es eine Strukturierung der Informationslandschaft vorzunehmen und die Komplexität zu reduzieren

Zusammenfassung der Definitionen

Quelle: Vgl. Matthes 2011, S. 17

Die Definition des Begriffes Rahmenwerk ist nicht eindeutig Oft erfolgt die Definition eines Rahmenwerkes in der Konzeptbeschreibung des Rahmenwerkes selbst

Es lassen sich jedoch bei genauer Analyse Übereinstimmungen feststellen Theoretisch definiert sich ein Rahmenwerk über seinen Modellcharakter

Rahmenwerke stellen Methodiken und Werkzeuge bereit die fortwährende Architekturentwicklung unterstützen Für Analyse, Entwurf, Implementierung und kontinuierliches Change Management

InhaltlichZeitlich

Frameworks Entwicklung

Quelle: Vgl. Shah, Kurdi 2007, S. 17ff

Ausgewählte Frameworks

Eng Verbunden mit Bedeutung der EA Frameworkkonzept seit Mitte 1980er Jahre

Vorreiter Zachman Danach kontinuierliche Weiterentwicklung für versah. Zielgruppen und Institutionen

Erkenntnis der systematischen Aufbereitung von Informationswegen Einführung von unterschiedlichen Perspektiven

Einige Frameworks nicht entwickelt, sondern Entstehung aufgrund praktischer Anwendung

Zachman, 1987

TOGAF, 1995 Gartner, 2005

Federal Enterprise Architecture (FEA), 2006

Diese Rollen variieren von Unternehmen zu Unternehmen nicht nur in der Bezeichnung, sondern auch in der Ausführung. Einzelnen Rollen können in großen Unternehmen auch von Komitees oder Gruppen ausgeführt werden.

Hierarchische Struktur der EA Rollen

3 Ebenen Struktur Strategisch, High Level Business/ IT, Application Scope Für jede ebene gibt es eigene IS Entwicklungstools

System Architect

Enterprise Infrastructure

ArchitectInfrastructure

Architect

Enterprise Business Architect

Enterprise IT

Architect

ChiefEnterprise Architect

Operation3rd Level

2nd Level

Quelle: Vgl. Shah, Kurdi 2007, S. 38-39

Strukturierung und Schichten (3 architectural layers)

Quelle: Vgl. Shah, Kurdi 2007, S. 38

Durch die hierarchischen Schichten bietet die EA-Frameworks einen holistischen Blick auf die Unternehmensarchitektur. Dafür müssen die 3 Schichten jedoch aufeinander abgestimmt sein.

Technology infrastructure Layer: umfasst die benötigte Hardware und Kommunikations- infrastruktur, die die Applikationen unterstützen

Application Layer: bestimmt die Datenelemente und Software Applikationen

Business Layer: beschreibt die Geschäftseinheiten

sowie Geschäftsprozesse und relevante Informationen

Verhaltensaspekte Informative Aspekte

Jede Schicht besteht jedoch aus verschieden Bereichen/ Domänen, die die informations, Verhaltens und strukturellen Aspekte wider spiegeln.

Strukturelle Aspekte

Eigenschaften von Schichten/ Aspekte

Quelle: Vgl. Shah, Kurdi 2007, S. 38

Strukturelle Aspekte unterteilen die verschiedenen Einheiten eines Unternehmens ins Subeinheiten

Die Verhaltensaspekte zeigen das verhalten, welches sich durch manifestierte Aktivitäten und Prozesse äußert, um die benötigten Services zu produzieren

Diese verschiedenen Einheiten können ggf. Informationen austauschen, um bestimmte Geschäftstätigkeiten auszuführen

Modellcharakter 2Verkürzungsmerkmal

Modellcharakter 3Pragmatisches Merkmal

Eine theoretische Definition eines Rahmenwerkes findet über seinen Modellcharakter

Modellcharakter 1Abbildungsmerkmal

Modellcharakter

Quelle: Vgl. Matthes 2011, S. 18

RM = abstrakte Abbildung des Originals

bei EA ist das Original das IT-System

Hervorhebung wichtiger Aspekte vs. Vernachlässigen umrelevanter Informationen

Umsetzung in Rahmenwerken durch bestimmte Sichtweisen, oder Views

Welches Problem wird durch das Rahmenwerk gelöst?

Für wen ist das Rahmenwerk?/Wer ist der Nutzer des Rahmenwerkes? Was ist der Zweck des Rahmenwerkes?

Ein Modell ist ein System, „welches durch eine zweckorientierte, abstrakte Abbildung eines anderen Systems entstanden ist.“

[KHFG02, S. 32]

Enterprise Architecture Frameworks play dual roles: Framework für Unternehmensarchitektur haben zwei Hauptaufgaben: 1. sie dienen als Instrumente der Dokumentation und Komponentenspezifikation 2. sie erleichtern die Unternehmensplanung und das Lösen von Problemen

Elemente/ Bausteine

Quelle: Shah, Kurdi 2007, S. 37

EA Frameworks beschreiben eine Methode, um Informationssysteme zu designen. Die Beschreibung

geschieht durch “Bausteine” und erläutert ebenfalls, wie diese zusammenpassen.

Empfehlung von

StandardsVerwendung von

zusammenspielenden Produkten

einheitliche Terminologie

Verwendung generischer Konzepte

und somit Unabhängigkeit der

verwendeten Sprache

im speziellen Interesse

Interesse des Informationsmanagers

im allgemeinen Interesse

Frameworks Merkmale Systematisierung und Gruppierung

Quelle : Vgl. Mattes 2011, S. 19-36

im Interesse der Umsetzung

Name des Rahmenwerkes Entwickler des Rahmenwerkes

Sprache der Rahmenwerksbeschreibung Nationalität

Nutzen Historie,Versionsverlauf & Vererbung Literatur

Marktanteil

Art des Rahmenwerkes (konzeptuelle und operationelle) Orientierung

Metamodell Stakeholder & treibende Kräfte IT-Planung

Zertifizierung

Abbildung der Geschäftsprozesse

Art der Komplexitätsreduktion (Sichtweisen, Ebenentrennung, Ebenenbeziehung) Berücksichtigung von Anwendungssystemen

Berücksichtigung physischer IS-Komponenten

Verfügbarkeit Anschaffungskosten

Methodik Referenzmodelle vorhanden Unterstützende Tools

Supportquellen

Frameworks Tooleinteilung

Quelle: Shah, Kurdi 2007, S. 38

Enterprise Architecture Frameworks

Komponenten-Spezifizierungstool

Planungs- und Problemlösungstool

Architektur Modelle

Architektur Schichten

Architektur Artefakt

Architektur Domains

Basis Architektur

Ziel Architektur

Architektur Roadmap

Transition Plan

Vendor-Specific Frameworks

MiscellaneousFrameworks

Government and Authoritative Frameworks

Frameworks Zielgruppe eines Rahmenwerkes nach FEURER 2007

Quelle : Vgl. Matthes 2011, S. 39f; Euerer 2007, S. 4

Erweiterung der Grundidee von Feurer

öffentl. Einrichtungen Militär

ursprünglich wurden diese geschaffen zur Entwicklung einer Standardarchitektur

entwickelt von (Software-)Herstellern Widerspiegelung von Unternehmenserfahrung

Vorgehensmodelle oder Standardansätze

alle anderen Frameworks

bspw. für Aufgaben aus der Industrie

Government and Agency Frameworks

Management Frameworks Military Frameworks Manufacturing-Specific Frameworks

Technically oriented Frameworks Interoperability Frameworks

Add-On Frameworks Stichpunkt 2 Stichpunkt 3

NachteileVorteile

FrameworksPro und Contra

Unterstützung definierter Ziele

Komplexität beherrschen Flexibilität und Versagilität Entscheidungshilfe leisten

Standardisierung gewährleisten Integration unterstützen Interoperability

Ganzheitlichkeit Strukturierung

Datenmanagement unterstützen Geschäftsprozesse mit der IT-Infrastruktur verbinden Geschäftsprozesse optimieren

Sicherheit erhöhen Unterstützung bei der Mitarbeiterausbildung

Investitionsaufwand Treibende Kräfte erforderlich

Erfolgsfaktor: Erfahrung

Quelle: Shah, Kurdi 2007, S. 21ff


Zachman – 1987, erstes EA Framework, sehr komplex aber gut geeignet, um einen begrifflichen Ordnungsrahmen zu erstellen.

ausgewählte Frameworks Zachman

Quelle: eigene Darstellung nach Sowa, Fachmann 1992, S. 602 (Zitat S. 590), vgl. Matthes 2011, S. 13

Software Architecture: Software Engineering System Architecture: System Engineering EA: System of Systems/ Enterprise Engineering

“If the computer is to do anything useful, the concrete things in the world must be related to the abstract bits in the computer. Z a c h m a n ’ s f r a m e w o r k f o r information systems architecture (ISA) makes that link.”

SOWA92, S. 590

ausgewählte Frameworks TOGAF

Quelle: TOGAF 2016, S.21-22; Matthes 2011, S. 188ff

The Open Group Architecture19

kein theoretisches Modell, sondern Best Practice aus über 300 Unternehmen

TOGAF wird kontinuierlich weiterentwickelt Version 1, 1995 Version 9.1, 2011

Tabelle: 7 Hauptteile TOGAF

Part Description

I:Einleitung High Level Einleitung zu EA und TOGAF Ansatz

II: Architecture Development

Method (ADM)

Dies ist das Herzstück von TOGAF zur Entw. einer EA: 9 Phasen

III: Architecture Content Framework Metamodel für Architekturartefakte

IV:ADM Guidlines & Techniques

Zusammenstellung von Guidlines und Techniken zur Entw. ADM

V: Enterprise Continum & Tools

Tools zum Kategorisieren und Speichern der Ergebnisse einer EA

VI: TOGAF Reference Model 2 Referenzmodelle: TRM & III-RM

VII:Architecture Capability

Framework

Diskussion der Organisation, Prozessen, usw. zur Entw. einer EA

Die Architecture Development Method (ADM) ist das Herzstück von TOGAF.

Architecture Development Method

ausgewählte Frameworks TOGAF ADM

Quelle: TOGAF 2016; Shah, Kurdi 2007, S. 188ff

Phase A-D: Definieren Zielarchitektur Phase E-F: Identifizierung von Umsetzungsmöglichkeiten

Phase G: Implementation Phase H: Change Management

G. Implemen-

tation Governance

C.Information

Systems Architecture

E.Opportunities

& Solutions Architecture

A.Architecture

Vision

H. Architecture

Change Management

F.Migration

Architecture

B.Business

Architecture

D.Technology Architecture

H. Architecture Change

Management

Primel. Framework &

Principles

Frameworks TOGAF Enterprise Continuum

Quelle: Vgl. Matthes 2011, S. 195f

Enterprise Continuum

Architecture Continuum

Solutions Continuum

Architecture Context and Requirements

Displayed Solutions

Generic Architecture

Specific Architecture

Adaption for use

Generalisation for future

Generic Solutions

Specific Solutions

Adaption for use

Generalisation for future


Vergleich der Frameworks

Kriterium Zachman TOGAF

Klasse des Rahmenwerks Management Framework Management Framework

Art konzeptuell operationell

Orientierung Gesamtarchitektur Gesamtarchitektur

Jahr der aktuellen Version 1992 2011

Sprache Englisch Englisch

Verfügbarkeit Ja Ja

Kosten 0 bis >0 0 bis >0

Quelle: Matthes 2011, S. 217ff



Dokumentationsumfang (A4-Seiten) 27 - 500 787

Zertifizierungen Ja erfüllt ISO/IEC 42010

Stakeholder- berücksichtigung Nein Ja

Abbildung der Geschäftsprozesse Ja Ja

Berücksichtigung von Entitäten Ja Ja

Anzahl an Sichtweisen 6 1

Anzahl der berücksichtigten Ebenen 6 >3




Ebenenbeziehung Ja Ja

Berücksichtigung rechnerbasierter

AnwendungssystemeJa Ja

Berücksichtigung konventioneller

AnwendungssystemeJa Ja

Kommunikations- beziehungen zw.

Anwendungssystemen Ja Ja

Berücksichtigung rechnerbasierter IS-

Komponenten Ja Nein

Berücksichtigung konventioneller IS-

Komponenten Nein Nein


Vergleich Dirk Matthes


Berücksichtigung des Menschen als IS-

Komponente zur DV Ja Nein

Vorgehens- Referenzmodell vorhanden Nein Ja

Architektur- Referenzmodell vorhanden Ja Ja

Tool(s) verfügbar

Casewise Corporate Modeler, EA Webmodeler,

Enterprise Framework, Mèga, Metis Product Family,

Provision Modeling Suite, Select Enterprise, System

Architect Family

Avolution ABACUS, Casewise Corporate

Modeler, Flashmap Systems IT atlas, Future Tech

Systems, Inc. Envision® VIP, ARIS IT Architect, Inspired

Archi, Telelogic System Architect, Troux Metaverse

Support verfügbar Ja Ja


Vergleich Urbaczewski & Mrdalj

Quelle: Urbaczewski, Mrdalj 2006, S. 20

Comparison by Views/Perspectives

Framework Planner Owner Designer Builder Subcontractor User

Zachman Scope Business Model

System Model

Technology Model

Detailes Representations

Functioning System

TOGAFBusiness Architecture View

Technical Architecture Views



Comparison by Abstractions

Framework What How Where Who When Why

Zachman Data Function Network People Time Motivation

TOGAFDecision-making

guidance

IT resource guidance



Comparison by SDLC Phases

Framework Planning Analysis Design Implementation Maintenance

Zachman yes yes yes yes no

TOGAF

principles that support decision making across enterprise; provide guidance of IT resources; support architecture principles for design and implementation

Literatur

BITKOM (2011): Enterprise Architecture Management – neue Disziplin für die ganzheitliche Unternehmensentwicklung, www.bitkom.org, 2011, zuletzt zugegriffen am 31.05.2016.

Buckl, S.; Matthes, F,; Schweda, C. (2010): Future Research Topics in Enterprise Architecture Management – A Knowledge Management Perspective, Journal of Enterprise Architecture, August 2010.

[DoDAF07] U.S. Department of Defence (2007): DoD Architecture Framework Version 1.5 - Volume 1 Definitions and Guidelines. Veröffentlichung vom 23. April 2007.

[FEAF99] Chief Information Officers Council (1999): Federal Enterprise Architecture Framework Version 1.1.

[F07] Feuerer, S. (2007): Enterprise Architecture - An Overview. SAP Deutschland AG & Co. KG., 2007.

GAO03 United States General Accounting Office (April 2003): Executive Guide. INFORMATION TECHNOLOGY. A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1). Paper Number GAO-03-584G.

[GO07] Goikoetxea, A. (2006): Enterprise Architectures and Digital Administration: Planning, Design and Assessment. World Scientific

[GOUT et al. 2006] F. Gout, F.; Robinson, P. (2006): XAF: A Minimalist EA Framework for an Agile Environment. Cutter IT Journal, Vol 19, No 3, March 2006.

[IDS08] IDS Scheer AG (2008): ARIS 7.1 Methodenhandbuch. Saarbrücken, Dezember 2008.

[KHFG02] Krallmann, H.; Frank, H.; Gronau, N. (2002): Systemanalyse im Unternehmen: Vorgehensmodelle, Modellierungsverfahren und Gestaltungsoptionen. Oldenbourg Wissenschaftsverlag. München, 2002.

[MA05] Masak, D. (2005): Moderne Enterprise Architectures. Springer Verlag, Berlin, 2005.

[MA08] Malich, S.(2008): Qualität von Softwaresystemen: Ein Patternbasiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen. Gabler Verlag, Wiesbaden, 2008.

[M08] Minoli, D. (2008): Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. CRC Press, 2008.

Literatur

[M11] Matthes, D. (2011): Enterprise Architecture Frameworks Kompendium, Springer-Verlag Berlin Heidelberg, 2011.

[N05] Niemann, K. (2005): Von der Unternehmensarchitektur zur IT- Governance. Vieweg-Verlag, Wiesbaden. 2005.

[SK07] Shah, H.; El Kourdi, M. (2007): Frameworks for Enterprise Architecture, IEEE, 1520-9202/07/, September/ October 2007.

[SCH05] Schekkerman, J. (2005): Trends in Enterprise Architecture 2005. Veröffentlicht vom Institute For Enterprise Architecture Developments (IFEAD) unter www.enterprise-architecture.info, 2005.

[SOWA92] Sowa, J.; Zachman, J. (1992): Extending and formalizing the framework for information systems architecture. IBM Systems Journal VOL 31, No 3 S. 590 - 616, 1992.

[SPEWAK93] Spewak, S.; Hill, S. (1993): Enterprise Architecture Planning - Developing a Blueprint for Data, Applications, and Technology. ISBN 0-471-59985-9, 1993.

[UM06] Urbaczewski, L.; Mrdalj, S. (2006): A Comparison of Enterprise Architecture Frameworks, Eastern Michigan University, Volume VII, No. 2, 2006 Issues in Information Systems, 2006.

VH07 Van Haren (2007): TOGAF 2007 Edition: (Incorporating 8.1.1). Van Haren Publishing. LJ Zaltbommel, 2007

TOGAF: TOGAF® VERSION 9.1 – A POCKET GUIDE, Van Haren Publishing, zuletzt zugegriffen Juni 2016.

[Z78] Zachman, J. (1987): A framework for information systems architecture. IBM Systems Journal VOL 26, No 3 S. 276 - 292, 1987.

[Z97] Zachman, J. (1997): Enterprise Architecture: The Issue of the Century - Artikel im Magazin Database Programming and Design. Miller Freeman, Publisher 415-905-2552, 1997

Univ.-Prof. Dr.–Ing. habil. Norbert Gronau Lehrstuhlinhaber | Chairholder

August-Bebel-Str. 89 | 14482 Potsdam | Germany

Tel +49 331 977 3322Fax +49 331 977 3406

E-Mail [email protected] lswi.de

Lehrstuhl für Wirtschaftsinformatik Prozesse und SystemeUniversität Potsdam

Chair of Business Informatics Processes and SystemsUniversity of Potsdam

Enterprise Architecture Management Architekturen betrieblicher Anwendungssysteme

enterprise architecture management - wi.uni-potsdam.de · hierarchische struktur der ea rollen 3...

Documents