Einführung
Beim Designen eines Softwaresystems hat sich ein allgemein gültiges Verfahren durchgesetzt, nämlich eine funktionale Spezifikation nicht mit einem technischen Design zu mischen. Auf diese Weise haben wir vor über 10 Jahren mit der Entwicklung von Datenmigrationssystemen begonnen. Heute sieht unser bewährtes Verfahren ganz anders aus: Die beste Art, ein Datenmigrationssystem zu designen ist, beide Designs in einem einzigen Dokument zu kombinieren.
Auf den ersten Blick mag dies kontraintuitiv erscheinen. Warum glauben wir also, dass das Designen von Datenmigrationssoftware anders ist und die Kombination dieser Designs in einem einzigen Dokument absolut sinnvoll ist?
Funktionales und technisches Design
Gehen wir kurz näher auf den Unterschied zwischen einem funktionalen und einem technischen Design ein. Das funktionale Design enthält Informationen darüber, was die entsprechende Software tun sollte, während das technische Design festlegt, wie die Software erstellt werden soll. Den meisten diesbezüglichen Blogs und Artikeln zufolge sollte das funktionale und das technische Design nicht in einem Dokument kombiniert werden (siehe z.B. https://www.techrepublic.com/article/functional-vs-design-in-documentation/).
Die häufigste Argumentation finden Sie z.B. hier: www.sinax.be:
„Die Bandbreite der funktionalen Analyse endet bei der Frage, wie die Software geschrieben werden muss. Daher enthält eine rein funktionale Analyse keine technischen Details über die Implementation der Software. Obwohl diese Erfordernisse genauso wichtig sind, müssen sie in die technische Analyse inkludiert werden und haben nichts mit den funktionalen Aspekten zu tun.
Der Grund dafür ist im Grunde ganz einfach: Die funktionale Analyse ist für alle Stakeholder ein Dokument zur Referenz. Hier überwiegt die Funktionalität der Software, und nicht die technische Implementierung. Die Endbenutzer der Software können keine Rückmeldung zur technischen Umsetzung geben (…) während sie sich mit dem funktionalen Aspekt auseinandersetzen müssen."
Auch wir sind der Meinung, dass es sich bei einem funktionalen und einem technischen Design um zwei verschiedene Dinge handelt, es gibt jedoch eine Reihe von Gründen, die uns überzeugen, dass ihre Kombination in ein einzelnes Dokument den Datenmigrationsprozess sogar verbessert:
- Das Deviationsrisiko zwischen den beiden ist geringer.
- Das funktionale Verständnis ist für die Softwareentwickler hilfreich.
- Die Zielgruppe des Dokuments ist eine andere, wenn es um Datenmigration geht.
- Weniger Redundanz bedeutet mehr Effizienz.
Geringere Deviationsrisiken
Ein Design ist kaum jemals endgültig abgeschlossen, solange nicht die Softwareentwicklung, die es beschreibt, abgeschlossen ist. Die Prüfung, die Komplikationen, die während der Softwarekonstruktion auftreten (für eine Beschreibung siehe: wikipedia.org/wiki/Software construction) und die Produkttests werden unweigerlich Veränderungen nach sich ziehen.
Die Kommentare des Kunden beziehen sich in der Regel auf das funktionale Design (darauf werden wir weiter unten näher eingehen …), während Softwareentwickler im technischen Design auf Probleme stoßen – dies kann leicht zu einer Situation führen, wo nur eines der Designdokumente geändert wird. Gerade für Datenmigrationen ist es besonders wichtig, dass sie angepasst werden, da sie weitgehend miteinander übereinstimmen, wie in diesem Beispiel zu sehen ist:
Man braucht einen sehr disziplinierten Designer, um sicherzustellen, dass immer beide Versionen angepasst werden! Warum machen wir uns das Leben nicht einfacher und stellen das funktionale Design neben das technische Design und verringern somit das Deviationsrisiko zwischen den beiden?
Die Anwesenheit des anderen Designs dient als freundliche Erinnerung daran, dass eine Veränderung in beiden Designs vorgenommen werden muss. Schluss mit: „Oh, ich darf nicht vergessen, das andere Dokument auch in Übereinstimmung zu bringen!“
Funktionales Verstehen hilft den Entwicklern
Der Hauptgrund für das Standardwissen über die Trennung von funktionalem und technischem Design liegt darin, dass das Zielpublikum für beide Designs sehr unterschiedlich ist. Das funktionale Design ist für jenen Kunden bestimmt, der sich nicht mit technischen Details herumschlagen möchte. Umgekehrt benötigen die Softwareentwickler nur die technischen und keine funktionalen Informationen. Soweit die Theorie.
Wir glauben, dass diese Argumentation nicht für die Software-Designs für Datenmigrationen gilt.
Sie bauen eine Software, Sie führen sie ohne Fehlerbenachrichtigungen aus – der Entwickler hat seinen Job gut gemacht, oder? Technisch ja, aber was, wenn Entwickler für das, was sie bauen, auch die funktionale Beschreibung zur Verfügung haben? Das würde ihnen bei der Prüfung ihrer Arbeit noch besser helfen.
Auch für Designer ist dies hilfreich, denn die Testergebnisse der Entwickler sind spezifischer und umfassender.
Datenmigrationsdesigns haben unterschiedliche Prüfertypen
Die Datenmigrationen unterscheiden sich von anderen Softwareentwicklungen durch einen wichtigen Aspekt: Wir designen die Software nicht von Grund auf, sondern beschreiben die Art und Weise, wie die Quelldatenbank zum Ausfüllen der Zieldatenbank verwendet werden muss. Hierfür kommt der hauptsächliche Input von Personen, die sowohl funktionale als auch technische Kenntnisse über das Quell- und Zielsystem haben.
Dies bedeutet, dass die Prüfung nicht nur auf das funktionale Design beschränkt werden kann. Auch das technische Design muss von den Workshopmitgliedern geprüft werden, denn sie müssen erkennen, dass das ‚Was‘ mit dem ‚Wie‘ übereinstimmt und die richtigen Tabellen und Attribute verwendet werden. Darüber hinaus werden die meisten Prüfer während eines Datenmigrationsprojekts über ihre funktionalen als auch technischen Kenntnisse verfügen. Die Kombination dieser Informationen in einem Dokument erleichtert ihre Aufgabe also in erheblichem Maße.
Weniger Redundanz bedeutet mehr Effizienz
Beim Designen eines Datenmigrationssystems werden viele redundante Informationen in technischen und funktionalen Designs angegeben. Das funktionale Design beschreibt zum Beispiel die Semantik eines speziellen Zielfeldes sowie einer Mapping-Funktion, die Zieldaten enthält. Das technische Design enthält genau die gleichen Informationen. Diese offensichtliche Redundanz ist für Datenmigrationssysteme typisch.
Bei der Kombination der Designdokumente wird diese Redundanz entfernt, wodurch das gesamte Design wesentlich kompakter und weniger zeitaufwändig (und damit kostengünstiger!) zum Erstellen und Verwalten von Designs wird.
Schlussfolgerung
Das standardisierte Wissen diktiert unterschiedliche Dokumente für das funktionale und für das technische Design. Wenn es um Datenmigrationen geht, bringt das Kombinieren der Designs erhebliche Vorteile mit sich. Jetzt ist es an Ihnen, um herauszufinden, ob diese Argumente auch für Ihre Situation zutreffend sind.