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.
