„DevOps macht die IT adaptiver!“

Prozesse und Geschäftsmodelle werden mehr und mehr digital umgesetzt. Dabei wächst nicht nur die Komplexität der zu optimierenden Prozesse, sondern auch der Anspruch der IT-Verantwortlichen. So entscheiden sich 53 Prozent der Befragten für die Entwicklung von Individualsoftware, weil standardisierte Branchensoftware notwendige Funktionen nicht oder nur teilweise abbildet (43 Prozent) oder weil sie unzureichend skalierbar ist (36 Prozent).

77 Prozent wollen mit Individualsoftware Wettbewerbsvorteile gegenüber der Konkurrenz erlangen oder bewahren. Nur durch einzigartige Produkte, Leistungen oder Prozesse können sich Unternehmen langfristig am Markt behaupten und von Innovationsvorsprüngen durch Differenzierung profitieren, glauben 71 Prozent. Zudem wird individuell erstellte Software auch als Treiber neuartiger Ideen und Innovationen gesehen. 

Als Mittel zum Zweck beim Erstellen von Individualsoftware gilt der DevOps-Ansatz, also das gekonnte Zusammenspiel von Teams aus Software-Entwicklung und IT-Betrieb. Das ist leichter gesagt als getan. Der 10. State of DevOps-Report von -Puppet zeigt, dass die große Mehrheit der Unternehmen immer noch in der mittleren Evolutionsphase feststeckt, wobei organisatorische und kulturelle Faktoren die großen Blockierer für den unternehmensweiten Erfolg bleiben. Die Mehrheit ist noch weit von DevOps-Praktiken entfernt, die zu On-Demand-Implementierungen führen, wobei Schlüsselkennzahlen wie die Vorlaufzeiten für Änderungen und die mittlere Zeit bis zur Lösung in Minuten und nicht in Stunden gemessen werden.

Doch wie ist es um die „Legacy-Systeme“ bestellt? Die über Jahre auf die Bedürfnisse von Anwendern, Kunden und Märkten zugeschnittenen Anwendungen sind wertvolle Software-Schätze. „Diese Assets dürfen nicht zur Achillesferse für den Erfolg der Unternehmen werden“, warnt Manfred Lackner. In DV-Dialog erläutert der Vorstandsvorsitzende von Profi Engineering, worauf es bei der Umsetzung von DevOps-Konzepten ankommt.

Dies ist ein Artikel aus unserer Print-Ausgabe 7-8/2021. Bestellen Sie ein kostenfreies Probe-Abo.

Das Konzept „DevOps“, die Verschmelzung von Software-Entwicklung und IT-Betrieb, gewinnt im Mittelstand immer mehr an Bedeutung. Im Interview erklärt Lackner, warum das so ist und welche Konsequenzen das Konzept auf innovative Anwendungen hat, in die natürlich auch auf die bewährten RPG-Programme einbezogen werden. Ob der Mittelstand „DevOps“ wegen des aktuellen Hypes darum nutzt oder weil er schon immer adaptiv handelt, spielt laut Lackner für diese nötige Veränderung in IT-Organisationen die kleinere Rolle. Wichtig sei, dass die Veränderung vollzogen wird, um langfristig die nötige Funktionalität, Sicherheit und Effizienz der IT sicherzustellen.

Herr Lackner, das Thema „DevOps“ gewinnt im Mittelstand und speziell auch bei IBM-Kunden immer mehr an Bedeutung. Warum?

Manfred Lackner: Getrieben durch digitale Geschäftsmodelle und automatisierte Abläufe nimmt der Software-Anteil an Produkten und Prozessen sehr stark zu. Die Interaktion mit Kunden und Anwendern, aber auch mit Services von Dritten in digitalen Wertschöpfungsketten unterliegt dabei dem Druck, sich schnell an ändernde oder neue Anforderungen anpassen zu müssen.

Sicherheitsfragen – wir erleben das ja gerade intensiv im Kontext der Cyberangriffe auf Unternehmen – sind neben Qualität und Verfügbarkeit ein zusätzlicher Treiber, Software schnell entwickeln und bereit stellen zu können. Das funktioniert im klassischen Plan-Built-Run und der traditionellen Aufgabenverteilung zwischen Software-Entwicklung, Infrastruktur und Betrieb eben nicht schnell und vor allem nicht gut genug. 

Die Beteiligten dieser – für Betriebswirtschaft-liche Standardsysteme wie ERP auch bewährten und guten – „Trennung“ wieder enger miteinander zu verzahnen und gemeinsam für das „Funktionieren“ der digitalen Services in Verantwortung zu nehmen, ist daher ein logischer und sehr sinnvoller Schritt. Wir sprechen dann von DevOps. Ob es der Mittelstand wegen dieses aktuellen Trends tut, oder weil er schon immer adaptiv handelt, spielt für die stattfindende Veränderung in IT-Organisationen die kleinere Rolle. Wichtig ist, dass es passiert.

Was muss der IT-Chef tun, damit diese enge Verzahnung von Software-Entwicklung und -Betrieb auch in der täglichen Praxis reibungslos funktioniert?

Lackner: Die crossfunktionalen Teams müssen auch die Verantwortung übernehmen können für das Funktionieren der Anwendungen bzw. der Software, die sie entwickeln. Das heißt, diese Teams müssen Entscheidungen während der Entwicklung schnell treffen können, aber auch die Verantwortung bis in den Betrieb dafür übernehmen. Das ist die eine Seite, die einige Herausforderungen an Kultur, Organisationsstruktur und Prozesse mit sich bringt. 

Die andere Seite heißt Herstellung eines sehr hohen Automatisierungsgrades. Jede manuelle Intervention in einem Deployment-Prozess bedeutet Abstimmung und Kontrolle und reduziert damit Qualität – zu der ich auch Sicherheit zähle – und Geschwindigkeit. Automatisierung umfasst dabei auch die Durchgängigkeit von Entwicklungs-, Test- und Produktivsystemen und das Testen nicht nur von Softwarefunktionen, sondern auch von Infrastrukturen und damit Sicherheitskomponenten.

Der IT-Chef muss dafür sorgen, dass die Zusammensetzung der Teams fundierte Entscheidungen auch ermöglicht – dazu zählen auch das Wissen und das Vorliegen von Informationen über die Qualität der Software im Betrieb. Stichwort hier: übergreifendes Monitoring der gesamten Infrastruktur und transparente Bereitstellung der entsprechenden Informationen an die Teams.

Neben der passenden Organisation der IT-Abteilung geht es also auch um die richtigen „Skills“. Welche neuen Skills müssen die Entwickler erlernen – und welche neuen Fähigkeiten müssen sich die Teams in Operating und Systemadministration aneignen?

Lackner: Wie eben erwähnt: Entwickler müssen sich – mindestens im Team – wieder mehr um Infrastruktur- und Betriebsfragen kümmern und dazu auch Wissen aufbauen. Containertechnologien mögen da zwar etwas Druck gegenüber Virtualisierung rausnehmen, aber wer „You build it – you run it“ ernst meint, muss eben „built“ und „run“ verstehen. 

Im Betrieb heißt das dann: man muss coden lernen. Nicht Anwendungscode, aber Infrastrukturen in Code zu gießen, diese zu testen und im Kontext von Automatisierung und Monitoring zu integrieren, ist „die neue Art“ zu arbeiten. Sicher helfen hier Erfahrungen aus dem Skripting, aber Infrastuktur als Code ist eben deutlich mehr.

Viele Unternehmen konzentrieren sich aber nur auf die Auswahl und den Betrieb von Containern, Automatisierung und „Infrastructure as Code“-Plattformen, statt diese auch mit veränderten Team- und Organisationsstrukturen zu benutzen. Cloud-native zu agieren, wie wir es unseren Kunden empfehlen, bedeutet eben einen Sichtwechsel auf den Beitrag eigener Skills zur Wertschöpfung. Der Service, die Anwendung und deren Funktionieren für den Nutzer stehen im Vordergrund, und nicht nur der pure Betrieb einer stabilen weiteren Plattform für Entwickler. 

Nicht all diese Skills müssen zwingend „inhouse“ vorhanden sein? Welche Skills braucht die IT-Abteilung – und was lässt sich zukaufen?

Lackner: Das ist richtig. Es ist wichtig die -Prozesse und dafür notwendigen Applika-tionen eines Unternehmens zu verstehen, zu optimieren und zu betreiben. Darauf sollte der Fokus einer IT-Abteilung liegen, die sich als Dienstleister im Unternehmen versteht. Und hier liegt aus unserer Sicht auch die Chance für das Thema Public-Cloud für die IT. Wenn der Beitrag an der Wertschöpfung auf die Anwendungen gerichtet wird, dann sind Software-definierte Infrastrukturen durch deren Beschreibung bestimmt und nicht durch den Ort, in dem sie physikalisch laufen.

Welche Form des Zukaufs, von „Body Leasing“ bis zu „Managed Services“, empfiehlt sich dabei – und warum?

Lackner: Body-Leasing empfiehlt sich in der Regel für dauerhafte Aufgaben „vor Ort“. Dies sind meist programmatische Aufgaben. Der eigentliche Betrieb der Systemlandschaft, um die entsprechende Basis zur Verfügung zu stellen, wird in der Regel über Managed-Service-Provider abgebildet. Die Mitarbeiter können sich dann auf die wesentlichen Aufgaben innerhalb eines Unternehmens fokussieren. 

Lassen Sie uns einen Blick in den DevOps-Werkzeugkasten werfen: Welche altbewährten Tools und Suiten bleiben unverzichtbar und welche Tools kommen neu hinzu?

Lackner: Unserer Erfahrung nach kann man auf der „Dev-Seite“ mit den bestehenden Entwicklungstools und denen für CI/CD – Continuous Integration / Continuos Delivery – gut weiter arbeiten. Viele dieser Tools stammen heute schon aus der Open-Source-Welt und stellen Marktstandards dar. 

Auf der Ops-Seite kommen neue Tools hinzu, getrieben durch Automatisierungs-, -Monitoring- und „Infrastructure as Code“-Plattformen. Auch hier kann man feststellen, dass aus der Open-Source-Welt viel Beitrag geleistet wird. Ein Beleg dafür ist die Akquise von Red Hat durch IBM, die hier wichtige Bausteine wie z.B. Open-shift oder Ansible als Enterprise-Open-Source-Lösung bereit halten. Viel wichtiger als die Diskussion um das richtige alte oder neue Tool ist, dass die Teams für sich zunächst die Werkzeuge finden und gemeinsam nutzen, mit denen sie schnell und produktiv arbeiten können. Wir sehen hier die Unternehmen in einer besseren Position, die dieser Sicht den Vorrang vor einer „wir definieren erst einmal den unternehmensweiten Tool- und Plattformstandard“ Diskussion geben. 

Wenn sich die IT-Anwendungen dank DevOps immer schneller ändern können und immer flexibler werden. Wieviel Automation ist dann im Ops-Bereich überhaupt noch möglich?

Lackner: So viel Automatisierung wie möglich muss das Ziel sein, wenn man DevOps wirklich leben will. Wiederholbare Arbeiten definieren sich nicht erst nach der hundertsten Wiederholung. DevOps-Organisationen automatisieren schon den ersten Task, weil es in ihrer DNA liegt.

Gibt es in DevOps-Szenarien schon praktikable Konzepte für die RZ-Automation? Oder muss die Idee vom „Lights out“-Betrieb ein Wunschtraum bleiben?

Lackner: Es gibt praktikable Konzepte, es gibt aber nicht „das Eine“. Jedes Unternehmen hat individuelle Voraussetzungen und Bedingungen, auf denen RZ-Automatisierung stattfinden kann. Wenn man lernt, wie sich durch Software Infrastrukturen definieren und damit auch betreiben lassen, ohne dass jemand vor der Konsole sitzen muss, dann kann man abschätzen, wann das Rechenzentrum die Lichter aus machen kann. Wer das schafft, der hat dann einen Cloud-native-Grad als Rechenzentrum erreicht, der dem eines Public-Cloud-Providers sehr nahe kommt – in deren Infrastruktur geht ja auch kein Mitarbeiter mehr rein. 

Wenn wir auf das RZ selbst schauen: Wird der Mittelständler das auf lange Sicht noch selbst betreiben? Oder wird er es bei einem Dienstleister hosten?

Lackner: Ich bin davon überzeugt, dass die Zukunft in einem hybriden Modell liegt. Dazu muss wie eben gesagt das Thema Automatisierung stattgefunden haben. Einige Services können und werden dann aus der Cloud (i.d.R. von Hyperscalern) bezogen, andere Dienste verbleiben im eigenen Rechenzentrum. Aber auch dieses muss nicht zwingend mehr in den eigenen Räumlichkeiten beherbergt werden. Dabei spielen natürlich die Kosten für das tatsächliche „Blech“ und die Unterhaltung der Räumlichkeiten eine wichtige Rolle.

Auch die Bedenken gegen die Cloud scheinen zu schwinden: In welchen Bereichen ist Cloud Computing heute noch mit Vorsicht zu betrachten?

Lackner: Wirklich mit Vorsicht zu betrachten sind weiterhin die Fragen des Datenschutzes. Also in welcher Region wird das Cloud--Angebot bereitgestellt? Und stehen diese unter dem Schutz z.B. der europäischen Datenschutzvorschriften? Daten- und Informationssicherheit in der Nutzung von Public-Cloud-Angeboten ist im sogenannten Shared-Responsibility-Modell der Cloud-Anbieter ja weiterhin und richtigerweise Aufgabe des Unternehmens. 

Gerade die vielen Cyber-Angriffe der jüngsten Zeit zeigen, dass hier generell Aufholbedarf besteht – egal, wo Systeme stehen. Wenn also versucht wird, mit „alten Sichtweisen“ in die Cloud zu gehen, in der Erwartung, dass ein Cloud-Betreiber einem das Risiko abnimmt, war und bleibt das falsch. Da sehen wir eher ein Risiko. DevOps, SecDevOps, DevSecOps und wie die Begriffe alle heißen, helfen hier besser zu werden. Und dann spielt wie schon gesagt der Ort, in dem die Compute-Leistungen erbracht werden, keine entscheidende Rolle mehr.

Hybrid Cloud gilt also zu Recht als das Ops-Patentrezept für den IT-Chef – oder sehen Sie Alternativen?

Lackner: Hybrid bedeutet ja zunächst, dass das eigene RZ cloud-fähig wird, damit es ähnlich wie die Services der Public-Cloud-Anbieter von den eigenen Anwendungen benutzt werden kann. Der Einsatz von Container-Technologien beschleunigt diese Entwicklung – daher wird sich der hybride Ansatz durchsetzen, er ist in vielen Fällen heute schon Realität. 

Bei der Entscheidung über Services, die über die geografische und zeitliche Verteilung von Rechenkapazität bezogen werden, spielen technische und kaufmännische Rahmenbedingungen immer eine wichtige Rolle. KI und IoT als Treiber der Digitalisierung können sinnvollerweise nur mit hybriden Ansätzen abgebildet werden – und auf diese Anwendungen will kein Unternehmen in Zukunft mehr verzichten. 

Kann die Hybrid Cloud auch bei der Modernisierung altbewährter RPG- und Cobol-Programmen Hilfestellung leisten – zum Beispiel in Form von Webservices, „Containierung“ und „App-ifizierung“? 

Lackner: Natürlich, denn mit der Modernisierung von alten Legacy-Anwendungen werden hybride Betriebsmodelle überhaupt erst möglich bzw. unterstützt. So werden neue, z.B. Java-basierende Anwendungsmodule entwickelt, in denen bestehender RPG- oder Cobol-Code integriert ist, der nach wie vor auf Legacy-Systemen laufen kann. Die neuen Anwendungsbestandteile können in Containern laufen, Webservices nutzen und natürlich auch auf anderen Systemen oder in der Cloud betrieben werden. 

Wenn wir abschließend auch noch in die Dev-Zukunft blicken: Welche Rolle spielen dabei innovative Technologien wie KI oder Machine Learning? 

Lackner: KI und Machine Learning werden bei der Entwicklung neuer Applikationen eine immer stärkere Rolle spielen, da KI-Technologien in nahezu allen Anwendungsszenarien eingesetzt werden können, um Abläufe, Ergebnisse und insbesondere Prognosen kontinuierlich zu verbessern oder zu optimieren. Insbesondere prediktive Modelle, also die Prognose zum Beispiel des zukünftigen Kaufverhaltens, von potentiellen Maschinen- oder Anlage-ausfällen oder auch von notwendigen Sanierungsmaßnahmen bei Gebäuden spielen dabei eine ganz entscheidende Rolle, denn es geht in erster Linie um Fehlervermeidung und nicht nur um eine verbesserte Analyse oder Fehlerbehebung.

Die Verarbeitung und Analyse enormer Datenmengen ist heutzutage kein Problem mehr, Kapazität und Leistung der notwendigen -Systeme lassen dies problemlos zu. Die zugrundeliegenden Verfahren und Methoden werden ständig weiterentwickelt und stehen als Webservices mit den entsprechenden APIs zur Verfügung, sodass der Einzug von KI-Methoden in die Software-Entwicklung zum Standard wird.

Sehen Sie schon tragfähige Brücken entstehen, die bewährte Legacy-Anwendungen in Zukunft so mit innovativen neuen Apps verbinden, dass der IT-Chef den maximalen Nutzen aus den Investitionen der Vergangenheit ziehen kann?

Lackner: Ja die gibt es – wir haben als Profi genau dazu eine Vorgehensweise entwickelt, wie man alte und neue Welt in idealer Weise zusammenbringt und mit kalkulierbaren Kosten erheblich an Produktivität und Flexibilität gewinnt. Die neuen Apps die im Zuge der Anwendungsmodernisierung von Legacy-Applikationen entstehen, haben häufig ein völlig neues Front-End-Design und sind user-zentriert aufgebaut. Das heißt: die Bedienung ist stark vereinfacht, und zwar geräteunabhängig. Damit wird den gestiegenen Anforderungen an Usability und Mobilität Rechnung getragen, die wichtig sind für deren Mehrwert und Nutzen. Ganz entscheidend ist, dass dabei Sicherheit und Stabilität gewährleistet bleiben, und zwar unabhängig vom gewählten Betriebsmodell.

Herr Lackner, vielen Dank für das Interview!

Bildquelle: Roger Richter