Business Engineering

Dienstorientierung im Business Engineering (S.46-47)

Business Engineering unterstützt die konsistente Entwicklung von Strategien, Prozessen und Informationssystemen. In letzter Zeit wird Dienstorientierung als Konstruktionsprinzip auf Softwareebene stark diskutiert. In diesem Beitrag wird untersucht, in welcher Form Dienstorientierung konzeptionell, d.h. auch auf den der Softwareebene übergeordneten Ebenen des Strategie-, Prozess- und Applikationsentwurfs zur Anwendung kommen kann. Für die fachlichen Gestaltungsebenen werden entsprechende Dienstkonstrukte vorgeschlagen, die Infrastrukturcharakter haben und damit die systematische Konstruktion entsprechender Artefakte auf der jeweiligen Ebene unterstützen.

Inhaltsübersicht

1 Dienstorientierung in der Unternehmensarchitektur
2 Architekturkonstrukte des Business Engineering
3 Dienste im Business-Engineering- Framework
3.1 Dienste auf Strategieebene
3.2 Dienste auf Prozessebene
3.3 Dienste auf Applikationsebene
4 Ausblick: Dienstorientierung vs. Infrastruktur
5 Literatur

1 Dienstorientierung in der Unternehmensarchitektur

Um wirksam zu werden, müssen strategische und/oder organisatorische Veränderungen auch die entsprechenden Informationssysteme einbeziehen. Leider folgen organisatorische Ablauf- bzw. Aufbaustrukturen und Informationssysteme unterschiedlichen Lebenszyklen. Die Analyse der Wirtschaftspresse macht deutlich, dass nicht nur »normale« Entwicklungsprojekte, sondern auch bereichs- oder sogar unternehmensweite Reorganisationsprogramme innerhalb von wenigen Quartalen wirksam werden müssen. Selbst für eine strategische Neuausrichtung (»Turnaround«) beschränken Investoren und Gläubiger den Zeitrahmen meist auf zwei bis maximal drei Jahre.

In den meisten Unternehmen geht die grundlegende Strukturierung vieler wichtiger Informationssysteme dagegen noch auf die 80er oder sogar 70er Jahre zurück, d.h., sie wurde häufig während mehr als zwanzig Jahren nicht fundamental verändert. Die großen Unterschiede der Lebenszyklen für Strategie, Organisation und Informationssysteme lassen sich mit der hohen Komplexität und den hohen Investitionskosten für Informationssysteme begründen.

Wenn auf Informationssystem-Ebene die Strukturierung aus fachlicher Sicht und aus technischer Sicht unterschieden werden, sind selbst innerhalb dieser Ebene verschiedene Lebenszyklen zu beobachten: Während die technische Architektur seit den 70er Jahren ein- bis zweimal grundlegend verändert wurde (z.B. von zentralen, großrechnerorientierten Strukturen zu Client-Server-Strukturen und aktuell weiter zu dienstorientierten Strukturen), dominiert als fachliche Architektur immer noch die ursprünglich aus den 70er und 80er Jahren stammende, siloartige Funktionalintegration.

Das in der Praxis feststellbare, nach einer ersten Welle Ende der 80er / Anfang der 90er Jahre wieder stärker werdende Interesse an Fragen der Unternehmensarchitektur ist auf folgende Entwicklung zurückzuführen: Nach diversen Technologieschüben (z.B. TCP/IP-Vernetzung, elektronische Vertriebskanäle, EAI, Portale), fachlich-strukturellen Veränderungen (z.B. Prozess- statt Funktionsorientierung, Verringerung der Fertigungstiefe, Integration mit Kunden und/oder Lieferanten) und fundamentalen Änderungen der IT-Strategie (z.B. von Individualentwicklung zum Standardsoftwareeinsatz, von homogenen Lösungen zum Best-of- Breed-Prinzip) ist die Heterogenität des betrieblichen Gesamtsystems so stark gestiegen, dass dieses nicht mehr beherrschbar erscheint und als zu unflexibel wahrgenommen wird und dass Betriebskosten als zu hoch angesehen werden. Das Ziel eines systematischen Managements der Unternehmensarchitektur ist deshalb, nachhaltige Bewirtschaftung des betrieblichen Gesamtsystems sicherzustellen, indem die verschiedenen Gesamtzusammenhänge aufeinander abgestimmt werden. Durch Sicherung der Konsistenz werden im Idealfall gleichzeitig die Flexibilität erhöht und die Betriebskosten gesenkt.

Laut einer Analyse in [Winter 2003a] unterscheiden die meisten Autoren dabei die folgenden Gesamtzusammenhänge des betrieblichen Systems:

- Geschäftsarchitektur als Gesamtzusammenhang der Leistungsverflechtung zwischen Organisationen in einem Wertschöpfungsnetzwerk

- Prozessarchitektur als Gesamtzusammenhang der Leistungsentwicklung, Leistungserstellung und des Leistungsvertriebs innerhalb einer Organisation

- Applikationsarchitektur als Gesamtzusammenhang der informatorischen Verflechtung von Applikationen innerhalb einer Organisation

- IT-Architektur als Gesamtzusammenhang der funktionalen Verflechtung zwischen Softwareartefakten einschl. Datenstrukturen innerhalb des Informationssystems

Im Business-Engineering-Ansatz repräsentieren die Gestaltungsebenen »Strategie«, »Prozess «, »Applikation« und »Software« diese Zusammenhänge (siehe [Winter 2003a] und auch den Beitrag von Österle & Blessing in diesem Heft). Durch ein umfassendes Metamodell, aufeinander abgestimmte Gestaltungstechniken, ein Rollenmodell usw. wird eine konsistente Entwicklung des betrieblichen Gesamtsystems unterstützt. Im Idealfall werden diese Ebenen »von oben nach unten« durchlaufen, d.h., jede Gestaltungsebene liefert Vorgaben, welche die Freiheitsgrade auf nachgelagerten Gestaltungsebenen einschränken. Spezielle Szenarien wie z.B. manche Standardsoftwareeinführungen oder der Abgleich zwischen auslagernden und ausführenden Organisationen erfordern jedoch auch »bottom-up« bzw. horizontale Vorgaben.