Skip to content

Instantly share code, notes, and snippets.

@almereyda almereyda/konzeptpapier.md Secret
Last active Aug 29, 2015

Embed
What would you like to do?
Subsistenzcloud : Konzeptpapier + Appendizes

Konzeptpapier

Jon Richter jon@gartenkarte.de +49 163 829 35 18

Berlin, den 20.03.2013


Subsistenzcloud

Stiftungsgemeinschaft Anstiftung & Ertomis + Grünanteil


Vorbemerkung

Die einzelnen Phasen des Entwicklungsprozesses greifen eigentlich stärker ineinader, als es aus diesem Konzept abzulesen ist. Es dient vornehmlich der Definition von klaren Anforderungen und damit Abnahmekriterien für die einzelnen Entwicklungs- und Finanzierungsschritte. Nach jeder Phase folgt eine Evaluation der Anforderungen sowie eine Anpassung des Entwicklungskonzeptes an womöglich veränderte Rahmenbedingungen.

Ausgangslage

Die Stiftung hat eine DB mit rund 400 Gartenprofilen. Diese werden aktuell auf einer GoogleMap dargestellt - mit Hilfe eines Joomla-Moduls, in dem auch die Daten verwaltet werden. Gleichzeitig gibt es aber auch noch andere „eigene“ Karten, z.b. offene Werkstätten, Velogistics, Repair Cafés und externe Karten, z.b. Stadtacker, urbane-gaerten-muenchen.dehttp://urbane-gaerten-muenchen.de, deren Grunddaten aus anderen Quellen stammen.

Ziel

1a) Darstellung der eigenen Daten auf OSM und 1b) Möglichkeit diese Daten anderen Projekten zur Verfügung zu stellen. 2) Gleichzeitig sollen auch andere Daten (z.b. die aus dem auslaufenden Stadtackerprojekt) auf den „eigenen“ Karten dargestellt werden können.

Strategie

Da nicht alle (Meta-)Daten der Karten der Stiftungsgemeinschaft Anstiftung und Ertomis in der Datenbank der OpenStreetMap abgelegt werden können, ist es notwendig dafür zusätzlich eine private Datenbank mit Zugriffsregelungen aufzubauen. Eine mit der Community abgesprochene Teilmenge dieser Daten wird später mit OpenStreetMap synchronisiert.


Begriffsklärung

OpenStreetMap (OSM) ist:

  • ...eine Datenbank mit geographischen Informationen.
  • ...eine aus diesen Daten berechnete Kartengrundlage zum Einbinden in Webkarten.
  • ...eine Webseite unter http://openstreetmap.org, welche diese und weitere Dienste (Geokoding, Bearbeitungsmöglichkeiten) zusammenfasst.

OpenStreetMap ist nicht:

  • ...ein Programm, welches die Anzeige von Webkarten im Internetbrowser ermöglicht.

Google Maps ist:

  • ...eine Datenbank mit geographischen Informationen.
  • ...eine aus diesen Daten berechnete Kartengrundlage zum Einbinden in Webkarten.
  • ...ein Programm, welches die Anzeige von Webkarten im Internetbrowser ermöglicht.
  • ...eine Webseite unter https://maps.google.com, welche diese Dienste (und Geokoding) zusammenfasst.

Phase I : Konzeptionierung

Die Konzeptionierungsphase für die Subsistenzcloud ist bereits abgeschlossen und wird hier in ihren Ergebnissen präsentiert.

Anforderung

  • klare Definition der Entwicklungsrichtung
  • sinnvolles Ergebnis > Implementierung

01.12.2013 - 28.02.2014

Prototyp : GeoCouch

GeoCouch ist eine schemafreie Geodatenbank, welche die Integration von vielfältigen Daten ohne vorher festgelegte Struktur erlaubt. Daher eignet sie sich besonders gut für die zentrale Aufnahme der bislang an unterschiedlichen Orten abgelegten Daten.

Entwurf : dezentrale Dienstarchitektur

Der Entwurf der dezentralen Dienstarchitektur umfasst Regelungen zur Ablage und Wiedergabe der in GeoCouch abgelegten Daten. Dazu gehören

  • Sicherstellung der Skalierbarkeit bei steigendem Datenaufkommen
  • Prototyping der Synchronisation mit OpenStreetMap
  • Festlegen der Schnittstellen (API) zur Zwei-Wege-Interaktion der verschiedenen Karten mit der Datenbank

Einrichtung : Kommunikationsinfrastruktur

Zur Kommunikationsinfrastruktur gehören Best Practices zur Nutzung virtueller Artefakte (Mailinglisten, Foren, Trello, Timeline) zur Prozesssteuerung wie auch die persönliche Verknüpfung der einzelnen an diesem Prozess beteiligten Personen(-gruppen).


Phase II : Implementierung

Im Verlauf der zweiten Phase erfolgt die Integration der geplanten Systeme und außerdem eine Abstimmung mit dem Webentwickler von anstiftung-ertomis.de und offene-werkstaetten.de.

Anforderung

  • vollständig funktionsfähiger Prototyp der Subsistenzcloud
  • Testen der Datenschnittstellen

01.03. - 31.05.2014

DevOps : Infrastrukturaufbau

Ziel der zweiten Phase Development & Operation ist das Programmieren der im Konzept festgelegten Schnittstellen und das Betreiben einer Entwicklungsumgebung der tatsächlichen Datenbank.

Private API : grünanteil

Testen der Schnittstelle zur Ausgabe und Ablage von Daten mit dem Subsistenzcloud-Partnerprojekt grünanteil, da deren Datengrundlage noch nicht so umfangreich ist wie die bestehenden Produktivumgebungen.

Kartendienste I : stadtacker offene-werkstätten velogistics bienenkiste repair-cafés urbane-gaerten-muenchen

Auf Basis der Ergebnisse des vorausgehenden Tests folgt die Integration der bereits an mehreren Orten veröffentlichten Daten in die GeoCouch. Dies geschieht durch das Vorbereiten der Umstellung durch die Implementierung von einfach zu bedienenden Interaktionsmöglichkeiten mit den Datengrundlagen.

  • Import der bisherigen Geodaten
  • Anzeige beliebig gefilterter Daten auf Webkarten
  • Editor zur Bearbeitung der Geo- und Metadaten

Phase III : Veröffentlichung

Auf Grund des dynamischen Charakters dieses Softwareentwicklungsprozesses lassen sich diese spätere Schritte noch nicht umfassender antizipieren.

Anforderung

  • Die Daten der Subsistenzcloud werden mit OpenStreetMap abgeglichen.
  • Die Subsistenzcloud als Open Source Projekt

01.06. - 31.08.2014

Öffentliche API : dauerhafte Integration in OSM + LD-ready

In der letzten Phase werden die Daten dauerhaft und regelmäßig mit OpenStreetMap synchronisiert. Gleichzeitig erfolgt die Vorbereitung auf Einbindung in die Linked Geodata Cloud.

Kartendienste II : weitere Integrationen

Abhängig vom Erfolg der vorausgehenden Schritte und den dann besser zu antizipierenden Infrastrukturnutzungen wie -kosten erfolgt womöglich die Öffnung der Datenbank für weitere, ausgewählte Projekte.

extensive Dokumentation

Der gesamte Entwicklungsprozess wird durch eine kontinuierliche Dokumentation begleitet, damit spätere Entwickler und Nutzer der Datenbank oder Schnittstellen einen einfachen Einstieg erhalten.


http://jonrichter.de

Konzeptpapier : Appendix I

Jon Richter

jon@gartenkarte.de +49 163 829 35 18

Berlin, den 15.07.2014

Subsistenzcloud

Schnittstellen zur Nutzbarmachung bestehender Datenbanken ökologisch-transformativer Projekte durch Synchronisierung mit Webdiensten.

Beschreibung der Referenzimplementierung für die Stiftungsgemeinschaft Anstiftung und Ertomis in Kooperation mit Stadtacker und grünanteil.

[TOC]

Vorbemerkungen

Dieses Dokument ergänzt das Konzeptpapier zur Subsistenzcloud vom 20.03.2014 um eine Synchronisationsebene, welche Änderungen der Datenbanken im Verbund aggregiert und verteilt.

Die Notwendigkeit zur Rekonzeptionierung entstand aus der im Entwicklungsgespräch gewonnenen gegenseitigen Erkenntnis, dass über den Zweck der Subsistenzcloud unterschiedliche Vorannahmen bestanden.

Die hier dargestellte Erweiterung der bisherigen Architektur wird auch eine stärkere Definition des Entwicklungsprozesses zur Folge haben.

Entwicklung von Webdiensten

Neben den sozialen Komponenten agiler Softwareentwicklung besteht eine ihrer Hauptaufgaben darin, vorhandene Werkzeuge zu einem logischen Gefüge anzuordnen. Der Schaffensprozess ähnelt auf Grund der Vielzahl an beteiligten Variablen der explorativen Methode, welche auch in Kreativitäts- und Innovationskontexten Erwähnung findet.

In gegenseitiger Abhängigkeit dazu steht das logische Gefüge selbst. Hochoptimierte Architekturen erlauben eine effiziente Verwendung bestehender Ressourcen und definieren bereits in ihrer Machart, wie sie selbst verwendet werden können. Dies ist der Zirkelschluss, wo das Soziale wieder ins Spiel kommt.

Die nun folgenden Ausführungen sind etwas detaillierter als nötig wiedergegeben, um die bevorstehenden Koordinationssaufgaben ausreichend abschätzen zu können. Außerdem ist es ein Versuch ein Bild von der Komplexität der Aufgaben im Unterschied zum ursprünglichen Konzept zu zeichnen.

Architekturen

Die mit dem Web groß gewordene Client---Server Beziehung bedeutete immer auch eine Abhängigkeit von verfügbaren Onlineresourcen. Ein Client stellt eine allumfassende Anfrage und ein Server liefert die vollständige Antwort aus.

Mit dem Web 2.0 genannten Umschwung zu benutzerorientierten Schnittstellen fand auch ein Umdenken der Systemdesigns statt. Server---Client Beziehungen werden neu dadurch geordnet, dass der Server flexible, standardisierte Schnittstellen bereitstellt, die es ermöglichen die berechnungsintensiven Aufgaben entsprechend den Anforderungen von mehreren Clients durch diese selbst ausführen zu lassen.

Mensch beachte auch diese Bilder zur Veranschaulichung des Konzepts.

Schnittstellen von Webdiensten

Webbasierte Datenaustauschdienste definieren klare Begriffe und Regeln, mit denen sie ihre eindeutig bezeichneten Objekte bearbeiten. Diese Definitionsvorgänge basieren selbst auf standardisierten Protokollen, welche die Interoperabilität gewährleisten.

Im Artikel RESTful Webservices: Was ist das überhaupt? erlaubt der Autor einen schnellen Überblick wovon hier die Sprache ist und geht, besonders für grünanteil interessant, am Ende auch auf TYPO3 Flow ein.

Im Grunde handelt es sich um einen Hybridansatz, da jeder Server zum anderen auch immer die Clientrolle einnehmen kann. Insofern ist Server---Server Kommunikation ein Spezialfall des Client---Server Modells.

Standardisierter Datenaustausch mit Zugangskontrolle ermöglicht einen flexiblen, vielfältigen Einsatz von den zu Grunde liegenden Daten. Die angestrebte Synchronisation ist ein Spezialfall hiervon.

Datenmodell

Es sollen zunächst nur durch die Kooperationspartner zu definierende Stammdaten zwischen den Servern ausgetauscht werden. Umfangreichere Interaktionsmöglichkeiten auch von Clientseite werden konzeptionell noch nicht explizit ausgezeichnet, aber auch nicht verhindert.

Synchronisationsstrategien

Die Konsistenz der synchronisierten Daten wird durch ein striktes Verfahren gewährleistet, welches Konflikte wenn möglich automatisch klärt und im Bedarfsfall meldet.

Da im Verbund verschiedenartige technische Systeme auf einander treffen, muss eine interoperable Sprache genutzt werden. Einfache CRUD Operationen (Create, Retrieve, Update, Delete) erlauben eine anwendungsagnostische Spezifizierung der Schnittstellen. Da wir nicht von einem Peer-to-Peer-Netzwerk der Server sprechen, benötigen wir eine zentrale Steuerungsinstanz des Austauschsvorgangs.

Die ausgelagerten, zu diesem Kapitel gehörigen Abbildungen dienen dem Überblick und leiten das Gespräch über konkrete technische Implementierungen ein.

Asynchroner Datenaustausch

Bei einem Synchronisierungsdienst zunächst von Asynchronität zu sprechen mag befremdlich erscheinen. Im Grunde beschreibt der Begriff aber lediglich, wie Aufgaben zwischen spezialisierten Subsystemen abgearbeitet und weitergereicht werden, ohne sich durch Abhängigkeiten gegenseitig zu blockieren.

Die erste Abbildung zeigt den Ablauf asynchron stattfindender Prozesse und wie sie mit einander im Kontakt stehen. Das Beispiel mit einem Flow von der Datenbank über Queue und Worker hin zum Hub veranschaulicht, wie Datenbankänderungen intern verwaltet und zur Veröffentlichung freigegeben werden.

Resourcenschonend, gewissermaßen nachhaltig ist dabei, dass sich die Warteschlangen-- und Arbeitsprozesse schon anderen Dingen zuwenden können, während die anhänglichen Prozesse noch damit beschäftigt sind ihre Aufgaben zu erfüllen. Diese nicht-blockierende Eigenschaft ist dann auch namensgebend.

Publish--Subscribe Strategie mit Webhooks

Die Darstellung der gewählten Synchronisationsstrategie gliedert sich in drei Bereiche:

  • Veröffentlichen aller globalen Änderungen durch den Hub und Abonnement dieser Ereignisse durch die angeschlossenen Partner.
  • Veröffentlichen der lokalen Änderungen der angeschlossenen Partner und Abonnement dieser Ereignisse durch den Hub.
  • Vereinfachte Sequenz eines Änderungsvorgangs ohne Versionierung und Konfliktbehandlung.

Die Details werden in einem langfristigen Technikgespräch der beteiligten Partner ausformuliert.

Konfliktverwaltung und Versionierung

Für die Verfolgung der Veränderungen wird eine für die Subsistenzcloud global gültige Identifikation der Datensätze eingeführt und ihnen beigefügt. Sollte bereits ein entsprechender OpenStreetMap Knoten bestehen ebenso dieser.

Die Arbeiter--Warteschlangen Architektur stellt dabei sicher, dass sich alle Datenbanken immer in einem konsistenten Zustand befinden und dabei stets von einer direkten Vorgängerversion auf die nächste aufgefrischt wird.

Im Widerspruch stehende Aktualisierungen lösen Benachrichtigungen aus und erfordern manuelle Auflösung.

Conclusio

Der technische Entwicklungsprozess und seine soziale Einbettung stehen in wechselseitigem Verhältnis. Die zwischenzeitlich widersprüchlichen Anforderungen blockierten ungünstigerweise beide gegenseitig den Weiter- und Neuentwicklungsprozess der ursprünglichen und hinzugefügten Spezifizierungen. Dieses Dokument hatte zum Anlass den Knoten wieder zu lösen und bietet unter Einbeziehung der Umstände eine fortgesetzte Entwicklungsperspektive.

Offene Fragen

Selbständige Agilität und institutionelle Vorgaben im Spannungsfeld von prekär-kreativer Innovation und sozialer Marktwirtschaft.

Als Unternehmer ist es schwierig bei Widersprüchen in den Anforderungen, die gestellt werden, etwas abzuliefern.

Abschluss Projektphase II ODER Ausarbeitung einer Rekonzeptionierung

Ich erkenne an, dass alle Aufgaben wichtig und mitunter auch dringend sind, doch darf es zu keinen Blockierungen von einander unabhängigen Teilaufgaben kommen. Wenn Aufgabe I : Abschluss der Projektphase II nicht kaufmännisch beendet werden kann, da die Ausarbeitung neuer Spezifikationen zusätzliche Aufmerksamkeit konsumiert und die bisherige Arbeit in Frage stellt, fehlen die Mittel, um Aufgabe II: Rekonzeptionierung überhaupt erst zufriedenstellend ausarbeiten zu können. Ein Teufelskreis der durch zirkuläre Abhängigkeit ins Stocken gerät.

Die nicht-blockierenden Elemente asynchroner Vorgangsbearbeitung lassen sich womöglich gar in begrenztem Umfang auch auf soziale Prozesse allgemein anwenden, um flüssigere Workflows zu erlauben. Einzig erkennen wir, dass sich das Verlassen des vorher abgesprochenen Prozesses durch Rückkehr in die Konzeptphase sowie ein gleichzeitiges Abschließen eines Teilprozesses unter zu verwerfenden Vorbedingungen ausschließen.

skizzenhafter Entwurf eines zeitlichen Ablaufs

Die Synchronisationslogik kann nicht im ursprünglichen Zeitrahmen der Subsistenzcloud abgeschlossen werden. Ihre Komponenten bedeuten doch eine umfassende Erweiterung des ursprünglich angedachten Systems.

Konzeptionierung : Juni---Juli
  • Zusammenstellen der Anforderungen für die Synchronisation
  • Einigung auf eine interoperable Architektur
  • Neubewertung der Gesamt-Roadmap unter Einbeziehung der Erweiterung
Implementierung : August---September
  • Entwicklung der PubSub-Dienste auf allen beteiligten Plattformen
  • Finalisierung des Stammdatenmodells und Einarbeitung in die Synchronisierung
  • Testsynchronisierungen
Verfeinerung : Oktober---November
  • Implementierung einer simplen Konfliktbearbeitung
  • Visualisierung der Versionierung
  • Dokumentation

Es gelten weiterhin alle nicht ausgeschlossenen Vorbedingungen aus dem Grundkonzept.

Konzeptpapier : Appendix II

Jon Richter

jon@gartenkarte.de +49 163 829 35 18

Berlin, den 15.07.2014

Subsistenzcloud

Schnittstellen zur Nutzbarmachung bestehender Datenbanken ökologisch-transformativer Projekte durch Webdienste zur Synchronisierung.

Beschreibung der Referenzimplementierung für die Stiftungsgemeinschaft Anstiftung und Ertomis in Kooperation mit Stadtacker und grünanteil.

[TOC]

Abbildungen

Asynchroner Datenaustausch

participant Datenbank
participant Queue
participant Worker
participant Hub

Datenbank->Queue: Datensatzänderung
Note over Queue: Aufnahme in Warteschlange
Queue-->Datenbank: Empfangsbestätigung
Note over Datenbank: nächste Aufgabe
Queue->Worker: Datensatzänderung
Note over Worker: Abarbeitung starten
Worker-->Queue: Empfangsbestätigung
Note over Queue: nächste Aufgabe
Worker->Hub: Datensatzänderung
Note over Hub: Aufnahme in Stammdatenbank
Hub-->Worker: Empfangsbestätigung
Note over Worker: nächste Aufgabe
Note over Hub: Verteilung an Verbund
Note over Hub: Ergebnis zurückgeben
Hub-->Worker: Ausführungsbestätigung
Note over Hub: nächste Aufgabe
Note over Worker: Ergebnis weiterleiten
Worker-->Queue: Ausführungsbestätigung
Note over Queue: aus Warteschlange löschen
Queue-->Datenbank: Ausführungsbestätigung
Note over Datenbank: Ergebnis präsentieren

Dieses Beispielszenario schließt keine Fehlerbehandlung mit ein. Der Begriff Datenbank steht hierbei auch nicht für die jeweiligen Datenbank Management Systeme, sondern stellvertretend für die im Verbund teilnehmenden Partner.

Publish--Subscribe Strategie mit Webhooks

Ähnlich wie ein Dienst einen einzelnen Datensatz mit dem Hub der Subsistenzcloud synchronisiert, funktioniert auch der Abgleich untereinander.

participant Subsistenzcloud
participant Stige
participant grünanteil
participant Stadtacker

Note over Subsistenzcloud: Publish: globale Änderungen
Stadtacker->Subsistenzcloud: Subscribe
Subsistenzcloud-->Stadtacker: Bestätigung
grünanteil->Subsistenzcloud: Subscribe
Subsistenzcloud-->grünanteil: Bestätigung
Stige->Subsistenzcloud: Subscribe
Subsistenzcloud-->Stige: Bestätigung

Note over Stadtacker: Publish: lokale Änderungen
Subsistenzcloud->Stadtacker: Subscribe
Stadtacker-->Subsistenzcloud: Bestätigung
Note over grünanteil: Publish: lokale Änderungen
Subsistenzcloud->grünanteil: Subscribe
grünanteil-->Subsistenzcloud: Bestätigung
Note over Stige: Publish: lokale Änderungen
Subsistenzcloud->Stige: Subscribe
Stige-->Subsistenzcloud: Bestätigung

Note over Stige: Datensatzänderung
Stige->Subsistenzcloud: Benachrichtigung
Note over Subsistenzcloud: lokale Aktualisierung
Subsistenzcloud-->Stige: Empfangsbestätigung
Note over Subsistenzcloud: Verteilung an Abonnenten

Subsistenzcloud->grünanteil: Stammdatensatz hat sich geändert
Note over grünanteil: lokale Aktualisierung
grünanteil-->Subsistenzcloud: übernommen
Subsistenzcloud->Stadtacker: Stammdatensatz hat sich geändert
Note over Stadtacker: lokale Aktualisierung
Stadtacker-->Subsistenzcloud: übernommen
Note over Subsistenzcloud: Verteilen erfolgreich

Diese beispielhafte Darstellung enthält noch keine Konfliktbehandlung oder Versionierung.

Subsistenzcloud

von Jon Richter Berlin, den 4. Dezember 2014

Konzeptpapier : Appendix III

Ein retrospektiver Kommentar zum Entwicklungsexperiment einer Subsistenzcloud, erdacht als

Gruppe von Webdiensten zur verteilten Synchronisation bestehender Datenbanken ökologisch-transformativer Projekte der teilnehmenden Partner.

Vorausgehende Schriftstücke sind

Inhaltsverzeichnis

[TOC]

Abschlussevaluation

Von 2013 bis 2014 engagierte sich die Stiftungsgemeinschaft Anstiftung & Ertomis gemeinsam mit den Partnern grünanteil und Stadtacker um die Schaffung der Subsistenzcloud. Ausgehend von den ursprünglichen Ideen, entwickelt auf einem Workshop in Berlin, zeichnet dieses Dokument den Verlauf der Planung und des Entwicklungsvorganges als auch deren Scheitern nach und möchte Anknüpfpunkte für eine mögliche Fortsetzung aufzeigen.

Ausgangslage

Zu Beginn bestand die Idee der Partner darin ihre Karten und Datenbanken über ökologisch-transformative Projekte (Urbane Gärten, Bienenkisten, Lastenräder, Optionsflächen, Offene Werkstätten) in einer Infrastruktur zu bündeln und dadurch Redundanzen zu minimieren. Dafür gab es mehrere Gründe:

  • Duplizierte Datensätze eines Objektes müssen nicht mehrfach gepflegt werden.
  • Standardisierte Geodatenformate und Anwendungsschnittstellen ermöglichen einen flexiblen Datenaustausch zwischen verschiedenen Plattformen und garantieren die Haltbarkeit, somit Nachhaltigkeit der kuratierten Bestände.
  • Proprietäre Kartensysteme und die Google Basiskarte (Anstiftung, Stadtacker) können im Sinne von Civic Open Data und unter Rücksicht auf die ökosozialen Hintergründe der Partner auf frei lizenzierte Open Source Software und Basiskarten aus OpenStreetMap Material (Offene Werkstätten) umgestellt werden.

Konzeptpapier

Zur Beantwortung dieser Anforderungen enstand das oben vermerkte Konzeptpapier, welches an einen Werkvertrag zwischen der Stiftungsgemeinschaft Anstiftung & Ertomis und Jon Richter gekoppelt war. Unter Ziel heißt es dort:

1a) Darstellung der eigenen Daten auf OSM und 1b) Möglichkeit diese Daten anderen Projekten zur Verfügung zu stellen.

  1. Gleichzeitig sollen auch andere Daten (z.b. die aus dem auslaufenden Stadtackerprojekt) auf den „eigenen“ Karten dargestellt werden können.

Zur Erreichung des Ziels wurden drei Phasen (I Konzeptionierung, II Implementierung, III Veröffentlichung) ausgelegt, welche konkrete Anforderungen benannten. Diese würden nach Abschluss einer Phase evaluiert, um die folgende gegebenenfalls an veränderte Gegebenheiten anpassen zu können.

01.12.2013 - 28.02.2014 : Konzeptionierung

Zunächst wurde eine klare Definition der Entwicklungsrichtung benötigt. Dies erfolgte durch den Entwurf einer dezentralen Dienstarchitektur auf Basis der skalierbaren, schemafreien Geodatenbank GeoCouch. Ferner wurde eine Kommunikationsinfrastruktur aus (privaten) Webforen, Kanban-inspirierten Workflows und Wikis vorbereitet. Der angedachte Prototyp der Synchronisation mit OpenStreetMap existiert jedoch lediglich als Absichtserklärung.

01.03. - 31.05.2014 : Implementierung

Die Implementierungsphase diente dem Infrastrukturaufbau eines Prototypens der Subsistenzcloud, an welchem die Datenschnittstellen mit grünanteil getestet werden sollten. Bei Erfolg wäre anhand des Beispiels die Datenintegration der weiteren Quellen durchgeführt worden.

01.06. - 31.08.2014 : Veröffentlichung

Finalisierend wäre die Subsistenzcloud als Open Source Projekt veröffentlicht worden. Weitere Integrationen, wie bspw. eine Synchronisation von ausgewählten Daten mit OpenStreetMap Punkten oder andere Partnerkarten, sollten das Gesamtbild abrunden. Eingedenk einer extensiven Dokumentation der technischen Schnittstellen, um die bequeme Aufnahme neuer Partner in den Verbund zu ermöglichen.

Appendizes

Wie bereits an mehreren Stellen angedeutet, konnte das Konzept aus vielerlei Gründen (siehe unten; Kommunikation) nicht wie angedacht umgesetzt werden. Im Rahmen der Zwischenevaluation nach Phase II wurde daher um eine Neuformulierung der strategischen und technischen Ausrichtung gebeten, welche in Form zweier Anhänge (siehe oben) zum Konzeptpapier erbracht wurde.

Beide Dokumente ergänzen die Subsistenzcloud um eine Synchronisationsebene, welche Änderungen mehrerer Datenbanken konstant im Verbund aggregiert und verteilt. Diese Aufgabe weist eine weithaus höhere Komplexität auf als die ursprüngliche Methode einer zentralen Datenbank. Anhand eines Stammdatenmodells wären analog der Synchronisation mit OpenStreetMap (siehe oben) nur bestimmte Aspekte, dafür aber kontinuierlich, zwischen einer vielzahl von autonomen Datenbanken auszutauschen gewesen.

Schließlich entstand im Verlauf der Gespräche auch ein Wunsch nach Versionierung und Konfliktbehandlung, was legitime, aber eben auch folgenreiche Anforderungen an eine solche Infrastruktur sind. Die den Appendizes beigefügte Skizze eines zeitlichen Ablaufs zeigte weiterhin, dass auch die Anforderungen an die Organisation der Zusammenarbeit der Partner gestiegen wären. Letztlich fand eine Quantifizierung des zu erwartenden Zusatzaufwands, welcher in ein weiteres Angebot gemündet wäre, nicht statt.

Kommunikation

Zur Synchronisierung der Arbeitsprozesse kann auf Grund des nötigen permanenten Wissensaustauschs weniger auf starre Organisationsschemata zurückgegriffen werden, sodass Organisation durch Kommunikation ersetzt wird. Wie ist das zu verstehen?

  1. Bei Abschluss von Kooperationsvereinbarungen ist nicht absehbar welche Entwicklungen der Anforderungen und Umstände sich im Verlauf ergeben.
  2. Bei asynchronen, hyperlokalen Vorgängen bildet die Dokumentation der Prozesse die Grundlage ihrer beständigen Reevaluation.

Im folgenden wird versucht sichtbar machen, wie beide Punkte vernachlässigt wurden.

Werkzeuge

Es war angedacht die zahlreichen E-Mails zwischen unterschiedlichen Empfängern in einem Forum mit Zugangs- und Sichtbarkeitsbeschränkungen zu bündeln, damit beim CC setzen niemensch vergessen würde und ein zentrales, von allen einsehbares Archiv der Kommunikation bestünde. Diese Idee ist auf Grund ungewohnter Verfahrensweise eingeschlafen.

Herausragende Informationen der Pads und technische Dokumentation hätten außerdem in einem Wiki gebündelt werden wollen, was jedoch auf Grund einer ursprünglichen Fehlentscheidung für ein schwer nachvollziehbares, experimentelles Wikisystem nie umgesetzt wurde. Das Wenige an technischer Dokumentation das existiert ist weiter unten verlinkt.

Aus der Erfahrung der Agilen Softwareentwicklung bot es sich außerdem an ein Kanban Brett (siehe oben) für die Darstellung einzelner Arbeitspakete und ihrer gegenwärtigen Stände zu verwenden. Da es nicht von allen gleichermaßen genutzt wurde, schlief auch diese Kommunikations- und damit Organisationsform ein.

Zentrales Bindeglied, neben E-Mails und Pads, waren die erst zwei- und später wöchentlichen Telefonkonferenzen, die leider in beiden Rhythmen auch kein Garant für einen ungehinderten Informationsfluss zwischen allen Beteiligten waren. Es zeigte sich relativ deutlich, dass die Kommunikationsaufwände der Partner falsch antizipiert wurden.

Dadurch dass keine strukturierte Dokumentation erfolgte, konnte nie ein globaler Überblick der Arbeit entstehen. Der daraus resultierende Mangel zeigte sich in unkonkreten Erwartungen und den daraus resultierenden Missverständnissen.

Partnerschaften

Konkrete Schritte wurden unternommen, um während der Testphase die Kooperation mit grünanteil und Stadtacker zu suchen. Institutionelle Hürden waren in beiden Fällen zu nehmen. Während grünanteil auf die Bewilligung seiner Mittel harrte, gestalteten sich die Gespräche mit dem Stadtacker anhand institutioneller Vorgaben. Ersteres führte zu einem beständigen Aufschub der technischen Zusammenarbeit, wohingegen eine Kooperationsvereinbarung mit dem für die technische Infrastruktur des Stadtackers betraute ZALF (Zentrum für Agrarlandschaftsforschung) weit gediehen war.

Die im Abschnitt Offene Fragen des Appendix I angeführten Gründe sorgten schließlich für einen Abbruch des Projektes, da es zum Interessenkonflikt kam : Fortführung der Entwicklung wie geplant, was für die monetäre Vergütung auf Basis des Werkvertrags grundlegend war, oder Anpassung an die geänderten Vorstellungen und damit Verwerfen bereits geleisteter Vorarbeit eingedenk anhänglicher Vergütungsansprüche.

In einer idealen Welt wäre Phase II erst zu ihrem Schluss evaluiert worden, sodass erst im Übergang der Phasen, wie ursprünglich angedacht, weitere Anforderungen ins Konzept hätten wandern können. Die kognitive Dissonanz kontradiktorischer Bedingungen ließ sich leider schlecht - weder in Form von Software noch eines erweiterten Konzeptes - gleichzeitig auflösen.

Die technischen Partner instant media und IN-BERLIN erfüllten ihre Anforderungen nach Erwartung.

Entwicklung

Der Entwicklungsprozess basierte im Selbstverständnis auf agilen Projektmanagementmethoden. Diese sind weder zu genüge transparent gemacht worden, noch waren die Bedingungen derart erfüllt, dass die Partner den Prozess bereits frühzeitig mit ihren Beiträgen anreichern konnten.

Technisch sind folgende Schritte unternommen worden:

Auf Seiten der Stiftung

  • Es wurde durch instant media ein Login zum Download von Rohdaten der Übersichtskarte Urban Gardening bereitgestellt.
  • subsistenzcloud.de wurde am 10.03.2014 registriert.
  • Eine Entwicklungsplattform wurde durch den IN-BERLIN als Virtuelle Maschine bereitgestellt.

Auf Seiten des Stadtackers

  • Es existierten noch aus Zeiten der Kooperation mit der Berliner Gartenkarte die notwendigen Zugangsberechtigungen, um die Rohdaten abrufen und umwandeln zu können.

Auf der Entwicklungsplattform

Die Virtuelle Maschine protocouch.in-berlin.de wurde wie folgt an die Bedürfnisse angepasst

  • Debian Kernel Backports für erhöhte Docker Kompatibilität
  • Docker zur Containervirtualisierung
  • nginx Reverse Proxy zur Verwaltung der Webdienste

Es wurden frühzeitig Experimente mit der GeoCouch Installation durchgeführt. Später sollte ein GeoCouch Dockerfile dabei helfen, dies zu vereinfachen. Beide Vorarbeiten wurden im weiteren Verlauf nicht mehr benötigt.

Da sich während der Telefongespräche zunächst abzeichnete, dass neben einer schlichten Geodatenbank auch Bedienelemente benötigt würden, fiel die Wahl schließlich auf uMap - ein einfach zu bedienendes, umfangreiches und selbst betreubares Kartensystem der französischen OpenStreetMap. Auch wurde die Integration von uMap, GeoCouch und Docker untersucht. Auf Grund der oben dargestellten kontradiktorischen Bedingungen erreichte leider keiner der Prototypen die gewünschte Reife, um in Verwendung zu gehen.

Anknüpfpunkte einer Fortsetzung

Folgende Schritte bieten sich an, um die ursprüngliche Idee, wenn auch jeweils in Teilen, wiederzubeleben:

  • Instanzierung einer uMap und Übertragung aller Karten der Anstiftung in dieses System.
  • Übertragung bestehender Karten auf die OpenStreetMap Basiskarte und eruieren der Verwendung der Overpass API für Stammdaten.
  • Kooperation mit der TransforMap Initiative und Überlassung der Rohdaten der Subsistenzcloudpartner, soweit noch nicht geschehen, zur Datenintegration in deren Synchronisationsinfrastruktur.
  • Aktive Prozessbegleitung unter Einbeziehung aller Partner. Flache, kurze Kommunikationswege mit einem speziellen Augenmerk auf die besonderen Bedingungen in der Softwareentwicklung.

Bei Wiederaufnahme dieses Unterfangens bin ich gerne bereit wieder beratend und operativ, gerne auch zunächst ehrenamtlich, mitzuwirken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.