Architektur und Architekturmanagement

Eine Architektur definiert die Grundstruktur eines DV-Systems. Sie ist damit einer der Schlüsselfaktoren für eine stabile, wartbare und funktionierende DV. Dieser Artikel umreißt den Begriff der "Architektur" und stellt deren Bedeutung in der Software-Entwicklung dar. Außerdem werden IT-Architektur und Unternehmens-Architektur gegeneinander abgegrenzt. Der Beitrag gibt eine Übersicht über die konkreten Arbeitsprodukte, mit denen eine Architektur definiert werden kann, und er zeigt die Aufgabe des Architektur-Managements in einer Organisation auf. Erschienen in der HMD–Zeitschrift für Wirtschaftsinformatik

Den Artikel können Sie rechts herunterladen.

Sinn und Zweck von Architektur

Begriff der Architektur

In diesem Beitrag werden unter Architektur die Dinge verstanden, welche die (Grund-)Struktur eines Systems definieren. Mit Struktur sind dabei nicht nur die statischen Aspekte eines Systems wie z.B. Komponenten, ihre Schnittstellen und Beziehungen untereinander gemeint, sondern auch dynamische Aspekte wie etwa die Kommunikation zwischen den Komponenten. Eine Architektur wird aus einer Reihe von Sichten – d.h. einzelnen Arbeitsprodukten – beschrieben, die zusammen die Architektur definieren (zu Architekturen siehe [1], [2] und [3]).

Eine DV-Architektur, wie wir Sie in diesem Artikel näher betrachten, beschreibt sowohl Hard- wie auch Software-Strukturen. Eine Architektur kann für nur ein System entworfen werden wie auch für eine ganze Systemfamilie (vgl. Abschnitt 2.2).

Ziele einer Architektur

Das Ziel einer Architektur ist es sicherzustellen, dass das spätere System die Anforderungen erfüllt (utilitas), robust gegenüber Änderungen ist (firmitas) und eine gewisse „Schönheit“ besitzt (venustas). Mit Schönheit ist dabei gemeint, dass ein System „seine Funktion durch seine Form kommuniziert“. Diese allgemeine Definition von „Architektur“ in der Encyclopaedia Britannica [4] ist auch für die Softwaretechnik unverändert gültig. Die Begriffe utilitas, firmitas und venustas fassen die drei wichtigsten Fragen zusammen, der sich eine Architektur täglich stellen muss: Wird das System damit die Anforderungen erfüllen? Wird es robust gegenüber möglichen Änderungen sein? Werden die Anwendungsentwickler die Architektur und die Anwender das System intuitiv nutzen können?

Einfluss der Architektur auf das System

Eine Architektur bestimmt die Struktur eines Systems auf zwei Ebenen. Zum einen legt die Architektur das Modell des späteren Systems in einem gewissen Umfang fest und definiert damit die Gegenstandsebene, u.a. durch die Strukturierung des Systems in bestimmte Subsysteme und durch die Entwicklung von Basiskomponenten wie z.B. einer standardisierten Datenhaltungs Zugriffschnittstelle (Persistenzframework). Zum anderen definiert sie Regeln, die bei der Entwicklung des Systems einzuhalten sind. Damit definiert sie die Metaebene der Entwicklung, z.B. durch Programmierrichtlinien oder Muster. Diesen Sachverhalt stellt Abbildung 1 näher dar.

Bedeutung der Architektur

Die Architektur eines Systems ist einer der zentralen Erfolgsfaktoren für den Projekterfolg. Die Architektur definiert die Basis eines Systems: mit ihr steht und fällt seine Qualität. Darüber hinaus wird mit einer Architektur erreicht, dass bewährte Lösungen nicht wiederholt neu erfunden werden müssen, dass Komponenten gewissen Strukturregeln folgen und sich in ein gemeinsames größeres Ganzes einfügen und in ihre IT-Umgebung passen (Interoperabilität, Integrierbarkeit, Austauschbarkeit). Schließlich spiegelt sich die Struktur des Systems bei größeren Entwicklungsteams in der Projektorganisation wider. Die Architektur kann gezielt das Projektmanagement unterstützen. Nicht zuletzt definiert die Architektur die technische „Sprache“ des Projekts und sichert ein gemeinsames technisches Grundverständnis.

Die bewusste Erstellung einer Architektur für eine ganze Familie von DV-Systemen ist für Unternehmen sinnvoll, die eine Reihe von Anwendungen miteinander interagieren lassen müssen, bzw. die auf einer Plattform eine Reihe von Anwendungen entwicklen. Eine Architektur für eine Systemfamilie ist nicht nur aus Synergiegründen sinnvoll, sondern für eine Wartbarkeit des Systems notwendig. Ohne eine einheitiche DV-Architektur entsteht ein System-Wildwuchs, der nicht nur teuer zu betreiben ist, sondern auch nur unter großem Aufwand weiterentwicklet werden kann. Eine Wiederverwendung von Lösungen und Ressourcen wird damit fast gänzlich unmöglich. Dadurch werden Unternehmen DV-technisch die Hände gebunden, und für das Geschäft benötigte Erweiterungen oder Änderungen können nicht oder nicht in einem akzeptablem Zeitraum durchgeführt werden.

Abgrenzung

Geschäftsarchitektur und DV-Architektur

Der Begriff Architektur wird für eine Vielzahl von Systemen verwendet. Grundsätzlich können wir zwischen der Architektur von DVSystemen (mit Hard- und Software) und sozialen Systemen (mit Organisationen, Prozessen und Ressourcen) unterscheiden – zur Definition von DV-Architektur und Unternehmensarchitektur siehe auch [12]. Im Kontext der Entwicklung von DV-Systemen sind vier Architekturen von Bedeutung (siehe Abbildung 2):

• Die Geschäftsarchitektur (auch Unternehmensarchitektur genannt) legt die Grundstrukturen des Geschäfts durch die Definition von Geschäftszielen, Prozessen, Organisationsstrukturen und Ressourcen fest. Für die Erstellung von betrieblichen Informationsund Unterstützungssystemen ist sie eine zentrale Informationsquelle.
• Die Projektarchitektur definiert die Prozesse, Organisation und Ressourcen des Projekts. Sie ist Voraussetzung für das reibungslose Funktionieren des Projekts.
• Die Systemarchitektur definiert die Hard- und Software des zukünftigen technischen Systems (das zur Unterstützung der Abläufe im Geschäft – beschrieben durch die Geschäftsarchitektur – verwendet wird).
• Die Entwicklungsarchitektur definiert die Hard- und Software der Entwicklungsumgebung, also des Systems, mit dem das Zielsystem erstellt wird. Ggf. tritt hierzu noch die Architektur für das Testsystem.

Die im folgenden vorgestellten Arbeitsprodukte dienen der Beschreibung der Architektur eines DV-Systems, d.h. sie können zur Definition der System- und Entwicklungsarchitektur verwendet werden (zur Modellierung der Architektur von sozialen Systemen siehe z.B. [7]).

Architektur eines Systems und einer Systemfamilie

Eine Architektur kann für ein System, aber auch für eine Systemfamilie entworfen werden. Während die Architektur eines Systems die Grundstrukturen für ein spezielles DV-System definiert, spezifiziert die Architektur einer Systemfamilie die Grundstrukturen für eine Familie von DV-Systemen und stellt sicher, dass die Systeme ein gemeinsames Ganzes ergeben. Die Architekturen der einzelnen Systeme bauen auf die Architektur der Systemfamilie auf. Die Architektur für ein System liegt in der Verantwortung des für das System verantwortlichen Projektteams. Die Architektur der Systemfamilie ist hingegen eine projektübergreifende Aufgabe. Das Management der Architekturen wird im Abschnitt 4 näher betrachtet.

Architekturen für Systemfamilien können in mehreren aufeinander aufbauenden „Schichten“ erstellt werden. So kann sich z.B. eine Architektur für Internetanwendungen auf die allgemeine DV-Architektur im Unternehmen stützen, die wiederum auf allgemeine Architekturmuster bzw. Architekturprinzipien aufbaut (siehe Abbildung 3).

Die im folgenden vorgestellten Arten von Arbeitsprodukte zur Definition einer DV-Architektur werden sowohl für die Architektur eines Systems wie für die Architektur einer Systemfamilie verwendet. Je nach Verwendung unterscheiden sich die Arbeitsprodukte jedoch in der Breite und Tiefe.

Arbeitsprodukte zur Beschreibung einer DV-Architektur

Funktionale und operationale Sicht

Die beiden zentralen Teile einer Architektur eines DV-Systems sind die softwaretechnische Architektur und die Infrastrukturarchitektur.

Die Infrastrukturarchitektur erfasst die holistische, operationale Sicht auf das System. Hierzu zählen unter anderem das technische System (mit Hardware, Plattformen, Lokationen, Verbindungen), die Platzierung der Softwarekomponenten in Rahmen des technischen Systems, die Konfiguration und das Management des Systems (Kapazitätsplanung, Softwareverteilung, Datensicherung und Wiederanlauf).

Die softwaretechnische Architektur erfasst die Softwarekomponenten, die auf den Hardwarekomponenten ausgeführt werden, d.h. die funktionale Sicht auf das System. Hierzu gehören unter anderem die Struktur und Aufteilung der Softwarekomponenten, die Schnittstellen der Komponenten, die Beziehungen zwischen den Komponenten und die Zusammenarbeit der Komponenten miteinander.

Abbildung 4 stellt die Arbeitsprodukte im Überblick dar, die in den Bereich der Systemarchitektur fallen. Arbeitsprodukte definieren die fassbaren (Zwischen-)Ergebnisse, d.h. „was“ für eine Architektur getan werden muss – unabhängig vom zeitlichen „wann“. Die Auswahl dieser Arbeitsprodukte zur Definition einer Architektur beruht auf den praktischen Erfahrungen, die wir in vielen Projekten gemacht haben und die sich in mehreren Schritten herauskristallisiert haben (siehe z.B. die Entwicklungsmethoden der IBM in [8], [9] und [10]). Eine ausführliche Darstellung der Arbeitsprodukte findet sich in [6] und [5].

Das in Abbildung 4 mit „Architektur DV-System (Gegenstandsebene)“ bezeichnete Paket enthält die Elemente der Architektur, welche die Gegenstandsebene betreffen (zur Gegenstandsebene siehe Abbildung 1). Im Wesentlichen sind dies das Komponentenmodell (component model) der Softwaretechnischen Architektur und das Operationale Modell (operational model) der Infrastrukturarchitektur. Zum Komponentenmodell gehören auch Architekturkomponenten, die der Anwendungsentwicklung zur Verfügung gestellt werden – z.B. gekaufte Komponenten oder von der Architekturgruppe entwickelte (Framework-)Komponenten. Installationseinheiten (deployment units) sind Komponeten Pakete, die auf den Knoten des Operationalen Modells platziert werden. Die zeitliche und organisatorische Lösung der Verteilung dieser Installationseinheiten zeigt der Verteilungs- Managementplan (software distribution plan). Die Architekturskizze (architecture overview diagram) entspricht dem mit „Gegenstandsebene“ bezeichneten Paket in einem frühen Stadium. Architekturmuster (architectural templates) stellen die Modellierungs- und Gestaltungsregeln auf der Metaebene dar, also Entwicklungsanleitungen zur Entwicklung der Architektur selbst sowie der einzelnen Anwendungssysteme; sie bilden zusammen mit dem inneren Paket „Gegenstandsebene“ die Architektur des DV-Systems.

Eine Architektur muss insgesamt die Anforderungen erfüllen, die durch eine Reihe von Arbeitsprodukten im Paket „Anforderungen“ festgehalten werden (utilitas). Die Anforderungen werden wiederum durch die Geschäftsarchitektur bestimmt, deren Prozesse durch die DV-Systeme unterstützt werden.

Bei der Definition einer Architektur ist es sinnvoll, auf bewährte Konzepte zurückzugreifen – die gezielte Auswahl von Referenzarchitekturen ist daher ein eigenes Arbeitsprodukt (reference architecture fit/gap analysis).

Schließlich muss eine Architektur überprüft werden. Einzelne Fragestellungen können ggf. durch Prototypen beantwortet werden. Darüber hinaus ist eine Überprüfung der Architektur notwendig hinsichtlich der Erfüllung der qualitativen und quantitativen nichtfunktionalen Anforderungen (service level characteristic analysis), wie auch gegenüber den Anforderungen insgesamt (viability assessment).

Nicht alle hier kurz dargestellten Arbeitsprodukte sind immer notwendig, und nicht jedes Arbeitsprodukt muss ein eigenes Dokument darstellen. Die Auswahl der für ein bestimmtes Projekt notwendigen Arbeitsprodukte, die Bestimmung der adäquaten Breite und Tiefe der Bearbeitung und ggf. die Zusammenfassung von Arbeitsprodukten zu einem Dokument ist einer der wichtigsten Aufgaben des Architekten bei der Projektplanung. Dies gilt gleichermaßen für die Auswahl der notwendigen Arbeitsprodukte für die Architektur einer Systemfamilie.

Architekturmanagement

Ziel und Definition des Architekturmanagements

Unternehmen müssen ihre DV-Strukturen langfristig beherrschen, warten und weiterentwickeln, damit die Systeme die jeweils aktuellen Wertschöpfungsketten unterstützen. Viele Unternehmen haben in der Vergangenheit festgestellt, dass sie miteinander verknüpfte Projekte nur unzureichend kontrollieren können und dass fachliche und technische Abhängigkeiten unklar sind. Letzteres kann bis zu dem Punkt gehen, dass geschäftliche Anforderungen und die durch die DVSysteme gegebenen Möglichkeiten so weit auseinanderklaffen, dass Marktchancen nicht realisiert werden können. Dies verursacht Kosten für unzureichend unterstützte Geschäftsabläufe und Opportunitätskosten für nicht realisierte Produkte oder Marktchancen. Ein weiteres Problem ist, dass in Projekten Technologien oder Software-Komponenten doppelt entwickelt werden und dass für Anpassungen oder Schnittstellen ein hoher Entwicklungaufwand notwendig ist – beides verursacht ebenfalls erhebliche Kosten.

Um dieses Problem zu lösen ist ein Architekturmanagement notwendig. Dieses entwickelt und pflegt die Architektur, so dass die strategischen und fachlichen Anforderungen kosten- und zeiteffizient erfüllt werden. Außerdem ist das Architekturmanagement dafür verantwortlich, dass die Architektur im Unternehmen gelebt wird. Während Projekte – und die Erstellung der systemspezifischen Architekturen – zeitlich begrenzte Vorhaben sind, ist Architekturmanagement eine dauerhafte Aufgabe.

Aufgaben des Architekturmanagements

Die obige Definition des Architekturmanagements zeigt die beiden zentralen Aufgaben auf (siehe Abbildung 5):

• Die DV-Architektur für die DV-Systeme des Unternehmens (Architektur für eine Systemfamilie, siehe Abschnitt 2.2) muss erstellt, gepflegt und weiterentwickelt werden. Diese DV-Architektur definiert eine einheitliche Basis für die DV-Systeme des Unternehmens. Die Definition der DV-Architektur erfolgt mit Hilfe der in Abschnitt 3 dargestellten Arbeitsprodukte.
• Um die Entwicklung der DV-Systeme und des Unternehmens zu verknüpfen und Klarheit über fachliche und technische Zusammenhänge zu gewinnen, muss eine Geschäftsarchitektur des Unternehmens (siehe Abschnitt 2.1) erstellt, gepflegt und weiterentwickelt werden. Diese Geschäftsarchitektur definiert eine einheitliche Basis für die Art und Weise, wie das Unternehmen „funktioniert“.

Theoretisch könnte die Entwicklung der Unternehmensarchitektur auch bei der Unternehmensführung angesiedelt werden. Die enge Verknüpfung der DV-Systeme und der Geschäftsarchitektur legt aber nahe, beide Aufgaben miteinander zu verbinden. Das Team muss interdisziplinär besetzt sein und Personen mit hohem fachlichen und Personen mit hohem technischen Know-How umfassen. Eine solche Bündelung der Aufgaben trägt auch der strategischen Bedeutung der DV-Systeme für den Unternehmenserfolg Rechnung.

Die dauerhafte Aufgabe des Architekturmanagements sollte klar definiert sein, d.h. dessen Organisation, Prozesse und Ressourcen sollten festgelegt sein. Erstellung, Weiterentwicklung und Kommunikation der Architektur im Unternehmen wird durch die Prozesse beschrieben. Hierzu gehören auch Prozesse zum Testen der Architektur und Ausnahmeregelungen (z.B. Fehlerbehebung, Änderung von Anforderungen). Die Organisation mit Rollen und Verantwortlichkeiten macht die Zuständigkeiten und Kompetenzen im Architekturmanagement klar und stellt dar, welche Organisationseinheiten eingebunden werden. Die Definition der Ressourcen legt fest, welche Arbeitsprodukte bzw. Ergebnisse vom Architekturmanagement erstellt bzw. benötigt werden.

Das Architekturmanagement steht mit seiner Arbeit im täglichen Spannungsfeld zwischen den strategischen Zielen, den konkreten fachlichen Anforderungen, den technologischen Rahmenbedingungen und der in Form von Projekten realisierten Weiterentwicklung der DV-Systeme und Unternehmensstrukturen. Die dokumentierte DV und Geschäftsarchitektur ist hierbei die Basis, um im täglichen Geschäft eine langfristige Ausrichtung und um eine Grundlage für fachliche und technologische Entscheidungen zu haben.

Für den Erfolg des Architekturmanagements ist eine langfristige Ausrichtung und eine Management-Unterstützung unabdingbare Voraussetzung. Darüber hinaus ist das Kow-How und die Akzeptanz der im Architekturteam beteiligten Personen und die enge Verzahnung von Projekten und dem Architekturmanagementteam von hoher Bedeutung. Ebenso ist eine pragmatische und an den Notwendigkeiten der Projekte orientierte Herangehensweise erforderlich. So kann z.B. für ein kleines Unternehmen alleine schon eine bewusste Gestaltung einer systemübergreifenden Architektur durch personelle Kontinuität und eine explizite Formulierung von Architekturgrundsätzen und -entscheidungen erreicht werden. Nicht zuletzt ist eine offene Kommunikation der Schlüssel für eine Akzeptanz.

Fazit

Eine Architektur bestimmt die Struktur eines Systems. Die explizite Definition einer Architektur ist unerlässlich, um die Systemstruktur nicht dem Zufall zu überlassen, sondern um sie gezielt zu gestalten. Aufgabe einer Architektur ist es, die Grundlagen für ein System bzw. für eine unternehmensweite Systemfamilie so zu legen, dass es die Anforderungen erfüllt, robust gegenüber Änderungen und verständlich ist. Die in diesem Artikel vorgestellten Arbeitsprodukte sind geeignet, eine Systemarchitektur umfassend bis hinunter auf die Detailebene zu modellieren. Diese Arbeitsprodukte werden von Architekten erstellt und müssen von den Anwendungsentwicklern als Nutzer der Architektur verstanden werden. Für ein konkretes Projekt ist es meist nicht erforderlich, alle vorgestellten Arbeitsprodukte als jeweils einzelne Dokumente zu erstellen, aber das Komponentenmodell, das Operationale Modell und die Architekturmuster sollten auf keinen Fall fehlen.

Um die Weiterentwicklung des Unternehmens und die der DVSysteme miteinander zu verknüpfen und langfristig ausrichten zu können, ist ein Architekturmanagement sinnvoll. Dessen Aufgabe ist es, die DV- und die Geschäftsarchitektur zu definieren, zu integrieren und weiterzuentwickeln.

Literaturverzeichnis

1. L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addisson-Wesley Publishing Company, Reading, 1998
2. L. Bass, R. Kazman: Architecture-Based Development, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI- 99-TR-007/ESC-TR-99-007, Pittsburgh, 1999
3. P. C. Clements, L. M. Northrop: Software Architecture: An Executive Overview, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI-96-TR-003/ESC-TR-96-003, Pittsburgh, 1999
4. Encyclopaedia Britannica Inc. (Hrsg.): The New Encyclopaedia Britannica, Macropaedia, Volume1, Stichwort Architecture, Seiten: 1088-1115, Encyclopaedia Britannica Inc, Chicago, 1978
5. M. Foegen, J. Battenfeld: Die Rolle der Architektur in der Anwendungsentwicklung, Informatik Spektrum, Band 24, Seiten 290-301, Springer Verlag, Heidelberg, 2001. Download unter www.wibas.de
6. M. Foegen, J. Battenfeld, P. Atamaniuk: Modellierung von Architekturen, in: T. Spitta, J. Borchers, H. M. Sneed (Hrsg.): Software Management 2002, Progress through Constancy, Seiten 119-130, Gesellschaft für Informatik, Bonn, 2002. Download unter www.wibas.de
7. D. W. McDavid: A standard for business architecture description, IBM Systems Journal, Vol. 38, No. 1, Seiten 12ff, IBM, 1999
8. IBM, Developing Object Oriented Software, An Experience-Based Approach, Prentice Hall, Upper Saddle River, 1997
9. IBM: IBM Global Services Method 3.0, Familie von Vorgehensweisen für Serviceprojekte, IBM internes Dokument, Dokument-Nummer ZZ81-0045-00, 2000
10. R. Youngs, D. Redmond-Pyle, P. Spaas, and E. Kahan: A standard for architecture description, IBM Systems Journal, Vol. 38, No. 1, Seiten 32ff, IBM, 1999
11. M. Werres: Enterprise Architecture Management – The IBM Approach, Vortrag für den GI Arbeitskreis „Enterprise Architecture“, akea.iwi.unisg.ch, 2002
12. K. Hildebrand: Informationsmanagement – Wettbewerbsorientierte Informationsverarbeitung mit Standard-Software und Internet, R. Oldenbourg Verlag, München, 2001

---