Das monolithische Problem

Die Deutsche Telekom IT GmbH ist der interne IT-Dienstleister der Deutschen Telekom AG. Mit weltweit rund 9.700 Mitarbeitern und einem Gesamtbudget von rund 1,9 Milliarden Euro ist das Unternehmen für die Konzeption, Entwicklung und den Betrieb aller eigens entwickelten und von Dritten eingeführten IT-Systeme verantwortlich, um die Geschäftsprozesse bei der Deutschen Telekom und ihren Tochtergesellschaften zu unterstützen.

Bereits seit 2007 verwendet die IT der Deutschen Telekom eine Oracle BPEL-Engine, um BPM-Workflows zu erstellen und auszuführen sowie Prozesse zu automatisieren. Dieser Monolith hat jedoch eine Reihe von Problemen mit sich gebracht, die sowohl das Geschäft selbst als auch das Nutzererlebnis erheblich einschränkten:

  • Lange „Time to Market“ von mehr als 12 Monaten
  • „Vendor Lock-In“, der die Telekom IT daran gehindert hat, neue Features zügig einzuführen – bis zu fünf Tage wurden benötigt, um Umgebungen neu aufzusetzen oder zu verändern
  • Durchschnittlich 1.000 Personentage und ungefähr drei Monate waren nötig, um Releases über die bisherige Wasserfallmethode zu veröffentlichen
  • Regressionstests benötigten gut zwei Tage, um alle Testfälle zu verarbeiten

Das Problem: „Wir müssen zeitnah liefern. Wir können nicht sieben Tage warten, bis ein Auftrag erledigt ist und wir können nicht erst sieben Tage warten, um auf eine Anforderung zu reagieren. Wir müssen vorausschauend und schnell handeln können“, erklärt Willm Tüting, Geschäftsführer der conology GmbH, die seit mehr als zehn Jahren für die Deutsche Telekom IT tätig ist.

Entweder ganz oder gar nicht agil

Im Jahr 2017 hat die Deutsche Telekom IT zunächst mit dem zehn Jahre alten monolithischen System erste Schritte unternommen, um die bestehenden Prozesse zu modernisieren. Dafür wurde ein „teilweise agiler“ Entwicklungsansatz gewählt, der Sprints von drei Monaten vorsah.

„Wir haben mehrere Prozesse umgestellt, um bei kleineren Anpassungen schneller als bisher liefern zu können“, so Tüting. „Damit haben wir uns das Leben aber nur noch weiter erschwert.“

Weil die „teilweise agil“ entwickelten Anpassungen zusammen mit größeren Change Requests zu liefern waren, musste beträchtlicher Aufwand getrieben werden, um das zu erreichen. Echte Agilität wird durch das monolithische BPEL-System schließlich gar nicht unterstützt.

Grundlagen für Veränderung legen

2017 hat die Deutsche Telekom damit begonnen, in Glasfaserkabel zu investieren, um ein besseres Nutzererlebnis zu erzielen. Dieses Hardware-Upgrade bot gleichzeitig die Gelegenheit, auch die veralteten IT-Systeme der Deutschen Telekom auf den aktuellen Stand zu bringen. Die Folge: ein vollständig überarbeitetes Betriebssystem und ein neuer DevOps-Ansatz. Damit verfolgte die Telekom IT vor allem drei Ziele:

  1. Geschwindigkeit: Statt auf BPEL wird ab sofort auf Java entwickelt und der Modus Operandi folgt agilen Methoden statt dem gewohnten Wasserfallmodell.
  2. Interdisziplinäre Teams: Statt Kompetenzen funktional zu bündeln, werden Teams ab sofort international und funktionsübergreifend zusammengestellt.
  3. Effizienz: Bessere Entwicklungsergebnisse durch Camunda, SPRING und andere State-of-the-Art Technologien.

Von einem Anbieter zu 43 Frameworks

Diesen drei Zielen folgend, führte die IT der Deutschen Telekom eine auf Microservices basierende Cloud-Architektur ein, in der die Camunda BPM-Engine jeden einzelnen Dienst steuert. Friedbert Samland, Projektleiter IT-Anwendung bei der Deutsche Telekom IT, erklärt, wie sich das System zusammensetzt:

  1. Microservices: „Inspiriert vom Microservices-Spickzettel, den Camunda-Mitgründer Bernd Rücker vorgestellt hat, betreiben wir Camunda-Engines in mehreren Microservices und sprechen direkt mit dem Message Broker“, erklärt Samland. Dieser Ansatz bricht den bisherigen Monolithen auf und macht funktionsübergreifendes Arbeiten möglich. Statt eines grafischen Interfaces (GUI) nutzt das System ausschließlich BPMN.
  2. Cloud: Durch eine leistungsfähige Cloud-Architektur verkürzen sich die Laufzeiten erheblich. Das ermöglicht ein mehrstufiges, zielgerichtetes Liefermodell. Diese Lösung hat die Telekom eigenständig auf Kubernetes entwickelt.
  3. SAFe agile framework: Eine neu eingeführte Organisation mit kürzeren End-to-End Durchlaufzeiten hat die Flexibilität und Geschwindigkeit erhöht.
  4. DevOps Philosophie: Automatisierung und Self-Service sind der Schlüssel einer neuen DevOps-Philosophie, die hohe Qualität und Geschwindigkeit gewährleistet.

Camunda als „Game Changer“

Einer der größten Vorteile, die sich für die Deutsche Telekom IT durch die Camunda-Einführung ergeben hat, ergibt sich aus der dadurch ermöglichten „Compliance by Default“. Weil die Telekom als globales Unternehmen auf der ganzen Welt mit mehreren Anbietern, unterschiedlichen Teams und teils vertraulichen Daten arbeitet, war eine hochautomatisierte Lösung unumgänglich. Jetzt sorgt die eingeführte Architektur standardmäßig dafür, dass Vorschriften eingehalten werden und die Datensicherheit stets gewährleistet bleibt.

Zusätzlich verfügt die IT der Deutschen Telekom über eine eigene Überwachungsplattform für Prozesse, die sich am Token-Konzept des Camunda Cockpits orientiert und Benutzern erlaubt, zu jeder Zeit den aktuellen Prozessfortschritt zu erkennen.

Camunda ermöglicht außerdem sowohl einer hochflexible DevOps-Philosophie zu folgen wie auch eine komplexe Geschäftslogik an zentraler Stelle zu visualisieren und dadurch manuelle und automatisch zu erledigende Aufgaben besser aufeinander abzustimmen. BPMN erleichtert dabei die Kommunikation zwischen Fachbereichen und IT, weil beide die gleiche Sprache sprechen.

Allen Unternehmen, die der Deutschen Telekom IT auf ihrem Weg zu einer verteilten Microservices-Architektur folgen wollen, rät Willm Tüting, trotz großer Ziele zuerst mit kleinen Schritten anzufangen: „Unternehmen sollten ihren Technologie-Stack selbst zusammenstellen und auf Komplettlösungen verzichten. Wichtig sind Technologien, die den größten Nutzen stiften, um die eigenen Ziele zu erreichen. Groß zu denken ist genauso wichtig wie klein anzufangen. Es geht nicht darum, gleich beim ersten Versuch den heiligen Gral zu finden, sondern sich langsam zur gewünschten Zielarchitektur hin zu entwickeln.“

Präsentationsfolien ansehen Mit einem Experten sprechen