EAM Light

Enterprise Architecture Management morgen: Pragmatik gefragt

Daniel Liebhart
©Shutterstock/ Vladitto

Enterprise Architecture Management (EAM) als durchgängiger Ansatz für die vollständige Abbildung einer Anwendungslandschaft ist angesichts der rasanten Entwicklung im Bereich Mobile-Arbeitsplätze und Consumerization für die meisten Unternehmen kaum zu leisten. Welches Architekturparadigma erlaubt jedoch die notwendige Flexibilität bei gleichzeitiger Steuerbarkeit? EAM Light verabschiedet sich von der Vollständigkeit zugunsten eines verständlicheren Gesamtbilds – also EAM „Reduce-To-The-Max“. Die Grundelemente sind die zentralen Geschäftsinformationen, die wichtigsten Geschäftsprozesse und die Hauptsysteme.

Jede IT-Abteilung steht im Grunde immer vor zwei gegenläufigen Aufgabenstellungen: Einerseits sollen stabil laufende Anwendungen immer effizienter und kostengünstiger betrieben, andererseits sämtliche neuen und innovativen Technologien nutzbringend in die bestehende Systemlandschaft integriert werden. Glaubt man den Analysten wie IDC, Gartner oder Forrester, so wird sich in den nächsten Jahren der Druck auf die IT in Unternehmen sogar noch steigern, da Trends wie Big Data [1], Consumerization [2] oder Gamification [3] zu starken Veränderungen der Unternehmens-IT führen werden. Dabei sind die meisten IT-Abteilungen erst heute dabei, bereits in die Jahre gekommene Innovationen wie Cloud Computing oder auch Social Networks als Virtualisierungs- und Kommunikationsplattformen zu integrieren. Und zwar in eine heterogene und historisch gewachsene Systemlandschaft, die zu einem großen Teil aus älteren Systemen besteht. Um die Balance zwischen Effizienzsteigerung, Kosteneinsparungen und Innovationsfähigkeit zu gewährleisten, sind verlässliche Fakten, Weitsicht und kluges Management gefragt.

Enterprise Architecture Management: Fakten, Weitsicht und Management

Grundsätzlich müssen verlässliche Fakten darüber vorliegen, wie viele Anwendungen, Systeme, Server und Datenspeicher im Einsatz sind. Außerdem ist es sinnvoll zu wissen, welche Informationssysteme von wem, wo und wie verwendet werden. Darüber hinaus stellen Fakten über die Arbeitsweise, den Aufbau, die Produkte und die Position in der Wertschöpfungskette eines Unternehmens die Grundvoraussetzungen zur effizienten und kostengünstigen Bereitstellung dar.

Weitsicht bedeutet nichts anderes, als dass jedes Unternehmen eine klare Vorstellung darüber haben sollte, wie es sich in Zukunft positionieren will. Dies betrifft insbesondere die Arbeitsweise, Größe, geographische Ausbreitung sowie die Produkte und Märkte. Weitsicht bildet die Grundlage für jede längerfristige Strategie zur Umsetzung innovativer IT-Technologien.

Kluges Management basiert auf einer Menge aus Prinzipien und Vorgaben, die den Rahmen für eine kontinuierliche Weiterentwicklung der bestehenden Anwendungslandschaft vorgibt. Es sorgt beispielsweise für eine vernünftige ständige Modernisierung der Systemlandschaft und für einen beherrschbaren Technologiemix.

Enterprise Architecture Management (EAM) ist das Mittel jeder größeren IT-Abteilung, wenn es darum geht, Fakten und Weitsicht klug zu managen. EAM schafft Ordnung als Grundvoraussetzung, damit wichtige Fakten überhaupt erst erfasst, verstanden und Weitsicht formuliert werden kann.

Aufmacherbild: modern glass silhouettes of skyscrapers at night von Shutterstock / Urheberrecht: Vladitto

[ header = Seite 2: Enterprise Architecture ]

Enterprise Architecture

Die IEEE beschreibt Architektur in ihrem Software-Engineering-Glossar als „organisierte Struktur eines Systems oder einer Komponente“ [4]. Eine gute Architektur basiert also auf einer Reihe grundlegender Prinzipien, beeinflusst die allgemeinen Eigenschaften eines IT-Systems und erlaubt einen geregelten und kommunizierbaren Entwicklungsprozess. Vor allem ermöglicht sie jedoch, dass Systeme miteinander und nebeneinander existieren können, ohne dass sie sich gegenseitig stören. Die „UML-Päpste“ Booch, Rumbaugh und Jacobson sind sogar noch etwas spezifischer in ihrer Definition des Architekturbegriffs: „Eine Architektur ist eine Menge von signifikanten Entscheidungen über die Organisation eines Softwaresystems, die Auswahl der einzelnen Strukturelemente und deren Schnittstellen sowie deren Verhalten“[5]. Diese Definition gilt jedoch nur für Softwaresysteme – eine Enterprisearchitektur hingegen stellt eine Erweiterung dar und bildet ein Ordnungsraster für das gesamte Unternehmen. Sie hat die Aufgabe, betriebliche Tätigkeiten und alle dafür verwendeten Informationssysteme formal und exakt zu beschreiben. Dazu gehört die Organisation mit sämtlichen Abläufen und Regeln, verwendete Informationen, IT-Systeme, Schnittstellen und andere Aspekte. Es gilt diese so genau zu erfassen, dass sämtliche Ressourcen eines Unternehmens als klare Fakten dargestellt werden können. Dies ist keine einfache Aufgabe, aber es gibt eine Vielzahl bewährter Methoden und Standards zur Darstellung und Weiterentwicklung von Enterprise-Architektur.

EAM Frameworks

Es existieren über zwanzig verschiedene Ansätze, wie Enterprise Architecture Management (EAM) aufzubauen und umzusetzen ist [6]. Allen gemeinsam ist die Tatsache, dass sie mit verschiedenen Sichten auf den Betrachtungsgegenstand arbeiten. Dies hat einen tiefen Grund: Leider ist es nicht möglich, Informationssysteme wie beispielsweise Bauwerke in einem einzigen Plan darzustellen. Im Bauwesen gibt es standardisierte Pläne in 3-D, die jeden einzelnen Aspekt eines Gebäudes darstellen. Spezialisierte Sichten, wie sie etwa für den Einbau der sanitären Anlagen und Leitungen notwendig sind, werden aus dem Gesamtplan extrahiert. Genau das klappt in der IT nicht. Da IT-Systeme sehr viel mehr dynamische Elemente als normale Bauwerke enthalten, sind mehrere Sichten notwendig, um eine IT-Landschaft vollständig darzustellen. Die Anzahl der notwendigen Sichten variiert zwar von Ansatz zu Ansatz, aber es sind immer mindestens drei Stück. Und sie werden auch nicht aus einem Gesamtplan extrahiert – schlimmer noch: Sie sind oft sehr schwer miteinander in Zusammenhang zu bringen.

Tabelle 1: Die dreißig Sichten des Zachmann-Frameworks

Das Zachmann-Framework beispielsweise verwendet nicht weniger als dreißig Sichten, um gemäß Information Systems Architecture (ISA) die Gesamtarchitektur auf Unternehmensebene darzustellen [7]. Die Systemlandschaft einer Unternehmung wird als Ganzes aus zwei Blickwinkeln betrachtet – aus der Perspektive und aus dem Fokus. Die Perspektive beschreibt die Sichtweise der am Systembau beteiligten Personengruppen – also der Planer, des Besitzers, der Gestalter und der Erbauer. Zudem sind detaillierte und operative Perspektiven vorgesehen. Der Fokus versucht, verschiedene Aspekte wie Daten, Funktion, Netzwerk, Personen, Zeit und Motivation eines Systems isoliert zu betrachten. Damit eine gesamte Systemlandschaft im Auge zu behalten, ist eine sehr komplexe Aufgabe. Das Zachmann-Framework aus dem Jahr 1987 gilt allgemein als Geburtsstunde von EAM, obwohl sich diese Ansätze aus den Computer-Integrated-Manufacturing-Standards der Siebzigerjahre entwickelt haben.

 Abb.1: ODP-Vorgehen

Open Distributed Processing (ODP), ein anderer EAM-Ansatz, arbeitet mit fünf verschiedenen Viewpoints: Enterprise, Information, Computational, Engineering und Technology [8]. Der Enterprise Viewpoint beschreibt die Gesamtumgebung des Systems sowie seinen Zweck. Außerdem werden die Anforderungen an das System, zu erfüllende Bedingungen, ausführbare Aktionen und Zielvorgaben aus Unternehmenssicht definiert. Der Information Viewpoint legt die Struktur und Semantik der Systeminformationen fest. Der Computational Viewpoint zerlegt ein System in logische, funktionale Komponenten. Das Ergebnis sind Objekte mit Schnittstellen, an denen sie Dienste anbieten bzw. nutzen. Der Engineering Viewpoint beschreibt die erforderliche Systemunterstützung, um schließlich eine Verteilung der Objekte aus dem Computational Viewpoint zu erlauben. Der Technology Viewpoint beschreibt die Wahl konkreter Technologien zur Implementierung und Realisierung des Systems. Das ODP-Vorgehen, ein ISO/IEC-Referenzmodell aus dem Jahr 1995, ist eine Art ursprüngliches Gesamtraster für die Neuentwicklung eines sehr großen Systems. Viele Abbildungen, die durch ODP vorgesehen worden sind, werden heute als UML-Diagramme realisiert.

Der heute in vielen Unternehmen und zunehmend in staatlichen Verwaltungen eingesetzte Ansatz ist The Open Group Architecture Framework, kurz TOGAF [9]. Es erlaubt eine Beschreibung in mehreren Sichten, wie beispielsweise Geschäftsarchitektur, Informationsarchitektur, Sicherheitsarchitektur und Technologiearchitektur. Die einzelnen Elemente der verschiedenen Sichten werden als Sammlung von Artefakten beschrieben. Mit einer abstrakten Ebene zur Darstellung aus fachlicher Sicht und einer konkreten Ebene zur Darstellung der technischen Umsetzung kann eine gesamte Systemlandschaft als verständliche und zusammenhängende Darstellung dokumentiert werden. Darüber hinaus arbeitet TOGAF mit Granularitätsstufen von der Vision über die Prinzipien über ein technisches Referenzmodell bis hin zu Enterprise-Architecture-Patterns, Software-Design-Patterns, Netzwerkkonzepten und Plattform-Best-Practices. Dahinter steckt ein Entwicklungsmodell, das rund um ein Anforderungsmanagement gruppiert wird. TOGAF sieht zur Erfassung einer Systemlandschaft eine Vielzahl von Darstellungen vor. Die Geschäftsarchitektur, die Architektur der Daten, der Anwendung und der Technologie werden getrennt dargestellt. Außerdem sind Anwendungsfälle, Prozesse, Organisation, Systems Engineering, Sicherheit, Betriebsprozesse und Kosten darzustellen. TOGAF ist mit seinem Zertifizierungsprogramm heute einer der wichtigsten EAM-Standards überhaupt.

[ header = Seite 3: Probleme in der Praxis ]

Probleme in der Praxis

Jeder EAM-Ansatz kämpft heute mit Akzeptanzproblemen. Es ist und bleibt schwierig, ein Unternehmen und seine Tätigkeiten formal so zu erfassen, dass die IT-Systeme und ihre Weiterentwicklung eins zu eins daraus abgeleitet werden können. Einer der Hauptgründe liegt darin, dass Fachabteilungen andere Bedürfnisse nach Formalisierung der Geschäftstätigkeiten haben als die IT. Um die bestmöglichen Hilfsmittel bereitzustellen, müssen IT-Entscheider jedoch wissen, wie genau eine Fachabteilung arbeitet. Das bedeutet nichts anderes als eine formale Erfassung im Rahmen eines EAM. Eine Fachabteilung benötigt diese Formalisierung jedoch nicht für ihre eigentliche Arbeit, da das Personal auf dem entsprechenden Fachgebiet ausgebildet ist und oftmals jahrelange Erfahrung hat. Das führt in der Praxis oft dazu, dass EAM die alleinige Aufgabe der IT bleibt, obwohl wichtige Aspekte des Business Engineerings wie Geschäftsmodelle, Prozesslandkarten und Wertschöpfungsnetze zentrale Bestandteile jeder Unternehmensarchitektur darstellen. Genau diese Elemente können ohne den systematischen Einbezug des Fachbereichs nicht vernünftig erhoben oder gepflegt werden. Zu diesen Schwierigkeiten kommt hinzu, dass die Pflege der einmal erhobenen Artefakte sehr zeitintensiv ist, selbst wenn entsprechende Profitools eingesetzt werden. Alleine aufgrund des Aufwands kommen die oben beschriebenen Ansätze lediglich für größere Unternehmen in Frage.

EAM Light?

Dennoch bleibt die Aufgabe, eine IT bereitzustellen, die effizient, kostengünstig und gleichzeitig innovativ ist. Relevante Informationen müssen deshalb so aufbereitet werden, dass Verantwortliche businessrelevante Entscheidungen vernünftig fällen können. Diese Aufgabe stellt sich nicht nur für große Unternehmen, sondern für jede Firma, deren Funktionieren direkt von IT-Systemen abhängig ist. Entscheidungsrelevante Fragestellungen und ihre möglichen Antwortvarianten sind meist auf eine Gesamtsicht angewiesen, um Tragweite und Spielraum überhaupt abschätzen zu können. Gefragt wäre ein Ansatz, der als Managementanweisungen die minimale Anzahl der Sichtweisen erlauben würde, die für ein Verständnis der Faktenlage als Istzustand, der zukünftig notwendigen Anwendungslandschaft als Sollarchitektur und möglicher Umsetzungsszenarien nötig sind. Eine Art „Lean Enterprise Architecture Management“ oder auch ein EAM Light.

Abb.2: Grundelemente des EAM Light

Die Grundelemente eines EAM Light sind die zentralen Geschäftsinformationen, die wichtigsten Geschäftsprozesse und die zentralen Anwendungen – also genau drei Sichten. Die Erfassung der Fakten ist dadurch mit endlichem Aufwand zu leisten. Zentral ist nicht die Vollständigkeit sämtlicher Artefakte, sondern die Zusammenstellung der wichtigsten Elemente. Dies kann oftmals auf Basis von Interviews mit den wichtigsten Stakeholdern in einem Unternehmen erfolgen. Ebenfalls wichtig ist die Verständlichkeit der Darstellung, denn ein formal korrektes Entity Relationship Model (ERD) hilft einem Entscheidungsträger oftmals nur wenig, wenn es um die Beurteilung der Verwendung und der Relevanz von Unternehmensinformationen geht. Für ihn ist es viel wichtiger zu wissen, welches Informationsobjekt von welcher Anwendung verwendet wird und welchen Weg Informationen durch Unternehmen und Anwendungen nehmen. Auch hilft ein vollständiges Klassendiagramm aller unternehmensweit verwendeten Objekte selten beim Abwägen, welcher Geschäftsbereich wie gut von Informationssystemen unterstützt wird und werden sollte. EAM Light bedeutet Pragmatik – ein bewusstes Weglassen überflüssiger Details zugunsten einer entscheidungsrelevanten Gesamtsicht.

[ header = Seite 4: Die zentralen Geschäftsinformationen ]

Basis 1: Die zentralen Geschäftsinformationen

Eine Basis von EAM Light sind die Geschäftsinformationen, die von jedem Unternehmen verwendet werden – relevant sind typischerweise zwischen 12 und 15 logische Entitäten. Es ist zwar sehr wahrscheinlich, aber keineswegs bewiesen, dass diese Entitäten für eine bestimmte Branche immer dieselben sind. Beispielsweise sind für Finanzdienstleister die Institution, das Instrument, der Kunde, das Konto, der Kredit als Entitäten relevant, während für ein Handelsunternehmen der Kunde, das Produkt, das Angebot, die Faktura oder der Partner wichtig sind. Für die Immobilienbranche stehen die Anlage, das Gebäude/Grundstück, der Vertrag oder der Kredit im Fokus, während für Energieversorger die Ressource, der Abnehmer, die Zeitreihe oder die Kapazität relevant ist. Für EAM Light sind die Auflistung und die Definition der zentralen logischen Entitäten aus Businesssicht relevant, wobei der Aufwand für die Abstimmung der genauen Definition nicht zu unterschätzen ist, da bestimmte Entitäten in unterschiedlichen Abteilungen anders verstanden werden können.

Basis 2: Die wichtigsten Geschäftsprozesse

Der zweite grundlegende Aspekt für EAM Light ist die Erfassung der Geschäftsprozesse auf oberster und auf zweitoberster Ebene. Dabei muss unbedingt zwischen wertschöpfenden Leistungsprozessen, Führungsprozessen und unterstützenden Prozessen unterschieden werden. Deren Erfassung erfolgt idealerweise durch eine Gruppierung in Leistungsgruppen wie beispielsweise Verkauf, Produktion, Produktentwicklung, Führung und Support. Die ersten drei sind wertschöpfende Leistungsprozesse, deren Erfassung so verständlich sein muss, dass sich sämtliche Mitarbeitende eines Unternehmens problemlos in der Prozesslandkarte wiederfinden können. Es soll also ganz bewusst auf unnötige Details verzichtet werden. Eine einfache Darstellung der Abläufe auf oberster und zweitoberster Ebene und eine verständliche Beschreibung der einzelnen Prozesse ist in vielen Fällen vollkommen ausreichend.

Basis 3: Die Hauptsysteme

Das dritte Basiselement von EAM Light sind die bestehenden und die in Zukunft vorgesehenen Anwendungen. Dabei ist eine einfache Zuordnung der gesamten Anwendungslandschaft beispielsweise in Haupt- und Hilfssysteme für einen bestimmten Geschäftszweig und in externe und interne Systeme hilfreich. Es ist eine logische Systemlandschaft zu entwerfen, die eine Darstellung sämtlicher Anwendungen auf einen Blick erlaubt. Das Ordnungskriterium für die Darstellung ist dabei der Sichtweise des jeweiligen Unternehmens anzupassen. Für eine Verwaltung ist beispielsweise eine Abgrenzung zwischen Kernsystemen und Hilfssystemen pro amtlicher Tätigkeit sowie zwischen Schnittstellen und externen Systemen sinnvoll. Handelt es sich bei der Organisation um eine Bank, muss zwischen Backend-Systemen, Backend-Integration sowie dezentralen Systemen, Fach-, Backoffice- und Client-Self-Service-Anwendungen unterschieden werden.

[ header = Seite 5: Erkenntnisse durch Gegenüberstellungen ]

Erkenntnisse durch Gegenüberstellungen

Sind nun die Anwendungen, Prozesse und logischen Informationsobjekte als Basis eines EAM Light erfasst, so werden sofort Zusammenhänge klar, die durch andere Ansätze erst durch längere Vorarbeiten einem eingeschränkten Expertenkreis zugänglich wären. Im nächsten Schritt werden die drei Grundelemente einander gegenübergestellt und damit Schnittstellen und Abhängigkeiten sichtbar gemacht.

Beispielsweise stellt man Anwendungen und logische Informationsobjekte gegenüber, um aufzuzeigen, welche Anwendung welche Operation auf den Informationsobjekten ausführt. Dabei wird zwischen den Operationen Create (C), Read (R), Update (U) und Delete (D) unterschieden. Wenn eine bestimmte Istanwendung durch andere oder anders strukturierte Sollanwendungen verändert oder gar abgelöst werden soll, so wird durch die Gegenüberstellung sichtbar, welche Informationsobjekte betroffen sind und welche Schnittstellen mit größter Wahrscheinlichkeit anzupassen sind.

Oder man stellt Prozesse und Anwendungen gegenüber, um aufzuzeigen, welche Prozesse durch welche Systeme wie unterstützt werden. Es wird typischerweise zwischen Kernsystem und Hilfssystem unterschieden. Ersteres wird hauptsächlich für die Unterstützung des entsprechenden Prozesses verwendet. Ohne Kernsystem kann ein Prozess nicht oder nur sehr schwierig abgewickelt werden. Ein Hilfssystem dient zur Unterstützung des Prozesses, sein Ausfall ist jedoch nicht kritisch für dessen Abwicklung. Wenn eine bestimmte Istanwendung durch andere oder anders strukturierte Sollanwendungen verändert oder gar abgelöst werden soll, so wird durch die nachfolgende Darstellung klar ersichtlich, welche Prozesse betroffen sind.

[ header = Seite 6: Fazit ]

Fazit

EAM Light reduziert die gängigen EAM-Ansätze auf ein Gesamtbild, das für sämtliche Stakeholder im Unternehmen verständlich wird. Als Grundelemente werden die zentralen Geschäftsinformationen, die wichtigsten Prozesse und die Anwendungen eingesetzt. Durch Gegenüberstellung und einfache Darstellung werden mögliche Optionen sichtbar und Entscheidungen sowie deren Konsequenzen transparent. Das erleichtert die Bereitstellung innovativer und gleichzeitig effizienter und kostengünstiger Anwendungslandschaften enorm. Eine solche Erleichterung ist unabdingbar, wenn Unternehmen dem klassischen „Softwarewildwuchs“ Einhalt gebieten und ihre Anwendungslandschaften nachhaltig weiterentwickeln wollen. 

Links & Literatur

[1] Laney, D.: „The Birth of Infonomics, the New Economics of Information“, Gartner, October 2012; Gantz, J., Reinsel, D.; Arend, C.: „The Digital Universe in 2020: Big Data, Bigger Digital Shadows, and Biggest Growth in the Far East –Western Europe“, IDC February 2013

[2] Forrester Consulting: „Key Strategies To Capture And Measure The Value Of Consumerization Of IT“, May 2012; Prete, C. D.; Levitas, D.; Grieser, T.; Turner, M. J.; Pucciarelli, J.; Hudson, S.: „IT Consumers Transform the Enterprise: Are You Ready? “, IDC, September 2013 (Republished)

[3] Fauscette, M.: „Enterprise Gamification: Creating a Leader’s Edge – Industry Development and Models“, IDC Jun 2013; Wise, J.: „Gamification: ‘Level Up’ Your Strategic Approach“, Forrester Report, May 2013

[4] IEEE Std 610.12-1990 (R2002), IEEE Standard Glossary of Software Engineering Terminology, IEEE 2002

[5] Booch, G.; Rumbaugh, J.; Jacobson,I.: „The Unified Modeling Language User Guide“, Addison-Wesley Professional, 2005

[6] Schönherr, M.: „EnterpriseArchitecture Frameworks“, in:EnterpriseApplication

Integration – Serviceorientierung und nachhaltige Architekturen, Reihe: Enterprise Architecture, Band 2, Technische Universität Berlin, 2004

[7] Zachmann, J. A.: „A Framework for Information Systems Architecture“, IBM Systems Journal, vol. 26, no. 3, 1987

[8] ITU-T: Reference Model for Open Distributed Processing Part 1–Part 4 ITU-T X.901/ISO 10746-1, May 1995

[9] Hornford, D.; Paider, T.; Forde, Ch.; Josey, A.; Doherty, G.; Fox, C.: „TOGAF Version 9.1“, The Open Group, 2011

Geschrieben von
Daniel Liebhart
Daniel Liebhart
Daniel Liebhart ist Dozent für Informatik an der Züricher Hochschule für Angewandte Wissenschaften (ZHAW) und Solution Manager der Trivadis AG. Er ist Autor des Buchs „SOA goes real“ (Hanser Verlag) und Koautor verschiedener Fachbücher.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: