Das Problem der Parallelität

Seit den 1970er Jahren bearbeiten Softwareentwickler dieselben Dateien gleichzeitig. Zwei Personen ändern dieselbe Funktion. Der eine überträgt seine Änderungen zuerst. Der andere erhält einen Merge-Konflikt. Dieses Problem wurde so gründlich gelöst, dass jeder heute tätige Entwickler die Lösung nutzt, ohne darüber nachzudenken: die Versionskontrolle. Speichere deine Änderungen vorläufig. Übertrage sie, wenn du bereit bist. Wenn jemand anderes dasselbe geändert hat, weist das System darauf hin, und du klärst den Konflikt, bevor etwas live geschaltet wird.

Bei Felddaten besteht dasselbe Problem. Zwei Teams bearbeiten Objekte im selben Gebiet. Das eine befindet sich unterirdisch und hat keine Internetverbindung. Das andere ist am anderen Ende der Stadt und hat nur einen unzuverlässigen Mobilfunkempfang. Beide kommen wieder online und übermitteln ihre Änderungen. Wenn das System die Überschneidung nicht erkennt, überschreibt die Arbeit des einen Teams stillschweigend die des anderen. Wenn das System Datensätze sperrt, um Konflikte zu vermeiden, kann niemand mehr offline arbeiten. Das sind dieselben Kompromisse, mit denen Software-Teams vor der Einführung der Versionskontrolle konfrontiert waren – und die meisten Feldsoftware-Lösungen stecken immer noch dort fest.

Wie die meisten Außendienstprogramme damit umgehen

Es gibt drei gängige Ansätze, und jeder davon ist mit Kosten verbunden.

Der letzte Schreibvorgang hat Vorrang. Die einfachste und gefährlichste Variante. Beide Benutzer nehmen Änderungen vor. Beide senden ihre Änderungen ab. Die zweite Übermittlung überschreibt die erste ohne Vorwarnung. Die Arbeit des ersten Benutzers ist verloren. Dieser Ansatz ist beunruhigend häufig in Feldsoftware anzutreffen, die ursprünglich für den Einzelbenutzerbetrieb konzipiert und später nachträglich um Mehrbenutzerunterstützung erweitert wurde. Er funktioniert, bis er nicht mehr funktioniert, und wenn er versagt, geschieht dies ohne Vorwarnung.

Datensatzsperren. Das System sperrt ein Objekt, sobald es von einem Benutzer zur Bearbeitung geöffnet wird. Solange die Sperre nicht aufgehoben wird, kann niemand anderes Änderungen vornehmen. Dadurch werden Konflikte vermieden, indem gleichzeitige Bearbeitungen verhindert werden – was allerdings auch die Arbeit im Offline-Modus vollständig ausschließt. Wenn ein Außendienstmitarbeiter ein Objekt sperrt und sich anschließend für vier Stunden in einen U-Bahn-Tunnel begibt, ist dieses Objekt für das gesamte Team gesperrt. Datensatzsperren tauschen Datenintegrität gegen einen Stillstand der Arbeitsabläufe ein.

Konfliktvermeidung durch Gebietsabgrenzung. Weisen Sie jedem Team einen geografischen Bereich zu und vertrauen Sie darauf, dass es darin bleibt. Dies funktioniert, wenn sich die Bereiche niemals überschneiden, die Grenzen stets eingehalten werden und keine Elemente über eine Grenze hinwegreichen. In der Praxis überschneiden sich die Bereiche jedoch an jeder Kreuzung, jeder Grenze und jedem gemeinsamen Infrastrukturkorridor. Der Ansatz funktioniert in der Theorie, versagt jedoch an den Rändern – genau dort, wo die meisten interessanten Aufgaben anfallen.

Das Modell der Versionskontrolle

Unser Ansatz orientiert sich direkt an der Arbeitsweise von Software-Teams. Die Konzepte lassen sich eins zu eins übertragen.

Die Bearbeitung erfolgt lokal. Wenn ein Außendienstmitarbeiter ein Objekt bearbeitet – einen Punkt verschiebt, eine Linie umformt oder Eigenschaften aktualisiert –, wird die Änderung in seinem Browser gespeichert. Sie ist für andere nicht sichtbar. Dies entspricht der Bearbeitung einer Datei in Ihrem lokalen Zweig. Der Mitarbeiter kann Schritte rückgängig machen, wiederholen und die Bearbeitung fortsetzen, ohne den gemeinsam genutzten Datensatz zu beeinflussen. Ein Badge für nicht festgeschriebene Änderungen zeigt an, wie viele Bearbeitungen noch ausstehen, genauso wie ein Entwickler nicht gestagte Änderungen verfolgt.

Einreichen bedeutet Festschreiben. Wenn der Mitarbeiter fertig ist, klickt er auf „Einreichen“. Alle ausstehenden Änderungen werden als eine einzige Version auf den Server übertragen – ein zusammenhängender Satz von Änderungen mit einem Zeitstempel und der Identität des Einreichers. Dies ist ein Commit. Er ist atomar: Entweder werden alle Änderungen übernommen oder keine.

Die Überprüfung durch den Administrator ist eine Codeüberprüfung. Für Mitarbeiter ohne Administratorrechte wird der Beitrag nicht direkt veröffentlicht. Es wird eine zur Überprüfung vorgesehene Version erstellt. Ein Administrator öffnet die Überprüfungswarteschlange, sieht die Unterschiede – was sich wo geändert hat und wie sich dies im Vergleich zum aktuellen Stand darstellt – und genehmigt oder lehnt den Beitrag ab. Dies entspricht einem Pull-Request. Der gemeinsame Datensatz ändert sich erst, wenn eine berechtigte Person dies genehmigt.

Konflikterkennung ist eine Zusammenführungsprüfung. Wenn eine Version eingereicht wird, prüft der Server, ob seit der letzten Synchronisierung des Einreichers jemand anderes dieselben Elemente oder dasselbe geografische Gebiet bearbeitet hat. Bei Überschneidungen wird der Konflikt markiert. Beide Versionen sind sichtbar – die Änderungen des Einreichers in Blau, die des anderen Benutzers in Orange – und das Team löst den Konflikt explizit. Keine stillschweigenden Überschreibungen. Kein Datenverlust.

Die Versionshistorie ist das Commit-Protokoll. Jede festgeschriebene Version wird gespeichert – wer sie eingereicht hat, wann, was geändert wurde und wer sie genehmigt hat. Versionen werden im Laufe der Zeit komprimiert, aber niemals gelöscht. Sie können den Zustand jeder Funktion zu jedem beliebigen Zeitpunkt in ihrer Historie rekonstruieren. Das Versionsprotokoll ist gleichzeitig Prüfpfad, Rückgängig-Mechanismus und institutionelles Gedächtnis.

Wie das in der Praxis aussieht

Zwei Teams arbeiten am selben Glasfasernetz. Team A ist vor Ort und bearbeitet die Kabeltrassen im nördlichen Abschnitt. Team B arbeitet unterirdisch und bearbeitet die Spleißstellen im zentralen Abschnitt. Beide sind offline.

Team A ist fertig und wieder online. Es übermittelt seine Version. Der Server akzeptiert sie – es gibt keine Konflikte, da seit der letzten Synchronisierung von Team A niemand sonst diese Funktionen geändert hat. Der Administrator prüft die Unterschiede, bestätigt, dass die Änderungen an der Kabelverlegung sinnvoll sind, und gibt sie frei. Die Änderungen werden live geschaltet.

Team B meldet sich eine Stunde später zurück und übermittelt seine Änderungen. Der Server erkennt, dass sich zwei der Bearbeitungen an den Spleißpunkten mit Elementen überschneiden, die Team A bereits geändert hat. Es erscheint eine Konfliktwarnung. Team B öffnet die Konfliktansicht und sieht beide Versionen – die eigenen Bearbeitungen in Blau, den festgeschriebenen Stand von Team A in Orange. Es passt seine Spleißpunkte an, um den Änderungen an der Kabeltrasse durch Team A Rechnung zu tragen, übermittelt die Änderungen erneut, und der Administrator genehmigt die bereinigte Version.

Gesamtzahl der verlorenen Daten: null. Gesamtzeit für den manuellen Abgleich: Minuten. Gesamtzahl der unbemerkt überschriebenen Funktionen: null.

Vergleichen Sie dies mit den Alternativen. Bei „Last-Write-Wins“ hätte der Eintrag von Team B die Änderungen an der Kabeltrasse von Team A stillschweigend überschrieben. Bei der Datensatzsperre hätte das eine Team keine Änderungen vornehmen können, während das andere unter Tage arbeitete. Bei der gebietsbasierten Vermeidung wäre der überlappende Abschnitt zu einem Koordinationsalptraum geworden, der über Telefonate und Tabellenkalkulationen abgewickelt worden wäre.

Offline zuerst, nicht nur offline-fähig

Ein weit verbreiteter Irrtum ist, dass Offline-Unterstützung bedeutet, bei einem Netzwerkausfall einen reibungslosen Übergang zu gewährleisten. Diese Sichtweise geht davon aus, dass der Online-Zustand die Norm ist und der Offline-Zustand eine Ausnahme darstellt, die behandelt werden muss. Im praktischen Einsatz ist das Gegenteil der Fall. Die Konnektivität ist von Natur aus unbeständig – in Kellern, Tunneln, ländlichen Gebieten und auf Baustellen ohne Empfang. Ein System, das den Offline-Zustand als Ausnahme behandelt, wird die meiste Zeit im Ausnahmemodus verbringen.

Bei der Versionskontrolle ist es genau umgekehrt. Der Standardarbeitszustand ist „offline“. Jede Änderung bleibt lokal, bis Sie sich entscheiden, sie zu übermitteln. Das Netzwerk wird nur für zwei Dinge benötigt: zum Hochladen Ihrer Änderungen auf den Server und zum Abrufen des aktuellen Status von anderen. Zwischen diesen beiden Vorgängen arbeiten Sie unabhängig und mit vollem Bearbeitungsumfang. Sobald die Verbindung wiederhergestellt ist, führen Sie eine Synchronisierung durch – und das System kümmert sich um den Rest.

Deshalb funktioniert das Modell. Es wurde nicht dafür konzipiert, den Offline-Modus als Sonderfall zu behandeln. Es basiert vielmehr auf der Annahme, dass Nutzer in der Regel offline und nur gelegentlich online sind – genau so, wie es bei der Arbeit vor Ort der Fall ist.

Zusammenfassung

Die Verwaltung von Felddaten weist dasselbe Problem der Parallelität auf, das in der Softwareentwicklung bereits vor Jahrzehnten gelöst wurde: Mehrere Personen bearbeiten denselben Datensatz, oft ohne Internetverbindung, was das Risiko stiller Überschreibungen birgt.
Das Prinzip „Last-Write-Wins“ führt zu stillen Datenverlusten. Die Sperrung von Datensätzen verhindert die Arbeit im Offline-Modus. Die gebietsbasierte Vermeidung versagt an jeder Grenze und bei jeder Überschneidung.
Das Versionskontrollmodell – lokale Entwürfe, atomare Commits, Überprüfung durch Administratoren, Konflikterkennung, permanente Historie – lässt sich direkt von der Softwareentwicklung auf den Außendienst übertragen.
Änderungen vor Ort werden lokal gespeichert, bis der Mitarbeiter sie übermittelt. Übermittlungen von Nicht-Administratoren durchlaufen eine Überprüfungswarteschlange. Konflikte werden auf dem Server erkannt und zur expliziten Lösung angezeigt – keine stillen Überschreibungen, kein Datenverlust.
Jede festgeschriebene Version wird mit Absender, Zeitstempel und Genehmiger gespeichert. Der Versionsverlauf wird komprimiert, aber niemals gelöscht. Der Zustand jeder Funktion kann zu jedem Zeitpunkt rekonstruiert werden.
Offline ist der Standard-Arbeitszustand, keine Ausnahme, die behandelt werden muss. Das System geht davon aus, dass Benutzer in der Regel nicht verbunden sind und gelegentlich synchronisieren – was der tatsächlichen Arbeitsweise im Außendienst entspricht.