Softwaresysteme waren früher so einfach! Vor 40 Jahren bestand ein Programm aus Statements zur Funktionsbearbeitung, die in Lochkarten gestanzt wurden. Dabei ging es vor allen Dingen um die Lösung von mathematischen Aufgaben. Dem Stapel folgte eine rote leere Karte und anschließend die Karten mit den zu verarbeitenden Daten. Die Reihenfolge, in der die Statements bearbeitet wurden, war durch die Reihenfolge der Lochkarten eindeutig festgelegt.
Inzwischen hat sich vieles verändert. Es wird immer schwieriger, den eigentlichen Programmcode eines Anwendungssystems zu identifizieren. Er ist heute auf viele Teilsysteme verteilt und macht es für den Programmierer sehr schwer, den Überblick über eine bestimmte Anwendung zu behalten.
Blicken wir zurück: Die Datenzugehörigkeit zu einem Anwendungsprogramm hatte ihre Tücken. Benutzten mehrere Programme die gleichen Daten, so war es schwierig, diese aktuell zu halten und sicherzustellen, dass alle Programme jeweils mit den gleichen Informationen arbeiteten. Deshalb wurden im Rahmen von ERP-Software die Daten den funktionsorientierten Programmmodulen entnommen und in einer eigenen unternehmens-weiten Datenbasis verwaltet. Nun konnten alle Programmteile auf die gleichen Datendefinitionen zugreifen, und die Integration zwischen den Funktionsmodulen zur Bearbeitung eines gesamten Geschäftsprozesses wurde wesentlich erleichtert.
Da die Daten von eigenen Verwaltungs- oder Datenbanksystemen organisiert wurden, beschränkt sich die Datenmanipulation in den eigentlichen Anwendungsprogrammen auf einfache Befehle wie Lesen, Speichern oder Verändern eines Datensatzes. Die eigentliche detaillierte Datenverwaltung und damit auch der dafür benötigte Programmcode wird in das Verwaltungs- beziehungsweise Datenbanksystem verlagert.
Mit der fortschreitenden Bedeutung der Geschäftsprozessorganisation wurde in einem weiteren Schritt die Ablaufsteuerung der Programme, die quasi die Geschäftsprozesslogik einer Anwendung enthält, zunehmend in Workflow-Systeme verlagert. Damit wurde wiederum den eigentlichen Anwendungsprogrammen ein Teil des Programmcodes entzogen. Die Organisationsform, ob ein Geschäftsprozess nach dem Pull- oder Push-Prinzip gesteuert werden soll, ob also die Mitarbeiter sich aus dem elektronischen Eingangskorb ihre zu bearbeitenden Vorfälle selbst ziehen dürfen oder sie ihnen zugeteilt werden, ist damit Aufgabe des Workflow-Systems.
Einheitliche Sicht via Portal
Um dem Benutzer eine einheitliche Sicht auf den Geschäftsprozess zu ermöglichen, selbst wenn zu seiner Bearbeitung unterschiedliche Anwendungsprogramme eingesetzt werden, wurde mit der Portaltechnik ein weiterer Schritt zur Zerlegung der Anwendungssoftware ge- tan. Die Anmeldung zum System, die Autorisierung und auch die einheitliche Bildschirmsteuerung hat man den Anwen dungsprogrammen entnommen und in die Portalsoftware übertragen.
In heterogenen Welten brauchte als weiterer Zerlegungsschritt die Integration zwischen unterschiedlichen Programm- und Datensystemen nicht mehr von den Anwendungsprogrammen selbst ausgeführt zu werden, denn mit der Technik für Enterprise Application Integration (EAI) wurden Konzepte und Tools verfügbar, die diese Aufgabe übernahmen. Dem EAI-System musste dazu mitgeteilt werden, welche Datenänderungen aus dem Update eines Teilsystems in anderen Systemen nachvollzogen werden mussten.
Diese Entwicklung der zunehmenden Verteilung einer Anwendung erhält derzeit durch die Einführung von so genannten prozessorientierten Plattformen einen neuen Schub: In Plattformen wie .NET (Microsoft), Websphere (IBM) und Netweaver (SAP) werden Portal-, Workflow- und EAI-Technologien zu einem Middleware-Konzept zusammengeführt, auf dem dann die Anwendungssoftware aufsetzen kann. Durch die Herausnahme von Datenverwaltung, Ablaufsteuerung und Benutzerführung aus den Anwendungssystemen bleibt für den Programmcode der eigentlichen Anwendungen vornehmlich noch die Funktionsausführung und die Definition der dazu notwendigen Daten.
Hier bietet der objektorientierte Ansatz mit seiner Zusammenführung von Datenobjekten und den darauf anzuwendenden Methoden eine konzeptionell transparente Hilfe. Die Bestimmung der Größe dieser Business Objects ist allerdings ein schwieriges Problem, da unterschiedliche Ziele wie Performance, einfache Schnittstellen nach außen, Wartungsfreundlichkeit etc. beachtet werden müssen. Die Business Objects werden dann über Services mit standardisierten Schnittstellen zur Orchestrierung durch die Prozessplattform bereitgestellt.
Die Flexibilität wächst
Verfolgt man also den Programmcode einer Anwendung, so verteilt er sich auf mehrere Hierarchiestufen von Middleware-Komponenten bis zu den immer kleiner werdenden Programmteilen der eigentlichen Funk- tionsbearbeitung. Der Vorteil dieser Verteilung liegt in einer wachsenden Flexibilität der Anwendungssysteme. Nun können Daten geändert werden, ohne dass notwendigerweise der Programmcode angetastet werden müsste und umgekehrt. Auch die Reihenfolge der Funktionsverarbeitung kann man unabhängig von Programmcode oder Datendefinitionen modifizieren. Kurz: Die Anwendungssysteme sollen nicht der Engpass für neue Organisationsformen der Unternehmen sein, sondern im Gegenteil innovative Anwendungskonzepte aufnehmen und umsetzen.
Mit Rules Engines stehen Softwaresysteme zur Verfügung, die diese Rolle übernehmen. Damit wird die Prozessbearbeitung flexibler. Willkommener Zusatzeffekt: Die Workflow- und Programmsteuerung wird einfacher.
Allerdings hat die zunehmende Flexibilität auch ihren Preis. Es ist nicht mehr so einfach, eine einheitliche Anwendung zu identifizieren. Wenn man nach dem Programmcode einer Anwendung sucht, dann ist zwar die Funktionsunterstützung leicht zu finden, aber um diese herum ist viel Code in Workflow, Netzwerksteuerung, Datenhaltung, Portaltechnik und Integrations-Tools versteckt, der durch einen Wald an "Call"-Befehlen aktiviert wird.
Entscheidungsregeln isolieren
Die nächste Entwicklungsstufe deutet sich bereits an. Auch die Entscheidungsregeln, nach denen Abläufe gesteuert werden, können dem Programmcode entnommen und eigenständig verwaltet werden. Hat man für einen einzelnen Prozessablauf, zum Beispiel einen Kundenauftrag, die Bearbeitungsschritte zusammengestellt, lässt sich mit den Entscheidungsregeln ein Auftrag mit einem Wert größer als 20000 Euro an verschiedenen Stellen des Prozesses anders behandeln als ein Bagatellauftrag. Eine Änderung dieser Regel, etwa die Erhöhung des Grenzwerts auf 25000 Euro, muss nur an einer einzigen Stelle eingegeben werden und ist sofort in allen betroffenen Prozessschritten verfügbar.
Der Programmierer muss damit eine weitere Schicht kontrollieren. Das Gute an dieser Entwicklung ist aber, dass der organisatorische Geschäftsprozessgedanke, der seit 20 Jahren die Richtung moderner Unternehmen bestimmt, nunmehr auch von den Softwarearchitekturen aufgenommen wird. (ue)