Digitalisierung fordert fortwährend Entwicklung, Test und Auslieferung der eingesetzten Softwareanwendungssysteme. Diese drei Aktivitäten sollen nicht mehr getrennt, sondern vereint ausgeführt werden. Die Anwender werden in die Entwicklung einbezogen.
DevOps ist eine Antwort auf die Nachfrage nach fortwährender Entwicklung. Moderne IT-Systeme sind prinzipiell nie fertig. Sie haben immer nur einen Stand erreicht, bei dem ein Teil der Benutzeranforderungen befriedigt ist. Aber sowohl die Anforderungen als auch die Rahmenbedingungen entwickeln sich weiter und verändern sich. Die Herausforderung für DevOps ist, die Systeme so zu konfigurieren, dass sie einerseits ständig weiterentwickelt werden können, aber andererseits immer in definierter Qualität einsatzfähig sind. Anwender müssen sich damit abfinden, dass sich das System laufend verändert, müssen sich aber auch auf das Erreichte verlassen können, während die Entwicklung weitergeht.
Digitalisierung ist ein sehr abstrakter Begriff für die Automatisierung aller Bereiche des menschlichen Lebens. Formal heißt es: “Der Begriff Digitalisierung bezeichnet allgemein die Veränderungen von Prozessen, Objekten und Ereignissen, die bei einer zunehmenden Nutzung digitaler Geräte erfolgt. Im ursprünglichen und engeren Sinne ist dies die Erstellung digitaler Repräsentationen von physischen Objekten, Ereignissen oder analogen Medien.” Voraussetzung dafür ist die Erfassung aller Daten über die Bereiche des menschlichen Lebens in digitalem Format, das heißt als Bits und Bytes. In der analogen Datenverarbeitung werden Daten als wechselnde Strömungen beziehungsweise Zustandswechsel ausgelegt. In der Digitalisierung werden die Zustände als Bitmuster festgehalten. Sie können aufbewahrt und wieder verarbeitet werden. Digitalisierung gibt uns die Möglichkeit, sämtliche betriebliche Anwendungen zu automatisieren und damit nach Belieben umzugestalten. Das Problem dabei ist, dass die Automatisierung einer Anwendung kein einmaliges Projekt ist. Systeme ändern sich unabhängig vom Grad ihrer Automatisierung, und wenn sie automatisiert sind, dann ändern sie sich nur noch schneller. Wer einmal begonnen hat, eine Applikation zu automatisieren, muss dranbleiben. Es gibt keinen Weg zurück. Das Know-how, das man braucht, um ein System manuell zu betreiben, wird in dem Zuge auch zurückgehen. So verheißungsvoll es klingen mag, ist Digitalisierung doch ein Pakt mit dem Teufel. Automatisierung heißt auch Abhängigkeit. Goethes Faust lässt grüßen.
Bei der Digitalisierung einer Organisation gibt es drei Hauptziele:
Die Daten sind alle Informationen, die das System braucht, um seine Funktion zu erfüllen, zum Beispiel die Kundendaten, die Mitarbeiterdaten, die Auftragsdaten, die Produktionsdaten und die Lagerungsdaten. Daten können auf elektronischen Speichermedien, auf Papier oder in den Köpfen der Mitarbeiter sein. Das Ziel der Digitalisierung ist, sämtliche Daten auf elektronischen Speichermedien zu haben, denn nur so sind sie für alle und alles zugänglich.
Die Prozesse sind die betrieblichen Abläufe wie die Bearbeitung von Aufträgen, die Planung und Steuerung der Produktion, die Lagerhaltung, die Auslieferung und die Abrechnung. Prozesse werden von Akteuren ausgeführt. Die Akteure können Menschen oder Maschinen sein. In einem semi-automatisierten Prozess sind die Akteure teils Menschen, teils Maschinen. In einem voll automatisierten Prozess sind nur Maschinen am Werk. Viele Prozesse lassen sich voll automatisieren. Andere werden nur teilweise automatisiert. Ein Ziel der Digitalisierung ist, möglichst viel zu automatisieren.
In einer Organisation kommunizieren die Akteure miteinander sowie mit Akteuren außerhalb des eigenen Systems. Sie sind miteinander vernetzt. Sie können über den Austausch von Papieren, über persönliche Gespräche oder über elektronische Nachrichten miteinander Daten austauschen. Auch die Geräte als Akteure können miteinander kommunizieren und zwar direkt und nicht über die Menschen. Deshalb spricht man von dem “Internet of Things (IoT)”. Ein Betrieb ist ein Netzwerk kommunizierender Knoten. Ein Ziel der Digitalisierung ist, dass möglichst viele Knoten miteinander verbunden sind. Es kann sich also jeder mit jedem und jedes mit jedem Daten austauschen. Digitalisierung erlaubt es im Prinzip, schneller auf Veränderungen in der Umgebung zu reagieren. Sowohl die Daten als auch die Operationen auf die Daten sind als Bitmuster festgehalten und Bitmuster lassen sich leicht überschreiben. In Sekundenschnelle entstehen neue Bitmuster, die die Bedeutung der Daten und deren Verarbeitung umgestalten. Wir haben damit die Möglichkeit, unsere Arbeitsprozesse ständig zu verändern.
Es klingt alles so einfach. Wir müssen nur die Daten elektronisch erfassen, die Prozesse programmieren und die Kommunikation digitalisieren. Aber alles, was “digitalisiert” wird, muss auch getestet werden. Es können Fehler auftreten, Fehlinformationen enthalten sein oder noch schlimmer, gefährliche Datenkombinationen? In dieser Hinsicht ändert sich nichts. Der Test blockiert die rasche Umsetzung der Anforderungen, vor allem wenn Test und Instandsetzung getrennt sind von der Implementierung der Anforderungen. Wenn ein neues Gesetz verabschiedet wird, hat es bisher Monate gedauert, bis das Gesetz umgesetzt wurde. Das ist in unserem schnelllebigen Zeitalter nicht mehr zu rechtfertigen. Der Test und die Übergabe müssen beschleunigt werden.
Zunächst müssen wir genau verstehen, was neu an der Digitalisierung ist. Elektronische Datenverarbeitung haben wir schon lange, automatisierte Prozesse auch und Breitband-Datenübertragung sowieso. Dass Funkkommunikation so eine große Rolle in unserem Alltag spielt, ist auch nicht erst seit gestern so. Was neu sein kann, ist die Verbindung von all dem. Letztendlich ist ein Betrieb digitalisiert, wenn seine sämtlichen Daten elektronisch gespeichert sind, wenn alle Arbeitsprozesse voll automatisch ablaufen und wenn alle Mitarbeiter miteinander und mit den Geräten verbunden sind.
Die Frage stellt sich, ob es wirklich vernünftig ist, so weit zu gehen, oder ob wir nicht auf halbem Weg anhalten sollten. Wie weit wollen wir es mit der Digitalisierung treiben? Auch hier hat der Test aktuelle Grenzen. Wir können nur so viel elektronisch speichern, automatisieren und fernübertragen, als wir für den Inhalt bürgen können. Die Daten, die wir elektronisch speichern, dürfen nicht korrumpiert werden. Die Fragen, die wir an das Datenverwaltungssystem stellen, müssen richtig beantwortet werden. Die Prozesse, die wir anstoßen, müssen nach den vorherrschenden Vorschriften beziehungsweise nach den gültigen Geschäftsregeln ausgeführt werden. Und, die Nachrichten, die wir senden, dürfen nicht unterwegs verändert oder abgefangen werden. Das bedeutet, alles was wir digitalisieren, muss getestet und gesichert sein.
Mit der Digitalisierung kommt ein enormer Testaufwand auf uns zu. Es beginnt mit dem Test der Daten und setzt sich mit dem Test der Prozesse und dem Test der Datenübertragung fort. Dieser Aufwand ist nur zu bewältigen, wenn wir systematisch vorgehen und wenn der Test selbst weitestgehend automatisiert ist. Der Digitalisierungsgrad kann als der Anteil der elektronisch gespeicherten Daten relativ zur Summe aller betrieblich relevanten Daten plus dem Anteil aller automatisierten Prozesse relativ zur Summe aller betrieblichen Prozesse plus dem Anteil vernetzter Systemknoten relativ zur Summe aller Systemknoten verstanden werden.
Es mag sein, dass dieses Maß betriebswirtschaftlich nicht relevant ist, aber als Ziel der IT ist es zunächst gut zu gebrauchen. Echte Digitalisierung, falls es so etwas wirklich gibt, bedeutet drastische Veränderungen zu den bestehenden Produkten und Geschäftsmodellen, das heißt, neue Systeme. Ob die Anwender dazu bereit sind oder eine Wahl haben, ist offen.
Dass wir physisch in der Lage sind, alle Daten zu speichern, ist seit der Einführung von Cloud-Computing unumstritten. Die Cloud-Anbieter bieten uns unbegrenzte Speicherkapazität an. Die Frage ist, ob wir auch nützliche Daten speichern und nicht nur Datenmüll. Die Daten müssen auch korrekt sein. Es dürfen sich keine ungültigen Werte einschleichen. Demnach gäbe es zwei Kriterien für die Daten:
Um festzustellen, ob die Daten nützlich sind, müssen sie mit allen betrieblichen Anwendungen getestet werden, einschließlich der Abfrage- und Berichtssysteme. Es wird damit geprüft, welche Daten verwendet werden und welche nicht. Das Ziel dieses Tests ist ein Verzeichnis sämtlicher verwendeter Daten. Ob die Anwendungen selbst von Nutzen sind, müssen die Anwender entscheiden. Um festzustellen, ob die Daten korrekt sind, müssen sie gegen die Regeln der Richtigkeit geprüft werden. Dazu bestehen zwei Möglichkeiten. Zum einen können die Daten miteinander verglichen werden. Neue Daten können gegen alte Daten oder Daten in der einen Anwendung mit Daten in einer anderen Anwendung abgeglichen werden. Die Daten sollten überall, wo sie verwendet werden, identische Wertbereiche haben.
Zum anderen können die Ist-Werte mit den Soll-Werten verglichen werden. Die einfachste Art dieser Kontrolle ist die Sichtkontrolle der Daten durch eine Fachperson. Doch ist diese Kontrollart zeitaufwendig und fehleranfällig. Die eleganteste Art der Datenkontrolle ist die automatische Werteprüfung gegen Regeln (Assertions). In den Assertions ist festgeschrieben, welche Werte die betroffenen Daten haben sollten. Sie können unter anderem als Wertebereiche, alternative Werte, berechnete Werte oder Relationen zu anderen Werten definiert sein. Der Zweck ist, ungültige Werte zu identifizieren und auszusortieren.
Allerdings setzt dieser automatisierte Ansatz voraus, dass für sämtliche Datenelemente Regeln spezifiziert sind. Weder mit dem einen noch mit dem anderen Ansatz gibt es eine hundertprozentige Garantie, dass die Daten wirklich richtig sind, aber mit ihrer Hilfe wird ein Großteil der ungültigen Daten erkannt.
Trotz Beschleunigung des Release-Prozesses darf die Qualität des Produktes nicht geopfert werden. Die Qualitätssicherung der elektronisch gespeicherten Daten und der automatisierten Prozesse ist eine unverzichtbare Voraussetzung für die betriebliche Digitalisierung. Das kann nur gelingen, wenn die Anwender einbezogen werden. Die Anwender müssen den Release-Prozess begleiten und die einzelnen Schritte sofort abnehmen. Das heißt, Vertreter der Endanwender müssen von Anfang an dabei sein. Sie sind für die Sicherung der Qualität unentbehrlich.
Viele Prozesse innerhalb heutiger Organisationen sind bereits automatisiert, jedoch mit zum Teil sehr alten Softwaresystemen– sogenannten Legacy-Systemen. Dort, wo die Prozesse einen hohen Standardisierungsgrad haben, sind die softwaretechnischen Lösungen als Standardsysteme verpackt. Dies gilt für einen großen Teil der betriebswirtschaftlichen Anwendungen. Ebenfalls sind immer mehr Produktionssysteme, Logistiksysteme und Verkehrsleitsysteme mit Standardprodukten abgedeckt. Standardpakete von der Stange sind die bevorzugten Lösungen für die Prozessautomatisierung. Sie sind preiswerter und zuverlässiger und leichter in der Pflege. Vor allem der Anbieter bürgt für deren Qualität und sichert deren Weiterentwicklung. Standardsysteme sind bereits mehrfach getestet und haben einen Zuverlässigkeitsgrad, den individuelle Lösungen nur selten erreichen können. Dennoch sehen sich immer noch viele Anwender gezwungen, eigene, maßgeschneiderte Lösungen zu stricken. Sie können auf einer grünen Wiese beginnen und alles von Grund auf neu bauen, oder sie können mit fertigen Bestandteilen beginnen und sie zu einem Ganzen zusammenfügen. Fehlende Bausteine können sie immer noch selber entwickeln. Wichtig ist, dass die neuen Anwendungssysteme aus möglichst vielen vorgefertigten und vorgetesteten Komponenten beziehungsweise Services bestehen.
Eine serviceorientierte Architektur mit Microservices ist ein vielversprechender Weg zu diesem Ziel. Neuentwicklungen sind trotz Fortschritten in der Softwaretechnologie weiterhin mit enormen Kosten und Risiken verbunden. Die Kosten für den Test automatisierter Prozesse sind enorm. Um als vertrauenswürdig zu gelten, muss jeder mögliche Ablaufpfad mit allen möglichen Zuständen getestet werden. Kurzum, es kann Jahre dauern, bis große, komplexe Prozesse ohne Automatisierung ausreichend getestet sind. Mit Testautomatisierung kann der Test beschleunigt werden, aber auch der automatisierte Test stößt an Grenzen. Der Mensch muss immer noch die Testdaten zuweisen und nur der Fachexperte kann die erwarteten Ergebnisse vorgeben. Ist der Test einer neuen Anwendung einmal erprobt, kann er automatisch mutiert und wiederholt werden, aber es muss erst so weit kommen.
Deshalb bleibt der Test das Haupthindernis bei der Automatisierung der Prozesse. Die erforderliche Software ist schnell geschrieben oder generiert, aber bis sie in allen Facetten als vollständige und zuverlässige Lösung bestätigt ist, kann es lange dauern und viel kosten. Solange Menschen die Software entwickeln, wird sie fehlerhaft entwickelt. Fehlerhafte Software macht es riskant, die betrieblichen Prozesse zu automatisieren. Die Risiken automatisierter Prozesse werden – wie die Risiken elektronisch gespeicherter Daten – durch Testen reduziert.
Die Qualität neuer Software lässt sich auch durch statische Analyse feststellen, aber nur der dynamische Test bringt heraus, ob der automatisierte Prozess sich wirklich so verhält, wie er sich verhalten sollte. Alles, was dazu beiträgt, diesen Beweis schneller und kostengünstiger zu erbringen, ist zu begrüßen, aber die schnellste und preiswerteste Lösung bleibt die Nutzung bereits bewährter Software, entweder als Ganzes oder als einzelne Bausteine.
Die dritte Säule der Digitalisierung ist, neben den elektronisch gespeicherten Daten und den automatisierten Prozessen, der omnipräsente Datenaustausch. Gewonnene Informationen müssen überall und zu jeder Zeit übertragen werden, von den Sensoren an den Geräten, von den Monitoren, die jene automatisierten Prozesse überwachen, von den Datenspeichern und von den Menschen, die Daten aufnehmen. Es müssen alle Elemente eines Systems, die Menschen wie auch die Maschinen miteinander vernetzt sein. Es gibt Mensch-zu-Mensch-, Mensch-zu-Maschine- und Maschine-zu-Maschine-Kommunikation – siehe auch “Internet of Things”.
Die Kommunikation muss jedoch einwandfrei funktionieren. Software kann sich selbst überwachen, aber dazu muss sie in der Lage sein, Nachrichten zu senden und zu empfangen. Der Austausch digitalisierter Nachrichten ist der Kit, der eine digitale Umgebung zusammenhält. Sie muss aber störungsfrei und gesichert sein.
Eine sichere Kommunikation ist eine, bei der alles, was gesendet wird, auch ankommt. Das Gesendete darf nicht unterwegs abgefangen, abgeschrieben oder abgehört werden. Die Nachrichten, die übermittelt werden, müssen versiegelt bleiben. Nur der Zielempfänger darf sie öffnen. Dies gilt für Menschen wie für Geräte.
In zunehmendem Maße senden Geräte und Softwarekomponenten Nachrichten aneinander. Der Sender einer Nachricht – ob Mensch, Hardwaregerät oder Softwareservice – muss die Gewissheit haben, dass die gesendeten Daten tatsächlich am Ziel unverändert ankommen und der Empfänger muss die Gewissheit haben, dass die empfangenen Daten nicht unterwegs missbraucht, manipuliert oder abgehört wurden. Dies ist nur über ein sicheres Kommunikationsnetz zu gewährleisten. Daher muss auch die Datenübertragung getestet werden. Wir brauchen Testwerkzeuge, die Nachrichten generieren und senden, Werkzeuge, um Nachrichten zu empfangen und zu validieren, und Werkzeuge, um die Nachrichten unterwegs durch das Netz zu verfolgen. Diese Werkzeuge müssen erkennen, wann und wo Nachrichten abgefangen werden. Durch den Kommunikationstest wird gesichert, dass die Datenübertragung einwandfrei funktioniert.
Die Überwachung der Datenübertragung spielt beim Test digitalisierter Betriebe eine besondere Rolle. Denn es geht nicht nur um die Korrektheit der Nachrichtenvermittlung, sondern auch um deren Sicherheit. Eingriffe ins Kommunikationsnetz müssen simuliert werden um zu testen, wie das Netz darauf reagiert. Das Abfangen, die Umleitung und die unberechtigte Verwendung von Nachrichten sind auszuschließen. Das Kommunikationsnetz kann nur dann als sicher gelten, wenn alle diese simulierten Angriffe erkannt und abgewiesen werden. Dazu gehört auch der Versuch unautorisierter Personen, in das Netz einzubrechen. Selbstverständlich müssen alle Einbruchsmöglichkeiten getestet werde. Die Sicherheit der Nachrichtenvermittlung ist eine unerlässliche Vorbedingung der Digitalisierung.
Hier wird ersichtlich, wie viel Aufwand mit dem Test der Kommunikation verbunden ist. Wer es mit der Digitalisierung ernst meint, muss bereit sein, einen hohen Preis für die Qualität zu bezahlen. Sonst bleibt er immer verwundbar.
Um der Herausforderung der Digitalisierung gerecht zu werden, müssen wir schauen, wie wir mit dem Testen weiterkommen.
Da es so viel in so kurzer Zeit zu testen gibt, muss die Testautomation vorangetrieben werden. Aber das allein reicht nicht. Die Anwender müssen in den Test einbezogen werden. Sie dürfen nicht abseits warten, bis der Test endlich als abgeschlossen deklariert ist. Die Anwender sind sogar für den Test verantwortlich. Denn nur die Endbenutzer können entscheiden, ob der Test ausreichend für den Einsatz ist. Sie tragen das Risiko, wenn etwas schief läuft. Natürlich werden sie von Fachleuten beraten, aber nur der Endverbraucher kann entscheiden, ob ein Produkt reif für den Einsatz ist.
Der Anwender ist auch für die Prüfung der Daten zuständig. Er muss wissen, in welchem Zustand sich die Daten befinden und ob dieser Zustand ausreichend für den Betrieb ist. Das heißt, die Datenbestände müssen durch Automaten fortwährend überwacht und die geringsten Abweichungen vom Soll berichtet werden. Die Überwachung der Daten findet solange statt, wie die Daten noch benutzt werden. Gleiches gilt für die automatisierten Prozesse.
Da die Prozesse ständig weiterentwickelt werden, müssen sie auch ständig weiter getestet werden. Der Test ist nie zu Ende. Bei jeder Änderung, sei sie sonst so gering, muss die Software neu getestet werden. Wie der Datenzustand sind auch die Prozessabläufe permanent zu überwachen und jede Abweichung vom Sollverhalten zu registrieren. Schließlich sind alle Kommunikationsvorgänge zu verfolgen und sämtliche Nachrichten zu überprüfen. Nachrichten, die von der Norm abweichen, sind auszusortieren, um näher untersucht zu werden. Der Inhalt sämtlicher Nachrichten ist gegen eine Spezifikation jener Nachrichten zu prüfen und die Abweichung zu melden.
Wer es wagt, in die Digitalisierungsarena einzutreten, muss sich von dem Projektdenken verabschieden. Projekte sind einmalige, zeitlich und kostenmäßig beschränkte Aktivitäten mit einem Anfang und einem Ende. Es dürfte in einer digitalisierten Welt keine zeitlich beschränkten Projekte mehr geben, nur Produkte, sprich Systeme, die fortwährend weiterentwickelt, getestet und ausgeliefert werden.
Testen findet im Rahmen der betrieblichen Übergabe statt. Bisher wurde immer getrennt zwischen Entwicklung, Test und Abnahme. Es gab Mauern zwischen den Aktivitäten. In DevOps fließen die Aktivitäten ineinander über.
Exploratives Testen und Benutzen sind voneinander kaum zu trennen. Der Endanwender ist zugleich Tester und Benutzer. Wenn Fehler auftreten, versucht er, sie zu umgehen. Gemeldet werden sie auf jeden Fall, aber sie dürfen die Inbetriebnahme des Systems nicht aufhalten, sofern sie den weiteren Betrieb nicht verhindern.
Für dieses Problem verspricht DevOps, die Lösung zu sein. Da immer mehr Softwaresysteme ein dynamisches Ziel im Auge haben, dürfen sie niemals als fertiges Produkt betrachtet werden. Sie bleiben lebenslänglich in der Entwicklung. Sie decken immer nur eine Untermenge der Anforderungen ab, eine Untermenge, die mit der Zeit immer kleiner wird. Anfänglich könnte das System über 90 Prozent der Digitalisierungsanforderungen abdecken, aber im Laufe der Zeit wird dieser Anteil auf 80 Prozent absinken und weiter nach unten. Softwaresysteme haben schon immer mit der Zeit an Wert verloren. Belady und Lehman haben dieses Phänomen schon in den Siebzigerjahren des letzten Jahrhunderts erkannt und mit ihren Gesetzen der Softwareevolution festgehalten.
Ein Softwaresystem ist die Abbildung einer gewissen Anwendung, zum Beispiel der Reisebuchung. Es veraltet in dem Maße, wie es mit jener Anwendung nicht mehr Schritt hält, das heißt, der Reiseanbieter möchte immer mehr Dienstleistungen anbieten, die von der Software nicht abgedeckt werden. Die Software fällt immer weiter zurück und ist für den Anwender des Systems immer weniger Wert.
Zu dem Zeitpunkt, als Belady und Lehman ihre Gesetze der Softwareevolution verkündet haben, war die Änderungsrate noch mit dem konventionellem Change-Management zu bewältigen. Die neuen Anforderungen blieben unter 5 Prozent der gesamten Anforderungen. Für die nicht oder unzulänglich abgedeckten Anforderungen stellten die Anwender Änderungsanträge. Diese wurden priorisiert und kamen in die Planung der nächsten Releases hinein. Früher oder später wurden sie implementiert. Später ist die Änderungsrate für immer mehr Systeme über 10 Prozent jährlich gestiegen. Das konventionelle Change-Management erreichte bald seine Grenzen. Die Funktionalität der Software fiel immer weiter zurück. Der Druck auf die IT nahm immer mehr zu.
Jetzt, im Zuge der Digitalisierung haben wir Anforderungsänderungsraten von über 20 Prozent und mehr. Das konventionelle Change-Management ist gänzlich überfordert. Es geht bei immer mehr Anwendungen nicht mehr, dass sie erst durch ein langwieriges Testverfahren gehen, ehe sie freigegeben werden. Sie müssen früher freigegeben werden, auch wenn sie nicht ausreichend getestet sind. Die verbleibenden Fehler müssen eben in der Produktion entfernt werden. Der Schaden, der durch die Fehler entsteht, ist geringer als der Schaden durch die Verzögerung der Auslieferung. Hauptsache ist, die ausgelieferten Systeme bleiben unter der Kontrolle des Produktmanagements. Die Fehler und sonstigen Mängel im System sind alle notiert und werden überwacht. Früher oder später werden sie auch behoben, aber sie dürfen nie der Anlass sein, ein Release nicht auszuliefern. Die kontinuierliche Auslieferung hat Vorrang.
Eine Anwendung, bei der Continuous Delivery praktiziert wird, ist das Abrechnungssystem der Länder Oberösterreich und Burgenland. Die Sachbearbeiter in der Personalabteilung sind dort auch für den Test und die Auslieferung zuständig. Das System mit einem VisualAge-Frontend und einem PL/I-Backend wird Stück für Stück in Java umgesetzt. Die alte Umgebung ist gleich der Testumgebung.
Seit anderthalb Jahren wird das Frontend komponentenweise in Java re-implementiert. Eine Komponente nach der anderen wird aus dem alten System herausgenommen und in Java umgeschrieben. Dann wird sie an die zuständigen Sachbearbeiter übergeben, die das Verhalten der neuen Komponente mit dem der alten abgleichen.
Die Sachbearbeiter testen die neuen Java-Komponenten neben ihrer täglichen Arbeit. Sollten Abweichungen auftreten, werden sie an die Entwickler gemeldet, die sie umgehend korrigieren. Bis es so weit ist, arbeiten die Endbenutzer mit der alten Komponente. Das aktuelle System ist eine Mischung aus neuen und alten Komponenten.
Bis zum Anfang 2017 ist ein Drittel der Anwendungsfälle auf diese Weise abgelöst worden. Bis Ende 2018 sollen alle Frontend-Komponenten in Java sein. Bis es so weit ist, werden die VisualAgeund Java-Komponenten in der gleichen Umgebung nebeneinander herlaufen. Ausschlaggebend ist die Kontinuität der Dienstleistung.
Die Digitalisierung der Unternehmen verlangt, dass ihre Anwendungssysteme einem permanenten Wandel unterworfen sind. Sie müssen ständig weiterentwickelt werden, um mit dem Wandel in der realen Welt Schritt zu halten. Entwicklung, Test und Auslieferung finden nebeneinander statt. Das setzt andere Organisationsformen voraus. Nicht alle Anwendungen eignen sich für eine DevOps-Organisation – aber bei immer mehr Frontoffice-Applikationen hat “Time to Market” Vorrang vor Qualität. Für diese Anwendungen ist DevOps die richtige Lösung.