Applikationsrückgewinnung

Wie aus einer bestehenden Software eine User Owned Application werden kann

Konstantin Diener, Daniel Kaminsky
© Shutterstock/Oleksiy Mark

In den IT-Landschaften der Unternehmen gibt es für viele Domänen etablierte Softwareprodukte, Neuentwicklungen scheiden hier oft aus. Mit welchen Vorgehensweisen kann man eine bestehende Fachapplikation zu einer User Owned Application machen?

Ausgelöst durch stetige Produktinnovationen und eine wachsende Zahl regulatorischer Anforderungen, verändern und verfeinern Unternehmen heute kontinuierlich ihre Produkte und Prozesse. Die klassische Arbeitsteilung zur Umsetzung einer Änderung ist: Die Fachabteilung spezifiziert sie und die IT-Abteilung setzt sie um. Die Erfahrung zeigt jedoch, dass diese Arbeitsteilung bei hohen Änderungsgeschwindigkeiten zunehmend an ihre Grenzen stößt, denn jede Anforderung muss beschrieben, in eine technische Sprache übersetzt und als Sourcecode implementiert werden.

Eine User Owned Application kürzt den Prozess zur Umsetzung von Änderungen ab, da hier die Pflege der kompletten Anwendungslogik (bestehend aus Domänenmodell und Geschäftsregeln) in der Hand des Fachanwenders selbst liegt. Die Unternehmens-IT setzt nicht mehr die fachlichen Anforderungen um, sondern stellt eine robuste technische Plattform für deren Umsetzung bereit. Diese Plattform ist insofern robust, als sie den Fachanwender dabei unterstützt, strukturelle Fehler zu vermeiden und inhaltliche Fehler so früh wie möglich aufzudecken (Prinzip „Poka Yoke“). Wer eine User Owned Application auf der sprichwörtlichen „grünen Wiese“ aufbaut, hat dafür eine Vielzahl technologischer Optionen, von denen eine exemplarisch hier vorgestellt wird. Oft ist es aber nicht möglich, eine Anwendung von Grund auf neu zu entwickeln, denn die IT-Landschaft der Unternehmen besteht nicht selten aus einer Reihe etablierter Fachapplikationen. Selbst wenn diese Applikationen nicht die Merkmale einer User Owned Application aufweisen, können sie anhand verschiedener Ansätze in eine solche verwandelt werden.

Fallstudie

Im Rahmen einer Fallstudie soll exemplarisch gezeigt werden, wie eine bestehende Anwendung in eine User Owned Application überführt werden kann. Dazu wird angenommen, dass eine fiktive Fachapplikation zur Anlagegrenzprüfung von Investmentfonds existiert und es sich bei ihr um eine Standardsoftware handelt. Ihre Einführung erfolgte seinerzeit unter hohem Zeitdruck, weshalb Abstriche bei der Erfüllung aller fachlichen Anforderungen gemacht wurden. Investmentfonds investieren die Gelder der Investoren in eine Reihe von Wertpapieren (Aktien, Anleihen etc.), die dann zusammen das Portfolio des Fonds bilden. Abbildung 1 zeigt beispielhaft die Verteilung der Investments für einen Fonds. In der Grafik sind keine einzelnen Aktien oder Anleihen mehr dargestellt, sondern lediglich der Anteil, den sie am Gesamtvermögen des Fonds ausmachen. Für diese Verteilung gibt es im Normalfall eine Reihe von Regeln, die von Fonds zu Fonds unterschiedlich sind und bei Investitionsentscheidungen durch den Fondsmanager berücksichtigt werden müssen. Beispielhafte Regeln sind:

• Der Fonds soll keinen Schwerpunkt auf Anleihen haben, sie aber beimischen dürfen. Der Anteil der Anleihen am Gesamtvermögen darf 40 Prozent nicht übersteigen.
• Damit der Fonds nicht ausschließlich in Aktien investiert, gilt für sie eine Obergrenze von maximal zwei Dritteln (66 Prozent) am Gesamtvermögen.
• Der Fonds darf seine Barmittel niemals vollständig investieren, sondern muss mindestens 5 Prozent Cash vorhalten.

Abb. 1: Beispielhafte Vermögenszusammensetzung eines Investmentfonds

Die beschriebenen Regeln werden als Anlagegrenzprüfungsregeln bezeichnet. Neben Wertpapierklassen können sie sich beispielsweise auch auf bestimmte Regionen beziehen („Der Fonds darf zu maximal 20 Prozent Wertpapiere aus Schwellenländern enthalten“). Bevor mit den eigentlichen Schritten zur Umwandlung der Applikation begonnen werden kann, muss als Voraussetzung für die User Owned Application das Domänenmodell erhoben werden. Abbildung 2 enthält ein stark vereinfachtes Modell für die Domäne „Anlagegrenzprüfung“, das durch Interviews mit den Fachanwendern entstanden ist.

Abb. 2: Domänenmodell für die Anlagegrenzprüfung

In Abbildung 3 ist das Datenbankmodell der bestehenden Anwendung dargestellt. Hierbei steht im Vordergrund, möglichst viele Aspekte der Umwandlung in eine User Owned Application veranschaulichen zu können.

Abb. 3: Datenbankmodell der Beispielanwendung

Aufmacherbild: Creative abstract computer media and internet communication business concept: macro view of heap of colorful cubes with application icons and symbols on laptop keyboard with selective focus effect von Shutterstock / Urheberrecht: Oleksiy Mark

[ header = Seite 2: Wie weit ist der Weg? ]

Wie weit ist der Weg?

Am Beginn der Umwandlung einer bestehenden Software in eine User Owned Application steht eine Bestandsaufnahme: Wie weit ist die derzeitige Software von dem Ziel entfernt, dass der Fachanwender die Geschäftsregeln und das Domänenmodell hauptverantwortlich pflegen kann? Abbildung 4 zeigt verschiedene Restriktionen als Antwort auf diese Frage:

Architekturrestriktionen: Das Domänenmodell und die Geschäftsregeln der Anwendung sind im Quellcode hinterlegt und lassen sich nur dort modifizieren. Eine solche Anwendung ist am weitesten vom Zielbild einer User Owned Application entfernt, denn der Fachanwender muss jede Änderung spezifizieren und durch einen Entwickler umsetzen lassen. Wenn die Anwendung basierend auf einer Plug-in-Architektur aufgebaut ist, rückt sie etwas näher an das Zielbild heran In diesem Fall müssen zwar immer noch alle Änderungen durch einen Entwickler vorgenommen werden, aber sie lassen sich im Optimalfall unabhängig vom Gesamtsystem deployen, was die Umsetzungsgeschwindigkeit erhöht. In der Beispielapplikation arbeiten die Grenzprüfungsregeln auf Attributen der Wertpapiere. Sollen neue Attribute eingeführt werden, müssen die Datenbank und der Quellcode angepasst werden.
Technische Restriktionen: Die Anwendung ist zwar dafür vorgesehen, konfigurierbar zu sein, für die Fachanwender sind allerdings keine adäquaten Masken oder dergleichen vorhanden. Sowohl das Domänenmodell als auch die Geschäftsregeln in der Anwendung sind in einer sehr technischen Sprache realisiert, die sich bis in die Benutzermasken fortsetzt. Meist wird die Pflege der Anwendung nicht durch einen Entwickler, sondern durch einen technischen Administrator vorgenommen. In der Beispielapplikation zeigt sich diese Restriktion an den fachlichen Elementen „Region“ und „Wertpapierklasse“, die in einer generischen technischen Datenstruktur VALUE_LIST verborgen sind. Diese Struktur kann der Fachanwender nicht intuitiv pflegen.
Restriktionen durch Komplexität: Eine solche Anwendung ist dem Zielbild einer User Owned Application bereits relativ nah. Der Benutzer kann theoretisch das Domänenmodell und die Geschäftsregeln pflegen. Da die Anwendung aber keine Robustheit nach dem Poka-Yoke-Prinzip bietet oder bei der Realisierung wichtige Arbeitsabläufe vergessen wurden, ist der Datenbestand so weit „erodiert“, dass die Fachanwender den „Wald vor lauter Bäumen nicht mehr sehen“. Sie finden sich in der eigenen Anwendung nicht mehr zurecht. Für diese Art von Restriktionen gibt es in der Anlagegrenzprüfungsanwendung zwei Beispiele: 1. Länder und Wertpapiertypen sind nicht als eigene Elemente modelliert und müssen für jede Region bzw. jede Wertpapierklasse neu redundant erfasst werden, was zu Fehlern führt. 2. Es gibt eine fachliche Verbindung zwischen dem Attribut COUNTRY_CODE und der Länderliste bzw. dem Attribut SECURITY_TYPE und der Wertpapierklasse, die im Applikationsmodell nicht abgebildet ist. So können Inkonsistenzen entstehen.

Abb. 4: Klassifikation bestehender Anwendungen

Abbildung 4 zeigt auch die Größenordnung des für die Umwandlung einer Anwendung in eine User Owned Application notwendigen Aufwands. Je weiter links die Anwendung durch die Bestandsaufnahme eingeordnet wurde, desto höher ist der Aufwand. In der Beispielapplikation kommen alle Arten von Restriktionen vor, weshalb sie der aufwändigsten Klasse zugeordnet wird. Dies ist um des Beispiels willens durchaus gewollt. Sind einzelne Restriktionen, wie beispielsweise die Einführung neuer Wertpapierattribute, weniger oder gar nicht wichtig, können sie ignoriert werden, was die Klassifizierung „verbessert“.

Applikationsmodell

Das Kernstück einer Anwendung ist das Applikationsmodell, also die Struktur, in der Domänenmodell und Geschäftsregeln modelliert und abgelegt sind. Andere Elemente, wie die Benutzermasken, orientieren sich an diesem Applikationsmodell. Die verschiedenen Arten von Restriktionen beziehen sich deshalb auch in erster Linie auf das Applikationsmodell der bestehenden Anwendung. Das Applikationsmodell der Beispielanwendung wurde in Abbildung 3 vorgestellt.

Verwandlung

Um aus einer bestehenden Anwendung eine User Owned Application zu machen, muss das Applikationsmodell in das Zielmodell des Fachanwenders (die „intuitive Sprache für Geschäftsregeln“ und das „natürliche Domänenmodell“) verwandelt werden. Im Extremfall ist das Applikationsmodell in der Anwendung in Form von Quellcode hinterlegt (Architekturrestriktionen). In diesem Fall bedeutet die Verwandlung, dass der Quellcode der Anwendung durch Refactoring angepasst werden muss. Die Modellierung des Domänenmodells und der Geschäftsregeln wird sukzessive aus der Anwendung herausgelöst. Die Änderung von Quellcode ist der maximal invasive Ansatz einer Umwandlung in eine User Owned Application, an der dann kein Weg vorbeiführt, wenn das Applikationsmodell ausschließlich im Quellcode implementiert ist. In vielen Fällen ist diese Art der Umwandlung aber nicht das Mittel der Wahl, da der Code wie in unserem Beispiel nicht vorliegt. Bei Standardprodukten verliert man durch Quellcodeänderungen außerdem in der Regel eine Reihe von Vorteilen wie kontinuierliche Releases und Bugfixes oder den Support durch den Hersteller. Hat die bestehende Anwendung keine Architekturrestriktionen oder basiert sie zumindest auf einer Plug-in-Architektur, kann die Umwandlung durch einen weniger invasiven Ansatz erfolgen. Die Funktionen einer User Owned Application können hinzugefügt werden, ohne die Anwendung selbst zu verändern. Die Umwandlung vom Applikationsmodell in das Zielmodell (und umgekehrt) findet nicht mehr zum Implementierungszeitpunkt, sondern zur Laufzeit statt, indem ein Adapter zwischen das Applikationsmodell und das Zielmodell gesetzt wird.

Abb. 5: Funktionsweise des Adapters

Zur Visualisierung wandelt der Adapter die Informationen aus dem Applikationsmodell in das Zielmodell um. Hat der Fachanwender sie im Zielmodell verändert, werden sie ins Applikationsmodell zurückgewandelt und dort gespeichert (Abb. 5). Innerhalb des Adapters erfolgt die Umwandlung durch einen Satz von Mapping-Regeln, die von IT- und Fachabteilung einmal zu Beginn definiert werden. Diese Regeln sind im Normalfall sehr stabil und ändern sich nur bei Änderungen am Applikationsmodell. Trotzdem sind sie zur Laufzeit konfigurierbar und nicht im Quellcode des Adapters hinterlegt.

Wie mächtig der Adapter bzw. wie umfangreich die Abbildungsregeln sein müssen, hängt davon ab, wie groß die Differenzen zwischen Applikations- und Zielmodell sind. Für eine bestehende Anwendung mit technischen Restriktionen müssen in der Regel große Teile der Geschäftsregeln und des Domänenmodells im Zielmodell vorhanden sein. Passend dazu sind entsprechende Abbildungsregeln im Adapter erforderlich. Die bestehende Anwendung wird im Wesentlichen als Datenquelle bzw. -senke verwendet und der Adapter fungiert als O/R Mapper oder O/O Mapper. In der Anlagegrenzprüfungsanwendung werden beispielsweise die Einträge in der VALUE_LISTS-Tabelle beim Lesen in passende Wertpapierklassen, Länder und Regionen umgewandelt. Beim Speichern der Daten erfolgt die Rückabbildung. Für eine bestehende Anwendung mit Restriktionen durch Komplexität kann der Adapter schlanker ausfallen. In den meisten Fällen gibt es einige Gemeinsamkeiten zwischen Applikations- und Zielmodell. Der Adapter muss durch die Abbildungsregeln nur „den Rest hinzufügen“. Darüber hinaus bringt der Adapter die Robustheit ins Modell zurück, deren Fehlen den Anstieg der Komplexität verursacht haben könnte. Für die Beispielanwendung bedeutet das, dass

• durch den Adapter die fehlenden Verknüpfungen bereitgestellt werden (COUNTRY_CODE auf Länderliste und SECURITY_TYPE auf Wertpapierklasse).
• der Benutzer beim Erstellen einer Länderliste oder einer Wertpapierklasse nur gültige Elemente angezeigt bekommt.

Wenn ein vollwertiger Adapter für den konkreten Anwendungsfall zu aufwändig wäre, kann er auch in einer reduzierten Variante bereitgestellt werden (Kasten: „Darf es nur die Hälfte sein?“).

[ header = Seite 3: Architektur ]

Architektur

Der vorgestellte Entwurf für die Umwandlung einer bestehenden Anwendung enthält drei Bestandteile: die Anwendung selbst, das Zielmodell und den Adapter (Abb. 6). Die beiden letztgenannten gliedern sich in die folgenden Komponenten:

Zielmodell:
• Modell-Repository und Regel-Repository: In diesen Repositories ist das Zielmodell der User Owned Application konfiguriert. Sie beschreiben die Struktur der fachlichen Daten im Zielmodell und die Geschäftsregeln in der Sprache des Fachanwenders.
• Konfigurationsmasken: Zur Pflege des Domänenmodells und der Geschäftsregeln durch den Anwender stehen eine Reihe von Benutzermasken zur Verfügung.
• Pflegeoberflächen: Für die Pflege der eigentlichen fachlichen Daten (bspw. konkrete Fonds, Regeln oder Regionen) gibt es entsprechende Benutzermasken. Die in diesen Masken angezeigten Daten werden aus dem Applikationsmodell geladen und vom Adapter umgewandelt. Zusätzlich können sie aus der Persistenz für fachliche Daten kommen.
• Persistenz für fachliche Daten: Im Normalfall werden fachliche Daten im Applikationsmodell der bestehenden Anwendung persistiert, um Redundanzen zu vermeiden. Das Zielmodell enthält solche Daten nur, wenn sie sich im Applikationsmodell nicht ablegen lassen, weil keine entsprechenden Datenstrukturen existieren (wie zusätzliche Verbindungen zwischen vorhandenen Modellelementen in unserem Beispiel).
Handelt es sich um eine performancekritische Anwendung, kann dieser Speicher als Cache verwendet werden. Die Umwandlung vom Applikations- ins Zielmodell muss dann nicht bei jedem Zugriff, sondern nur bei Invalidierung des Caches erfolgen.
Adapter:
• Repository für Abbildungsregeln: In diesem Repository sind die Regeln für die Abbildung der fachlichen Daten vom Applikations- ins Zielmodell und umgekehrt beschrieben.
• Konfigurationsmasken für Abbildungsregeln: Die Abbildungsregeln können zur Laufzeit über entsprechende Konfigurationsmasken verändert werden.
• Abbildungskomponente: Die Abbildungskomponente führt die eigentliche Umwandlung der fachlichen Daten zwischen Applikations- und Zielmodell aus.

Abb. 6: Architektur der umgewandelten Anwendung

Die vorgestellte Vorgehensweise stellt eine konsequente Weiterentwicklung modellgetriebener Softwareentwicklungsansätze dar. Das Zielmodell bildet das Pendant zum Platform Independent Model (PIM) und das Applikationsmodell zum Platform Specific Model (PSM). Die Verbindung wird in beiden Ansätzen durch den Adapter realisiert. Die beiden entscheidenden Unterschiede sind, dass der Adapter bidirektional arbeitet und dass die Umwandlung vom PIM ins PSM und zurück zur Laufzeit und nicht zur Entwicklungszeit erfolgt.

Fazit

Eine User Owned Application erlaubt es den Fachanwendern, die Geschäftsregeln und das Domänenmodell ihrer Anwendung selbstständig zu pflegen. Dieser Artikel hat vorgestellt, wie eine bestehende Anwendung in eine User Owned Application umgewandelt werden kann. Er hat aufgezeigt, wie sich die bestehende Anwendung klassifizieren lässt, um die notwendigen Schritte und den Aufwand zur Umwandlung abzuschätzen. Diese Klassifizierung ist darüber hinaus auch für die Evaluierung von Standardsoftware verwendbar. Anhand einer Fallstudie wurde demonstriert, wie eine bestehende Anwendung ohne große Eingriffe umgewandelt werden kann. Das vorgestellte Vorgehen berücksichtigt dabei den Investitionsschutz für eine bestehende Anwendung und ermöglicht eine gleichzeitige Öffnung dieser Anwendung für die Fachanwender.

Darf es nur die Hälfte sein?
Oft reicht es aus, wenn der Benutzer die Inhalte des Applikationsmodells in der Sprache seines Domänenmodells und seiner Geschäftsregeln dargestellt bekommt. In einer weniger aufwändigen Variante kann der Adapter für solche Einsatzszenarien nur unidirektional ausgelegt werden. Er liest lediglich die Inhalte der bestehenden Anwendung und stellt diese im Zielmodell dar. In der vorgestellten Beispielapplikation ließen sich mit diesem Ansatz bspw. die Wertpapierklassen, Regionen und Länder fachlich sauber darstellen und die im Applikationsmodell fehlenden Verbindungen zwischen den Wertpapierattributen und den Listen visualisieren.
Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Daniel Kaminsky
Daniel Kaminsky
Daniel Kaminsky ist als Consultant bei der Cofinpro AG beschäftigt. Er ist seit Jahren in der Java-Welt zu Hause und setzt seine Projekte mit Vorliebe nach der Scrum-Methodik um.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.