enterprise architecture management - wi.uni-potsdam.de · hierarchische struktur der ea rollen 3...
Post on 16-Aug-2019
222 Views
Preview:
TRANSCRIPT
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 ngronau@lswi.deWeb 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 Management Frameworks Ausgewählte Frameworks Vergleich von Frameworks
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
Enterprise Architecture Management Frameworks Ausgewählte Frameworks Vergleich von Frameworks
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
Enterprise Architecture Management Frameworks Ausgewählte Frameworks Vergleich von Frameworks
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
Enterprise Architecture Management Frameworks Ausgewählte Frameworks Vergleich von Frameworks
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
Vergleich der Frameworks
Kriterium Zachman TOGAF
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
Quelle: Matthes 2011, S. 217ff
Vergleich der Frameworks
Kriterium Zachman TOGAF
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
Quelle: Matthes 2011, S. 217ff
Vergleich Dirk Matthes
Kriterium Zachman TOGAF
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
Quelle: Matthes 2011, S. 217ff
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
Vergleich Urbaczewski & Mrdalj
Quelle: Urbaczewski, Mrdalj 2006, S. 21
Comparison by Abstractions
Framework What How Where Who When Why
Zachman Data Function Network People Time Motivation
TOGAFDecision-making
guidance
IT resource guidance
Vergleich Urbaczewski & Mrdalj
Quelle: Urbaczewski, Mrdalj 2006, S. 22
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 ngronau@lswi.deWeb 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
top related