Enterprise Architecture Management

BIC Enterprise Architecture Management ist ein separates Modul und eine eigene Lizenz.

Was ist Enterprise Architecture Management?

Enterprise Architektur Management (EAM) ist ein strategischer Ansatz zur nachhaltigen Gestaltung, Steuerung und Weiterentwicklung der IT-Landschaft eines Unternehmens oder einer Behörde. Wesentlich ist, dass eine gute Enterprise Architektur mehr betrachtet als „nur“ die Informationstechnologie. Vielmehr liefert sie einen ganzheitlichen Blick auf die strategischen, operativen und (informations-)technologischen Zusammenhänge einer Organisation. Grundsätzlich werden dabei die folgenden Architekturbereiche unterschieden, welche zusammen eine strukturierte und ganzheitliche Sicht auf eine Organisation ermöglichen:

1. Geschäftsarchitektur (Business Architecture)

• Geschäftsstrategie: Definition der Geschäftsziele und -strategien.

• Geschäftsprozesse: Dokumentation und Optimierung der Kernprozesse.

• Organisation: Erfassung der Struktur und Hierarchie der Organisation.

2. Datenarchitektur (Data Architecture)

• Informationsstrukturen: Definition der Informationsstrukturen und deren Beziehungen.

• Datenmanagement: Erfassung, Speicherung, Verwaltung und Nutzung von Informationen / Daten.

• Datenqualität und -sicherheit: Sicherstellung der Integrität, Vertraulichkeit und Verfügbarkeit von Informationen / Daten.

3. Anwendungsarchitektur (Application Architecture)

• Anwendungsportfolio: Verwaltung und Optimierung der Unternehmensanwendungen.

• Integration: Erfassung und Verwaltung der Integration verschiedener Anwendungen.

• Lebenszyklusmanagement: Entwicklung, Wartung und Stilllegung von Anwendungen.

4. Technologiearchitektur (Technology Architecture)

• Infrastruktur: Hardware, Netzwerke und Basissoftware, die die IT-Umgebung unterstützen.

• Technologiestandards: Richtlinien und Standards für die eingesetzten Technologien.

• Plattformen: Betriebssysteme, Middleware und Datenbanken, welche für den Betrieb von Anwendungen benötigt werden.

EAM hat damit zum Ziel, die Unternehmensstruktur und ihre strategischen, fachlichen und (informations-)technologischen Perspektiven möglichst umfassend und transparent abzubilden.

Die operative Umsetzung erfordert, diese Perspektiven in einem ganzheitlichen Bild zusammenzuführen. Dazu wird ein Enterprise Architektur Modell entworfen. Ein EAM-Modell umfasst die systematische und strukturierte Darstellung der strategischen, fachlichen und technologischen Zusammenhänge eines Unternehmens oder einer Behörde. Es dient als umfassende Basis zur Planung, Analyse, Weiterentwicklung und Verwaltung der betrachteten Organisation.

Ziele und Nutzen eines Enterprise Architektur Modells

1. Transparenz: Schaffung eines klaren Überblicks über strategische, fachliche und technologische Zusammenhänge.

2. Effizienz: Identifikation von Redundanzen und Optimierungspunkten diverser Ressourcen.

3. Flexibilität und Agilität: Unterstützung der Fähigkeit, schnell auf Veränderungen im Markt oder in den Geschäftsanforderungen zu reagieren.

4. Strategische Ausrichtung: Sicherstellung, dass die IT-Strategie mit den Geschäftsstrategien und
-zielen im Einklang steht.

5. Risikomanagement: Identifikation und Management von Risiken in der IT-Infrastruktur und den Geschäftsprozessen.

6. Innovation: Förderung und Unterstützung der Implementierung neuer Technologien und innovativer Lösungen.

Zur Erstellung eines Enterprise Architektur Modells werden verschiedene Bereiche einer Organisation mit Hilfe von Modellierungsobjekten erfasst und deren Zusammenhänge dokumentiert. Das hieraus entstehende Netzwerk erlaubt die Analyse und Optimierung der gesamten Unternehmensarchitektur, nicht nur im Hinblick auf IT-bezogenen Fragestellungen. Übergreifende Beziehungen ermöglichen Zusammenhänge und Verbesserungspotenzial unternehmensweit zu identifizieren und Auswirkungen auf alle betroffenen Geschäftsbereiche frühzeitig zu erkennen (z.B. für anstehende IT-Transformationen, Digitalisierungsprojekte oder KI-Einführungen).

Die Aufteilung nach den aufgeführten Architekturbereichen ermöglicht es, Inhalte einfach zu erfassen und gleichzeitig übergreifende Zusammenhänge zu verstehen, zu interpretieren und schnell auf Veränderungen zu reagieren. Mit Hilfe ausgefeilter Analysen und Auswertungen ermöglicht ein integriertes EAM-Modell Aufgaben und Fragestellungen verschiedene Stakeholder optimal zu beantworten.

Struktur (Methode)

Schichten

Die EAM-Modellierung in BIC Process Design folgt den allgemeinen Architektursichten:

• Geschäftsarchitektur:

Der Schwerpunkt der Geschäftsarchitektur liegt in der systematischen Analyse, Gestaltung und Optimierung der Geschäftsprozesse und Organisationsstrukturen eines Unternehmens. Sie zielt darauf ab, die Geschäftsstrategie und -ziele in effiziente und effektive Abläufe zu übersetzen, um die Unternehmens- bzw. Behördenleistung zu steigern. Dies umfasst die Modellierung von Prozessen, die Definition von Rollen und Verantwortlichkeiten sowie die Sicherstellung, dass die Geschäftsprozesse optimal von der IT-Infrastruktur unterstützt werden.

• Datenarchitektur:

Der Schwerpunkt der Datenarchitektur liegt in der strukturierten Erfassung, Organisation, Speicherung und Verwaltung von Informationen innerhalb eines Unternehmens oder einer Behörde. Sie zielt darauf ab, die Integrität, Konsistenz und Verfügbarkeit von Daten sicherstellen. Mit Hilfe der Datenarchitektur ist es einfach möglich, einen effizienten Datenfluss zwischen Systemen und Anwendungen zu gewährleisten. Dabei werden Strategien zur Datenqualität, Datenintegration und Datensicherheit festgelegt, um die Nutzung von Informationen als wertvolle Ressource zu optimieren.

• Applikationsarchitektur:

Der Schwerpunkt der Applikationsarchitektur liegt in der Planung, Gestaltung und Verwaltung der Softwareanwendungen einer Organisation. Sie zielt darauf ab, ein kohärentes und effizientes Anwendungsportfolio zu entwickeln, das die Geschäftsprozesse optimal unterstützt. Dies umfasst die Definition von Anwendungskomponenten, deren Interaktionen und Integrationen sowie die Festlegung von Standards und Richtlinien für die Entwicklung, Wartung und Weiterentwicklung der Anwendungen.

• Technologiearchitektur:

Der Schwerpunkt der Technologiearchitektur liegt in dem Entwurf und der Verwaltung der technischen Infrastruktur eines Unternehmens oder einer Behörde. Sie umfasst die Hardware, Netzwerke, Middleware und grundlegenden Softwareplattformen, die die Basis für Anwendungen und Datenmanagement bilden. Ziel ist es, eine stabile, skalierbare und sichere technische Umgebung zu schaffen, die die Geschäftsanforderungen effizient unterstützt und den Einsatz neuer Technologien ermöglicht.

Zur Modellierung der Inhalte werden verschiedene Objekttypen angeboten. Jeder Objekttyp ist dabei eindeutig einer Architekturebene zugeordnet. Durch die Verbindung von Objekten – auch über mehrere Architekturebenen hinweg – entsteht eine transparente, zusammenhängende und vollständige Sicht auf die Architektur eines Unternehmens bzw. einer Behörde.

Spezielle Objekte der EAM-Modellierung

Um die zuvor beschriebenen Architektursichten aufzubauen, stellt BIC EAM verschiedene Katalog-Objekttypen bereit. Die folgende Tabelle stellt sie in einer Übersicht mit zugehöriger Schicht und kurzer Beschreibung vor:

Objekttyp	Architekturschicht	Beschreibung
Business Capability	Geschäftsarchitektur	Eine Business Capability ist die Fähigkeit eines Unternehmens oder einer Behörde, bestimmte Geschäftsprozesse oder -funktionen auszuführen um seine strategischen Ziele zu erreichen.
Geschäftskontext	Geschäftsarchitektur	Ein Geschäftskontext beschreibt den fachlichen Rahmen, in dem eine operative Geschäftstätigkeit ausgeführt wird. Ein Geschäftskontext-Objekt kann mit bestehenden Prozessdiagrammen verknüpft werden, um detaillierter Dokumentationen zu erstellen.
Organisationseinheit	Geschäftsarchitektur	Eine Organisationseinheit ist eine spezifische, strukturierte Gruppe innerhalb eines Unternehmens oder einer Behörde, die bestimmte Aufgaben, Funktionen oder Verantwortlichkeiten erfüllt. Sie ist in der Regel hierarchisch gegliedert.
IT-Risiko	Geschäftsarchitektur	Ein IT-Risiko ist die Möglichkeit, dass eine Applikation oder eine IT-Komponente aufgrund von Bedrohungen oder Schwachstellen negative Auswirkungen auf die Informationsverarbeitung, -sicherheit oder -verfügbarkeit hat. IT-Risiken können sowohl interne als auch externe Faktoren umfassen und beinhalten potenzielle Schäden oder Verluste, die durch Sicherheitsvorfälle, Systemausfälle, Datenverlust oder andere IT- bezogene Probleme entstehen können.
Applikation	Applikationsarchitektur	Eine Applikation ist eine Softwareanwendung, die Geschäftsprozesse und -funktionen innerhalb eines Unternehmens unterstützt und optimiert.
Schnittstelle	Applikationsarchitektur	Eine Schnittstelle ist ein definierter Punkt der Interaktion zwischen verschiedenen Softwaresystemen, Hardwarekomponenten oder Kombinationen daraus. Sie ermöglicht den Datenaustausch und die Kommunikation zwischen unterschiedlichen Systemen.
Datenobjekt	Datenarchitektur	Ein Datenobjekt ist eine spezifische, eindeutig identifizierbare Einheit von Daten, die Informationen in strukturierter Form repräsentiert und in einem IT-System gespeichert, verarbeitet oder übertragen werden. Datenobjekte sind die Grundbausteine der Datenverwaltung und können unterschiedliche Datentypen und -strukturen umfassen.
IT-Komponente	Technologiearchitektur	Eine IT-Komponente ist ein einzelnes, in sich geschlossenes Element der IT-Infrastruktur eines Unternehmens oder einer Behörde, das spezifische Funktionen oder Dienstleistungen bereitstellt und mit anderen Komponenten interagieren kann. IT-Komponenten können Hardware, Software, Netzwerkelemente oder eine Kombination davon sein.
Provider	Technologiearchitektur	Ein Provider ist ein Unternehmen oder eine Organisation, die Dienstleistungen oder Ressourcen für andere Unternehmen, Organisationen oder Einzelpersonen bereitstellt. In der IT und im Unternehmenskontext bezieht sich ein Provider häufig auf Anbieter von IT-Dienstleistungen, Cloud-Services, Internetzugang, Softwarelösungen oder anderen technologiebasierten Diensten.

Eine detailliertere Beschreibung der Objekte finden Sie hier.

Diagramme

Die oben aufgeführten EAM-Objekttypen beschreiben einzelne „Bausteine“ zur Modellierung einer Enterprise Architektur. Zur Abbildung der Zusammenhänge zwischen diesen Bausteinen stellt BIC EAM verschiedene Diagrammtypen bereit, die unterschiedliche Inhalte der jeweiligen Architekturebenen enthalten. Durch die Verknüpfung der Objekttypen entsteht auf diese Weise ein Netzwerk von –mitunter architekturschichtübergreifen – Inhalten. Im Ergebnis entsteht eine umfassende und transparente Dokumentation der Unternehmensarchitektur (Enterprise Architektur). Folgende Diagrammtypen werden von BIC EAM bereitgestellt:

Diagramm	Beschreibung
Perspektive:	Business Architektur
Business Capability Map	Eine Business Capability Map (Geschäftsfähigkeitslandkarte) ist eine grafische Darstellung der verschiedenen Fähigkeiten eines Unternehmens oder einer Behörde, die zur Erreichung seiner Geschäftsziele notwendig sind. Sie bietet eine strukturierte Übersicht über die wesentlichen Fähigkeiten der Organisation und zeigt, wie diese miteinander in Beziehung stehen. Diese Karte ist ein zentrales Werkzeug im Enterprise Architecture Management, um die strategische Ausrichtung und operative Exzellenz zu unterstützen.
Perspektive:	Business- und Applikationsarchitektur
Business Capability Kontextdiagramm	Ein Business Capability Kontextdiagramm ist eine graphische Darstellung, welche die Interaktionen und Beziehungen zwischen einer Business Capability, den betroffenen Stakeholdern sowie den wichtigsten fachlichen Kontexten (z.B. Kernprozessen) zeigt. Darüber hinaus ermöglicht sie in einfacher Weise die zur Realisierung einer Business Capability erforderlichen betriebswirtschaftliche Softwareanwendungen zu dokumentieren.
Perspektive:	Business-, Applikations-, Daten- und Technologiearchitektur
Applikationskontextdiagramm	Ein Applikationskontextdiagramm ist eine grafische Darstellung, die die Interaktionen und Beziehungen einer spezifischen betriebswirtschaftlichen Softwareanwendung mit anderen Anwendungen, deren Schnittstellen, ausgetauschten Datenobjekte und erforderlichen IT- Komponenten visualisiert. Darüber hinaus bietet sie weiterhin die Möglichkeit zusätzliche Beziehungen zu Geschäftskontexten, Capabilities, Risiken und Organisationseinheiten einzubeziehen. Dieser Diagrammtyp ermöglicht die umfassende Darstellung der Zusammenhänge einer Enterprise Architektur.
Datenobjektdiagramm	Im Datenobjektdiagramm werden die hierarchischen Beziehungen zwischen Datenobjekten durch graphische Verschachtelung bzw. baumartige Verbindungen modelliert. Dadurch ist es (neben dem Entity Relationship Diagramm) möglich, komplexe Datenstrukturen (z.B. zur Modellierung von Data Products) zu erstellen.
IT-Komponentendiagramm	Ein IT-Komponentendiagramm ist eine grafische Darstellung, die die Struktur und die Beziehungen von IT-Komponenten innerhalb eines Systems oder einer IT-Infrastruktur zeigt. Es visualisiert, wie verschiedene Software- und Hardware- Komponenten miteinander verbunden sind und welche Rollen sie im Gesamtsystem spielen. Dieses Diagramm dient dazu, die Architektur und das Zusammenspiel der IT- Komponenten zu verstehen, zu dokumentieren und zu planen.

Eine detailliertere Beschreibung der Diagramme finden Sie hier.

Objekte

Business Capability

Eine Business Capability beschreibt eine Fähigkeit, die ein Unternehmen besitzen muss, um seine geschäftsmäßige Aufgabe zu erfüllen. Sie beschreibt also „was“ ein Unternehmen tut, ohne dabei zu konkretisieren, „wie“ es dies tut. Letzteres wird üblicherweise durch die Modellierung von Prozessen beschrieben, auf die im Zuge der EAM-Modellierung über Geschäftskontexte verwiesen wird. Eine detaillierte Prozessmodellierung erfolgt in der Regel innerhalb von BIC Process Design.

Business Capabilities stellen in der Geschäftsarchitekturschicht das zentrale Element dar, da durch sie das geschäftsmäßige Aufgabenfeld abgebildet wird. Da sie sich im Allgemeinen nur recht selten ändern, beschreiben sie grundsätzlich gültige Aufgabenbereiche. Vor allem durch die Verknüpfung von Business Capabilities mit Applikationen kann effektiv dargestellt werden, welche betriebswirtschaftlichen IT-Anwendungen essenziell für welche Geschäftsfähigkeit sind.

Geschäftskontext

Ein Geschäftskontext definiert abstrakt „wie“ ein Unternehmen seine unterschiedlichen Aufgaben und Ziele erreicht. Diese Beschreibung kann auf vielfältige Art und Weise geschehen, zum Beispiel durch eine Customer Journey oder eine klassische Prozessmodellierung. Über eine Verknüpfung von Geschäftskontexten mit Business Capabilities und Applikationen kann der konkrete Zusammenhang zwischen grundsätzlichen Fähigkeiten, den zu deren Realisierung erforderlichen fachlichen Tätigkeiten sowie der dafür benötigten IT-Unterstützung dargestellt werden. Z.B. welche Applikation unterstützt welchen Geschäftskontext und welcher Geschäftskontext beschreibt die konkrete Umsetzung welcher Business Capability.

Da BIC Process Design die Modellierung verschiedener Detaillierungen von Prozessen anbietet, ist es möglich, bestehende Diagramme mit einem Geschäftskontext-Objekt zu verknüpfen.

Organisationseinheit

Eine Organisationseinheit repräsentiert unterschiedliche aufbauorganisatorische Einheiten, geographische Regionen oder Benutzergruppen / Teams innerhalb eines Unternehmens oder einer Behörde. In der EAM-Modellierung werden mit Applikationen und Business Capabilities verbunden, um darzustellen welche Organisationseinheit bei der Realisierung einer Business Capability beteiligt sind bzw. welche Applikationen nutzt.

Zur übersichtlicheren Strukturierung ist es darüber hinaus möglich, Hierarchien von Organisationseinheiten graphisch in Organigrammen abzubilden.

Applikation

Applikationen stellen das zentrale Bindeglied zwischen den Architektursichten dar. Durch ihren Einsatz in diversen Geschäftskontexten wird die Umsetzung von Business Capabilities unterstützt. Im Betrieb von (betriebswirtschaftlichen) Applikationen werden dafür Daten – häufig in Verbindung mit anderen Applikationen – verarbeitet und über Schnittstellen ausgetauscht. Weiterhin erfordert der Einsatz von Applikationen häufig die Verfügbarkeit weiterer IT-Komponenten (z.B. Server, Cloud-Dienste) und entsprechender Provider.

In einem Unternehmen gibt es unterschiedlichste Applikationen mit unterschiedlichstem Einsatzzweck: Standard-Anwendungssoftware, SaaS oder Microservices. Generell empfiehlt es sich, sich im Rahmen der EAM-Modellierung an konkreten Applikationen bzw. Anwendungsfällen der eigenen Organisation zu orientieren.

Schnittstelle

Der Datenaustausch zwischen Applikationen kann durch Schnittstellen dargestellt werden. Hierbei kann eine Schnittstelle von einer Applikation bereitgestellt bzw. von ihr genutzt werden. Dies ermöglicht es, sowohl anbietende als auch konsumierende Schnittstellen zu modellieren.

Neben der reinen Verbindung zwischen Applikationen kann zusätzlich auch eine Verbindung zu Datenobjekten dargestellt werden. Dadurch lassen sich sehr detailliert einzelne Applikations-Informationsflüsse, inklusive der grundlegenden Datenoperationen (CRUD) modellieren.

Datenobjekt

Ein Datenobjekt beschreibt von Applikationen verarbeitete bzw. über Schnittstellen ausgetauschte Daten. Sie repräsentieren jeweils ein Datenobjekt, wie zum Beispiel Kunde, Angebot oder Vertrag. Für eine entsprechende Austauschbeziehung (z.B. in Verbindung mit einer Schnittstelle) können die Datenoperationen (CRUD) angegeben werden.

Die konsistente Modellierung von Datenobjekten erlaubt das umfassende und transparente Nachverfolgen von einzelnen Datenobjekten über verschiedene Applikationen hinweg und ermöglicht zielgenaue Entscheidungshilfen bei IT-Transformationen oder Konsolidierungsmaßnamen.

IT-Komponente

IT-Komponenten stellen ein zentrales Element einer IT-Architektur dar. Mit Ihnen werden Strukturen modelliert, die zum Betrieb von Applikationen erforderlich sind. Sie sind ein essenzieller Bestandteil bei IT-Transformations- oder IT-Cloud-Strategieprojekten.

Jede IT-Komponente kann einem Provider zugeordnet werden, welcher genauer spezifiziert, wer eine IT-Komponente betreibt oder bereitstellt. Im Allgemeinen wird durch einen Provider nicht der Hersteller modelliert (eine Ausnahme stellen hier Cloud-Dienste dar).

Provider

Als Provider werden typischerweise Unternehmen modelliert, die eine IT-Komponente bereitstellen oder sie betreiben, selten der tatsächliche Hersteller einer IT-Komponente. Gerade bei der Auswertung von Geschäftsbeziehungen können durch die Verknüpfung mit IT-Komponenten wertvolle Informationen gewonnen werden.

Diagramme

Business Capability Map

Business Capabilities werden üblicherweise innerhalb einer Business Capability Map modelliert. Die Darstellung in BIC EAM erfolgt als graphische Hierarchie: In Säulen (idealerweise nicht mehr als 10), die jeweils die Kern-Business Capabilities wie zum Beispiel „HR“, „Auftragsmanagement“ oder „Kundenmanagement“ abbilden und untergeordnete Business Capabilities – wie zum Beispiel „Recruiting“, „Auftragsverhandlung“ oder „Vertragsmanagement“ – bündeln.

Durch die verschachtelte Modellierung von Business Capabilities wird implizit eine Aggregationsbeziehung modelliert und somit eine Hierarchie von Business Capabilities ermöglicht.

In der Symbolpalette des Diagramms stehen zwei Business Capability Symbole zur Verfügung: Business Capability und Business Capability (Lebenszyklus). Während das erste Symbol das Standard-Symbol einer Business Capability darstellt, enthält das zweite Symbol eine bedingte Formatierung basierend auf dem Wert des Ausprägungsattributs „Lebenszyklus“ der Business Capability: Je nach ausgewähltem Lebenszyklus wird das Symbol entsprechend eingefärbt. Hierdurch werden die einzelnen Lebenszyklusphasen direkt visuell sichtbar.

Business Capability Kontextdiagramm

In diesem Diagramm werden Business Capabilities mit Applikation, Business Kontexten und Organisationseinheiten in Beziehung gesetzt. In diesem Diagramm liegt der Fokus auf der Darstellung der Beziehung zwischen Applikationen und der fachlichen Modellierung - konkret der Beziehung zu Business Capabilities und Business Kontexten. Die Modellierung von Schnittstellen oder IT-Komponenten ist auf diesem Diagrammtyp nicht vorgesehen (siehe Applikationskontextdiagramm).

Generell wird empfohlen, wenn möglich, EAM-Objekte mit der größten Hierarchie-Tiefe zu verwenden, um einen möglichst konkreten Kontext abzubilden.

Applikationskontextdiagramm

In einem Applikationskontextdiagramm werden die Beziehung zwischen Applikationen und den weiteren EAM-Objekten für einen vom Modellierer definierten Kontext bzw. Einsatzfall modelliert. Ein Kontext kann hierbei z.B. der dedizierte Einsatz einer Applikation für eine ausgewählte Business Capability und Organisationseinheiten sein oder die Verwendung einer Schnittstelle für einen konkreten Business Kontext. Prinzipiell sollten alle EAM-Objekte, die konkret in einem Zusammenhang stehen in einem eigenen Kontext-Diagramm modelliert werden. Somit ist zum Beispiel einfach ersichtlich, welcher Business Kontext mit welcher Applikation welche Business Capability unterstützt.

Konkret können Applikationen mit Business Capabilities, Geschäftskontexten, Organisationseinheiten, Schnittstellen, Daten, IT-Komponenten und Risiken in Beziehung gesetzt werden.

Zusätzlich können an Schnittstellen auch weitere beteiligte Applikationen sowie die verwendeten Datenobjekte und zugehörige Risiken modelliert werden. Dabei ist zu beachten, dass in einem Applikationskontextdiagramm immer nur eine Applikation als zentrales Objekt definiert wird. Weitere ausgeprägte Applikationen werden auf dem jeweiligen Diagramm nur zur modelliert, um Beziehungsstrukturen der zentralen Applikation zu diesen sekundären Applikationen abzubilden.

Über passende Ausprägungsattribute an den einzelnen Objekten können kontext-spezifische Eigenschaften für den modellierten Kontext gesetzt werden.

Generell wird empfohlen, wenn möglich, EAM-Objekte mit der größten Hierarchie-Tiefe zu verwenden, um einen möglichst konkreten Kontext abzubilden (z.B. SAP S4/HANA anstatt ERP-System).

IT-Komponentendiagramm

Dieses Diagramm wird verwendet, um Zusammenhänge zwischen verschiedenen IT-Komponenten abzubilden. Dabei werden im Wesentlichen Aggregationsbeziehungen erfasst, die sowohl durch graphische Verschachtelung als auch durch eine entsprechende Kantenbeziehung modelliert werden. Neben der Aggregation können auch noch die Beziehungstypen Komposition, bedient und Realisierung über visuelle Kanten modelliert werden.

Datenobjektdiagramm

Dieses Diagramm wird dazu verwendet, eine Hierarchie von Datenobjekten durch Aggregationsbeziehungen zu modellieren. Eine Aggregationsbeziehung kann sowohl durch graphische Verschachtelung als auch durch eine entsprechende Kantenbeziehung modelliert werden. Mit Hilfe des Datenobjektdiagramms können in der Datenarchitektur komplexe Data Products beschrieben werden.

Modellierung

Was ist das allgemeine Modellierungskonzept bei BIC EAM?

BIC EAM kombiniert die intuitive Modellierung in Diagrammen mit klassischen EAM-Objekten, wie zum Beispiel Business Capabilities, Applikationen oder IT-Komponenten mit der Erfassung umfassender Detailinformationen über formularartige Eingabemasken. Wie von BIC Process Design gewohnt, werden EAM-Objekte als Katalogobjekte angelegt und zentral gepflegt. Über verschiedene Diagramme können diese Elemente in unterschiedlichen Modellierungssituationen in Beziehung gesetzt werden.

Grundsätzlich lassen sich die EAM-Diagramme in zwei Typen einteilen:

• Kontextdiagramme:

Mit dem Business Capability Kontextdiagramm und Applikationskontextdiagramm werden Beziehungen zwischen verschiedenen EAM-Objekten in frei definierbaren Szenarien (Kontexten) modelliert

• Hierarchiediagramme:

Mit der Business Capability Map, dem IT-Komponentendiagramm, dem Datenobjektdiagramm und dem IT-Architekturdiagramm werden darüber hinaus hierarchische Aggregationsbeziehungen für Business Capabilities, IT-Komponenten, Datenobjekte und Applikationen modelliert.

Das Grundkonzept in der Modellierung von EAM-Objekten und deren Beziehungen ist die kontextbezogene Modellierung. Dies bedeutet, dass für einen konkreten Kontext oder Anwendungsfall ein EAM-Element in einem entsprechenden Kontextdiagramm dargestellt und mit den im jeweiligen Anwendungsfall relevanten weiteren Artefakten verbunden wird. Hierdurch kann intuitiv in einem Kontextdiagramm (z.B. „BIC Usage EMEA Australia“) modelliert werden, dass BIC Process Design in der Public Cloud bereits in den Organisationseinheiten EMEA und Australien verwendet wird, während in einem anderen Kontextdiagramm (z.B. „Modelling Tool Canada“) in Kanada noch ein anderes System zur Unterstützung der Business Capability Modellierung verwendet wird. In jedem dieser Kontextdiagramme können kontext-sensitive Attribute wie z.B. die funktionale Eignung gesetzt und ausgewertet werden.

Durch die kontextbezogene Modellierung wird es möglich, dass Eigenschaften der einzelnen EAM-Objekte (vor allem für Applikationen, Business Capabilities, IT-Komponenten und Schnittstellen) für jeden Kontext gezielt definierbar sind. Viele EAM-Attribute (z.B. funktionale oder technische Eignung, eine TIME oder 6R Klassifizierung oder eine Kritikalitätsbewertung) sind aus diesem Grund Ausprägungsattribute. Diese gelten nur für die konkrete Ausprägung eines Objektes in einem konkreten Kontextdiagramm.

Wie starte ich mit der EAM-Modellierung?

Zu Beginn wird empfohlen, die zu modellierenden EAM-Elemente dem Katalog hinzuzufügen. Je nach Fokus und Architektursicht ergeben sich hier unterschiedliche Schwerpunkte:

Geschäftsarchitektur

Zentraler Bestandteil der Business Architekturmodellierung ist die Business Capability. Sie beschreibt die Fähigkeit, die ein Unternehmen oder eine Behörde zur Zielerreichung besitzen muss. Hierbei ist es oft hilfreich, Business Capabilities nach Funktionsbereichen oder Abteilungen zu gruppieren. Mit dem Diagramm Business Capability Map können Business Capabilities übersichtlich dargestellt werden und erlauben eine zentrale Sicht auf die Fähigkeiten des Unternehmens.

Bei einer EAM-Modellierung mit Geschäftsfokus können Business Capabilities mit Businesskontexten, Organisationseinheiten und Applikationen in Beziehung gesetzt werden. Dadurch entsteht ein Business Capability Kontextdiagramm, in dem abgebildet wird, welcher Geschäftskontext, meistens ein Prozess, eine Geschäftsfähigkeit unterstützt, welche Organisationseinheiten betroffen sind und welche Applikationen dabei erforderlich sind. Je nach gewünschtem Detaillierungsgrad können diese Zusammenhänge allgemein oder auch für gezielt für einzelne Kontexte modelliert werden, z.B. wenn bestimmte Organisationseinheiten für eine Geschäftsfähigkeit unterschiedliche Applikationen einsetzen. Es wird empfohlen, vor Beginn der Modellierung einen Entwurf möglicher Kontexte zu bestimmen.

Applikationsarchitektur

Die Applikation steht im Mittelpunkt der Applikationsarchitektur. Vergleichbar mit dem Business Capability Kontextdiagramm erlaubt das Applikationskontextdiagramm die Modellierung von Zusammenhängen zwischen Applikationen und anderen EAM-Objekten. Hierbei stellt eine Applikation das Bindeglied zwischen der Geschäftsarchitektur und der Technologiearchitektur dar. Konkret bedeutet dies, dass eine Applikation sowohl mit Business Capabilities, Geschäftskontexten und Organisationseinheiten als auch mit IT-Komponenten, Schnittstellen und Datenobjekten verbunden werden kann. Vereinfacht betrachtet kombiniert das Applikationsarchitekturdiagramm den Blick „nach oben“ in Richtung der Fachlichkeit und den Blick „nach unten“ in Richtung der Informationstechnologie. Analog zum Business Capability Kontextdiagramm ist auch hier der Detaillierungsgrad der Modellierung sehr flexibel.

Datenarchitektur

Die Datenarchitektur erlaubt die strukturierte Beschreibung, welche Informationen / Daten innerhalb eines Unternehmens oder einer Behörde verarbeitet werden bzw. welche Data Products im Unternehmen entstehen oder verarbeitet werden. Mit Hilfe der Datenarchitektur ist es einfach möglich, einen effizienten Datenfluss zwischen Systemen und Anwendungen zu gewährleisten. Dabei werden Strategien zur Datenqualität, Datenintegration und Datensicherheit festgelegt, um die Nutzung von Informationen als wertvolle Ressource zu optimieren. Es wird empfohlen, zunächst die wesentlichen Datenobjekte der Organisation im Katalog zu erfassen und zu detaillieren. Dabei ist eine einheitliche Nomenklatura besonders hilfreich, da dadurch eine redundanz- und widerspruchsfreie Verwendung der Datenobjekte im EAM-Modell sichergestellt wird.

Technologiearchitektur

Zur Detailmodellierung der vorhandenen IT-Ressourcen dienen die Diagramme IT-Komponentendiagramm und das IT-Architekturdiagramm. In diesen Diagrammen werden vornehmlich Hierarchien von IT-Komponenten, Datenobjekten und Applikationen modelliert. Darüber hinaus können im IT-Komponentendiagramm auch Beziehungen zwischen IT-Komponenten mit Hilfe von Kompositions- oder Assoziationsbeziehungen modelliert werden.

Wie in vielen Bereichen der BIC EAM Modellierung besitzen auch die Objekttypen der Technologiearchitektur sowohl Entitäts- als auch Ausprägungsattribute. Während die Entitätsattribute immer, also in jedem Kontext, für das Objekt gelten, gelten Ausprägungsattribute immer nur für die konkret in einem Diagramm ausgeprägte Instanz eines Objekts. Somit haben Sie die Möglichkeit, bei der Modellierung in einem Kontextdiagramm, spezielle Attribute, zum Beispiel die fachliche Eignung, eines Objekts in verschiedenen Kontexten mit unterschiedlichen Werten zu versehen.

Wie modelliere ich den Lebenszyklus eines EAM-Objekts?

Jedes EAM-Objekt hat ein Lebenszyklus-Attribut als Ausprägungsattribut. Damit können Sie, vor allem in den beiden Kontext-Diagrammen, den Lebenszyklus des jeweiligen Objekts im jeweiligen Kontext individuell festlegen. Darüber hinaus gibt es für Applikationen, IT-Komponenten und Provider die Möglichkeit konkrete Datumsangaben für die einzelnen Phasen des Lebenszyklus als Entitätsattribute festzulegen.

Welche Hierarchiestufe sollte ich in Kontextdiagrammen verwenden?

Generell wird empfohlen, wenn möglich, EAM-Objekte mit der größten Hierarchie-Tiefe zu verwenden, um einen möglichst konkreten Kontext abzubilden.

Wie lege ich Gültigkeiten der einzelnen Kontextdiagramme fest?

Den Gültigkeitszeitraum eines Kontextdiagramms kann über die Governance-Attribute „Gültig von“ und „Gültig bis“ festgelegt werden. Über diese Attribute wird die zeitliche Abfolge von verschiedenen Kontextdiagrammen abgebildet. Zusätzlich steht für Business Capability Kontextdiagramme und Applikationskontextdiagramme das Attribut „Vorgänger“ zur Verfügung, mit dem ebenfalls eine explizite Abfolge von verschiedenen Diagrammen dokumentiert werden kann.

Wie verwalte ich am besten Varianten eines Kontextdiagramms?

Es gibt mehrere Möglichkeiten verschiedene Varianten eines Kontextdiagramms zu verwalten. Je nach Kontextvielfalt können verschiedene Kategorien wie „AS-IS“ und „TO-BE“ oder Diagrammnamenspräfixe verwendet werden. Darüber hinaus ist es auch möglich über das „Vorgänger“ oder das Variantenmanagement entsprechende Kontextdiagramme zu verknüpfen

Hinweis

Jedes EAM-Modell ist individuell bezogen auf das Unternehmen oder die Behörde, welche es erstellt. Aus diesem Grund wird empfohlen vor dem Beginn einer EAM-Modellierung einen Best-Practice Abgleich mit den Experten von GBTEC durchzuführen.