Mittwoch, 16. März 2016

Die Ablösung von "SuperMario" - oder das Thema "ReadOnly"


Diesen Artikel hat mein Opitz-Kollege Jürgen von Wachtendonck für unser Intranet verfasst. Das Konzept der folgenden Idee haben wir zusammen erarbeitet und verprobt. Alle Original Projekt- und Kundennamen wurden durch Ersatzkonstrukte aus meiner Fantasie ersetzt. Technologisch bewegen wir uns im PL/SQL, Datenbank und Forms Umfeld der Firma Oracle.

Dieser Artikel betrachtet die unterschiedlichen Aspekte, die bislang bei den Arbeiten an der Ablösung von <SuperMario> für das ehemalige <Firma1>-Team zum Tragen gekommen sind. - Nur kurz für diejenigen unter euch, die es vielleicht noch nicht wissen: 
"<SuperMario>" heißt die von unserem Team über viele Jahre hinweg entwickelte und betriebene Lösung bei <Firma1>. - Auch wenn die Umsetzung über normale <SuperMario>-Tickets erfolgt, so handelt es sich dennoch um ein großes Projekt: Es handelt sich um das größte Arbeitspaket, welches wir bei <Firma1> seit Jahren umgesetzt haben. 

Im Oktober 2015 haben wir begonnen, ein stabiles und tragfähiges Konzept zu entwickeln. Das Konzept ermöglicht eine abschnittweise Ablösung von <SuperMario> mit einer zeitversetzten Datenmigration, die nicht an die Releasezyklen der Anwendung gebunden ist. Wesentliches Ziel ist es, eine Datenmigration durchzuführen, ohne dass es bei der abzulösenden Anwendung <SuperMario> zu technischen Problemen kommt.

Worum geht es bei dem Projekt?
Seit Jahren gibt es Bestrebungen, die Anwendung <SuperMario> oder Teile der Anwendung abzulösen. Im Gespräch waren die Auslagerung von Modulen wie des Java-Clients oder die Ablösung von <SuperMario> durch eine Standardsoftware im Rahmen des <Himmel>-Projekts. Zu einer erfolgreichen und vollständigen Ablösung ist es bisher allerdings noch nicht gekommen. 

Nachdem <Firma2> <Firma1> gekauft hat, wurde beschlossen, dass die Planungstools bei <Firma2> erhalten bleiben und die Tools von <Firma1> abgelöst werden sollen. Diese Festlegung veränderte die Rahmenbedingungen. Seit dieser Entscheidung wird gezielt daran gearbeitet, die "überflüssigen" Tools abzulösen. 

In Zusammenarbeit mit <James Bond>, unserem direkten Ansprechpartner bei <Firma1>, haben Jürgen  und ich ein tragfähiges Konzept für <SuperMario> entwickelt, welches den Übergang der Verantwortung von verschiedenen fachlichen Bereichen von <Firma1> zu <Firma2> abbildet. Ziel ist es, die Bereiche in der Anwendung <SuperMario>, die nicht mehr in der Verantwortung von <Firma1> sind, auf "ReadOnly" zu setzen. 

Fachlicher Ansatz
Es ist geplant, dass der Wechsel der Verantwortung von <Firma1> zu <Firma2> sukzessive erfolgen wird. Aus diesem Grund ist es erforderlich, eine Konstruktion zu erstellen, die sicherstellt, dass Daten in den einzelnen Bereichen nur noch in dem verantwortlich führenden Tool angelegt, bearbeitet und gelöscht werden können. 

Durch diese Vorgabe muss für jede betroffene Tabelle und für jeden einzelnen Datensatz in den betroffenen Tabellen zu jeder Zeit die Datenhoheit eindeutig zu ermitteln sein. Weil das konkrete Vorgehen bei der Datenmigration noch nicht festgelegt wurde, haben wir eine Konstruktion aufgebaut, in der es möglich ist, die Datenhoheit für einen Teil der Datensätze bereits von <Firma1> zu <Firma2> zu übertragen. Gleichzeitig können aus <SuperMario> immer noch neue Datensätze in die entsprechenden Tabellen geschrieben werden, weil die Datenhoheit für diesen Bereich noch bei <Firma1> liegt. 

Technisches Konzept "ReadOnly"
Wichtig ist an dieser Stelle die Statements 'Insert' und 'Update und Delete' getrennt zu betrachten, weil die Datenhoheit für einzelne Datensätze schon vor der Übergabe der jeweiligen Tabelle an <Firma2> übergehen kann. 

Alle betroffenen Tabellen werden um eine Spalte "Besitzer" erweitert, damit es möglich ist, die Datenhoheit für den einzelnen Datensatz zu ermitteln. Dieser Wert steuert, ob ein Update oder Delete für den Datensatz abgesetzt werden darf. 

Für jede betroffene Tabelle wird ein Eintrag in einer Steuertabelle erstellt, in der der Besitzer für die Tabelle gespeichert ist. Solange die Datenhoheit der Tabelle bei <Firma1> liegt, ist es möglich in der Tabelle neue Datensätze anzulegen. Diese neuen Datensätze unterliegen immer der Datenhoheit von <Firma1>. 

Die Prüfung der Statements wird durch neue Trigger auf allen betroffenen Tabellen gewährleistet, die jeweils prüfen, ob das abgesetzte Statement erlaubt ist oder nicht. Im Fehlerfall wird eine Exception mit eindeutiger Fehlernummer ausgelöst, welche die Verarbeitung abbricht. Um sicher zu stellen, dass es für uns möglich bleibt alle Daten in einer Datenbereinigung verarbeiten zu können, haben wir eine Package-Variable definiert, die bestehende Verbote aufhebt. Mit dieser robusten und einfachen Konstruktion stellen wir sicher, dass auf der Datenbank keine unerwünschten Datenänderungen mehr erfolgen können. 

An dieser Stelle hatten wir datentechnisch, d. h. auf der Datenbank, bereits eine sichere Lösung erreicht. Offen war an dieser Stelle noch, wie die Anpassungen in der Anwendung <SuperMario> aussehen sollen. Hier haben wir verschiedene Aspekte diskutiert und letztlich gemeinsam mit dem Kunden entschieden, dass es nicht darum gehen kann, dass sich der Anwender "wohlfühlt". Wichtig ist, dass er die nötigen Informationen erhält. 

Um dies zu gewährleisten, müssen die erforderlichen Informationen an allen Stellen in <SuperMario> dargestellt werden, an denen Daten aus den betroffenen Tabellen dargestellt und/oder bearbeitet werden. Die im Folgenden beschriebenen Änderungen wurden alle in Oracle Forms umgesetzt: 

Für jeden Datensatz einer betroffenen Tabelle wird die Darstellung in der Anwendung um das jeweilige Besitzer-Flag ergänzt. So kann der Anwender erkennen, wer für den einzelnen Datensatz verantwortlich ist. Zusätzlich wird für die jeweilige Tabelle ein Info-Feld angelegt, das sichtbar wird, sobald die Datenhoheit für die Tabelle an <Firma2> übertragen worden ist. Im Einzelfall werden Buttons deaktiviert, wenn sie im Hintergrund Daten in die betroffenen Tabellen schreiben. 

Dem Endanwender wird grundsätzlich die Freiheit gelassen, alle Daten zu bearbeiten. Wenn Daten nicht mehr in <SuperMario> gespeichert werden dürfen, so wird dies durch die Trigger auf der jeweiligen Tabelle verhindert. Die oben beschriebene Exception wird in <SuperMario> gezielt abgefangen und mit einer sprechenden Meldung dargestellt. Eventuelle Veränderungen der Daten in einer Maske werden automatisch zurückgerollt und der Ursprungszustand der Daten wieder hergestellt. 

Stufenweise Umsetzung
Wichtig ist beim Thema ReadOnly eine robuste Umsetzung, die sicherstellt, dass keine fehlerhaften Daten auf der Datenbank ankommen können. Nach den konzeptionellen Überlegungen haben wir eine beispielhafte Teilumsetzung als "Proof of Concept" erstellt. Diese Umsetzung hat <Firma1> intensiv geprüft. Erst nach erfolgreichem Abschluss dieser Prüfungen wurden die betroffenen Bereiche fachlich in einzelne Phasen unterteilt, damit die Projekte überschaubar abgewickelt werden können.
So haben sich bis heute drei Phasen ergeben:
  • Proof of Concept
  • Phase 1 (<Fachliches Objekt 1>, <Fachliches Objekt 2>, <Fachliches Objekt 3>, und anderes)
  • Phase 2 (<Fachliches Objekt 4> und Fachliches <Objekt 5>)

Ob wir weitere Phasen umsetzen werden, ist zurzeit nicht klar, weil die Möglichkeit besteht, dass <Firma2> <SuperMario> vorher stilllegt und die verbleibenden Daten im Anschluss in die eigenen Systeme migriert. Wenn sich allerdings abzeichnet, dass die Übergangsphase noch länger dauert, wird das Projekt ReadOnly voraussichtlich noch weitere Bereiche in <SuperMario> entsprechend bearbeiten. 

Wie sind unsere Erfahrungen in diesem Projekt?
Unsere Erfahrung mit dem gewählten Vorgehen ist sehr gut und alle Beteiligten zeigen sich mit dem technischen Ansatz sehr zufrieden. Allerdings ist der Entwicklungs- und Testaufwand ist im Vergleich zu den anderen Tickets, die wir derzeit bei <Firma1> umsetzen, sehr hoch. Aus diesem Grund gab es in Zusammenarbeit mit <Firma1> leider auch einige Unstimmigkeiten:

Die Erwartungshaltung der Gegenseite zum zeitlichen Aufwand war immer deutlich niedriger, als der von uns geschätzte und der tatsächliche Aufwand. Dies passierte sowohl in Phase 1 als auch in Phase 2. Bei Phase 2 gab es sogar eine zeitliche Planung der Fertigstellung, die nicht mit uns abgestimmt war. Möglicherweise wäre hier ein anderer Ansatz zielführender gewesen, nämlich eine möglichst frühe Umsetzung ohne eine konkrete lückenlose Spezifikation nach dem Wasserfallmodell. Das hätte wesentlich schneller Ergebnisse geliefert, dabei wären aber mögliche anzupassende Module eventuell vergessen worden. Der Auftraggeber hatte jedoch explizit eine Schätzung verlangt, wie lange die Umsetzung dauern wird. 

Wir haben aus diesen, für alle Beteiligten, unangenehmen Situationen gelernt. Die anschließend aufgeführten Punkte beziehen sich natürlich auf dieses Projekt und lassen sich bestimmt nicht 1:1 auf andere Projekte übertragen, trotzdem können sie vielleicht dem ein oder anderen von euch in ähnlichen Situationen helfen.
  • Früh über erste/ungefähre Schätzungen oder sogar über das Bauchgefühl sprechen
  • Früh über Kosten, Zeit, zeitliche Planung und Verfügbarkeiten sprechen
  • Möglichst früh konkrete Erwartungshaltungen der anderen Beteiligten abholen
  • Zeitplanung/Meilensteine und Prioritäten des Auftraggebers abfragen, insbesondere wenn nichts kommuniziert ist
  • Nicht von gleichen Annahmen ausgehen, was Zeit, Aufwand, Planung etc. betrifft, selbst wenn die unbestimmte Beschreibung gleich ist. (Begriffe können im Kontext unterschiedlich belegt sein, wie z.B. schnell, einfach, zügig, komplex, schwierig, wichtig, …)
  • Sich fragen, ob man durch die Brille des Auftraggebers schauen kann.
    Was passiert, wenn der Auftraggeber nicht die Brille des Dienstleisters aufhat?
  • Prüfen, ob alle Beteiligten über alle Punkte (Aufgabe, Zeit, usw.) vollständig kommuniziert haben
Zum Schluss möchten wir noch erwähnen, dass wir von <Firma1> eine Person an die Seite gestellt bekommen haben, welche die durchgeführten Änderungen in der Anwendung testet. Wir müssen teilweise fachlich und technisch unterstützen. Was uns dabei sehr gut gefällt, ist die Tatsache, dass diese Person auch in anderen Bereichen für den Test von Anwendungen verantwortlich ist. Unsere Änderungen werden daher über den Entwicklertest hinaus sehr ausführlich getestet. Aus unserer Sicht ist das dem Thema ReadOnly angemessen und wir begrüßen dies auf jeden Fall. So können wir uns auf die fachlichen Anforderungen und die technische Umsetzung konzentrieren.
Und nun noch ein schönes Schlusswort …    

… ein Zitat vielleicht?
"Der Langsamste, der sein Ziel nicht aus den Augen verliert, geht noch immer geschwinder, als jener, der ohne Ziel umherirrt." (Gotthold Ephraim Lessing)

Schönen Gruß
Jürgen und Holger

P.S.: Gerne stellen wir dieses Thema auch näher bei einem DOAG-Vortrag vor.