Terravis

Dr.-Ing. Daniel Lübke

Werner Möckli

Walter Berli

Vor fast fünf Jahren begann das Projekt Terravis (vgl. [1]): Zu diesem Zeitpunkt hätten wohl die wenigsten gedacht, wie komplex das zu entwickelnde System werden und welche Herausforderungen auf das Projekt zukommen würden. Erstaunlicherweise ist es gerade mit zunehmender Größe und Komplexität immens wichtig, einfache und wiederverwendbare Strukturen zu schaffen, an denen sich ein Projekt ausrichten und entlang derer es sich entwickeln kann. Im Rahmen des Projekts wurden Strukturen gebildet, die sowohl technischer (insbesondere die Software- und Servicearchitektur) als auch organisatorischer Natur (unter anderem Entwicklungs- und Support-Prozesse, Stakeholder-Management) sind. Dieser Artikel zeigt entlang dieser Strukturen auf, wie sich Terravis entwickelt hat und zu welchem Zeitpunkt gewisse Entscheidungen getroffen werden mussten.

Terravis ist eine Plattform zur Abwicklung von Schuldbriefgeschäften, die in der Regel im Bereich der Immobilienfinanzierung nötig werden: Möchte jemand eine Immobilie kaufen oder renovieren, benötigt er in der Regeln einen Kredit von einer Bank. Diese Bank möchte sich absichern und verlangt daher einen Schuldbrief auf dem Grundstück. Der Schuldbrief muss durch einen notariell beurkundeten Vertrag im Grundbuchamt errichtet werden. Zusätzlich kann der neue Hauseigentümer Mittel aus seiner Pensionskasse für die Finanzierung nutzen. Es sind also verschiedene Parteien an den jeweiligen Geschäften beteiligt. Terravis und alle beteiligten Partner sowie deren Anzahl zeigt Abbildung 1.

Kommen wir zurück in das Jahr 2010. Die erste Terravis-Komponente – die Grundstücksauskunft – war gerade produktiv gegangen. Innerhalb von circa sechs Monaten war diese Komponente von der Konzeption zum Rollout gebracht worden. Die Auskunft ist ein Datenintegrationsservice, der Abfragen auf Grundstücksinformationen entgegennimmt und diese über eine standardisierte Schnittstelle an das jeweils zuständige Grundbuchamt weiterleitet. Zu den XML-Daten wird ein PDF-Auszug generiert, der die jeweiligen Daten zu einem Grundstück für Menschen lesbar darstellt. Der Dienst ist sowohl als SOAP-Service als auch über ein Web-Portal verfügbar. Mit der Auskunft mussten bereits einige administrative Funktionen wie Benutzerverwaltung, Auditing und Rechnungsstellung implementiert werden. Dieser erste Schritt war vor allem psychologisch sehr wichtig: Bevor Terravis von der SIX Group als Projekt geführt wurde, steckte das Vorgängerprojekt eGRIS seit acht Jahren unter der Hoheit des Schweizer Bundes fest. Niemand glaubte, dass es möglich sein könnte, in annehmbarer Zeit etwas Funktionierendes zu liefern. Dies gelang, obwohl die SIX Group selbst keine agile Managementmethodik verfolgt(e).

Prinzip 1

Liefere schnell etwas Funktionierendes (oder in der Managementsprache: Kurzes Time-to-Market erhöht die Kundenzufriedenheit und gewinnt Kundenvertrauen). Bekannt von diversen agilen Methoden ist das Prinzip von schnellen Releases auch für nicht-agile Projekte immens förderlich. Die frühe Verfügbarkeit einer Version erhöht das Vertrauen der verschiedenen Stakeholder in die Entwicklung und in die Kompetenz des Entwicklungsteams. Egal, wie widrig der Kontext ist, sollte es die oberste Maxime sein, irgendeine (einfache) Funktionalität so schnell wie möglich zu liefern.

Nach der Implementierung der Auskunft begann die Implementierung des Geschäftsverkehrs. Damit war zunächst die Prozesssteuerung zwischen Banken, Notaren und Grundbüchern für Standardgeschäftsfälle gemeint. Das erste produktive Release enthielt drei Geschäftsprozesse sowie die Architektur und Grundimplementierung der Serviceinfrastruktur. Wichtig war hierbei, dass die Architektur für die spätere Entwicklung bereits bekannt war.

In ATAM (Architecture Tradeoff Analysis Method) (vgl. [2]) gibt es zur Architekturbewertung Änderungsszenarien, mit denen man evaluiert, ob die Architektur zukünftigen Änderungen wahrscheinlich genügt. Gerade am Anfang eines Projekts sollte sich das Projektteam (oder das Architekturteam) darüber ausgiebig Gedanken machen. Insbesondere wenn Services externen Parteien angeboten werden, ist es nicht einfach so möglich, Serviceverträge zu ändern, und man benötigt eine Strategie, wie man mit zukünftigen Änderungen umgehen möchte. Hierbei ist es wichtig festzuhalten, dass man nur eine Idee benötigt, wie man diese Anforderungen zukünftig umsetzen will, und dass man nur die Komponenten realisiert, die man aktuell benötigt. Ein befreundeter Softwarearchitekt mag den Ausdruck „Platz für xyz schaffen“: Als die ersten Terravis-Prozesse produktiv gingen, hatten wir noch lange nicht alle technischen Komponenten und keine Komponente hatte ihren endgültigen Ausbaustatus, aber wir haben für alle Funktionen „Platz geschaffen“ und hatten bislang kein Problem, antizipierte und nicht antizipierte Funktionen in unserer Architektur unterzubringen. Die grobe Architektur zeigt Abbildung 2. Der Geschäftsverkehr besteht aus den Komponenten:

• elektronischer Geschäftsverkehr Terravis (eGVT)
• eGVT-Portal

Die erste Komponente enthält die gesamte Prozesssteuerung, Autorisierung, Message-Routing und Message-Transformation, die mit beliebigen eGVT-Teilnehmern kommuniziert. Besitzen Banken oder Notare keine Software, die die eGVT-Schnittstellen unterstützen, so kann der Teilnehmer das von Terravis bereitgestellte Portal benutzen, das den vollen Funktionsumfang der Prozesse unterstützt, aber keine Integration in die jeweiligen anderen (Banken-)Systeme. Im ersten Release gab es nur rudimentäre Autorisierungs- und Message-Routing-Komponenten, die vollkommen ausreichend waren, solange es nur jeweils eine Serviceversion der verschiedenen Services gab. Erst mit Multiversionssupport mussten diese Komponenten vollständig realisiert werden. So hat Terravis bis heute kein ESB-Produkt, sondern lebt noch sehr gut mit einer selbst leicht zu pflegenden Apache-Camel-Lösung. Andere Projekte hätten erst einmal Monate damit verbracht, ein passendes Produkt zu evaluieren und auszurollen.

Prinzip 2

Das Ziel für das erste Release ist es, eine Architektur zu haben, in der alle bereits bekannten Funktionen ihren Platz haben, auch wenn die Komponenten überhaupt nicht oder noch nicht ganz implementiert sind oder implementiert werden mussten.

Neben der zukünftigen Funktionalität ist es auch nötig, Erweiterungspunkte für nicht-funktionale Eigenschaften des Systems zu schaffen. Terravis rechnet im Endausbau mit über 1.000 angebundenen Umsystemen. Wie kann die Verfügbarkeit garantiert werden? Wie werden Prozesse angehalten, die auf ein nicht verfügbares Umsystem stoßen? Wie können überhaupt die Schnittstellen zu den 1.000 Umsystemen verwaltet werden? Wie werden 5.000 Prozesse am Tag abgewickelt? Dies sind alles Fragen, für die es bereits in der ersten Architekturskizze Antworten oder Platz für Antworten geben muss.

Prinzip 3

Das Ziel für das erste Release ist es, eine Architektur zu haben, bei der klar erkenntlich ist, wie die wichtigsten nicht-funktionalen Eigenschaften erfüllt werden können.

Ein entscheidendes Prinzip bei der Entwicklung des eGVT-Portals war, dass dieses keinen „Heimvorteil“ genießt: Das Portal darf nur genau dieselben Services aufrufen, die auch für die extern angebundenen Partner zur Verfügung stehen. Dies führte immer wieder zu Diskussionen, weil Terravis ja viel mehr Informationen zu einem Prozess und den Teilnehmern hat und weil immer wieder Anforderungen kamen, diese im Portal sichtbar zu machen. Wir sind immer den korrekten Weg gegangen und haben die externen Serviceschnittstellen angepasst und dann das Portal erweitert. So stehen allen Partnersystemen die gleichen Informationen zur Verfügung. Das ist in zwei Richtungen wichtig: Das Portal ist eine Referenzimplementierung, die sicherstellt, dass alle extern angebotenen Services wirklich fachlich funktionieren und keine Daten fehlen. Zum anderen ist es nicht das Hauptziel von Terravis, ein geniales Portal anzubieten, sondern eine saubere Prozesssteuerung zu implementieren. Partner und insbesondere die Banken profitieren mehr von Terravis, wenn ihre Systeme Daten beziehen und an Prozessen teilnehmen können, ohne dass Benutzer per Copy&Paste-Daten zwischen Bankensystemen und dem Terravis-Portal kopieren müssen.

Prinzip 4

Eat your own Dog Food! Wenn ein System einen Service extern anbietet, dann muss die eigene Lösung den Service genauso benutzen. Dies stellt sicher, dass der externe Service sowohl technisch als auch fachlich wie erwartet arbeitet.

Beim initialen Prozessdesign von Terravis – und damit auch der funktionalen Anforderungen an die Software – wurde immer von einem 90-prozentigem Umfang gesprochen. Damit war gemeint, dass man nicht alle Ausnahmen unterstützt, sondern nur die Prozessvarianten implementiert, mit denen 90 Prozent aller Geschäftsfälle dieses Prozesses abgedeckt werden. Die verbleibenden maximal 10 Prozent mussten dann außerhalb der Plattform und wie bis dahin mit Papier und Post abgewickelt werden. Solche Ziele sind deutlich realistischer umzusetzen, erhöhen die Liefergeschwindigkeit der Softwarelösung und erlauben eine aus Kostensicht sinnvolle Umsetzung von Funktionen.

Prinzip 5

Setze die Funktionen um, die sich betriebswirtschaftlich rechnen. Funktionen (auch Sonderfälle), die das nicht tun, werden nicht umgesetzt.

Schon allein, um festzulegen, welches die Masse der Geschäftsfälle darstellt, benötigt man viel Interaktion mit den Stakeholdern. Um Prozesse und Funktionen festzulegen,benötigt man noch viel mehr Interaktion und Zeit. Hierbei gab es im Fall von Terravis viele Probleme zu lösen:

• Viele zukünftige Benutzer waren seit Jahrzehnten den Papierprozess gewöhnt und hatten Probleme sich vorzustellen, wie ein elektronischer Prozess aussehen konnte. Hierunter fallen schon einfache Dinge, wie die Oberflächen aussehen und wie sich so eine Lösung bedienen lassen könnte, bis hin zu technisch und rechtlich komplizierten Fragestellungen, wie digitale Signaturen einzusetzen und zu validieren sind.

• Seit Jahrzehnten gelebte Prozesse sind schwer aufzubrechen. Wenn diese elektronisch umgesetzt werden, ist es aber sinnvoll, die Gunst der Stunde zu nut- zen und die Prozesse zu hinterfragen und nicht nur das Medium, sondern auch die Abläufe zu optimieren.

Prinzip 6

Hole immer und immer wieder konkretes Feedback von den Stakeholdern – sowohl durch frühe und immer wiederkehrende Releases als auch durch Prototypen und Workshops.

Zu Beginn war die Herausforderung, dass sich niemand fand, der einen rudimentären Überblick über die etablierten Papier-Prozesse im Hypothekar-, Notariats- und Grundbuchwesen in allen schweizerischen Kantonen hatte. Zudem fehlte es an einheitlichen Strukturen und es gab nur ein kleines Beziehungsnetz. Außerdem liefen in der Schweiz diverse intransparente und unkoordinierte Aktivitäten mit dem Ziel einer elektronischen Abwicklung.

Mit diesen Voraussetzungen und aufgrund fehlender gesetzlicher Vorschriften war das Projekt gezwungen, die Stakeholder mit konkreten Vorschlägen und dem Aufzeigen des Nutzens zu überzeugen. Das Feedback der Stakeholder wurde aufgenommen und analysiert. Konstruktive Rückmeldungen wurden danach soweit wie möglich berücksichtigt. Die anderen Statements wurden entweder so stehen gelassen oder auf politischer Ebene thematisiert. Da aus technischen, rechtlichen, Komplexitäts- und Kapazitätsgründen eine Big-Bang-Umstellung unrealistisch war, wurde die Aufschaltung, d. h. die Anbindung der Grundbuchsysteme, jeweils mit denjenigen Partnern vorangetrieben, die den Veränderungen offen gegenüber standen.

Landesweite radikale Veränderungen bei verschiedenen Berufsgruppen laufen in der Schweiz nicht ohne politische Diskussionen ab, wobei diese üblicherweise bottom-up geführt werden. Deshalb wurden die zuständigen Kantonsregierungen jeweils in zwei Schritten involviert, erstmals beim Entscheid, im Projekt Terravis mitzuarbeiten, und später, als die einzelnen Kantonsregierungen über die Aufschaltung bei Terravis entscheiden mussten. Es ist zu vermuten, dass eine schweizweite gesetzliche Pflicht, beim elektronischen Geschäftsverkehr teilzunehmen, im Nachhinein gesetzlich verankert wird, nachdem die überwiegende Mehrzahl aller Kantone diese Vorgabe bereits umgesetzt hat.

Prinzip 7

Binde die Stakeholder frühzeitig ein, vor allem bei radikalen Veränderungen

Als Terravis anfing, gab es in jedem Kanton unterschiedliche Dokumente, Anträge und Verträge. Diese Komplexität war den Banken schon lange ein Dorn im Auge und Terravis hätte nicht implementiert werden können, wenn jeder Prozess in einer Variante für jeden der 26 Kantone hätte implementiert werden müssen. In solchen Konstellationen müssen alle Beteiligten darauf hinwirken, Standards zu etablieren. Für Grundbuchämter und die dahinterstehenden Kantone stellte dies ein Umdenken dar, da sie bislang einfach allein und unabhängig entscheiden konnten (und es rechtlich gesehen auch heute immer noch können).

Prinzip 8

Prozessausführung ist nur dann sinnvoll, wenn Varianten durch Standardisierung reduziert werden können. Dazu ist es ggf. nötig, mit Stakeholdern diese Standards erst zu erstellen und Varianten zu vereinheitlichen.

Insgesamt stellen die gesamten Änderungen und Anpassungen der Rechtsgrundlagen, neue Software, Medienumstellung von Papier auf elektronisch, neue Verträge usw. hohe Anforderungen an die Änderungsbereitschaft der Stakeholder. Zwar sind (hoffentlich) alle dem gemeinsamen Ziel verpflichtet und finden es gut, Softwareunterstützung für die ganze Prozessabwicklung zu bekommen, jedoch haben Menschen eine innere Abneigung gegen Änderungen, vor allem, wenn diese zu groß und zu regelmäßig werden. Daher ist es nicht immer sinnvoll, möglichst viel und oft produktiv verfügbar zu machen. So mussten wir in Terravis einige Funktionen Monate zurückhalten, weil die Grundbuchmitarbeiter noch nicht geschult werden konnten. Zwar war es aus Entwicklungssicht wichtig, dass die Funktion in einer Iteration fertig implementiert werden konnte, jedoch benötigt man Mechanismen wie Konfigurationsschalter, um Funktionen aktivieren und deaktivieren zu können.

Prinzip 9

Erhöhe niemals deine Releasegeschwindigkeit über das, was deine Stakeholder verkraften können. Notfalls gehört dazu das Deaktivieren von Funktionen auf der Produktivumgebung.

Terravis war von Anfang an ein iteratives Projekt. Die Release-Geschwindigkeit hat sich von einem circa dreimonatlichen Zyklus auf monatliche Releases erhöht. Dies geschah aus mehreren Gründen. So war weniger Grundlagenarbeit erforderlich, das Stakeholder-Management hatte sich eingespielt und die Änderungen waren weniger neue Prozesse, sondern vielmehr neue Funktionen oder Anpassungen an bestehenden, besser verstandenen Prozessen, so dass die Aufwände durchschnittlich ebenfalls kleiner wurden. Nach dem schnellen ersten Release sind regelmäßige Releases ebenfalls wichtig, um Feedback von den Stakeholdern zu bekommen und das Vertrauen in die Lösung zu steigern.

Prinzip 10

Implementiere iterativ und rolle dabei oft (am besten jeden Monat) etwas Nutzenstiftendes aus!

Neben schnellen, geplanten Releases gehören auch außerplanmäßige Fix-Releases für kritische Fehler dazu. Bislang hat es das Terravis-Team geschafft, Fixes schneller auszurollen als die Entwicklungsteams aller anderen Umsysteme. Das hat teilweise schon dazu geführt, dass uns Kunden anderer Systeme gefragt haben, ob wir nicht Workarounds in Terravis implementieren könnten, die Fehler in anderer Software kaschieren, da die anderen Entwicklungsteams Monate für die Behebung der Fehler benötigen würden. Dies funktioniert nur, wenn Deployment-Einheiten möglichst klein und mit möglichst wenigen Abhängigkeiten (lose Kopplung) geschnitten sind und wenn die Software immer releasebereit ist (z. B. indem nur funktionierender Code in den Master-Branch eingecheckt werden darf oder bei Bedarf Fix-Branches zur Verfügung gestellt werden).

Prinzip 11

Sei immer bereit einen kritischen Fix innerhalb von einem Tag in Produktion zu bringen! Keine Ausreden sind erlaubt!

Viele Iterationen und Releases bringen jedoch wenig Vorteile, wenn die Priorisierung von Aufgaben und technischen Features nicht stimmt oder zu große Features einfach über mehrere Pseudoiterationen verteilt werden (d. h. mehrere Iterationen einfach zu einer großen zusammengefasst werden). Neben dem Problem, Features so zu verkleinern, dass sie realistisch in einer Iteration zu implementieren und zu testen sind, gibt es zwei teilweise konkurrierende Priorisierungsstrategien:

• Priorisierung nach Kundennutzen, was man eher im eXtreme Programming (XP) verfolgen würde.

• Priorisierung nach technischem Risiko bzw. Dringlichkeit, was eher dem Spiralmodell (vgl. [3]) entspricht.

Jede Iteration sollte Features aus beiden Kategorien umsetzen: Zwar kann man Kunden glücklich machen, indem man schnell viele Features ausrollt, jedoch wird dabei die Lösung technische Schulden en masse anhäufen, bis das System in sich kollabiert. Technische Features sind Architekturarbeiten, Refactorings, Arbeiten an Entwicklungs- und Testinfrastruktur etc. Hierbei gibt es keine feste Quote: Terravis hatte Iterationen mit ausschließlich fachlichen Features und Iterationen, in denen überproportional viele technische Probleme ausgemerzt wurden.

Prinzip 12

Bringe fachliche und technische Features in Einklang und priorisiere aus beiden Pools in die Iterationen!

Um mehr Flexibilität in der Iterationsplanung zu haben, sollte man sich bewusst sein, dass einige Probleme durchaus auch außerhalb der Softwarelösung zu lösen sind. Temporäre und teilweise sogar permanente Betriebsorganisatorische Lösungen erlauben es, mit einem technischen Problem oder technischen Unzulänglichkeiten umzugehen. In Terravis akzeptierte ein kleiner Kanton z.B. die Standardverträge nicht, sondern verlangte zusätzliche Daten auf den Verträgen. Änderungen an den Standardverträgen dauern in der Umsetzung, weil diese mit den anderen Kantonen abgesprochen werden müssen. Übergangsweise wurden die PDFs per Hand editiert.

Prinzip 13

Betriebsorganisatorische Lösungen können Druck aus der Entwicklung nehmen.

Nachdem in Terravis die ersten fünf eGVT-Prozesse implementiert waren, gab es eine neue Entwicklung: Die Schweiz hatte den Registerschuldbrief eingeführt, der nicht auf Papier sondern lediglich als Eintrag im Grundbuch existiert. Die ursprüngliche Intention war Medienbruchfreiheit und einfachere Handhabung. Durch diese Umstellung wurde aber auch der Gläubigereintrag im Grundbuch rechtsbindend: Nicht mehr der Inhaber des Papierschuldbriefes war Gläubiger, sondern jeder Gläubigerwechsel muss nun über das Grundbuchamt vorgenommen werden. Einige Banken führen Extra-Fonds, die über Schuldbriefe gesichert sind. Für diese Konstruktion werden regelmäßige Gläubigerwechsel zwischen der Bank und den Fonds benötigt, die nun durch das Grundbuchamt teuer werden. Als Lösung hat die SIX Group eine treuhänderische Verwaltung (Nominee) von Registerschuldbriefen entwickelt und angeboten. Neben neuer Fachlichkeit wurde damit der Scope in einigen Bereichen des Systems größer: Statt der 90%-Fälle mussten Wege geschaffen werden, um alle Schuldbriefgeschäfte abwickeln zu können. Dies hatte zwei Konsequenzen: Zu den bestehenden Prozessen gibt es jeweils eine Offline-Variante, die in Kantonen oder mit Notaren, die bislang noch nicht an Terravis teilnehmen, mit Papier arbeiten. Die Banken können weiterhin ihre Aufträge elektronisch einreichen, aber die neue Abteilung, die die Schuldbriefe verwaltet, wickelt dann mit den modifzierten Prozessen die Aufträge auf Papier gegenüber den Notaren und dem Grundbuch ab. Für Prozessvarianten, die fachlich nicht unterstützt sind, gibt es einen generischen Catch-All-Prozess, in dem Banken beliebige von ihnen verfassten Verträge in das System eingeben können, welche dann durch Terravis nur noch an die Prozessbeteiligten verteilt werden und die standardisierten Schnittstellen zu und von dem Grundbuchamt verwendet werden.

Prinzip 14

Wenn eine 100%ige fachliche Prozessabdeckung erforderlich ist, wäge genau ab, welche Varianten spezifisch umgesetzt werden müssen, und wie ein „Catch All“ aussehen kann, der den fachlichen Druck von den anderen Prozessvarianten nehmen kann.

Durch zusätzliche Prozessvarianten und weiteren Prozessen, die nur für Nominee-Banken vorgesehen sind, wuchs die fachliche Komplexität in Terravis deutlich. Dies erhöhte den Druck im Bereich der Qualitätssicherung. Bis dahin konnte Terravis mit einer guten Unit-Test-Abdeckung und manuellen Systemtests gut leben. Jedoch dauerten die manuellen Systemtests nun zu lange. Insbesondere die Anzahl an nötigen Regressionstests wuchs auf ungefähr die dreifache Anzahl wie zuvor. Da der Geschäftsverkehr auf SOAP-Nachrichten, also klassischen M2M-Schnittstellen aufbaut, ist es vergleichsweise einfach, System- und Integrationstests zu schreiben. So konnten weitere automatisierte Tests entwickelt werden. Der automatisierte Testscope wird laufend erweitert. Die Maxime der Testbarkeit erhöht außerdem die Klarheit des Schnittstellendesigns. So wie Anforderungen immer testbar formuliert sein sollten, so sollten alle Schnittstellen so entworfen werden, dass es möglichst einfach ist, automatisierte Tests dagegen zu implementieren. Erfahrungen mit dem Testen von Terravis sind in [4] dokumentiert.

Prinzip 15

Sorge dafür, dass deine Anwendung automatisiert testbar ist! (Auch wenn du dies im Moment noch nicht benötigst; irgendwann wirst du es!)

Mit der Nominee-Funktionalität wurde die Last auf dem System spürbar höher. Viele Dinge, die vorher einfach funktionierten, funktionierten nun langsamer oder mit zu vielen Ressourcen. Für diese Fälle war es nötig mehr technische Features in den Iterationen einzuplanen. Um aber das System zu verbessern, bevor die Kunden negativ betroffen sind, ist es nötig, Probleme vor den Kunden mitzubekommen und Zeit zu haben, das System zu optimieren. Auch wenn es formell einen „Betrieb“ gibt, so interessiert diesen meistens nur, ob das System gerade läuft. Veränderungen über die Zeit bleiben meistens unbeachtet. Terravis hat nach und nach die applikatorische Überwachung mit technischen Features erweitert. CPU-Last, Speicherverbrauch, erweiterte Logging-Warnungen, aktuelle Request-Metriken, Performance-Messungen und Lasttests mit angepassten Lasterwartungen gehören zu den Maßnahmen, die ein Projekt ergreifen muss, um nicht kalt erwischt zu werden.

Prinzip 16

Wisse, wie sich dein System gerade fühlt (auch wenn du nicht Betrieb bist)!

Die Erkennung von Engpässen ist der erste Schritt zu deren Prävention. Schlechte Erfahrungen hat sicherlich jeder schon gemacht, wenn er einem Datenbankadministrator mitteilt, dass dieser doch bitte die Datenbank optimieren solle. Die Administratoren haben oftmals schlicht genug nicht die Kenntnisse, um beurteilen zu können, wie das Profil der jeweiligen Anwendung ist. Die Entwickler können dies meistens besser beurteilen. Dazu gehören auch alle anderen Einstellungen zur JVM. Im Laufe der Zeit hat es sich in Terravis etabliert, dass die Entwickler auf der Entwicklungsumgebung die Einstellung testen, bevor diese durch das Projekt freigegeben und von den Administratoren auf den folgenden Umgebungen implementiert wird. Alle Konfigurationsänderungen der Administratoren müssen durch das Entwicklungsteam freigegeben werden, um Ausfällen und Problemen vorzubeugen. Dazu gehören z.B. auch Änderungen an den gesamten Zertifikaten, die für die Umgebung mit Umsystemen nötig sind.

Prinzip 17

Lasse Entwickler an der Optimierung der Anwendung mitarbeiten!

Diese Prinzipien sind einfach Dinge, die im Verlauf von Terravis oder vorigen Projekten gelernt wurden. Die Nummern implizieren keine Gewichtung, sondern sind einfach von vorne nach hinten durchnummeriert.

Das Projekt Terravis ist noch nicht beendet und es warten noch einige fachlich große Brocken wie ein richtig großer neuer Prozess auf das Entwicklungsteam. Solche Projekte machen Spaß, weil sie einen herausfordern und einem die Chance geben, besser zu werden und Erfahrungen zu sammeln. Und damit das so bleibt, sollte man jeden Tag das letzte Prinzip beachten. Keine Entscheidung, die man vorher getroffen hat, darf aus persönlichen oder politischen Gründen unumstößlich sein! Es können sich immer Dinge ändern und man selber ist hoffentlich auch erfahrener geworden.

Prinzip 18

Lerne jeden Tag dazu! Und handle danach!

Die Architektur spielt bei Terravis eine entscheidende Rolle. Sie ist ausführlicher in [5] beschrieben: Je mehr ein System oder ein System von Systemen mit seiner Umgebung verflochten ist, desto mehr muss man von Anfang an wissen, wo man hin möchte, und teilweise auch Änderungen in der Systemumgebung provozieren, die Zeit benötigen. Einfaches „Drauflosentwickeln“ (selbst wenn es fälschlicherweise als agil getarnt wird), wird ein Projekt schnell über die Klippe stürzen lassen.

Die anderen hier gezeigten Faktoren in Terravis könnten alle irgendwo aus der agilen oder aus der DevOps-Bewegung stammen. Terravis ist jedoch ein Projekt, das nicht einer agilen Methode entsprechen würde und schon gar keins, was in einer DevOps-Umgebung funktioniert. Dies liegt vor allem an der Umgebung, die dies nicht zu lässt. Trotzdem sollte dies niemals eine Ausrede darstellen, bewährten Prinzipien nicht zu folgen. Lieber schnelle Releases umsetzen als Agilität zu missionieren, lieber als Entwickler Einfluss auf die Produktivumgebung nehmen, als auf DevOps zu bestehen. Je mehr alle Beteiligten merken, dass diese Dinge funktionieren, desto eher sind sie bereit den nächsten Schritt zu gehen.

Und so lernen alle jeden Tag dazu!

Referenzen