In der Theorie klingt es einfach: Einführung von agilen Methoden, kleiner Domänenschnitt, Zerlegung des Monolithen, Reduktion der Abhängigkeiten, Automatisieren der Codierung und einfache Dokumentation – alles kein Problem.
Beim Einstieg in die Pionierprojekte nach RNext für Bestands- und Schadenprozesse sowie in die Begleitgruppen für organisatorische, fachliche und technische Fragestellungen wurde es griffiger aber gleichzeitig auch komplexer weshalb es galt, die neuen Fragen in der Praxis zu den vorgenannten Themenfeldern zu lösen.
Die Teams haben sich hohe Ziele gesteckt und arbeiten in den Projekten mit dem klaren Ziel, dass ohne eine aktiv angestrebte Implementierung kein Projekt startet. Der Anspruch ist, den praktischen Nutzen und die tatsächliche produktive Implementierung zwischen Provider und Consumer in den Mittelpunkt zu stellen. Andere Branchen bezeichnen dies bereits seit Längerem als Kundenperspektive und Nutzenfokussierung. Dieser Perspektivenwandel stellt die selbst gezogenen Leitlinien für die neuen Projekte dar.
In der Praxis zeigt sich, dass die neuen Methoden für die Teilnehmer zunächst schwierig anzuwenden waren und nicht alle Fragen mit den bisherigen Arbeitsweisen und Diskussionsansätzen gelöst werden konnten. Es wurde schnell klar, dass ein agiles Vorgehen erlernt und geübt werden will und sich klassische Projekte erstmal daran gewöhnen müssen. Konkret gemeint sind gerade die üblichen Arbeitsweisen, die bei der bisherigen Projektarbeit u.a. mit Präsenzterminen, Gruppen aus 80 Personen, umfassender Agenda und Impulsvorträgen im Kontext von RNext genau nicht mehr zum Tragen kommen.
In der RNext-Gruppe wird vielmehr agil gearbeitet, mit dem Ziel, schneller als vorher zu sein. Die Teams tagen wöchentlich in virtuellen Konferenzen, modellieren mit Swagger, führen Backlogs und pflegen öffentliche Teilnehmerlisten. Darüber hinaus wird ein Protokoll im Wikipedia-Stil verwendet, das den Arbeitsstand dokumentiert statt den Gesprächsverlauf.
Die kleinen Gruppen fordern von allen Beteiligten ein hohes Engagement, die Bereitschaft jede Woche teilzunehmen und Ergebnisse kontinuierlich abzuliefern um schnell voranzukommen. Je nach Umfang der Teilnahme kann das bis zu einer Arbeitskraft pro Unternehmen binden, was von den Teilnehmern aber als wichtige Investition für RNext verstanden wird.
Nicht nur die Arbeitsweise und Intensität sind bei RNext anders als in der klassischen Projektgruppe: so finden Webcam-Konferenzen anstatt Präsenzmeetings statt und persönliche Treffen (sofern nötig) werden auch in den Unternehmen der Teilnehmer der Projektgruppe anstatt nur in der Geschäftsstelle abgehalten. Auch die Art und Weise wie diskutiert wird ist neu: immer strikt am minimal überlebensfähigen Produkt (sog. "MVP") entlang. Dies mit dem Ziel, eine schlanke und sofort anwendbare Lösung mit klarem und schnellem Produktivnutzen herzustellen.
Um die API nicht zu komplex zugestalten, werden einzelne Spezialfälle bewusst außer Acht gelassen. Denn die Teams zielen auf eine einfache und tragfähige Lösung ab, anstatt die komplexe Vollabbildung anzustreben. Es wird in Ende-zu-Ende-Prozessen gedacht, welche in kurzen Entwicklungszyklen umzusetzen sind, schnell in den produktiven Einsatz gelangen und bei Bedarf einfach erweitert werden könnten.
Im BiPRO e.V. ist impliziter Konsens, den Prozess in den Vordergrund zu stellen und danach die Normen zu entwickeln. RClassic unterscheidet sich von RNext in vielen Punkten, vor allem aber fachlich in der Vorgehensweise. RClassic ist dabei von folgenden Paradigmen geprägt: Vollständige Abbildung der in den Gruppen ermittelten Anwendungsfälle und Erarbeitung von Use-Cases und Implementierungsstufen. Diese Mechanismen erlauben im Großen zu modellieren und in kleinen Schritten zu implementieren. Die praktische Hürde ist dabei allerdings, dass Implementierende dennoch das mächtige Datenmodell verwenden und sich damit zwangsläufig umfassend beschäftigen müssen - auch wenn diese davon ggf. nur wenige Teile umsetzen.
RNext hingegen richtet sich an konkrete Umsetzungsvorhaben, womit viel kleinere Ausschnitte im Datenmodell betrachtet werden können. Anpassungen und Erweiterungen werden in nachgelagerten und kurzen Zyklen durchgeführt, um Erfahrungen aus der Praxis schnell einfließen lassen zu können. Dies bedeutet natürlich automatisch, dass sich die Releases deutlich verkürzen. Damit wird sich aber voraussichtlich auch die Versionsvielfalt erhöhen.
In der Zukunft werden dem Autor nach sicherlich auch einige Fragestellungen kontrovers zu diskutieren sein, wie beispielsweise:
Wie werden die Hersteller RNext umsetzen? Können sie den allgemein vorherrschenden Wunsch nach mehr Umsetzungsgeschwindigkeit in der Praxis tatsächlich stemmen?
Wie werden sich bei agiler Vorgehensweise autarker Domänen und dem sich stetig weiterentwickelnden kleineren Schnitt dauerhaft die Normierungsgrundsätze berücksichtigen lassen?
Gerade letztere Frage ist für die BiPRO als zentrales Normungsinstitut für nachhaltige Branchenprozesse und stabile Datenmodelle von elementarer Bedeutung. Ansätze, Regeln und Rollen werden von den Begleitgruppen bereits entwickelt und mit viel Erfahrung diskutiert. Dies stimmt positiv und zuversichtlich, dass gemeinsam die passenden Antworten gefunden werden.
Das aktuelle Meinungsbild zeigt zudem, dass es in den nächsten Jahren nicht entweder RClassic oder RNext sein wird, was uns voranbringt, sondern vielmehr, wie man effizient mehrere Modellierungsansätze zugleich verfolgen können wird. Die Gemeinschaft steht am Anfang der Arbeit und die Chancen für nachhaltigen Erfolg sind groß, wie gerade die Arbeit der Projektgruppen und der schnelle Knowhow-Aufbau der Teilnehmer zeigen.
Einer der Entwickler von zeitsprung reflektierte jüngst wie folgt:
RNext steht am Anfang. Dabei muss auf Erfahrungen zurückgegriffen und gleichzeitig das Umdenken zugelassen werden, um Fehler zu vermeiden. Die Normen sind umfangreich und es gilt Vorhandenes schrittweise in eine neue Release-Generation zu überführen. Das Vorgehen und der Stack werden sich ändern. Aber egal wie: Ärmel hoch und packen wir`s an.