Informatik Spektrum Dezember 2006 Sonderdruck. hoher Qualität

Transkript

1 Informatik Spektrum Dezember 2006 Sonderdruck Regeln für serviceorientierte Architekturen hoher Qualität von Andreas Hess (sd&m), Prof. Dr. Bernhard Humm (Hochschule Darmstadt), Dr. Markus Voß (sd&m)

2 Informatik Spektrum Dezember 2006 Einleitung Das Schlagwort der serviceorientierten Architektur (SOA, siehe zum Beispiel [1, 3, 11, 15, 16, 24]) beherrscht gegenwärtig die Diskussion um die Gestaltung unternehmensweiter IT-Anwendungslandschaften. Unternehmen erwarten sich von einer SOA eine höhere Flexibilität ihrer Geschäftsprozesse sowie die Reduktion von IT-Kosten. Die Erreichung dieser Ziele ist möglich. Die Einführung einer SOA erfordert jedoch neben guter Planung auch eine fachliche Architektur von hoher Qualität (siehe zum Beispiel [17]): zuverlässig, effizient und vor allem änderbar. Aber wie erreicht man diese hohe Qualität? Wie ist eine Anwendungslandschaft zu gestalten? Wie sind n und Services zu schneiden? In der SOA- Literatur (zum Beispiel [1, 3, 11, 15, 24]) werden dazu allgemeine Hinweise gegeben. Leider stehen jedoch sowohl die Forschung als auch die Industrie noch am Anfang, wenn es um konkrete Regeln und nachprüfbare Kriterien für die Gestaltung von Anwendungslandschaften und den Entwurf von Services geht. Das Forschungsvorhaben Quasar Enterprise der sd&m AG adressiert genau diese Lücke: konkrete Regeln für den Aufbau einer SOA mit hoher Qualität vor allem im Hinblick auf Flexibilitätskriterien wie Erweiterbarkeit, Anpassbarkeit etc. Quasar Enterprise setzt das langjährige Forschungsvorhaben Quasar (Qualitäts-Software-Architektur, siehe zum Beispiel [2, 20]) bei sd&m fort. Quasar beschreibt Konzepte, Architektur und Lösungen für betriebliche Informationssysteme. Quasar Enterprise weitet den Fokus auf die Gestaltung ganzer Anwendungslandschaften und die Integration von Systemen. Seit nunmehr zwei Jahren kondensieren wir die Projekterfahrungen aus über zehn Integrationsprojekten und SOA-Vorhaben der sd&m AG der letzten fünf Jahre mit einem Gesamtvolumen von über 100 Bearbeiterjahren. In diesem Artikel veröffentlichen wir einen wesentlichen Teil unserer bisherigen Ergebnisse aus dem Teil von Quasar Enterprise, der SOA behandelt. Einige der Regeln sind schon konkret und nachprüfbar, andere sind noch eher Heuristiken, welche sich jedoch im Projektalltag bewährt haben. Weitere Ergebnisse von Quasar Enterprise, auf die wir in diesem Artikel nicht eingehen, sind Referenzarchitekturen, Integrationsebenen, Integrationsmuster [23] und Sicherheit in Anwendungslandschaften. Der Artikel ist wie folgt aufgebaut: Im nächsten Kapitel führen wir die Geschäftsarchitektur als Grundlage der Architektur von Anwendungslandschaften ein. Wesentliche Begriffe werden definiert. Danach stellen wir eine Referenzarchitektur für Anwendungslandschaften vor. Die drei folgenden Abschnitte beschreiben Regeln zur Gestaltung von n, Services und zur Kopplung von Systemen in Anwendungslandschaften. Im Anschluss beschreiben wir Projekt- erfahrungen mit der Anwendung der Regeln. Der Artikel endet mit einem Fazit und einem Ausblick auf weiterführende Arbeiten. Geschäftsarchitektur und Architektur von Anwendungslandschaften IT-Anwendungslandschaften Als IT-Anwendungslandschaft (oder kurz: Anwendungslandschaft) bezeichnen wir die Gesamtheit der betrieblichen IT-Anwendungen eines Unternehmens mit ihrer Vernetzung über Schnittstellen und Daten. Anwendungslandschaften gestalten heißt höchste Komplexität beherrschen. Anwendungslandschaften großer Unternehmen und Organisationen umfassen oft hunderte von einzelnen Anwendungen jede in sich komplex und mit vielen Abhängigkeiten untereinander. Serviceorientierte Architektur (SOA) SOA ist ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus einzelnen fachlichen, das heißt geschäftsbezogenen n beschreibt. Diese sind lose miteinander gekoppelt, indem sie einander ihre Funktionalität in Form von Services anbieten. Die Definition eines Service hat den Charakter einer vertraglichen Übereinkunft zwischen Service- Anbieter und Service-Nutzer. Services werden über einen einheitlichen Mechanismus aufgerufen, der die n plattformunabhängig miteinander verbindet und alle technischen Details der Kommunikation verbirgt [16]. Dies erlaubt es, Geschäftsprozesse auf der Basis von Services möglichst einfach zu implementieren und zu ändern. Geschäftsarchitektur Eine IT-Anwendungslandschaft ist kein Selbstzweck. Sie dient der Umsetzung und Unterstützung des Geschäfts eines Unternehmens. Die Geschäftsarchitektur eines Unternehmens umfasst unter anderem die Geschäftsstrategie, die Geschäftsprozesse mit den Akteuren in ihren verschiedenen Rollen und die Informationen, die im Rahmen der Geschäftsprozesse benötigt und erzeugt werden. Diese Bestandteile der Geschäftsarchitektur sind der Ausgangspunkt für die Gestaltung der Architektur einer Anwendungslandschaft. In diesem Artikel benennen wir nur kurz die Bestandteile der Geschäftsarchitektur, welche für die Gestaltung der Anwendungslandschaft wichtig sind, ohne sie präzise zu definieren. I Geschäftsstrategie: Die Geschäftsstrategie eines Unternehmens lässt sich im Kern auf die Frage zurückführen, mit welchen Produkten beziehungsweise Dienstleistungsangeboten es auf welchen Märkten auftritt und welche Fertigungstiefe es dabei verfolgt. Die Strategie liefert sowohl Kriterien für die Strukturierung des Geschäfts selbst (siehe Geschäfts- 2

3 domänen unten) als auch Kriterien für die Strukturierung der IT-Anwendungslandschaft. I Geschäftsdomänen sind Segmente im Unternehmen, die einen Einfluss auf Prozesse und Organisation haben, wie zum Beispiel Kundengruppen, Märkte, Lieferanten, Produkt- oder Dienstleistungstypen, geografische Niederlassungen, Vertriebswege, Technologie usw. I Geschäftsprozesse: Ein Geschäftsprozess ist eine Folge von Arbeitsschritten zur Erreichung eines geplanten Arbeitsergebnisses in einem Unternehmen. Er dient direkt oder indirekt der Erzeugung einer Leistung für einen Kunden oder den Markt. I Geschäftsfunktionen: Geschäftsfunktionen entsprechen Arbeitsschritten, die aus fachlicher Sicht eine Einheit bilden. I Geschäftsobjekte sind reale Objekte der Geschäftswelt. Diese können materieller Art sein zum Beispiel ein Bestellformular oder immaterieller Art zum Beispiel die Bestellung des Kunden im Lokal, die der Kellner sich im Gedächtnis merkt. Die Geschäftsarchitektur eines Unternehmens ist zunächst einmal unabhängig von IT-Systemen. Auch Jakob Fuggers Kontore aus dem 16. Jahrhundert hatten eine Geschäftsarchitektur lange vor der Erfindung des Computers. In heutigen Unternehmen bildet die Geschäftsarchitektur den Ausgangspunkt für die Gestaltung der IT-Anwendungslandschaft. Architektur von Anwendungslandschaften Um die Komplexität einer Anwendungslandschaft in den Griff zu bekommen, definieren wir Begriffe zu deren Strukturierung. Siehe Abb. 1. I Anwendungsdomänen: Eine Anwendungsdomäne (im Folgenden auch kurz als Domäne bezeichnet) fasst eine Menge von Anwendungskomponenten zusammen, die aus Sicht der Geschäftsarchitektur sinnvollerweise gemeinsam betrachtet werden. I Anwendungskomponenten: Nach [20] ist eine die wesentliche Einheit des Entwurfs, der Implementierung und der Planung. Sie exportiert und importiert Schnittstellen und verbirgt ihre Implementierungsdetails. Diese allgemeine Definition kann sowohl auf ganze Anwendungslandschaften als auch auf ihre hierarchisch gegliederten Bestandteile bis hin zu einzelnen Klassen angewandt werden. Im Folgenden sprechen wir von Anwendungskomponenten oder kurz von n, meinen aber stets n im Großen, also auf der Ebene von Anwendungslandschaften. I Anwendungsservices: Anwendungsservices (oder kurz Services) bilden die Schnittstellen von Anwendungskomponenten. Ein Service bietet eine definierte fachliche Funktionalität, die als Bestandteil eines größeren Verarbeitungsablaufs verwendet werden kann. Als solcher stellt der Service eine abstrakte Sicht auf die exportierende dar und verbirgt alle Implementierungsdetails. Die Definition eines Service hat den Charakter einer vertraglichen Übereinkunft zwischen Service-Anbieter und Service-Nutzer (Service Level Agreement SLA). I Anwendungsservice-Operationen: Anwendungsservice-Operationen oder kurz Operationen bilden die eigentliche Funktionalität von Services. Die Signatur einer Operation ist definiert durch die Eingabeparameter und ihre Typen und optional durch den Typ eines Rückgabewerts. Dieser subsumiert auch Ausnahmen. Den Begriff der Anwendung verwenden wir nur informell als die von Anwendern als sinnvoll erachtete Zusammenfassung von n. Von der Geschäftsarchitektur zur Architektur der IT- Anwendungslandschaft Die Geschäftsarchitektur bildet den Ausgangspunkt für die Gestaltung der Architektur der IT-Anwendungslandschaft. Dabei sind die Anwendungsdomänen in idealen Anwendungslandschaften identisch mit den Geschäftsdomänen (geschäftsorientierte Abb. 1: Elemente einer IT-Anwendungslandschaft Anwendungslandschaft Domäne 1 Domäne Service Service Service Domäne Service Abhängigkeit 3

4 Gestaltung der Anwendungslandschaft). In gegebenen, nicht ideal geschnittenen Anwendungslandschaften dienen Anwendungsdomänen vor allem als Mittel zur Beschreibung des Zielzustands einer Migration, zum Beispiel in sogenannten Business-IT-Alignment-Projekten. Ein Arbeitsschritt in einem Geschäftsprozess kann sowohl manuell als auch automatisiert (systemunterstützt) ablaufen. Systemunterstützte Arbeitsschritte werden mithilfe von Anwendungsfällen (Use Cases [9]) näher beschrieben und die im Zusammenhang mit einem Anwendungsfall durchzuführenden Aktivitäten werden über Serviceoperationen realisiert. In diesem Sinne vermitteln Anwendungsfälle beim Übergang von der Geschäftsarchitektur zur Anwendungslandschaft und beeinflussen wesentlich den Zuschnitt der Services und ihrer Operationen. Darüber hinaus muss man Services beziehungsweise n einer Anwendungslandschaft danach unterscheiden, welchem Zweck sie primär dienen. So obliegt die Durchführung von komplexen Geschäftsfunktionen den Services von sogenannten Funktionskomponenten (siehe unten). Die Informationen von Geschäftsobjekten, welche in IT-Systemen abgebildet werden, werden über Services von sogenannten Bestandskomponenten bereitgestellt. Automatisierte Geschäftsprozesse werden hingegen als Services von so genannten Prozesskomponenten implementiert. Letztere werden in modernen serviceorientierten Architekturen idealerweise technisch über Engines realisiert, die Modelle der Geschäftsprozesse ausführen und dabei über die sogenannte Orchestrierung Services der zuerst genannten Arten aufrufen. Dieses Konzept der Kategorisierung von Services wird weiter unten genauer beschrieben. Es stellt eine Referenzarchitektur zur Strukturierung von Anwendungslandschaften dar. Hieraus, wie auch aus generellen architektonischen Überlegungen, leiten wir dann die Regeln zum Design von n und ihren Services für serviceorientierte Architekturen hoher Qualität im oben genannten Sinne ab. Referenzarchitektur Anwendungslandschaft Servicekategorien Sorgfältig gestaltete Anwendungslandschaften folgen neben der Strukturierung in Anwendungsdomänen einer Strukturierung nach Servicekategorien. Wenn der Kontext klar ist, sprechen wir kurz von Kategorien. Die folgenden Kategorien unterscheiden wir: I Bestand: Verwaltung von Datenbeständen und Zugriff auf diese I Funktion: Implementierte fachliche Funktionalität I Prozess: Implementierte Geschäftsprozesse I Interaktion: Benutzerinteraktion mit einer Anwendungslandschaft In erster Linie sind die Operationen in einer Anwendungslandschaft einer Kategorie zugeordnet. Sind alle Operationen eines Service von ein und derselben Kategorie, so ist auch der Service von dieser Kategorie. Sind alle Services einer von einer Kategorie, so ist auch die von dieser Kategorie. Wir sprechen dann von Bestandsoperationen, Bestandsservices und Bestandskomponenten die Bezeichnungen in den anderen Kategorien lauten analog. So verwaltet beispielsweise die Bestandskomponente Partnerverwaltung nur Zugriffe auf den Datenbestand an Geschäftspartnern, führt aber kein Rating von Kunden nach deren Bonität durch. Dies ist Aufgabe der Funktionskomponente Kundenrating, die dazu beispielsweise neben den Services der Partnerverwaltung auch Services der Vertragsverwaltung verwendet. In den nachfolgenden Abschnitten erläutern wir die Kategorien im Detail. Abb. 2: Referenzarchitektur Anwendungslandschaft Domänen Kategorien Die Referenzarchitektur in der Übersicht In einer ideal strukturierten Anwendungslandschaft sind alle n eindeutig kategorisiert. Abb. 2 veranschaulicht dies in der Referenzarchitektur Anwendungslandschaft. Die Referenzarchitektur stellt eine idealisierte Blau- Interaktions- n Prozess- n Funktions- n Bestands- n Domäne Interaktionskomponente Prozesskomponente Funktionskomponente Bestandskomponente Abhängigkeit 4

5 pause für die Gestaltung einer Anwendungslandschaft dar. Sie destilliert Projekterfahrungen von qualitativ hochwertigen Anwendungslandschaften und wird als Startpunkt für die Ist-Analyse und Sollkonzeption von Anwendungslandschaften verwendet. Gemäß der Referenzarchitektur wird eine Anwendungslandschaft in erster Linie nach Anwendungsdomänen strukturiert (vertikal als Säulen dargestellt). In zweiter Linie werden die n einer Anwendungslandschaft nach den Kategorien strukturiert in der Referenzarchitektur horizontal als Schichten dargestellt. In den nachfolgenden Abschnitten definieren wir die n der einzelnen Kategorien. Die Darstellung der Kategorien als Schichten der Referenzarchitektur erinnert an die klassische Drei- Schichten-Architektur (zum Beispiel [26]). In der Drei- Schichten-Architektur werden einzelne Anwendungen nach Präsentation, Anwendungskern und Datenhaltung strukturiert. Die Servicekategorien sind aber keinesfalls mit den Schichten einer Anwendung zu verwechseln. n aller vier Servicekategorien können alle drei Schichten beinhalten. Beispielsweise ist eine Partnerstammdatenanwendung von der Servicekategorie Bestand. Sie umfasst jedoch sowohl einfache Dialoge zur Partnerpflege (Präsentation), einen einfachen Anwendungskern mit Plausibilitätsprüfungen als auch als wesentlichen Bestandteil die Datenhaltung. Anmerkung: Die saubere Trennung aller n einer Anwendungslandschaft nach den Kategorien stellt eine idealisierte Sicht dar. In realen Anwendungslandschaften sind die n selten so klar oder nach anderen Kriterien (zum Beispiel technikorientiert) getrennt. Am Ende des Artikels beschreiben wir Regeln zum Umgang mit realen Anwendungslandschaften. Bestandskomponenten Bestandskomponenten haben die Hoheit über jeweils einen Ausschnitt der Geschäftsdaten eines Unternehmens. Ihre Services umfassen die CRUD-Operationen (Create, Read, Update, Delete) sowie darauf aufbauend komplexe Pflegeoperationen und lesende Sichten auf die gespeicherten Geschäftsdaten. Bestandskomponenten kennen fachliche Konsistenzbedingungen und überwachen diese bei der Datenpflege. Sie implementieren elementare, auf die Daten bezogene fachliche Logik wie beispielsweise die Buchung eines Umsatzes oder Historienführung für Daten. Darüber hinausgehendes fachliches Wissen besitzen sie nicht. Funktionskomponenten Funktionskomponenten bieten Services an, welche die Geschäftsfunktionen eines Unternehmens unterstützen. Beispiele von Operationen solcher Services sind die Einplanung von Aufträgen, die Bonitätsprü- fung und Klassifikation von Kunden sowie die Erstellung von Abrechnungen. Viele dieser Services sind für sich allein sinnvoll, andere lassen sich nur im Kontext und unter der Kontrolle eines Geschäftsprozesses ausführen. Funktionskomponenten nutzen Services der Bestandskomponenten. Die Integration verschiedener Funktionsservices erfolgt über Prozesskomponenten. Prozesskomponenten Jede Prozesskomponente unterstützt einen oder mehrere Geschäftsprozesse. Ihre Aufgabe ist die Steuerung von Abläufen gemäß den Geschäftsregeln meist über verschiedene Funktionskomponenten hinweg. Darunter fallen sowohl vollständig automatisierte Abläufe als auch Abläufe mit Benutzerinteraktion. Prozesskomponenten verwenden Services anderer Prozesskomponenten sowie die Services von Funktionsund Bestandskomponenten. Eine Prozesskomponente muss keine manuell programmierte und unabhängig installierbare Einheit sein. Zunehmend werden Geschäftsprozesse mittels Workflow-Werkzeugen modelliert und ausgeführt. Aber auch dann ist es sinnvoll, Einheiten zusammengehöriger Geschäftsprozesse zu bilden auch diese nennen wir n. Interaktionskomponenten Zahlreiche Anwender verschiedener Gruppen nutzen die Services einer Anwendungslandschaft. Dabei bedienen sie sich meist mehrerer Kanäle. Beispiele sind Intranet-Portale für Innendienstmitarbeiter, Anwendungen auf mobilen Endgeräten für Außendienstmitarbeiter sowie Internet-Portale für Kunden. Interaktionskomponenten ermöglichen Anwendern den Zugang zu den Services einer Anwendungslandschaft. Nach außen bieten sie eine einheitliche Sicht auf unterschiedliche n und Anwendungen, die in einem gemeinsamen Rahmen integriert werden. Idealerweise ist die Grenze zwischen einzelnen Anwendungen für den Anwender nicht mehr sichtbar. Dies wird beispielsweise unterstützt durch ein einheitliches Layout und durch Funktionen wie Single Sign-on. Die Services von Interaktionskomponenten sind die Benutzerschnittstellen selbst. Insofern unterscheiden sich Interaktionskomponenten von den n der anderen drei Kategorien, deren Services Schnittstellen im softwaretechnischen Sinne sind. Beispiel Abb. 3 zeigt beispielhaft einen Ausschnitt aus der Anwendungslandschaft einer Versicherung. Im Beispiel werden zwei Domänen unterschieden: Partner und Vertrag. Die Bestandskomponente Partnerstammdaten ist der Domäne Partner zugeordnet. Dies könnte eine Mainframe-Anwendung sein oder auch Bestandteil eines Customer-Relationship-Management -(CRM-)Systems. Sie enthält auch eine eige- 5

6 Kategorien Interaktions- n Prozess- n Funktions- n Bestands- n Domänen Partner Vertrag Call-Center Internet-Antrag Berater-Laptop Antrag bearbeiten Antragsberechnung Partner-Stammdaten Vertragsdaten Domäne Interaktionskomponente Prozesskomponente Funktionskomponente Bestandskomponente Abhängigkeit Lokale Präsentation Abb. 3: Beispiel Anwendungslandschaft gemäß Referenzarchitektur ne Präsentationsschicht zum Pflegen von Partnerdaten durch Sachbearbeiter. Über ihre Services wird diese aber auch aus dem Call-Center genutzt eine Interaktionskomponente. Mitarbeiter des Call-Center können Auskunft über Kunden- und Vertragsdaten geben. Für die Bearbeitung von Versicherungsanträgen sind zwei Kanäle vorgesehen: eine Internet-Anwendung und eine Anwendung auf einem Berater-Laptop. Beides sind Interaktionskomponenten, welche der Domäne Vertrag zugeordnet sind. Hinter der Antragsbearbeitung liegt ein komplexer Workflow mit unterschiedlichen Stufen der Freigabe. Dieser sei in einem Workflow-System implementiert eine Prozesskomponente. Diese benutzt komplexe Versicherungsmathematik zur Antragsberechnung, welche in einer Funktionskomponente einer individuell entwickelten Host-Anwendung implementiert ist. Diese wiederum legt alle Daten in einer Bestandskomponente Vertragsdaten ab. Die Referenzarchitektur Anwendungslandschaft liefert einen Startpunkt für die Gestaltung einer Anwendungslandschaft. Anschließend müssen im Detail n und Services gestaltet werden. Die folgenden Kapitel liefern dazu Regeln. Regeln für den nschnitt Übersicht Was ist der richtige nschnitt? Das ist eine der wichtigsten Fragen, die sich ein IT-Architekt stellen muss. Diese Frage ist aber auch für den Manager relevant, der die Implementierung des nschnitts finanzieren muss. Denn reale Anwendungslandschaften sind nie ideal, das heißt von optimaler Qualität. Die Kunst des Architekten besteht darin, unter den gegebenen Randbedingungen existierende Altsysteme, vorhandenes Know-how, bestehende Infrastruktur, Performanceanforderungen, Zeit und Budget eine adäquate Lösung zu erarbeiten. In den folgenden Abschnitten beschreiben wir Regeln für den nschnitt. Die Regeln sind jeweils mit einer Nummer und durch Kursivdruck kenntlich gemacht. Sie geben Hilfestellungen aus architektonischer Sicht mit dem Ziel, Anwendungslandschaften wartbar und flexibel erweiterbar zu gestalten. In der Praxis werden jedoch selten alle Kriterien eingehalten das wäre aufgrund unterschiedlicher Randbedingungen auch nicht adäquat. Auch stehen die Regeln im praktischen Einsatz manchmal untereinander im Konflikt. Entscheidet sich jedoch ein Architekt explizit für die Verletzung einer der Regeln, so sollte er wissen, was er tut, und die möglichen Folgen bewusst abwägen. Fachliche n R1: n sollen nach fachlichen Kriterien gebildet werden. Kriterien für die nbildung sind: I Fachlichkeit, die von unterschiedlichen Sponsoren und Organisationseinheiten definiert wird, soll getrennt werden I Fachlichkeit, die sich bezüglich Märkten, Produkten oder Partnern unterscheidet, soll getrennt werden I Fachlichkeit, die sich bezüglich der unterstützten Geschäftsprozesse unterscheidet, soll getrennt werden I Fachlichkeit unterschiedlicher Fertigungstiefe soll getrennt werden I Fachlichkeit, die sich aufgrund rechtlicher Bestimmungen oder anderer Einflüsse unterschiedlich häufig ändert, soll getrennt werden I Sich schnell ändernde Geschäftsobjekte (Bewegungsdaten) sollen von sich langsam ändernden Geschäftsobjekten (Stammdaten) getrennt werden Die nbildung nach fachlichen und nicht nach technischen Kriterien erleichtert die Weiterentwicklung der Anwendungslandschaft bei sich ändernden Geschäftsanforderungen. n nach Servicekategorien R2: Alle Operationen einer sollen von genau einer Kategorie (Bestand, Funktion, Prozess, Interaktion) sein. Das ist nicht selbstverständlich und in der Praxis selten durchgängig der Fall. Gerade Bestandskomponenten sind selten von Funktionskomponenten 6

7 getrennt. Probleme, die aus der Vermischung der Servicekategorien resultieren, zeigen sich häufig erst Jahre später, zum Beispiel wenn redundante Stammdatenbestände harmonisiert werden sollen. Dann besteht ein beträchtlicher Projektaufwand darin, die Datenverwaltung von Geschäftsfunktionen der Anwendungen zu trennen Aufwand, der bei einer sorgfältigen Trennung zu Beginn hätte vermieden werden können. Abhängigkeiten gemäß Servicekategorien n haben Abhängigkeiten untereinander. Diese können die Ausprägungen haben kennt, ruft auf und bezieht Daten von. R3: n unterschiedlicher Servicekategorien sollen ausschließlich Abhängigkeiten gemäß der Referenzarchitektur Anwendungslandschaft (Abb. 2) haben. Konkret bedeutet dies: I Interaktionskomponenten sollen höchstens Abhängigkeiten untereinander oder zu Prozess-, Funktions- und Bestandskomponenten haben I Prozesskomponenten sollen höchstens Abhängigkeiten untereinander oder zu Funktions- und Bestandskomponenten haben I Funktionskomponenten sollen höchstens Abhängigkeiten untereinander oder zu Bestandskomponenten haben I Bestandskomponenten sollen ausschließlich Abhängigkeiten untereinander haben. Die Einhaltung der Regel erleichtert das Austauschen einzelner n der Anwendungslandschaft. Keine zyklischen Abhängigkeiten R4: Die Abhängigkeiten (kennt/ruft auf/bezieht Daten von) zwischen n sollen einen gerichteten azyklischen Graphen bilden. Diese Regel ist hinreichend aus der Literatur bekannt (zum Beispiel [4, 14]) sie ist auch für n in Anwendungslandschaften wichtig, da sie deren Austausch vereinfacht. Enger Zusammenhalt, geringe Kopplung R5: n sollen so geschnitten werden, dass sie intern einen engen Zusammenhalt haben und untereinander gering gekoppelt sind. Auch diese bekannte Design-Regel [6] gilt analog für n auf der Ebene von Anwendungslandschaften. Die Regel erleichtert Änderungen von n aufgrund fachlicher oder technischer Gegebenheiten. Auf die lose Kopplung zwischen n gehen wir weiter unten detailliert ein. Datenhoheit R6: Bestandskomponenten sollen die Datenhoheit über alle Geschäftsobjekte haben. Das bedeutet: Der Zugriff auf alle Geschäftsobjekte soll ausschließlich über Bestandskomponenten erfolgen. Jede Bestandskomponente soll einen disjunkten Ausschnitt aller Geschäftsobjekte des Unternehmens verwalten. Schreibende Zugriffe (anlegen, ändern, löschen) sowie möglichst auch lesende Zugriffe auf die Geschäftsobjekte sollen ausschließlich über Services der Bestandskomponente erfolgen. Dabei sollen sie jederzeit die fachliche Integrität der Daten sicherstellen. In realen Anwendungslandschaften ist Datenredundanz die Regel, nicht die Ausnahme siehe auch den Abschnitt über ideale und reale Anwendungslandschaften unten. Dennoch ist es möglich, mit Mitteln der Datenintegration (zum Beispiel [12], [18]) redundante Datenbestände zu harmonisieren und über Bestandsservices nutzenden n zur Verfügung zu stellen. Das Prinzip der Datenhoheit geht auf die grundlegenden Arbeiten von Parnas zur Modularisierung zurück (zum Beispiel [13]). Es erleichtert die Implementierung fachlicher Änderungen. Regeln für das Design von Services und ihren Operationen Übersicht Im letzten Abschnitt haben wir Regeln für den Schnitt von n formuliert. Services sind die Schnittstellen zu n. Sie sollen eine fachlich sinnvolle Gruppierung von Operationen bilden. Auch das Design der Operationen ist entscheidend für die Qualität einer Anwendungslandschaft. Daher formulieren wir auch dafür Regeln. Siehe Abb. 4 für eine Übersicht. Einige Regeln des Designs von Operationen gelten für alle Servicekategorien (Bestand, Funktion, Prozess, Interaktion), andere nur für bestimmte Kategorien. Wir unterscheiden die folgenden Arten von Operationen: I Elementar: Elementare Operationen stellen einfache Basisfunktionalität bereit. I Zusammengesetzt: Zusammengesetzte Operationen werden durch Aufrufe elementarer oder anderer zusammengesetzter Operationen implementiert. I Orchestrierbar: Unter Orchestrierung verstehen wir die möglichst einfache Implementierung von Geschäftsprozessen auf der Basis von Services. Um flexibel neue Geschäftsprozesse in einem Unternehmen zu implementieren, ist es wichtig, Services bereitzustellen, mit denen Geschäftsprozesse möglichst einfach implementiert werden können. Solche Services bezeichnen wir als orchestrierbar. Orchestrierbarkeit ist wichtig für alle Operationen von Prozesskomponenten sowie für die Operationen von Funktions- und Bestandskomponenten, welche direkt von Prozesskomponenten genutzt werden. Selbstverständlich können sowohl elementare als auch zusammengesetzte Operationen orchestrierbar sein. In den folgenden Abschnitten formulieren wir eine Reihe von Regeln für das Design von Services und 7

8 Kategorie Art Regeln Interaktion Prozess Funktion, Bestand zusammengesetzt elementar orchestrierbar technikneutral, referenzfrei grobgranular, idempotent normal kontextfrei Service Abhängigkeit Abb. 4: Regeln für das Design von Serviceoperationen ihren Operationen teilweise unterschieden nach Kategorien und Arten. Für alle Operationen fordern wir die Eigenschaften technikneutral und referenzfrei. Orchestrierbare Operationen sollen zusätzlich grobgranular und idempotent sein. Die Menge der elementaren Operationen einer muss zusätzlich normal (vollständig und redundanzfrei) sein. Für alle Funktions- und Bestandsoperationen fordern wir die Kontextfreiheit. Technikneutral R7: Jede Serviceoperation soll ausschließlich fachliche Funktionalität bereitstellen und nichts über die eingesetzte Implementierungstechnik verraten. Implementierungstechnik umfasst die eingesetzten Programmiersprachen, technische Infrastruktur wie Datenbanken, Betriebssysteme und Hardware-Plattformen. Die Regel reduziert den Anpassungsaufwand an einer rufenden, wenn technische Änderungen an der gerufenen durchgeführt werden. Referenzfrei R8: Die Parameter von Serviceoperationen (Eingabeund Rückgabeparameter) sollen niemals Referenzen auf interne Objekte enthalten. Das bedeutet, dass Operationen stets call-by-value und niemals call-by-reference aufgerufen werden. Statt Referenzen, zum Beispiel auf Entitäten, sollen nur fachliche oder technische Datentypen oder Transportstrukturen bestehend aus Datentypen übergeben werden. Siehe Abb. 5 für Beispiele. Die Referenzfreiheit entkoppelt rufende und gerufene (siehe auch [20]). Normal (vollständig und redundanzfrei) Wir definieren, dass die Operationen einer in Normalform oder kurz normal sind, wenn sie vollständig und redundanzfrei sind [8]. Vollständig bedeutet, dass die die geforderte nach außen sichtbare Fachlichkeit implementieren muss: Abfragen (lesende Operationen), die einen vollständigen Zugriff auf den Zustand der erlauben, und Kommandos (schreibende Operationen), die alle erlaubten Zustände erreichen. Das ist eigentlich selbstverständlich, aber leider in der Praxis doch nicht immer der Fall. Redundanzfreiheit bedeutet, dass weder in Abfragen noch in Kommandos Arbeit doppelt gemacht wird. R9: Die elementaren Operationen einer sollen in Normalform, das heißt vollständig und redundanzfrei sein. Redundanzen zu vermeiden ist immer eine gute Idee, da dies den Erstellungs- und Änderungsaufwand für n reduziert. Nichts einzuwenden ist jedoch gegen bewusst eingesetzte Redundanz: aus Gründen der Nutzungsfreundlichkeit der Schnittstelle oder aus Gründen der Performance. Insofern dürfen zusammengesetzte Operationen Redundanzen beinhalten für elementare Operationen fordern wir aber die Normalform. Grobgranula Wenige Aufrufe, die viel bewirken, sind besser als viele Aufrufe, die erst zusammen den gewünschten Effekt erzielen. So ist es beispielsweise sinnvoll, alle Kundendaten zu einer Kundennummer mit einer einzigen Operation zur Verfügung zu stellen, als dem Aufrufer zuzumuten, Name, Adresse usw. einzeln abzuholen. R10: Orchestrierbare Serviceoperationen sollen grobgranular sein. Abb. 5: Referenzfreiheit Parameterart Beispiele erlaubt Technischer Datentyp String, Integer Ja Fachlicher Datentyp Adresse, ISBN Ja Transportstruktur BuchRecord Ja Entitätsobjekt Buch Nein 8

9 Grobgranularität reduziert die Anzahl von Services, deren Erstellungs- und Änderungsaufwand. Die Orchestrierung von Prozessen aus Serviceoperationen gestaltet sich weniger komplex, wenn die Operationen grobgranular sind. Idempotent Idempotente Serviceoperationen zeichnen sich dadurch aus, dass ein mehrmaliger Aufruf mit denselben Parametern denselben Effekt hat wie der einmalige. Beispiel: Einmal stornieren genügt; ein zweiter Aufruf der Storno-Operation bleibt ohne Wirkung und richtet daher keinen Schaden an. R11: Orchestrierbare Operationen sollen, falls fachlich sinnvoll und möglich, idempotent sein. Idempotenz wirkt sich positiv auf die Robustheit von Anwendungen aus. Die Orchestrierung robuster Prozesse aus Operationen ist einfacher, wenn die Operationen idempotent sind. Kontextfrei R12: Operationen von Funktions- und Bestandskomponenten sollen kein Wissen über den Kontext haben, in dem sie aufgerufen werden, und entsprechend über den Aufrufkontext keine Annahmen machen. Es gibt verschiedene Arten von Aufrufkontexten: I Sessionkontext: Serviceoperationen sollen weder Benutzer noch Sessions kennen und kein Wissen über den Aufrufkontext benötigen. Sie sollen ausschließlich fachliche Funktionen implementieren. Die Berechtigungsprüfung soll außerhalb der fachlichen Operation erfolgen. I Transaktionskontext: Serviceoperationen sollen keine Annahmen über ihren Transaktionskontext machen. Regeln zur transaktionalen Koppelung von Operationsaufrufen beschreiben wir unten. I Batch-/Online-Betrieb: Idealerweise sollen Serviceoperationen von Funktions- und Bestandskomponenten sowohl im Batch- als auch im Online-Betrieb nutzbar sein und keine Annahmen über den Modus machen. Die Kontextfreiheit hat den Zweck, rufende und gerufene zu entkoppeln. Sie erhöht die Wiederverwendbarkeit von Services und ist daher besonders vorteilhaft für orchestrierbare Services. Beispiel In der fachlichen Referenzarchitektur für die Versicherungsbranche [21] ist für die Partner nur eine Serviceoperation (in der VAA als Anwendungsfall bezeichnet) Partner ändern definiert, aber interessanterweise weder eine Operation Partner anlegen noch eine Operation Partner löschen. Die Operation Partner ändern beinhaltet laut Spezifikation die folgende Funktionalität: I Prüfung, ob Partner bereits besteht. Falls nicht: Neuanlage I Änderung der Eigenschaften des Partners. Dies kann auch das logische Löschen des Partners beinhalten I Validierung der Änderungen I Dublettenprüfung: bei Identifikation von Dubletten Anstoßen der Operation Dubletten zusammenlegen Dieses auf den ersten Blick überraschende Servicedesign erfüllt alle obigen Kriterien: I Technikneutral: Die Spezifikation der Operation verrät nichts über die eingesetzte Implementierungstechnik I Referenzfrei: Ein- und Ausgabeparameter sind nur Datentypen beziehungsweise fachliche Schlüssel I Normal (vollständig und redundanzfrei): Durch das Zusammenlegen der Funktionalität von Anlegen und Ändern wird eine Redundanz vermieden. Die Schnittstelle ist auch vollständig, da sowohl das Anlegen, das Ändern wie auch das logische Löschen möglich sind. Daher ist die Schnittstelle in Normalform. I Grobgranular: Die Operation umfasst nicht nur alle möglichen Attributänderungen eines Partners, sondern auch das Anlegen und logische Löschen. Ein physisches Löschen von Partnern ist fachlich nicht vorgesehen. I Idempotent: Die Dublettenprüfung stellt die Idempotenz der Operation auch bei einer Neuanlage sicher. Beim ersten Aufruf der Operation wird der Partner neu angelegt. Bei jedem weiteren Aufruf mit identischen Parametern identifiziert die Dublettenprüfung das bereits vorhandene Partnerobjekt. Die Funktionalität für das Ändern und logische Löschen ist von Natur aus idempotent. I Kontextfrei: Sessionkontext: Die Operation kennt keine Benutzer und keine Sessions Transaktionskontext: Die Operation macht keine Annahmen über den Transaktionskontext Batch-/Online-Betrieb: Die Spezifikation der Operation enthält keine Spezifika über den Betriebsmodus Nachdem wir in diesem Kapitel Regeln für das Design von Services und ihren Operationen beschrieben haben, beschreiben wir im nächsten Kapitel Regeln für den Aufruf von Operationen zwischen n. Lose Koppelung Eines der Grundprinzipien der SOA ist die lose Koppelung. Lose Koppelung fördert die Unabhängigkeit und damit die Wartbarkeit und Austauschbarkeit von n einer Anwendungslandschaft. Aber lose Koppelung kostet auch viel: erhöhten Aufwand für Integrationstechnik, Fehlerbehandlung und Sicherheit sowie schlechtere Performance. Die Kunst des Architekten besteht darin, den angemessenen Grad der Koppelung zu wählen. In diesem Kapitel stellen wir dazu Regeln vor. 9

10 Inhaltliche Entfernung von n Ein wichtiges Kriterium für die Wahl eines angemessenen Grades von Koppelung ist die Entfernung einer rufenden zu einer gerufenen. Siehe Abb. 6. Die Entfernung zweier n hat zwei Dimensionen: die fachliche Entfernung und die technische Entfernung. n sind fachlich weit entfernt, wenn sie wenig fachliche Gemeinsamkeiten haben, besonders wenn sie unterschiedlichen Domänen zugeordnet sind. n sind technisch weit entfernt, wenn sie unterschiedlichen Kategorien zugeordnet sind. In Abb. 6 werden die Entfernungen von n anhand der Abstände in einer zweidimensionalen Darstellung der Anwendungslandschaft anschaulich gemacht. Ein numerisches Maß für die Entfernung von n kennen wir nicht definitiv ist dies nicht der Abstand der nsymbole auf einem Schaubild der Anwendungslandschaft in Zentimetern! Dennoch gelingt es in der Praxis häufig intuitiv, n als mehr oder weniger entfernt einzustufen. Der richtige Grad der Koppelung von n hängt von ihrer Entfernung ab. Siehe Abb. 7. Das Vertrauen in die Zuverlässigkeit bezüglich der Einhaltung von Service Levels das umfasst funktionale Korrektheit, Sicherheit, Zuverlässigkeit, Performance etc. nimmt ab, je größer die Entfernung von rufender und gerufener ist. Das Gleiche gilt für ihr gemeinsames Wissen. Während nahe n Wissen zum Beispiel über fachliche Datentypen teilen, können solche Annahmen von entfernten n nicht gemacht werden. Daher ist es sinnvoll, entfernte n loser zu koppeln als nahe n. In den folgenden Abschnitten geben wir dafür Regeln an. Vertrauen Wissen Koppelung Entfernung hoch viel eng nah fern gering wenig Abb. 7: Vertrauen, Wissen und Koppelung in Abhängigkeit von der Entfernung lose Koppelungsmechanismen Wir unterscheiden die folgenden Koppelungsmechanismen: I Intraprozesskommunikation synchron: Services werden mit Mitteln der Programmiersprache synchron im gleichen Betriebssystemprozess gerufen I Request/Reply synchron: Services werden über einen Enterprise Service Bus (ESB) synchron gerufen. Dieser Aufruf kann über Prozess-, Maschinen- und Programmiersprachengrenzen hinweg erfolgen I Message asynchron: Services werden über einen ESB asynchron gerufen. Dieser Aufruf kann über Prozess-, Maschinen- und Programmiersprachengrenzen hinweg erfolgen I Publish/Subscribe: Aufrufende und gerufene n werden über einen Registrierungsmechanismus entkoppelt. Alle registrierten n erhalten asynchrone Nachrichten Der Grad der Koppelung nimmt bei den Mechanismen von oben nach unten ab. R13: Der Koppelungsmechanismus sich aufrufender n soll so gewählt werden, dass der Grad der Koppelung mit zunehmender Entfernung abnimmt. Abb. 6: Entfernung von n Domänen Kategorien Domäne Service Entfernung 10

11 Kategorie Vertrauen hoch gering Interaktion, Prozess Orchestrierbar kompensierende Aktionen notwendig nichttransaktional Funktion, Bestand transaktional Service Abhängigkeit Abb. 8: Transaktionssteuerung Wichtig ist, Kosten und Nutzen abzuwägen. Denn lose Kopplung bringt zwar erhöhte Flexibilität, aber kostet, wie oben erwähnt, auch viel. Selbstverständlich gelten diese Regeln nicht nur für die Koppelung innerhalb von Anwendungslandschaften, sondern im B2B-Geschäft (Business-to-Business) auch zwischen den Anwendungslandschaften unterschiedlicher Unternehmen. Siehe dazu auch [7]. Die lose Koppelung erhöht die Stabilität von Anwendungen auch bei Nichtverfügbarkeit einzelner genutzter n. Regeln für die Transaktionssteuerung Transaktionen [5] garantieren ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) und erhöhen damit das Vertrauen des Aufrufers in die Servicequalität der gerufenen. Umgekehrt koppeln Transaktionen Aufrufer und Gerufenen eng aneinander. Abb. 8 veranschaulicht die Regeln zur Transaktionssteuerung: R14: Aufrufe von Funktions- und Bestandsservices sollen stets in einem Transaktionskontext laufen. Aufrufe von Interaktions- und Prozessservices sollen in keinem Transaktionskontext laufen. Während für Funktions- und Bestandsservices geschachtelte Transaktionen möglich sind, sind diese für Interaktions- und Prozessservices verboten. Da in diesem Fall kein technischer Rollbackmechanismus verwendet wird, müssen im Falle des Fehlschlagens von Aufrufen kompensierende Aktionen (siehe zum Beispiel [25]) durchgeführt werden. Dies gilt auch für Funktions- und Bestandsservices, welche direkt von Interaktions- oder Prozessservices gerufen werden (orchestrierbare Services). Ein Beispiel für eine kompensierende Aktion ist die Stornierung einer Flugbuchung. Die Implementierung kompensierender Aktionen ist teuer. Das ist der Preis der losen Koppelung. Regeln für den Umgang mit Datentypen Fachliche Services, die einander aufrufen, müssen ein gemeinsames Verständnis fachlicher Begriffe haben. Siehe Abb. 9. Das geringste und minimal notwendige gemeinsame Abb. 9: Datentypen Kategorie Wissen viel wenig Interaktion, Prozess, Funktion, Bestand Entitäten Transport strukturen fachliche Datentypen technische Datentypen Service Abhängigkeit 11

12 Domänen Ideale AL Interaktions- n Prozess- n Funktions- und Bestands- Services Domäne Interaktionskomponente Prozesskomponente Service Adapter Produkt Reale AL Reale n und Produkte Kommerzielles Produkt Open-Source Produkt individuelles Altsystem neue Anw.- Abb. 10: Ideale und reale Anwendungslandschaften Wissen zweier n bei dem Aufruf einer Operation sind gemeinsame technische Datentypen wie String oder Integer. Bei weit entfernten n ist dies der Mechanismus der Wahl für die Parametertypen. n, die in einem gemeinsamen fachlichen Umfeld zum Beispiel derselben Domäne angesiedelt sind, können auf einem gemeinsamen fachlichen Datentypverzeichnis basieren. Referenzen auf Entitäten sollen jedoch nie bei Aufrufen zwischen n aller vier Kategorien ausgetauscht werden. Sie werden ausschließlich innerhalb von n verwendet. Stattdessen sollen flache Transportstrukturen verwendet werden. R15: Je größer die Entfernung zweier sich aufrufender n ist, desto geringer sollen die Annahmen für ein gemeinsames Verständnis fachlicher Begriffe sein. Die Regel hilft, die rufende von der gerufenen zu entkoppeln und notwendige Anpassungen bei Änderungen zu reduzieren. R15 ist die letzte der hier vorgestellten Regeln. Bevor wir auf die Praxiserfahrungen mit den Regeln eingehen, geben wir im nächsten Kapitel einige Hinweise zur Anwendung der Referenzarchitektur und der Regeln in realen Anwendungslandschaften. Ideale und reale Anwendungslandschaften Die Referenzarchitektur Anwendungslandschaft sowie die beschriebenen Regeln idealisieren Anwendungslandschaften. Reale Anwendungslandschaften sind jedoch nie ideal. Meist enthalten sie Redundanzen, in ihnen werden Anwendungskategorien gemischt und technische Details offengelegt. Das kommt daher, dass Anwendungslandschaften meist über lange Zeit gewachsen sind und Altsysteme und Produkte enthalten, welche nach unterschiedlichen Architekturprinzipien entworfen wurden. Aufgrund von den Randbedingungen wie Zeit, Kosten oder Performance ist es selten angemessen, die Referenzarchitektur Anwendungslandschaft und alle Regeln in ihrer Reinform umzusetzen. Dennoch ist es möglich, auch reale Anwendungslandschaften mit hoher Qualität zu gestalten. Siehe Abb. 10. Im unteren Teil der Abbildung sind reale n und Produkte einer Anwendungslandschaft dargestellt: kommerzielle Produkte wie SAP-R/3-Module, Open-Source-Produkte, individuell entwickelte Altsysteme sowie neue, nach den genannten Regeln entwickelte Anwendungskomponenten. Für reale n, welche nicht den obigen Regeln zum Schneiden von n und Services genügen, soll eine schlanke Schicht von Funktions- und Bestandsservices eingezogen werden. Diese Services sind in logische n gruppiert und folgen weitgehend den Regeln für den n- und Serviceschnitt. Implementiert werden sie aber im Wesentlichen als Adapter auf die existierenden n und Produkte der realen Anwendungslandschaft. Prozess- und Interaktionskomponenten können dann gemäß den Regeln für ideale Anwendungslandschaften entwickelt werden. Die Entwicklung solcher Serviceadapter ist nicht trivial, besonders bei komplexen und umfangreichen Produkten. Außerdem lösen Serviceadapter alleine nicht das Problem der Redundanz in Anwendungslandschaften. Redundanz entsteht durch Verschmelzung von Anwendungslandschaften zum Beispiel aufgrund von Firmenfusionen, durch den Einsatz von Produkten oder einfach durch unkontrollierte Evolution. Redundanz kann auch bewusst aus Gründen der Performance oder der Ausfallsicherheit eingesetzt werden. Redundanz kommt sowohl auf der Ebene von Daten als auch von Funktionen vor. Ein typisches Beispiel ist die mehrfache Ausprägung eines Kundenstamms in verschiedenen Systemen. Hier helfen Techniken der Datenintegration, bei der physikalisch getrennte Datenbestände für Nutzer logisch als ein integrierter Datenbestand dargestellt werden. Technische Produkte (zum Beispiel [12], [18]) unterstützen die Datenintegration. Weitere Integrationstechniken, neben der Datenebene auch auf der Präsentationsebene, gehören zum Handwerkszeug eines Architekten. Sie sind daher auch wesentlicher Bestandteil von Quasar Enterprise. Dennoch liegen sie nicht im Fokus dieses Artikels. 12

13 Nachdem wir in den letzten Kapiteln eine Referenzarchitektur und Regeln zur Gestaltung von n, Serviceoperationen und zur Koppelung von n in Anwendungslandschaften vorgestellt haben, begründen wir im folgenden Kapitel die Praxisrelevanz der Aussagen anhand umfangreicher Projekterfahrungen. Praxiserfahrungen Es ist ausgesprochen schwierig, den positiven Effekt der Anwendung der oben genannten Regeln auf Qualitätseigenschaften von Anwendungslandschaften wie Zuverlässigkeit, Effizienz und Änderbarkeit schlüssig zu argumentieren. Auf der anderen Seite stellen wir fest, dass diese Regeln in vielen Projekten unabhängig voneinander häufig implizit und zunehmend auch explizit angewendet werden. Wir konnten auch beobachten, wie die Anwendungslandschaft eines Unternehmens getrieben durch operative Notwendigkeit und ohne einen entsprechenden Masterplan schrittweise gemäß den Servicekategorien aufgeteilt wurde. Insofern können wir derzeit nur empirische Belege für den Wert der Regeln angeben. Wir haben dazu über zehn Projekte mit einem Gesamtvolumen von über 100 Bearbeiterjahren analysiert, welche von sd&m in den letzten fünf Jahren bei unterschiedlichen Kunden unterschiedlicher Branchen durchgeführt wurden. Eine Übersicht eines Ausschnitts der Ergebnisse zeigt Abb. 11. In der Abbildung werden die Regeln konkreten, aber anonymisierten Projekten gegenübergestellt. Wurde eine Regel in einem Projekt explizit angewendet, so ist dies mit einem Kreis notiert. Hatte die Anwendung der Regel nachweislich einen positiven Effekt auf die Qualität der Anwendungslandschaft, so wird dies durch einen großen Kreis dargestellt. Kein Tabelleneintrag bezeichnet, dass die Regelanwendung nicht zum Projektumfang gehörte oder zumindest nicht explizit möglicherweise aber implizit erfolgte. Abb. 11: Projekterfahrungen P1: IT Anbieter für Finanzdienstleister AL-Beratung P2: Automobilhersteller Auftragsverwaltung P3: Bundesbehörde IT-Gesamtkonzeption P4: ITK-Unternehmen Architekturberatung P5: Logistikdienstleister Auftragsverwaltung P6: Logistikdienstleiter Unternehmensarchitektur P7: Automobilhersteller Logistiksystem P8: Finanzdienstleister SOA-Beratung P9: Finanzdienstleister SOA-Beratung P10: Finanzdienstleister Architekturberatung R1: Fachliche n R2: n nach Servicekategorien Regeln für den nschnitt R3: Abhängigkeiten gemäß Servicekategorien R4: Keine zyklischen Abhängigkeiten R5: Enger Zusammenhalt, geringe Kopplung R6: Datenhoheit R7: Technikneutral Regeln für das Design von Services und ihre Operationen R8: Referenzfrei R9: Normal (vollständig und redundanzfrei) R10: Grobgranular R11: Idempotent R12: Kontextfrei Regeln zur Koppelung R13: Koppelungsmechanismen R14: Transaktionssteuerung R15: Datentypen Regel angewendet Erfolg nachgewiesen 13

14 Den positiven Effekt nachzuweisen, ist schwer. In den allerwenigsten Fällen gelingt es, ihn quantitativ monetär, also durch Angabe eines eingesparten Geldbetrages, zu beziffern. Wir stützen uns hier auf die Einschätzung des jeweils für das Projekt verantwortlichen Architekten. Beispielsweise wurde in einem Projekt die Regel R7 (Technikneutral) erfolgreich eingesetzt. Dies wurde deutlich, als bei vereinzelter Missachtung der Regel enorme Folgeprobleme auftraten. So wurde eine produktinterne Datenstruktur über eine Serviceoperation nach außen gegeben, um andere n über fachliche Änderungen zu informieren. Daraufhin musste eine nutzende 80 % der Änderungsmeldungen filtern, da sie fachlich irrelevant waren. Abb. 11 zeigt, dass alle vorgestellten Regeln in mehr als drei großen Industrieprojekten Anwendung fanden. Dies signalisiert die Praxisrelevanz der Regeln. Einordnung in die SOA-Literatur Serviceorientierte Architektur ist derzeit ein viel beachtetes und diskutiertes Thema. Zahlreiche Publikationen belegen dies. Beispielhaft dafür seien genannt: [BBF06, ERL06, 10, 11, 24]. Schwerpunkte in der gängigen Literatur sind: I ESB-Infrastruktur und Standards I Allgemeine Architekturrichtlinien I Vorgehen in SOA-Vorhaben Literatur zu ESB-Infrastruktur kommt vor allem aus dem Umfeld der Produkthersteller (zum Beispiel [19]) und Standardisierungsgremien (zum Beispiel [22]). Zunehmend gibt es auch Literatur, welche den wichtigen Bereich des Vorgehens in SOA-Vorhaben beleuchtet (zum Beispiel [27]). Was Architekturrichtlinien betrifft, herrscht auf der allgemeinen Ebene der Konzepte eine weitgehende Übereinstimmung in der Literatur (zum Beispiel [1, 11, 24]). So werden die Prinzipien der Prozessorientierung und der losen Koppelung durchgängig als zentral herausgestellt. Auch die Referenzarchitektur Anwendungslandschaft findet sich in ähnlicher Form in mehreren Veröffentlichungen wieder, teilweise mit anderen Abgrenzungen und Namen. Beispielsweise heißen die Servicekategorien Interaktion, Prozess und Funktion in [24] User Interface, Composite Application und Enterprise Services. Wenn es aber um Regeln zur Gestaltung von n und Services zur Erhöhung der Qualität von Anwendungslandschaften geht, dann findet sich nach unserem Kenntnisstand in der aktuellen SOA-Literatur kaum Konkretes, was über das allgemeine Prinzip der losen Koppelung hinausgeht. Eine solide Basis sind die grundlegenden Arbeiten über Modularisierung, die zum großen Teil auf D. L. Parnas zurückgehen [13], siehe auch [4]. Viele der Prinzipien, die für n im Kleinen gelten, lassen sich auf n im Großen übertragen. Fazit und Ausblick IT-Anwendungslandschaften gestalten heißt höchste Komplexität beherrschen. Als Fazit fassen wir die folgenden Kernaussagen zusammen: I Die Ziele einer SOA Flexibilisierung von Geschäftsprozessen und Reduktion von IT-Kosten erreicht man nur mit einer fachlichen Architektur hoher Qualität. I Das Verständnis des Geschäfts eines Unternehmens ist die Grundlage für die Gestaltung von Anwendungslandschaften. Diese werden primär nach Domänen strukturiert. I Eine konsequente Trennung von n nach den Kategorien Interaktion, Prozess, Funktion und Bestand schafft Klarheit in der Anwendungslandschaft. I Regeln zum Schneiden von n und zum Design von Services geben dem Architekten Leitlinien für die Gestaltung der fachlichen Architektur. I Regeln geben dem Architekten Leitlinien für die Wahl adäquater Koppelungsmechanismen bei der Integration von n. I Reale Anwendungslandschaften sind nie ideal. Für eine adäquate Architektur sind neben Architekturprinzipien auch andere Randbedingungen wie Zeit, Kosten oder Performance relevant. Konkrete Regeln und nachprüfbare Kriterien für Anwendungslandschaften hoher Qualität: Das sind Ziele des Forschungsvorhabens Quasar Enterprise. In diesem Artikel haben wir Ergebnisse von zwei Jahren Forschung vorgestellt und deren Praxisrelevanz anhand umfangreicher Projekterfahrungen begründet. Während einige Regeln schon konkret und nachprüfbar sind, sind andere jedoch noch eher Heuristiken. Hier liegt noch viel Arbeit vor uns: I Regeln sind weiter zu konkretisieren. Wo immer möglich, streben wir die Messbarkeit an I Der Regelkanon ist ständig anzupassen und zu erweitern I Der Nutzen einzelner Regeln und die Auswirkung ihrer Anwendung auf Qualitätsmerkmale ist genauer zu untersuchen Aus unserer Projektpraxis wissen wir: Die Weiterführung dieser Arbeit ist von hohem Nutzen für die effiziente und sichere Gestaltung von Anwendungslandschaften hoher Qualität. Literatur [1] Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah: Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap. IBM Press [2] Ernst Denert, Johannes Siedersleben: Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur. Informatik Spektrum 4/2000, pp

15 [3] Thomas Erl: Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall PTR. April [4] Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: Fundamentals of Software Engineering. Prenctice Hall [5] Jim Gray, Andreas Reuter: Transaction Processing: Concepts and Techniques. The Morgan Kaufmann Series in Data Management Systems Morgan Kaufmann. 1st edition [6] B. Henderson-Sellers, L. L. Constantine, I. M. Graham: Coupling and Cohesion (Towards a Valid Metrics Suite for Object-Oriented Analysis and Design). Object-Oriented Systems, vol. 3, no. 3, pp , [7] Pat Helland: Autonomous Computing Fiefdoms and Emissaries. Presentation Microsoft TechEd [8] Bernhard Humm, Oliver Juwig: Eine Normalform für Services. Proceedings Software Engineering GI Edition Lecture Notes in Informatics (LNI) P-79. Gesellschaft für Informatik, [9] Ivar Jacobson: Object-oriented software engineering: a use case driven approach. Addison Wesley, [10] Wolfgang Keller: Enterprise Application Integration. Erfahrungen aus der Praxis. dpunkt-verlag [11] Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA: Service-Oriented Architecture Best Practices. The Coad Series. Prentice Hall PTR. November [12] Oracle Corp.: Data Hubs. com/data_hub/ [13] D. L. Parnas: On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, Vol. 15, No. 12, December 1972 pp [14] D. L. Parnas: Designing software for ease of extension and contraction. IEEE Transactions on Software Engineering, 5(2): , [15] Jan-Peter Richter, Thomas George, Tim Gugel, Thomas Heimann, Harald Lange, Thomas Möllers: Serviceorientierte Architekturen, Version 1.1. sd&m Technology Guide. sd&m AG [16] Jan-Peter Richter, Harald Haller, Peter Schrey: Aktuelles Schlagwort Serviceorientierte Architektur. Informatik-Spektrum Band 28, Heft 5, S Springer-Verlag, [17] Jan-Peter Richter: Wann liefert eine serviceorientierte Architektur echten Nutzen? Proceedings Software Engineering 2005, Fachtagung des GI-Fachbereichs Softwaretechnik, in Essen, S [18] SAP: Master Data Management. [19] SAP: Netweaver. solutions/netweaver [20] Johannes Siedersleben: Moderne Software-Architektur umsichtig planen, robust bauen mit Quasar. dpunkt Verlag [21] Gesamtverband der Deutschen Versicherungswirtschaft e. V.: Versicherungs-Anwendungs-Architektur (final edition). [22] World wide web consortium (w3c): Web services architecture. [23] Johannes Willkomm, Bernhard Humm: i-portal- Patterns Lösungsmuster für wiederkehrende Anforderungen. Lecture Notes of Informatics 35. S Gesellschaft für Informatik [24] Dan Woods: Enterprise Services Architecture. Galileo Press. Bonn, [25] William Cox, Felipe Cabrera, George Copeland, Tom Freund, Johannes Klein, Tony Storey, Satish Thatte (BEA, IBM, Microsoft): Web Services Transaction. [26] F. DeRemer, H. Kron: Programming-in-the-Large versus Programming-in-the-Small. IEEE Transactions on Software Engineering, Vol. 2, No. 2, pp , [27] Boris Zech, Bernhard Humm: Architekturzentriertes Vorgehen für Integrationsprojekte. In: Peter Dadam, Manfred Reichert (Eds.): INFORMATIK 2004 Informatik verbindet, Band 2, Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e. V. (GI), Ulm, September Lecture Notes of Informatics 51. S Gesellschaft für Informatik Die Autoren Andreas Hess ist Chefberater der sd&m IT-Beratung mit Schwerpunkt IT-Architektur. Seit mehreren Jahren beschäftigt er sich mit Unternehmensarchitektur und ist an der Konzeption von Quasar Enterprise beteiligt. Dr. Markus Voß arbeitet seit 11 Jahren bei sd&m. Mehrere Jahre verantwortete er als Geschäftsbereichsleiter Kundenprojekte mit Schwerpunkt im Bereich großer Internet-Lösungen und war dabei selber auch in unterschiedlichen Architekturberatungsprojekten tätig. Seit 2006 ist er Leiter bei sd&m Research und verantwortet dort den Bereich Architektur und Technologie. Prof. Dr. Bernhard Humm arbeitete 11 Jahre für sd&m als Software- Architekt, Projektmanager, Bereichsleiter und Leiter von sd&m Research. Seit 2005 hat er eine Professur für Software-Engineering und Projektmanagement an der Hochschule Darmstadt. 15

16 sd&m AG, Stand: Mai 2007 Die sd&m AG software design & management entwickelt seit 25 Jahren maßgeschneiderte, leistungsfähige Softwarelösungen und berät in allen Fragen der IT. Unsere Kunden sind Großunternehmen aller Branchen, insbesondere der Bereiche Automotive, Banken und Versicherungen sowie öffentliche Institutionen. Unter anderem vertrauen BMW, DaimlerChrysler, HypoVereinsbank, Münchener Rück, Deutsche Post, Deutsche Telekom, AOK, die Bundesagentur für Arbeit und das Bundesverwaltungsamt auf die Softwarelösungen von sd&m. sd&m beschäftigt in den Niederlassungen München, Stuttgart, Frankfurt, Köln/Bonn, Düsseldorf, Berlin, Hamburg und Zürich Mitarbeiter und erwirtschaftet einen Umsatz von 184 Mio. Euro (2006). Das Unternehmen gehört zu Capgemini und ist damit Teil eines weltweiten Netzwerkes. I service@sdm.de