You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
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?
Bei Abschluss von Kooperationsvereinbarungen ist nicht absehbar welche Entwicklungen der Anforderungen und Umstände sich im Verlauf ergeben.
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.
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.
