„Der primäre Treiber der Umsetzung der definierten Vision sind dann vor allem die Menschen, erst danach kommen die zu definierenden Prozesse und anschließend die Technologie.“

Oliver Lemm, Fachbereichsleiter APEX Development und DOAG-Themenverantwortlicher DevOps, sprach mit Markus Peppler, Direktor/Abteilungsleiter für Business Analytics bei Universal Investment, über den Einsatz von DevOps in Unternehmen.

Was sind Ihre Aufgaben bei Universal-Investment?

Die Entwicklungs-Abteilung, die ich leite, nennt sich Business Analytics & Business Applications Development.

Wir sind für die komplette Business Intelligence & Analytics Infrastruktur in der Universal-Investment Gruppe, deren Weiterentwicklung und Instandhaltung zuständig. Sie umfasst eine zentrale Oracle- Datenbank sowie zahlreiche Satelliten wie SAP, das CRM (Microsoft Dynamics), unzählige Anwendungsdatenbanken, Sharepoints u. v. m. Alles verbunden durch anwendungsbezogene, aber auch eigenentwickelte ETL-Prozesse, Datenbanklinks und APIs.

Darüber hinaus entwickeln wir auf Basis von Oracle APEX für alle Unternehmensbereiche Business- Applikationen. Aktuell betreuen wir 50 Anwendungen mit knapp 1000 internen und externen Anwendern. Für zwei Teams agiere ich als Scrum Master, bin Projektleiter eines Cloud-Projektes, Business Relationship Manager für die Bereiche Portfoliomanagement & Immobilien sowie IT Innovation Ambassador.

In welchem Rahmen sind Sie zum ersten Mal mit dem Thema DevOps konfrontiert worden?

Im Jahr 2016 haben wir unsere Produktentwicklung auf das agile Vorgehensmodell Scrum umgestellt. Dieses basiert auf Werten und Prinzipen, stellt aber keinesfalls eine präskriptive Methode dar, die vorschreibt, wie der Prozess aussehen soll.

In der Agile Community wurde das Thema DevOps so ab 2017 mehr und mehr als fester Bestandteil integriert und auf Events und in den entsprechenden Community-Blogs nahezu gehypt. Da wir uns beginnend 2018 auch mit Cloud-Themen beschäftigt haben, sind wir endgültig am Thema DevOps nicht mehr vorbeigekommen und haben begonnen, uns darüber Gedanken zu machen, wie wir davon profitieren könnten.

Scrum konzentriert sich stark auf das, was während des Sprints geschieht. Scrum sagt dir nicht, wie der Prozess innerhalb des Sprints aussehen soll. Außerdem wird lediglich die Entwicklungsphase des Application Lifecycle betrachtet.

Wir sind in der Finanzbranche sehr stark reguliert und haben hohe Dokumentationspflichten an unsere Entwicklungsprozesse. D. h. wir müssen auch für das „Wie“ im  Entwicklungsprozess eine Antwort liefern und nachweisen, dass wir uns an diese Vorgaben halten.

Außerdem sind wir in unserer Einheit nicht nur für die reine Entwicklung zuständig, sondern bedienen auch andere Phasen im Application Lifecycle Management (ALM), u. a. das Requirements Engineering oder die Business-Analyse. Zuletzt sind wir auch für die Maintenance und den Betrieb der Applikationen verantwortlich.

Wir haben bei uns im Haus das Glück der kurzen Wege und arbeiten auf dem gleichen Flur wie unsere System- und Datenbank- Administratoren. Die Kollegen haben sich parallel mit unseren Bemühungen hin zu einem agilen Entwicklungsprozess sehr stark mit dem Thema „Infrastructure as Code“ sowie CI /CD beschäftigt. Mit den gemeinsamen Erfahrungen haben wir uns 2019 in ersten Pilotprojekten zusammen dem Thema DevOps gewidmet, sind experimentell vorgegangen, haben uns gleichzeitig durch Teilnahme an Events und Schulungen theoretisch schlaugemacht und Zertifizierungen durchlaufen.

Was sind die Schlüsseltreiber, um DevOps erfolgreich einzusetzen?

Der allererste Schritt sollte sein, zu definieren, was DevOps in der eigenen Organisation eigentlich bedeutet und wie die Vision aussieht, die man zu erreichen versucht.

Noch vor der Einführung von Technologie und der Änderung bestehender Prozesse müssen ein einheitliches Verständnis darüber bestehen und auch klare Grenzen zwischen DevOps und den bestehenden strukturierteren Ansätzen für das IT-Servicemanagement gezogen werden.

Der primäre Treiber der Umsetzung der definierten Vision sind dann vor allem die Menschen, erst danach kommen die zu definierenden Prozesse und anschließend die Technologie. Bei der Zusammenstellung eines DevOps-Teams sollten Organisationen Rollen und Verantwortlichkeiten definieren, um eine größere Effizienz zu erreichen.

Der DevOps-Prozess muss auch von Anfang an durch definierte KPIs begleitet werden. Durch diese kann man bewerten, ob die Initiativen erfolgreich sind und ob es Änderungsbedarf gibt. Diese orientieren sich an vereinbarten Zielen, die auf die DevOps-Vision einzahlen und auf dem Weg dorthin als Wegweiser dienen sollen.

Sehr wichtig ist es auch, sich regelmäßig mit Entwicklern und Systemadministratoren, die nicht zum Team gehören, zu treffen und die Ergebnisse objektiv zu bewerten.

Welchen kulturellen Problemen sind Sie zum Thema DevOps begegnet?

Eine der Herausforderungen für Organisationen, die sich auf DevOps hinbewegen wollen, ist der Kampf der Kulturen zwischen Dev und Ops. Meiner Ansicht nach ist diese Kluft nicht anders als andere, die wir in den meisten Organisationen finden, wie z. B. Business vs. IT, agil vs. Wasserfall, On-prem vs. Cloud oder make vs. buy.

In der täglichen Praxis gibt es allerdings keine echten, unüberwindbaren Reibungspunkte. Entwicklern ist es – entgegen der Mär – nicht egal, ob ihre Software später auch wirklich läuft, und dass Admins sich nicht für neue Technologien interessieren und Verständnis für Entwicklungsprozesse haben, ist auch schlicht falsch. Die Beteiligten sind es lediglich nicht gewohnt, sich über diese Themen auszutauschen. Hier liefert meines Erachtens DevOps auch die Lösung für diese kulturellen Hürden gleich mit. DevOps fördert eine Denkweise der Kommunikation, Zusammenarbeit, Integration und Automatisierung zwischen Softwareentwicklern und IT-Abteilungen, sodass es mehr als nur ein neuer Satz von Werkzeugen ist: Es ist ein kultureller Wandel. Diese Veränderung geschieht nicht sofort oder automatisch, sondern erfordert bewusste Schritte und Maßnahmen sowie kalkulierte Entscheidungen.

Worauf man bei der Einführung aber sehr diszipliniert achten muss, ist, dass sich – gerade die technikverliebten Entwickler – nicht ausschließlich auf die neuen Tools und technischen Möglichkeiten stürzen. Getreu dem Motto „a fool with tool is still a fool“ gilt es, bei allen Aktivitäten die nötigen organisatorischen und kulturellen Änderungen und vor allem die Vision hinter der DevOps-Organisation stets im Fokus zu behalten.

Wie kann man Vertrauen für das Thema DevOps erzeugen?

Von Anfang an muss man aus dem Management heraus ein klares Commitment abgeben und auch immerwährend deutlich den Beteiligten zeigen, dass man selbst mit Eifer bei der Sache ist und das Team auf die Unterstützung durch das Management bauen kann.

Die agilen Prinzipien und Werte wie „right to fail“, Autonomie, Selbstorganisation, Initiative, Subsidiaritätsprinzip, Delegation dürfen keine Lippenbekenntnisse bleiben, sondern müssen von allen Beteiligten als gelebte Praxis empfunden werden.

„Feiern“ ist eine weitere Möglichkeit, eine Verbindung der Teammitglieder untereinander und das Vertrauen in das Vorhaben herzustellen. Das Feiern gerade anfänglicher, auch kleiner Erfolge sowie die Wertschätzung des Beitrages am Erfolg jedes einzelnen. Dabei ist es wichtig, daran zu denken, als Gesamt-Organisation zu feiern, nicht als einzelne Teams. Die Vorstellung, dass die DevOps-Organisation als Einheit und nicht als einzelne Teams Erfolg hat und scheitert, muss Teil der DNA werden.

Dabei muss es nicht immer ein großes Event sein, schon kleine Aufmerksamkeiten, ein selbstgebackener Kuchen, eine Intranet-Meldung zu errungenen Meilensteinen oder ein Kegelabend nach dem erfolgreichen Rollout eines neuen Releases.

Was umfasst das Thema DevOps bei Ihnen alles?

Wie erwähnt ist die DevOps-Initiative bei uns aus den Erfahrungen und dem Ansatz der agilen Software-Entwicklung heraus entstanden. Gestartet sind wir zunächst mit dem Product Management, der Planung der Software nach Scrum und der Generierung von Features aus den Requirements, die wir im Zuge von Sprints in Form von User Stories entwickelt und als Releases zur Verfügung gestellt haben.

Nach und nach haben wir diesen Prozess erweitert und neben der kontinuierlichen Planung auch automatische Testverfahren, Continuous Integration und zuletzt auch Continuous Delivery aufgenommen. Die Ausprägungen und der Einsatz dieser Elemente kommt bei uns (noch) nicht flächendeckend in allen Projekten zum Tragen, da dies zum einen mit einigen Altsystemen mit sehr hohem Migrationsaufwand verbunden wäre und wir andererseits bei diversen Applikationen nur wenige Releases im Jahr benötigen, sodass der Mehraufwand für den vollumfänglichen Einsatz des Prozesses nicht zu rechtfertigen ist.

Unsere Vision ist es dennoch, im Falle der sehr dynamischen Applikationen auch in Zukunft noch einen Schritt weiter zu gehen und den Prozess bis hin zum Continuous Deployment auszuweiten, um den Applikations-Lebenszyklus bis auf wenige Tage verkürzen zu können. Dafür sind aber noch einige Hausaufgaben, gerade im Umfeld der automatischen Tests und Quality Assurance, zu erledigen.

Welche Tools setzen Sie im Bereich DevOps ein?

Zentrales Tool unserer DevOps-Prozesse sind die Azure DevOps Services und das darin integrierte Git Repository. Der Microsoft- Cloud-Dienst Azure DevOps Services bietet Entwicklern Unterstützung von Teams bei der Arbeitsplanung, der Zusammenarbeit bei der Code-Entwicklung und der Erstellung und Bereitstellung von Anwendungen.

Darüber hinaus setzen wir weitere Tools und Frameworks wie beispielsweise Docker, Kubernetes, PowerShell, Selenium, usw. ein. Diese sind voll in Azure DevOps Services integrierbar und kommen in den CI/CD Pipelines für unterschiedliche Aufgabe im Build, Deployment und Test-Prozess zum Einsatz.

Setzen Sie bereits DevOps in Kombination mit Cloud-Technologien ein?

Wir nutzen zum Verteilen von Open-API-basierten MicroServices die Azure Container Services, welche z. B. Python-basierte Algorithmen in der Cloud zur Verfügung stellen.

Unsere BI-Infrastruktur haben wir kürzlich um den Cloud Services Power BI sowie die Azure Analysis Services ergänzt und unsere aktuelle Data Analytics & Data Science-Plattform ist Databricks. All diese Cloud Services sind voll integriert in unsere DevOps-Umgebung und durchlaufen hier sowohl Planung, Entwicklung, Source Code-Verwaltung als auch CI- und CD-Prozesse.

Wir setzen insgesamt auf einen hybriden Ansatz aus On- Premises- und Cloud-Modulen und wenden uns verstärkt auch Cloud-gehosteten Infrastrukturen zu.

Welche Veränderungen erwarten Sie in den nächsten Jahren im Bereich DevOps?

Durch die steigende Anzahl an Cloud-Projekten und die Migration ganzer IT-Infrastrukturen in die Cloud wird das Thema DevOps noch stärker in den Fokus geraten. Denn DevOps und Cloud sind eng miteinander verwoben und verfolgen die gleichen Ziele und Strategien wie beispielsweise schnellere Bereitstellung von Anwendungen, um die Bedürfnisse der Geschäftseinheiten schneller zu erfüllen, Benutzeranforderungen, die schnell wieder in die Software einfließen, und niedrigere Kosten für Entwicklung, Tests, Bereitstellung und Betrieb.

Mit der zunehmenden Verbreitung von Cloud-nativen Ansätzen rücken Container Images und Registries sowie die passenden Werkzeuge wie Kubernetes, Docker, Artifactory etc. stark in den Fokus der Entwicklungsprozesse und werden mehr und mehr zentraler Bestandteil der DevOps-Prozesse. Open-Source erhält immer mehr Aufmerksamkeit, da die Vorteile und die Flexibilität, die es den Entwicklern bringt, immer mehr Beachtung finden. Gerade im DevOps-Umfeld gewinnt das Thema auch in großen Unternehmen stark an Bedeutung, so auch bei uns.

Durch die zunehmende Automatisierung, die schnelleren Produktzyklen und nicht zuletzt das Outsourcen von ganzen Prozessen in die Cloud tritt das Thema Security auch zunehmend in den Mittelpunkt und Sicherheit hat im Entwicklungslebenszyklus mehr denn je Priorität. Sicherheit wird zur Verantwortung aller und nicht nur der Sicherheitsexperten.

Nicht zuletzt bieten die Automatisierung, Cloud Computing sowie der DevOps-Prozess auch die Möglichkeit, neue Technologien in den Entwicklungsprozess zu integrieren und mithilfe von AI-Tests, Fehlerbehebungen und Problemerkennung durch Machine Learning zu unterstützen und damit den Lebenszyklus der Produkte bei höherer Qualität zu verkürzen.

Categories:

Tags:

Keine Kommentare vorhanden.

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.