openKONSEQUENZ im Detail
Wer bei openKONSEQUENZ mitarbeiten will, wird Mitglied. Vier Mitgliedsklassen stehen dazu zur Verfügung:
- Driver Members - typischerweise Netzbetreiber, die mit viel Einsatz, viel Einfluss erhalten.
- User Members - Netzbetreiber, die sich auf die Entwicklung von neuen Modulen konzentrieren möchten.
- Service Provider Members - Anbieter, die gemeinsam mit Netzbetreibern und anderen Anbietern Architektur und Qualität definieren.
- Guest Member - Berater oder solche, die erst einmal Einblick in die Arbeit des Konsortiums erhalten wollen.
Je nach Mitgliedsklasse besetzt das Mitglied Sitze in den Committees. In vier Committees wird gearbeitet:
- Steering Committee - lenkt das Konsortium
- Architecture Committee - definiert die Architektur
- Quality Committee - definiert und sichert die Qualität
- Project Planning Committee - plant Entwicklungsprojekte
Jedes Mitglied verpflichtet sich auf die Ableistung von Service Tagen und auf einen Mitgliedsbeitrag. Je mehr Tage und Beitrag, desto mehr Einfluss, was sich in stimmberechtigten Sitzen in den Committees ausdrückt:
Entwicklung von Modulen
Wer neue Anforderung an den Netzbetrieb in Software umsetzen will, ist bei openKONSEQUENZ richtig: Das Project Planning Committee (PPC) plant, spezifiziert und beauftragt neue Module. In Abstimmung mit dem Architecture Committee (AC) wird gewährleistet, dass diese neuen Module mit bereits vorhanden Modulen nahtlos zusammenarbeiten und gemeinsam mit dem Quality Committee (QC) wird die Qualität der Software definiert und sichergestellt, um den hohen Anforderung an Software für den Netzbetrieb gerecht zu werden. Zusätzlich sorgt ein Style Guide für eine einheitliche Oberfläche der Module und für Software-Ergonomie zur effizienten Bedienbarkeit der einzelnen Module.
Entwicklungskosten
Im Standardfall beteiligen sich die Netzbetreiber des Konsortiums, abhängig von ihrer Größe (Größenkennwert ist die Anzahl versorgter Kunden), mit 30 % an den Entwicklungskosten. 70 % der Kosten eines Moduls trägt ein oder mehrere "Treiber". Wer ein Modul dringend benötigt und es deshalb vorantreiben will wird Treiber. Er organisiert Workshops, um sich mit anderen Netzbetreibern abzustimmen und treibt die Spezifikation voran, bis diese zur Anfrage bei Entwicklungs-Unternehmen bereit ist. Dabei wird er vom PPC, dem AC und dem QC unterstützt.
Konnte ein Anbieter ausgewählt werden, entscheidet das Steering Committee (SC) über die Beauftragung. Eine Kooperationsvereinbarung der Netzbetreiber des Konsortiums regelt die genaue Kostenverteilung.
Eine detailliertere Beschreibung und Rechenbeispiele zur Verteilung der Kosten sind in diesem Dokument zu finden.
Lead Buyer
Um das Know How in dem noch neuen Gebiet der Open Source Beschaffung zu bündeln, wurde ein Lead Buyer in der Genossenschaft integriert. Im Namen von openKONSEQUENZ bestellt der Lead Buyer die Entwicklung von Open Source Code. Der Lead Buyer gibt Zahlungen nach Abnahme frei und verteilt die damit entstehenden Kosten auf die Netzbetreiber des Konsortiums entsprechend der Kooperationsvereinbarung. Die Einbindung von beteiligten Einkaufsabteilungen, insbesondere der des Treibers, ist natürlich möglich und auch gewünscht.
Entwicklungsprozess
Die Entwicklung erfolgt agil. Die Anforderungen aus der Spezifikation/Anfrage werden in einen Product Backlog überführt und in Sprints abgearbeitet.
Mit der Abnahme eines Sprints ist eine Teilzahlung verbunden. Die Abnahme erfolgt unter definierten Bedingungen auf der openKONSEQUENZ Refernzplattform. Auf Seite des Auftraggebers sind dabei vier Rollen besetzt:
Der Modul-Treiber ist während des gesamten Entwicklungsprozesses beteiligt. Er steht für Rückfragen und Anpassungen des Product Backlog zur Verfügung und gibt in enger Zusammenarbeit mit dem Lead Buyer die Sprints frei. Dabei wird er von einem Beauftragten des QC unterstützt, der die Einhaltung der openKONSEQUENZ Qualitätsvorgaben überprüft. Ein Vertreter des AC steht für Rückfragen des Auftragnehmers, die Architektur betreffend bereit.
Abnahme und Integration
Mit der Abnahme des letzten Sprints endet der Entwicklungsprozess und damit auch das openKONSEQUENZ-Projekt. Jetzt muss ein Dienstleister gefunden werden, der das Modul beim Anwender integriert.
Initial, bei der Integration der ersten Module, wird dazu ein System aufgebaut, das der openKONSEQUENZ-Referenzarchitektur möglichst entspricht. Damit ist sichergestellt, dass Module, die auf der openKONSEQUENZ Referenzplattform abgenommen wurden problemlos laufen.
Auch die vorhandenen bzw. benötigten Datenquellen müssen angeschlossen werden. Dieser Schritt wird immer sehr kundenspezifisch sein, da viele verschiedene Systeme bei Netzbetreibern im Einsatz sind. Verschiedene System-Hersteller entwickeln derzeit Konnektoren, die von den Modulen benötigte Daten im openKONSEQUENZ-Format (CIM) zur Verfügung stellen.
Jetzt kann der Integrator die gewünschten Module konfigurieren. Auch Anpassungen und Erweiterungen sind möglich. Diese sollten aber im original openKONSEQUENZ Source Code vorgenommen werden, da sonst permanenter Anpassungsaufwand bei neuen Versionen entsteht.
Der Integrator
Obwohl Jeder openKONSEQUENZ-Module integrieren (oder nutzen) kann, ohne das Lizenzkosten anfallen, empfiehlt es sich also einen Integrator zu wählen, der Schreibrechte auf dem Original-openKONSEQUENZ-Source-Code hat. Schreibrechte erhalten nur Entwickler mit ausreichendem Knowhow - Committer genannt.
Da der Integrator auch Support und Gewährleistung bieten kann bzw. muss ist der Nachweis von Kenntnissen der openKONSEQUENZ Module und Systemarchitektur (Systemkomponenten) eigentlich unerlässlich: Hier kommt man an den openKONSEQUENZ Service Provider Membern eigentlich nicht vorbei. Deren Arbeit in den Committees für Architektur und Qualität plus Entwicklungsaufträge gewährleisten das für Software im Netzbetrieb erforderliche Knowhow.