Vorwort

Der Beginn meiner Reise in die Welt der Anwendungsentwicklung unter Berücksichtigung komplexer verteilter Systemlandschaften liegt mehr als 10 Jahre zurück: Ich arbeitete seinerzeit bei Siemens Business Services (SBS) in einer Abteilung zur Entwicklung Java-basierter Anwendungen und konnte mitverfolgen, wie unser Entwicklungsteam an einer neuen Software zur Umsetzung neuer Geschäftsprozesse für die Verwaltung von Softwarelizenzen arbeitete. Es ging darum, die in einem Unternehmen eingesetzten Lizenzen zentral in einem Lizenz-Pool zu sammeln. Beim Kauf neuer Rechner installierte die IT-Abteilung entsprechend der Rolle des Mitarbeiters, für den der Rechner vorgesehen war, passende Software und entnahm sie dazu dem Lizenz-Pool. Im umgekehrten Fall, also immer dann, wenn ein Computer ausgemustert wurde oder ein Mitarbeiter das Unternehmen verließ, wanderte die Lizenz in den Pool zurück und stand folglich für weitere Installationen wieder zur Verfügung. Die neu zu entwickelnde Anwendung musste zudem mit einer Vielzahl bestehender Systeme interagieren: Die Bestellung neuer Lizenzen wickelten wir beispielsweise über ein SAP-System ab, die Informationen über Mitarbeiter steckten in einem LDAP-System (Lightweight Directory Access Protocol), der Versand der Workflow-Benachrichtigungen erfolgte über einen E-Mail-Server. Abgerundet wurde die Applikation um eine eigene JDBC-basierte Persistenz zur Speicherung der Informationen, welcher Benutzer welchen Rechner besitzt und welche Software sich auf dem Rechner befindet. Letztendlich handelte es sich also um eine klassische verteilte, webbasierte Anwendung, die neue Prozesse implementierte, die sich über mehrere Systeme hinweg erstreckte.

Das Team entwickelte die Lösung nach allen Regeln der damals bekannten JavaEE-Kunst: Session Beans, Entity Beans, Message-driven Beans, Servlets, Java Server Pages, Apache Struts als Web-Framework, Webservices, die gesamte Palette also. Zudem legte unser Architekt sehr viel Wert auf eine moderne Softwarearchitektur: Ich erinnere mich noch gut an den Tag, als er bei mir an meinem Schreibtisch vorbeikam und mir voller Stolz berichtete, wie viele Pattern der »Gang of Four« [Gamma et al. 1995] er in der erstellten Software sinnvoll einbringen konnte (obwohl aus der Anzahl der verwendeten Pattern allein natürlich nicht auf die Qualität einer Software geschlossen werden kann). Die Software lief auf einem BEA Weblogic Server und fand schließlich auch ihren Weg auf einen SAP Web Application Server [Stiehl 2004]. Die Kundenresonanz auf die neue Lösung war äußerst positiv, doch es stellte sich alsbald heraus, dass potenzielle Kunden ihre Daten in anderen als den von uns bei der Erstellung der Software vorgesehenen Systemen ablegten. Wie sollten wir aber mit diesem Problem umgehen, wenn unsere Software weiterhin für einen möglichst großen Kundenkreis attraktiv sein sollte? Für jeden Kunden eine neue Variante erstellen? Bei der Anzahl möglicher Kombinationen von Backend-Systemen ist das sicherlich kein vielversprechender Ansatz. Die Anfälligkeit der Lösung bezüglich der Änderungen an der Systemlandschaft war offensichtlich, oder, um es mit anderen Worten auszudrücken, wir hatten uns zu sehr von einer konkreten IT-Landschaft abhängig gemacht. Sie werden sich jetzt vielleicht fragen, wie es dazu kommen konnte und warum die Lösung nicht von vornherein mehr von den Backend-Systemen abstrahierte? Aber wie setzt man eine solche Abstraktion konkret um? Wie weit geht die Abstraktion? Wie werden die Aufgaben auf die Abstraktionsebenen verteilt? Und überhaupt: Sollte die serviceorientierte Architektur nicht genau diese Probleme lösen? Letztendlich gipfeln all diese Fragestellungen in der einen zentralen Frage: Wie erstelle ich robuste Anwendungen für verteilte IT-Landschaften, die zukünftig durch die steigende Zahl von On-Demand- und Cloud-Angeboten sogar noch fragmentierter werden?

Je mehr ich mich damit auseinandersetzte, Projekte analysierte, Fachartikel las und auf Konferenzen Vorträge über ähnlich geartete Problemstellungen hörte, umso mehr musste ich feststellen, dass die dort vorgestellten Architekturen mit ähnlichen Unzulänglichkeiten zu kämpfen hatten. In Gesprächen mit den Projektverantwortlichen wurden oft weitere Gründe genannt, die zu derartigen Abhängigkeiten führten: Ein hoher Projektdruck verbunden mit fehlender Zeit bei einem knapp bemessenen Budget verhinderten die Ausarbeitung einer robusten Softwarearchitektur, obwohl wider besseren Wissens die Folgen eines derartigen Vorgehens hinlänglich bekannt sind: Die kurzfristig schnellere und damit kostengünstigere Entwicklung verschlingt später, auf lange Sicht betrachtet, ein wesentlich höheres Budget für die Wartung, Betreuung und Weiterentwicklung, als dies notwendig gewesen wäre. Ein langfristiges Ziel wurde also einem kurzfristigen geopfert! So dürfen wir uns nicht wundern, wenn allseits eine fehlende Agilität bei der Anpassung der Software an die vom Management vorgegebene Geschäftsstrategie beklagt wird, da niemand mehr in der Lage ist, die Verflechtungen aufgrund der gewachsenen Abhängigkeiten zwischen Endanwendungen und Systemlandschaft auseinanderzudividieren.

In diesem Buch stelle ich daher einen Ansatz zur Umsetzung einer Architektur für Endanwendungen vor, die eine vernünftige Balance zwischen Entwicklungs-und Wartungskosten, Nachhaltigkeit, Skalierbarkeit, Fehlertoleranz sowie die Erfüllung von Flexibilitätsanforderungen bei gleichzeitiger moderater Komplexität anstrebt und auf eine weitestgehende Unabhängigkeit der Endanwendung gegenüber der Systemlandschaft, gegen die sie operiert, setzt. Auf der Suche nach einer solchen Lösung bin ich überraschenderweise bei dem Prozessmodellierungsstandard BPMN (Business Process Model and Notation) fündig geworden: Gestartet als eine grafische Notation zur Modellierung von Geschäftsprozessen, entpuppte sie sich als geradezu vorzügliches Mittel für dieImplementierung einer Anwendungsarchitektur, wie sie mir vorschwebte. Dabei verstehe ich unterAnwendungsarchitektur eine Lösung für Endanwendungen auf Basis heterogener IT-Landschaften, die sowohl fachliche als auch integrationszentrische Prozesse unterscheidet. Da mit der neuesten Version 2.0 des BPMN-Standards zudem die Ausführbarkeit derart erstellter Prozessmodelle aufgrund semantischer Erweiterungen gewährleistet wurde, begann ich damit, komplette Anwendungsarchitekturen mithilfe der BPMN zu entwerfen und ablaufen zu lassen. Dabei verwende ich die BPMN eben nicht nur zur Modellierung der fachlichen Prozesse der Endanwendung, wie das »B« in BPMN ja suggeriert, sondern ich nutze sie auch zur Modellierung und Ausführung der systemnahen Integrationsprozesse. Wie diese auf den ersten Blick widersprüchliche Verwendung der BPMN zusammen-passt, erfahren Sie ebenfalls in diesem Buch.

Mit der vorgeschlagenen Anwendungsarchitektur verfolge ich das Ziel, Architekten und Softwareentwicklern eine möglichst detaillierte Architektur-Blaupause in die Hand zu geben, nach deren Prinzipien zukünftig verteilte Anwendungen in den Unternehmen geplant und implementiert werden können. Wird die Anwendungsentwicklung vermehrt nach dieser Vorlage umgesetzt, trägt jede dieser Lösungen dazu bei, dass sich Unternehmen ganz allmählich aus dem eingangs erwähnten Würgegriff der Abhängigkeiten und Systemverbindungen lösen können. Von daher sehe ich die prozessgesteuerten Anwendungen als einen Beitrag zum Unternehmensarchitekturmanagement (Enterprise Architecture Management, EAM) an, womit auch gleichzeitig gesagt ist, dass dieses Buch sich vom großen Feld des EAM unterscheidet und EAM selbst nicht zum Gegenstand macht.

Das Buch richtet sich an Softwarearchitekten, technisch interessierte Manager, IT-Leiter, Softwareentwickler, Projektleiter, aber auch an Studenten der Informatik und Wirtschaftsinformatik. Ich setze Grundkenntnisse der BPMN voraus. Ich führe zwar kurz in die Notation ein, beschreibe allerdings nicht jedes BPMN-Element im Detail. Auch im Hinblick auf serviceorientierte Architekturen bin ich von einem grundlegenden Wissen bei meinen Lesern ausgegangen, da ich natürlich bei meinem Ansatz ebenfalls auf wiederverwendbare Dienste in den Backend-Systemen angewiesen bin.

Danksagungen

Ein solches Buch entwickelt sich über einen sehr langen Zeitraum, während dessen eine Vielzahl von Personen involviert ist. Ich möchte mich ganz herzlich bei all den Menschen bedanken, die mich auf diesem Weg begleitet haben: bei meinem Doktorvater Prof. Dr. Erich Ortner, bei meinen Gutachtern Prof. Em. Dr. Dr.-Ing. E.h. Hartmut Wedekind und Prof. Dr. Mathias Weske. Bei meinen Vorgesetzten Gunther Rothermel, Dr. Achim Kraiss und Sindhu Gangadharan sowie meinen Kollegen Dr. Udo Paltzer, Dr. Alexander Bundschuh und Waldemar Befort. Zudem bin ich folgenden Personen sehr zu Dank verpflichtet (in alphabetischer Reihenfolge): Sascha Alber, Prof. Dr. Thomas Allweyer, Dr. Dirk Ammermann, Sascha Bertsch, Dr. Gero Decker, Marcus Elzenheimer, Matthias Fischer, Prof. Dr. Elisabeth Heinemann, Nicolai Josuttis, Holger Koschek, Marco Link, Dr. Daniel Lübke, Christoph Neumann, Prof. Dr. Gunther Piller, Peter Schwab sowie Nicole Zeise.

Ein besonderer Dank geht an das Team vom dpunkt.verlag, vor allem an Christa Preisendanz. Doch all dies wäre undenkbar gewesen, gäbe es...