Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN

Wie flexible Anwendungsarchitekturen wirklich erreicht werden können

Volker Stiehl

• Verlag: dpunkt.verlag
• Jahr: 2012
• eBook-ISBN: 9783864912306
• Auflage: 1
• Thema: Informatik
• Thema: Qualitätssicherung & Prüfung

Die effiziente Entwicklung neuer, differenzierender fachlicher Prozesse in heterogenen Systemlandschaften ist seit jeher eine der größten Herausforderungen für Unternehmen. Denn die neuen Lösungen müssen ...- ... über lange Zeiträume hinweg wartbar bleiben,- ... flexibel auf neue fachliche Anforderungen reagieren können,- ... unabhängig von der vorhandenen IT-Landschaft sein.Dieses Buch vermittelt Ihnen, wie Sie ausgehend von Ihren fachlichen Prozessen und unter Verwendung der BPMN eine nachhaltige Softwarearchitektur entwickeln können, die den genannten Anforderungen gerecht wird.

11 Einleitung

1.1 Unternehmenssoftware im Zeitalter der Globalisierung

Keine Frage: Heutige Unternehmen sehen sich aufgrund der Globalisierung einem erhöhten Wettbewerb ausgesetzt. Sie müssen im alltäglichen Kampf ums Überleben schneller und nachhaltiger als die Konkurrenz auf Veränderungen reagieren können. Besonders treffend fasst in diesem Zusammenhang das folgende von Charles Darwin stammende Zitat die Situation zusammen:

It is not the strongest of the species that survives,
nor the most intelligent that survives.
It is the one that is the most adaptable to change.

Frei übersetzt: Es ist weder der Stärkste noch der Intelligenteste, der überlebt.
Es ist derjenige, der sich am besten dem Wandel anpassen kann.

Es ist genau die Fähigkeit von Unternehmen, auf Veränderungen adäquate Antworten parat zu haben, die ihnen ihre Existenz letztendlich garantiert. Dazu kann die Informationstechnologie (IT) maßgeblich beitragen: Dank enormer Fortschritte im Software Engineering, wie z. B.

der modellgetriebenen Softwareentwicklung,

der Standardisierung von Kommunikations- und Schnittstellentechnologien,

der Modularisierung fachlicher Funktionalitäten in Form von wiederverwendbaren Services,

der Produktivitätssteigerungen für Softwareentwickler aufgrund hochintegrierter Entwicklungsumgebungen sowie

dem Einsatz agiler Entwicklungsmethoden,

ist die effiziente Bereitstellung neuer Softwarelösungen weniger das Problem. Stattdessen erweisen sich aus der Gesamtkostenbetrachtung, der Total Cost of Ownership (TCO) also, die Pflege, die Erweiterung sowie die Anpassung der Software an veränderte Bedingungen als viel größere Hürden: Aufgrund erhöhten Zeit- und Kostendrucks entstehen Softwarearchitekturen, die genau der immer wichtiger werdenden Fähigkeit eines Softwaresystems zur Anpassbarkeit entge-genwirken. 2Dies gilt insbesondere für Software, die bereits existierende fachliche Funktionalität zu neuen, system- und anwendungsübergreifenden Applikationen gemäß der SOA-Idee zusammenfügen soll. Der ursprüngliche Gedanke einer serviceorientierten Architektur (SOA), nämlich Potenziale wie gesteigerte Agilität, geringere Kosten, Wiederverwendbarkeit sowie eine zeitnahe Umsetzung der Unternehmensstrategie in Software heben zu wollen, sind in den Projekten nicht wie erwartet erfüllt worden. Fast schon legendär ist da schon der von Anne Thomas Manes veröffentlichte Blog geworden, in dem sie die Beerdigung von SOA ankündigt [Manes 2009]. Es gibt sicherlich eine Vielzahl von Gründen, warum die Erwartungen nicht in dem Maße wie erhofft erfüllt wurden, was zweifelsohne auch mit der nach wie vor nicht vorhandenen Definition von SOA zusammenhängt. Ich möchte an dieser Stelle auf einen Grund verweisen, der auf den ersten Blick gar nicht so offensichtlich ist und mit der Übernahme der aus der Programmierung eng gekoppelter Lösungen stammenden Erfahrungen beim Anwendungsentwurf in die serviceorientierte Welt zusammenhängt: Architekturen, die in eng gekoppelten Standalone-Anwendungen vollkommen richtig waren, sind in lose gekoppelten verteilten Anwendungen schlichtweg untauglich. Ob es um die Verwendung von Datentypen (Auseinandersetzung mit nur einem Datentypsystem vs. Umgang mit mehreren Datentypsystemen), der Kommunikation mit Systemen oder das Transaktionsverhalten geht – in einer verteilten Umgebung sind dazu andere Lösungen notwendig. Sie verlangen ein Umdenken bei den Entwicklern: So wie bei jedem Paradigmenwechsel sind veränderte Herangehensweisen die logische Konsequenz. Ob beim Wechsel von der maschinennahen zur strukturierten Programmierung, ob von der strukturierten zur objektorientierten Programmierung oder eben wie zurzeit der Wandel hin zur Entwicklung von serviceorientierten Architekturen: In jedem dieser Evolutionsschritte nimmt die Abstraktion zu und verlangt eine Auseinandersetzung des Entwicklers mit den neuen Paradigmen, um optimal von den neuen Möglichkeiten profitieren zu können. Alte Gewohnheiten in die neue Welt transportieren zu wollen hilft in den wenigsten Fällen und ist eher hinderlich. Prozessgesteuerte Anwendungen oder Composite Applications, kurz auch Composites genannt – diese Begriffe werde ich im Laufe dieses Buches synonym verwenden –, bilden hier keine Ausnahme: Sie kontrollieren eben nicht mehr alleine die beteiligten Ressourcen (wie zum Beispiel Datenbanksysteme oder ERP-Systeme). Wir bewegen uns vielmehr in einer heterogenen Systemlandschaft, in der es existierende Dienste zu neuer Geschäftslogik zu kombinieren gilt, was schlussendlich ein gesteigertes Problembewusstsein bei den Anwendungsentwicklern erfordert.

Damit sind die Anforderungen an derartige Systeme aber bei weitem nicht erschöpft. Der Flexibilitätsaspekt ist ebenfalls nicht zu unterschätzen und lässt sich konkret an zwei Anforderungen verdeutlichen:

1. 3Bedarf an Änderungen innerhalb der prozessgesteuerten Anwendung selbst, insbesondere Änderungen an den Geschäftsprozessen,
2. laufende Veränderungen innerhalb der Systemlandschaft, auf der die prozessgesteuerte Anwendung basiert.

Änderungen an den Geschäftsprozessen

Geschäftsprozesse (im klassischen Sinne zu verstehen als »eine Reihe von festgelegten Tätigkeiten (Aktivitäten, Aufgaben), die von Menschen oder Maschinen ausgeführt werden, um ein oder mehrere Ziele zu erreichen« (aus [EABPM 2009], siehe auch [Hammer & Champy 1993] oder [Gaitanides 1983]) spielen bei prozessgesteuerten Anwendungen eine besondere Rolle: Um sich von der Konkurrenz absetzen zu können, müssen Unternehmen ständig an genau den Geschäftsprozessen feilen, die ihnen einen Wettbewerbsvorteil sichern. Erfolgreiche Prozesse werden dabei unweigerlich von der Konkurrenz kopiert, so dass der Vorteil wieder schrumpfen wird. Hier sei beispielhaft an Fluggesellschaften erinnert: Die Bereitstellung von Selbstbedienungsterminals zum Einchecken brachte dem Kunden des Unternehmens, das diese Idee als Erstes umsetzte, den Vorteil verkürzter Wartezeiten (und damit verbunden eine höhere Kundenzufriedenheit) und dem Unternehmen selbst den Vorteil, Personal und damit Kosten einsparen zu können. Heute stellen nahezu alle Fluggesellschaften einen solchen Service zur Verfügung, so dass die Vorteile wieder verloren gingen. Auch geänderte Marktbedingungen verlangen von den Unternehmen eine schnellstmögliche Anpassung ihrer Prozesse. Was auch immer der Auslöser sein mag, die Folgen werden stets dieselben sein: Ein neuer Innovationszyklus zwingt Unternehmen schließlich dazu, weitere Optimierungen an den geschäftskritischen Prozessen vorzunehmen, um weiterhin erfolgreich agieren zu können. Je schneller solche Änderungen implementiert werden können, umso wahrscheinlicher wird das Vorgehen von Erfolg gekrönt sein. Folglich muss die Änderungsfreundlichkeit der Software in der Architektur von prozessgesteuerten Anwendungen bereits verankert sein, um den Bedarf nach Flexibilität und Agilität gerecht werden zu können.

Änderungen in der Systemlandschaft

Auf der anderen Seite müssen prozessgesteuerte Anwendungen auf eine sich ständig ändernde Systemlandschaft vorbereitet sein. Es gehört zum Kern von Composite Applications, dass sie in einem heterogenen Systemumfeld agieren: Der Wiederverwendungsgedanke, den wir ja bei SOA schon gefunden haben, spielt also auch hier eine wichtige Rolle. Das Rad soll eben nicht immer wieder neu erfunden werden, und wo etablierte, funktionierende Geschäftslogik bereits existiert, soll diese auch entsprechend genutzt werden. Allerdings ergibt sich daraus eine besondere Herausforderung: Derartige Systemlandschaften sind nicht stabil. Auch hier müssen Veränderungen von vornherein bei der Konzeption von prozessgesteuerten 4Anwendungen berücksichtigt werden. Mindestens drei Gründe sprechen dafür, dass sich Systemlandschaften auch in Zukunft ständig, vielleicht sogar in einem noch höheren Tempo, verändern werden:

1. Systemkonsolidierungen
2. Firmenfusionen
3. Software as a Service (SaaS), On-Demand, Cloud

Schauen wir uns die drei Punkte im Detail an: IT-Abteilungen in Unternehmen unterliegen einem enormen Kostendruck. Die Unternehmensleitung verlangt von IT-Verantwortlichen eine ständige Kostenoptimierung. Systemkonsolidierungen sind da ein probates Mittel: Je mehr Systeme und Funktionalitäten zusammengelegt werden können, umso geringer werden die Belastungen. Allein aus diesem Grund werden Systemlandschaften sich ständig weiterentwickeln. Für prozessgesteuerte Anwendungen bedeutet dies, dass Aufrufe, die zuvor gegen mehrere Systeme erfolgten, nun gegen eine reduzierte Anzahl von Systemen abgewickelt werden müssen.

Doch das ist nur die eine Seite der Medaille: Durch das Abschalten von Systemen und die Überführung von ehemals differierenden Prozessen in Standardsoftware wird zwar eine Vereinfachung der IT-Landschaft erreicht. Diesem Trend entgegen wirkt jedoch die Fusion von Unternehmen. Zur Erreichung bestimmter Wachstumsziele für die Unternehmung wird das organische Wachstum durch Firmenakquisitionen unterstützt. Allerdings wächst durch derartige Firmenzusammenschlüsse naturgemäß der System- und Anwendungspark. In diesen Fällen ist die Composite Application gemäß der geänderten Rahmenbedingungen an die gestiegene Systemanzahl anzupassen.

Schließlich muss man dem neuen Trend der Software-as-a-Service-(SaaS-), On-Demand- sowie Cloud-Anbieter Rechnung tragen: Fachliche Dienste werden jetzt kostengünstig von Dienstleistern angeboten mit weiterem Optimierungspotenzial für IT-Leiter. Sie können nun unkritische Funktionalitäten auslagern und somit zu einer weiter optimierten Kostenstruktur für die IT beitragen. Für die Architektur von prozessgesteuerten Anwendungen bedeutet allerdings auch dieses Szenario einen erhöhten Bedarf nach Flexibilität. Welches der drei Szenarien auch immer zum Tragen kommt, ob Systemkonsolidierungen, Hinzufügen neuer Systeme oder die Verlagerung von Funktionalitäten: Für prozessgesteuerte Anwendungen gehören derartige Herausforderungen zum Alltag und müssen bei deren Konzeption integraler Bestandteil sein. Oder mit anderen Worten ausgedrückt: Trotz all dieser möglichen Veränderungen in der Systemlandschaft können und wollen Firmen nicht auf gewinnbringende Innovationsprozesse verzichten – und das sollen sie auch nicht: Eine geeignete Architektur gibt ihnen dazu die notwendige Rückendeckung und Sicherheit, dass sich die zwangsläufig kommenden nachgelagerten Änderungen an der Systemzusammenstellung nicht nachteilig auf die prozessgesteuerten Anwendungen auswirken! Die Innovationskraft des Unternehmens bleibt also erhalten.

5Prozessgesteuert...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Geleitwort von Sascha Bertsch
• Geleitwort von Prof. Dr. Erich Ortner
• Vorwort
• Inhaltsverzeichnis
• 1 Einleitung
• 2 Definition von prozessgesteuerten Anwendungen
• 3 Architektur von prozessgesteuerten Anwendungen
• 4 Implementierung der Grundarchitektur von prozessgesteuerten Anwendungen
• 5 Ergänzende Konzepte zur Unterstützung der Architektur von prozessgesteuerten Anwendungen
• 6 Fazit und Ausblick
• A Anhang
• B Abkürzungsverzeichnis
• C Glossar
• D Literaturverzeichnis
• Index
• Fußnote