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].
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.
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.
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.
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.
|
|