Konzept: Geschäftsarchitektur
Die Geschäftsarchitektur ist per Definition eine organisierte Gruppe von Elementen mit klar definierten Beziehungen untereinander, die zusammen ein Ganzes bilden, das sich durch seine Funktionalität definiert.
Beziehungen
Hauptbeschreibung

EinführungSeitenanfang

Wir definieren eine Geschäftsarchitektur als organisierte Gruppe von Elementen mit klar definierten Beziehungen untereinander, die zusammen ein Ganzes bilden, das sich durch seine Funktionalität definiert. Die Elemente stellen die Organisations- und Verhaltensstruktur eines Geschäftssystems dar und zeigen Abstraktionen der Schlüsselprozesse und -strukturen des Geschäfts [NDL97], [ERI00].

Kontext der GeschäftsarchitekturSeitenanfang

Jede Person hat einen anderen Hintergrund und andere Sichtweisen. Wenn Sie versuchen, ein gemeinsames Verständnis für etwas so Komplexes wie die Organisation, einschließlich ihrer Prozesse, Struktur und Strategie, zu erreichen, benötigen Sie eine Methode, um die Architektur und die architektonisch relevanten Probleme so beschreiben zu können, dass es für jede betroffene Gruppe verständlich ist. Wie weiter hinten in diesem Dokument noch gezeigt und erläutert wird, werden hierfür drei unterschiedliche, aber miteinander in Zusammenhang stehende Architekturen beschrieben.

Im Inhalt beschriebene Abbildung

Geschäftsarchitektur ist eine Beschreibung der wichtigen Aspekte der Organisation. Anwendungsarchitektur ist eine Beschreibung der Softwareanwendungen, die das Geschäft beschreiben, und der Verwendung dieser Anwendung und ihrer Interaktionen untereinander. Technische Architektur ist eine Beschreibung der Hardwareinfrastruktur, die die Softwareanwendungen unterstützt.

Die Geschäftsarchitektur muss die Anwendungsarchitektur steuern und diese wiederum die technische Architektur. Dies impliziert keine hierarchische Beziehung, in der sich die technische Architektur an die Anwendungsarchitektur und diese dann an die Geschäftsarchitektur halten muss. Es bedeutet vielmehr, dass die Ziele und Einschränkungen (Faktoren oder Triebfedern) in eine Richtung kommuniziert werden und alle architektonischen Entscheidungen (Kompromisse), die sich auf die steuernde Architektur auswirken, auf der Ebene der steuernden Architektur vorgenommen werden müssen. Ein Architekturziel impliziert einen gewünschten Zustand, während eine Architektureinschränkung eine verbindliche Konformität impliziert. Aber selbst Einschränkungen können absichtlich ignoriert werden. Eine Einschränkung, die erfordert, dass das Geschäft bestimmten gesetzlichen Vorschriften entspricht, kann beispielsweise ignoriert werden, wenn die Kosten für die zur Einhaltung der Bestimmungen erforderlichen Änderungen die Geldstrafen, die sich aufgrund eines Verstoßes gegen die Bestimmungen ergeben, erheblich übersteigen.

Beim Erstellen einer Architektur geht es darum, Kräfte im Gleichgewicht zu halten und Kompromisse zu schließen, um eine Lösung zu erstellen, die sich widersprechenden Anforderungen optimal genügt. Die Geschäftsarchitektur definiert also die Ziele und Einschränkungen, die die Unterstützung beschreiben, die sie von der Anwendungsarchitektur fordert. Dasselbe gilt für die Anwendungsarchitektur und die technische Architektur. Wenn Konflikte auftreten, und das ist immer der Fall, müssen lokal gebundene suboptimale Lösungen gefunden werden, um eine insgesamt optimale Lösung zu gewährleisten. Falls diese Entscheidungen weitreichende Auswirkungen haben, werden sie als architektonische Probleme bezeichnet, über die sich die Stakeholder, die von einem Architekturgremium vertreten werden, formal einigen müssen.

Diese unterschiedlichen Architekturen müssen bei der Kommunikation mit Stakeholdern immer berücksichtigt werden. Wenn nur eine der Architekturen mit einer Person besprochen wird, die weder Form noch Anwendung oder Notation der Architektur versteht, ist dies in höchstem Maße ineffizient. Außerdem kann dies dazu führen, dass die Person die Konsequenzen ihrer Entscheidungen auf die anderen Architekturen missversteht. Die Auswirkungen von Entscheidungen in einer der Architekturen müssen in die anderen Architekturen übersetzt werden. Auf diese Weise können die Stakeholder die Vor- und Nachteile von Kompromissen besser verstehen, was zur Ausrichtung der Architektur beiträgt. Die Ausrichtung der Architektur hilft uns, die Konsequenzen von Entscheidungen zu begreifen.

Geschäftsarchitektur als Framework für ÄnderungenSeitenanfang

Wir verwenden die Geschäftsarchitektur, um mit unterschiedlichen Stakeholdern über das Geschäft zu kommunizieren, um ein gemeinsames und einheitliches Verständnis zu erzielen. Die Geschäftsarchitektur lässt sich als Framework beschreiben, in dem wir Änderungen an der Organisation vornehmen, damit das Geschäft letztendlich in der Lage ist, die Geschäftsidee zu verwirklichen. Schauen Sie sich die folgende Abbildung an.

Im Inhalt beschriebene Abbildung

GeschäftsarchitektursichtenSeitenanfang

Da eine Geschäftsarchitektur komplex und schwierig zu bewerten ist, teilen wir sie in eine Reihe unterschiedlicher Sichten auf. So wie die Softwarearchitektur auf der Seite Konzept: Softwarearchitektur definiert wird, definieren wir hier die Architektursichten des Geschäfts.

Jede Sicht beschreibt einen Aspekt des gesamten Geschäfts. Sie enthält deshalb einen architektonisch relevanten Teil der vollständigen Definition. Anders ausgedrückt, eine Architektursicht enthält die 20 %, die für diesen Aspekt des Geschäfts wirklich eine Rolle spielt [ROY98].

Die Architektursichten sind hilfreich, wenn die Geschäftsarchitektur mit unterschiedlichen Stakeholdern besprochen wird. Da jeder Stakeholder mindestens eine Sicht hat, die von besonderem Interesse für ihn ist, kann er sich auf diese Aspekte der Organisation konzentrieren, die diesen Sichten zugeordnet sind, ohne auch alles andere verstehen zu müssen.

Nicht alle Sichten gelten gleichermaßen für alle Situationen. Einige Sichten können ignoriert werden, wenn sie keinen Mehrwert darstellen. Manchmal müssen auch neue Sichten definiert werden. Im Folgenden werden einige typische Geschäftsarchitektursichten beschrieben:

  • Die Marktsicht beschreibt die Märkte, in denen das Geschäft operiert, Kundenprofile und Angebote oder die Produkte und Services, die das Geschäft den Kunden in den Zielmärkten bietet.
  • Die Geschäftsprozesssicht beschreibt die wichtigen Ziele des Geschäfts und skizziert die wichtigsten Geschäftsanwendungsfälle, die diese Ziele unterstützen. Wenn Geschäftsanwendungsfälle für die Dokumentation von Geschäftsprozessen verwendet werden, wird diese Sicht auch die Geschäftsanwendungsfallsicht genannt.
  • Die Organisationssicht beschreibt die Gruppierungen von Rollen und Zuständigkeiten innerhalb des Geschäfts und die Realisierung der Geschäftsanwendungsfälle.
  • Die Personalsicht beschreibt Vergütungsprofile und Incentive-Mechanismen, wichtige kulturelle Merkmale und Mechanismen, Kompetenzprofile sowie Ausbildungs- und Schulungsmechanismen.
  • Die Domänensicht beschreibt die wichtigsten Geschäftskonzepte und die im Geschäft eingesetzten Informationsstrukturen.
  • Die geographische Sicht beschreibt die Verteilung der Organisationsstruktur, Funktionen und Ressourcen auf die physischen Standorte wie Städte und Länder.
  • Die Kommunikationssicht beschreibt die Kommunikationswege innerhalb des Geschäfts.

Zuordnung der Geschäftsarchitektursichten zu RUP-Blickpunkten

RUP-Blickpunkte sind auf der Seite Konzept: Systemarchitektur beschrieben. Diese Blickpunkte sind generell auf die Systementwicklung anwendbar. Wenn es sich bei dem zur Diskussion stehenden 'System' um ein Geschäft handelt, bilden die Geschäftsarchitektursichten eine nachhaltigere Spezialisierung der generischen Blickpunkte. Die folgende Tabelle zeigt, wie diese miteinander in Zusammenhang stehen. Die Geschäftsarchitektursichten decken gemäß Definition auf der Seite Konzept: Systemarchitektur in manchen Fällen mehrere Sichten ab (wobei eine Sicht der Schnittpunkt von Blickpunkt und Abstraktionsebene ist).

Geschäftsarchitektursichten RUP-Blickpunkte
Marktsicht

Die Marktsicht definiert - zumindest teilweise - den Kontext für das Geschäft. Sie konzentriert sich auf tatsächliche und potenzielle Produkte und Services, die den Kunden in den ausgewählten Märkten angeboten werden. Sie entspricht dem Schnittpunkt von logischem Blickpunkt und Kontextebene. Für das Arbeitsergebnis Geschäftsarchitekturdokument wird die Marktsicht auf die Faktoren, die sich auf die Architektur auswirken, und die Bereiche beschränkt, in denen sich Änderungen an der Architektur auf den Erfolg in ausgewählten Märkten auswirken würden.

Eine allgemeinere Diskussion über Märkte und die Begründung für Geschäftsstrategieoptionen finden Sie auf der Seite Arbeitsergebnis: Geschäftsvision.

Die Marktsicht kann verwendet werden, um neue Geschäftsziele festzulegen, was sich wiederum auf die Geschäftsarchitektur auswirken kann.

Geschäftsprozesssicht Diese Zuordnung ist einfach und entspricht dem Schnittpunkt von Prozessblickpunkt und Kontextebene.
Organisationssicht Bei der Organisationssicht geht es darum, wie das Geschäft strukturiert wird, um die Geschäftsanwendungsfälle zu realisieren, und nicht um Positions- oder Mitarbeiterhierarchien und -netze. In dieser Sicht würde man beispielsweise Kollaborationen von Geschäftssystemen erwarten. Sie entspricht deshalb dem Schnittpunkt von logischem Blickpunkt und Analyseebene.
Personalsicht Die Personalsicht ergänzt den Mitarbeiterblickpunkt, eventuell auf allen Ebenen, am signifikantesten aber auf der Kontextebene, auf der die Richtlinie definiert wird, aber auch auf Analyse- und Designebene, z. B. mit der Anwendung von Kompetenzprofilen.
Domänensicht Die Domänensicht entspricht relativ gut dem Schnittpunkt von Informationsblickpunkt und Kontextebene.
Geographische Sicht und Kommunikationssicht Diese Sichten zusammen entsprechen dem Schnittpunkt von Verteilungsblickpunkt und Kontextebene (die Unternehmenslokalitätssicht), wobei die Lokalitäten dem geographischen Aspekt und die Konnektoren dem Kommunikationsaspekt zuzuordnen sind.