Konzeption und Einführung von DevOps in einem mittelständischen IT-Bereich

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 EINLEITUNG
1.1 Motivation
1.2 Unternehmensdarstellung
1.3 Problemstellung
1.3.1 Überleben im digitalen Wandel
1.3.2 Vision Mobile App als Strategiebereiter
1.3.3 Vision 2030 – Mobile, Cloud und Brillen
1.4 Herausforderung
1.5 Zielsetzung
1.6 Vorgehensweise

2 GRUNDLAGEN
2.1 IT-Bereich
2.1.1 IT-Organisation
2.1.2 IT-Infrastruktur
2.1.3 Anwendungsentwicklung
2.1.4 IT-Betrieb
2.2 Continuous Integration
2.3 Continuous Delivery
2.4 Continuous Deployment
2.5 Infrastructure as Code
2.6 DevOps
2.6.1 Historie
2.6.2 CALMS
2.6.3 Mehrwerte

3 ANALYSE DES IT-BEREICHS DER BRILLENMANN AG
3.1 Grundlegendes
3.2 Datenlage und –Erhebung
3.2.1 Interviews
3.2.2 Systemanalyse
3.2.3 Beobachtungen
3.3 Messmethoden & Leistungskennzahlen
3.4 IT-Bereich
3.4.1 Culture
3.4.2 Automation
3.4.3 Lean
3.4.4 Measurement
3.4.5 Sharing
3.5 Bewertung der Ausgangssituation
3.5.1 IT-Organisation
3.5.2 IT-Infrastruktur
3.5.3 Anwendungsentwicklung
3.5.4 IT-Betrieb
3.6 Haupttreiber für DevOps
3.6.1 Projekt- und IT-Betriebsabstimmung
3.6.2 Standardisierung und Qualitätsrichtlinien
3.6.3 Komplexe Release Prozesse
3.6.4 Kommunikationsprobleme

4 KONZEPTION UND EINFÜHRUNG VON DEVOPS
4.1 Strategische und operative Ziele
4.2 Einführungsplanung
4.3 Softwareauswahlprozess
4.4 IT-Organisation
4.4.1 Cross-functional Delivery Team
4.4.2 Early Feedback
4.4.3 Develop for Production
4.4.4 Sync Meeting
4.5 IT-Infrastruktur
4.5.1 Cloud – Platform as a Service
4.5.2 Vagrant
4.5.3 Docker
4.5.4 Chef
4.6 Anwendungsentwicklung
4.6.1 GitHub
4.6.2 Maven
4.6.3 Selenium
4.6.4 Jenkins
4.7 IT-Betrieb
4.7.1 AppDynamics
4.7.2 Service Level Agreements

5 BEWERTUNG DER ERGEBNISSE
5.1 IT-Organisation
5.1.1 (C) Culture
5.1.2 Ergebnisse
5.2 IT-Infrastruktur
5.2.1 (A) Automation
5.2.2 Ergebnisse
5.3 Anwendungsentwicklung
5.3.1 (L) Lean
5.3.2 Ergebnisse
5.4 IT-Betrieb
5.4.1 (M) Measurement
5.4.2 (S) Sharing
5.4.3 Ergebnisse
5.5 SOLL / IST Vergleich

6 ABSCHLUSS
6.1 Probleme
6.2 Ergebnis
6.3 Ausblick

Anhang

Kennzahlen

Metriken

Messungen

Interviewfragen

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Deloitte – Digital Disruption Map

Abbildung 2: Innovations- und Releasezyklen werden kürzer

Abbildung 3: Sinnbildliche Darstellung des Dev – Ops Dilemmas

Abbildung 4: Aspekte eines IT-Bereichs

Abbildung 5: Sichten und Ebenen der IT-Infrastruktur

Abbildung 6: Anwendungsentwicklung eingebettet in den IT-Bereich

Abbildung 7: Stufenbild des IT-Betriebs

Abbildung 8: Continuous Integration Modell

Abbildung 9: Beispielhafte Deployment Pipeline

Abbildung 10: Continuous Delivery Modell

Abbildung 11: DevOps Life Cycle

Abbildung 12: Gartner – Hype Cycle for Application Services, Juli

Abbildung 13: DevOps Mehrwerte

Abbildung 14: Hewlett-Packard – DevOps Maturity Model als Referenz

Abbildung 15: Bewertung der Ausgangssituation (IT-Organisation)

Abbildung 16: Bewertung der Ausgangssituation (IT-Infrastruktur)

Abbildung 17: Bewertung der Ausgangssituation (Anwendungsentwicklung)

Abbildung 18: Bewertung der Ausgangssituation (IT-Betrieb)

Abbildung 19: Bewertung der Ausgangssituation (Gesamt)

Abbildung 20: Zielbild DevOps <-> Ops Dev

Abbildung 21: DevOps Phasenplan zur Toolermittlung

Abbildung 22: DevOps Tool Qualifizierung laut Gartner, Oktober

Abbildung 23: DevOps Tools für die Brillenmann AG

Abbildung 24: Strategische Imperative der Einführung

Abbildung 25: Idealtypischer IT-Bereich

Abbildung 26: Legacy IT, IaaS, PaaS und SaaS Modelle

Abbildung 27: Vagrant – Architektur

Abbildung 28: Docker – Architektur

Abbildung 29: Chef in der Kombination mit Vagrant und Docker

Abbildung 30: GitHub – Version Control

Abbildung 31: Maven – Build Automatisierung

Abbildung 32: Selenium – Code Testing

Abbildung 33: Jenkins – Dashboard mit Statusmeldungen

Abbildung 34: Aspekte des Monitorings

Abbildung 35: Komplexität der Monitoring Struktur

Abbildung 36: SLA Monitoring mit Güteklassen

Abbildung 37: Aspekte einer funktionierenden DevOps Kultur

Abbildung 38: Bewertung des Ergebnisses (IT-Organisation)

Abbildung 39: Bewertung des Ergebnisses (IT-Infrastruktur)

Abbildung 40: Bewertung des Ergebnisses (Anwendungsentwicklung)

Abbildung 41: Bewertung des Ergebnisses (IT-Betrieb)

Abbildung 42: Bewertung des Ergebnisses (Gesamt)

Abbildung 43: Problembereiche bei der Einführung von DevOps

Tabellenverzeichnis

Tabelle 1: Interviewpartner mit Funktion bei der Brillenmann AG

Tabelle 2: Systemanalyse im IT-Bereich bei der Brillenmann AG

Tabelle 3: Beobachtungen im IT-Bereich der Brillenmann AG

Tabelle 4: Definition der Reifegrade

Tabelle 5: Zuordnung der neuen Tools zur Anwendungsentwicklungsphase

Tabelle 6: Definition der Leistungskennzahlen

Tabelle 7: Metriken der Leistungskennzahlen

Tabelle 8: Messungen der Leistungskennzahlen 2014 und 2016

1 EINLEITUNG

„DevOps is not a goal, but a never-ending process of continual improvement” ^[1]

1.1 Motivation

Für viele mittelständische Unternehmen sind die Themen Digitalisierung und der stetig steigende Wettbewerb im digitalen Handel Anlass für die intensive Auseinandersetzung mit der Einführung von neuen Technologien und Methoden.^[2] Gerade die Unternehmen, die historisch erfolgreich waren und sind, müssen sich aus der Komfortzone des wirtschaftlichen Erfolgs heraus intensiv mit der Digitalisierung und der begleiteten IT-Transformation auseinandersetzen, um den zukünftigen Erfolg zu ermöglichen.^[3]

Viele neue, innovative und explorative Geschäftsfelder werden geplant und durch bestehende Ressourcen realisiert. Die Probleme, die sich gerade in Hinblick auf die Einführung von neuer Software und bei deren kontinuierlichen Weiterentwicklung ergeben, sind mannigfaltig, lassen sich nicht sinnvoll mit bestehenden (IT-)Architekturen des Unternehmens realisieren und erfordern einen multidimensionalen Wandel. Vor allem erfordert der Innovationsdruck einen Paradigmenwechsel in der IT. Es gibt ein Spannungsverhältnis zwischen den Mitarbeitern, die Innovationen entwickeln und denen, die diese sinnvoll betreiben müssen.^[4] Es gilt, aus den konkurrierenden Zielen (Innovationen versus Betriebsstabilität) komplementäre Ziele zu schaffen, um dem stetigen Wandel nicht nur zu folgen, sondern ihn gestalten zu können.^[5]

DevOps setzt sich zum Ziel, die Anwendungsentwicklung mit dem IT-Betrieb zu harmonisieren, um Unternehmen in die Lage zu versetzen, schnell und adaptiv auf Änderungen des Markts zu reagieren. Es handelt sich bei der Einführung von DevOps nicht um die Einführung einer Technologie, sondern um eine mehrdimensionale Betrachtung des gesamten IT-Bereichs mit strategischen Ausmaßen.

Im Rahmen dieser Master-Thesis wird DevOps in einem mittelständischen IT-Bereich konzeptioniert und eingeführt.

1.2 Unternehmensdarstellung

Die Brillenmann AG ist ein fiktives deutsches Unternehmen mit Schwerpunkt Augenoptik für Verbraucher. Das Unternehmen wurde im Jahr 1999 von Herrn Peter Brillenmann in Bremen gegründet. Mit derzeit (Stand: Juli 2016) 599 Filialen (etwa fünf Prozent der Optikfachgeschäfte in Deutschland) erzielte Brillenmann 2015 einen Absatzmarktanteil von 50 Prozent und einen Umsatzmarktanteil von 20 Prozent und gilt in der Branche als europäischer Marktführer.

Die Brillenmann AG gab im Jahr 2015 8 Millionen Brillen ab, erzielte einen Außenumsatz von 0,51 Milliarden € und einen Konzernumsatz von 1,30 Milliarden €.

Der Gewinn vor Steuern stieg auf 140,1 Millionen €, der Jahresüberschuss auf 70,5 Millionen €. Die Brillenmann-Aktie notiert im MDAX und der Gewinn pro Aktie erhöhte sich auf 1,97 €. Augenoptikermeister Brillenmann ist Gründer, Mehrheitsaktionär und Vorstandsvorsitzender der Brillenmann AG.

Für die Betrachtung dieser Arbeit sind drei wesentliche Unternehmensbereiche relevant: Der Konzernzentrale in Köln, die Produktion & Logistik in Rathenow und die insgesamt 695 Filialen.

Die Brillenmann AG erwirtschaftet den größten Teil ihrer Umsätze in den Filialen, die aus Gründen der Corporate Identity (kurz: CId) stets das gleiche Ausstattungsmuster befolgen.

Charakteristisch für die Filialen der Brillenmann AG ist es, so wenig IT wie möglich für den Kunden sichtbar zu haben, um den Faktor Mensch beim Verkauf in den Vordergrund zu stellen. Die Brillenmann AG wirbt damit, dass in den Filialen als Unique Selling Proposition (kurz: USP) lediglich Augenoptikermeister, meist selbst ausgebildete Mitarbeiter, als Beratungspersonal arbeiten. Dieser USP war über Jahrzehnte einer der Erfolgsfaktoren der Brillenmann AG. Durch die wenig vorhandene IT und das Befördern des USP hatte und hat die IT einen geringen Stellenwert in den Filialen. Eine Filiale kann de facto ohne IT das Kerngeschäft der Brillenmann AG umsetzen. Lediglich die Zentrale und die Produktion & Logistik sind auf wesentliche Aspekte in der Wertschöpfung auf IT angewiesen. Die Brillenmann AG produziert sowohl für die eigenen Filialen als auch für weitere strategische Partner Brillen in Rathenow. Die Produktion ist eng mit der Zentrale gekoppelt und das Supply Chain Management (kurz: SCM) ist auf SAP-Basis seit 1994 etabliert. Das SCM sorgt dafür, dass alle Aufträge aus den Filialen sowohl zeitnah produziert als auch versendet werden. Jeder Auftrag, der in der Filiale – teilweise noch schriftlich – entgegengenommen wird, wird über die Zentrale in das SCM überführt. Sobald der Auftrag in der Zentrale digitalisiert wurde, wird die Produktion aufgenommen. In der Zentrale werden die Kernsysteme des SCMs betrieben. Darüber hinaus gibt es verschiedene, wesentliche Aspekte für das SCM zu beachten. Die Kundendaten sind ausschließlich in der Datenhoheit der Filialen, da jede Filiale eine eigenständige Gesellschaft in verschiedenen Rechtsformen (GmbH, KG, etc.) darstellt. Somit muss jede Filiale eine eigene Standort-IT vorhalten, die alle Aspekte um die Datenerfassung, Datenhaltung, Datensicherung und den Datenschutz umfasst. Durch diesen Umstand ist die Brillenmann IT in zwei logische Bereiche unterteilt. Der erste Bereich der IT besteht aus der Zentrale und der Produktion & Logistik. Der zweite Bereich umfasst die IT der Filialen. Den IT-Betrieb der beiden Bereiche und des Kern-SCMs übernimmt die IT in der Zentrale in Köln. Das SCM System wird von den gleichen Personen entwickelt, die auch den Betrieb gewährleisten. Darunter fallen auch wesentliche infrastrukturelle Aufgaben, wie die Bereitstellung von IT-Infrastruktur in den Filialen und das Ausrollen neuer SAP-Forms-Entwicklungen. Der IT-Bereich der Brillenmann AG ist auf die Kernelemente der Wertschöpfungskette optimiert. Der Kunde wird in der Filiale, durch einen Augenoptikermeister, beraten und bestellt dann im Anschluss seine Brille. Diese wird in Rathenow produziert und im Anschluss zur Abholung in die Filiale geliefert.

1.3 Problemstellung

Die Brillenmann AG, die sich intensiv mit dem digitalen Wandel beschäftigt, hat festgestellt, dass sich Geschäftsbereiche wandeln müssen, um neue Kundenanforderungen bedienen zu können.^[6] Gemäß einer Studie der Firma Deloitte aus dem Jahr 2015 werden sich bestehende Geschäftsmodelle je nach Branche in den nächsten 5 Jahren massiv wandeln. Dazu hat Deloitte die „Disruption Map“ erzeugt, die Branchen in vier Felder einteilt und zeigt, wie stark sich der digitale Wandel auf das bestehende Geschäftsmodell auswirkt. Wie in Abbildung 5 zu sehen ist, befindet sich der Einzelhandel in dem Quadranten „Kurze Lunte, Großer Knall“. Laut Deloitte muss sich der Einzelhandel im digitalen Wandel auf zeitnahe große Umwälzungen gefasst machen.^[7]

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (Deloitte, 2017)

Abbildung 1: Deloitte – Digital Disruption Map

Auf Basis dieser Erkenntnis gilt es Vorbereitungen zu treffen, den Einzelhandel so aufzustellen, dass er die Digitalisierung als Chance nutzt und nicht versucht sie als Gefahr abzuwehren.

1.3.1 Überleben im digitalen Wandel

Der Vorstand der Brillenmann AG hat bereits im Jahr 2009 beschlossen, eine Unternehmenseinheit zu gründen, die sich intensiv mit dem Thema Digitalisierung beschäftigt. Sebastian Brillenmann, der Sohn des Gründers, hat im Jahr 2009 die Brillenmann Innovation (kurz: BV) gegründet, die sich zum Ziel setzt, die digitalen Märkte für die Brillenmann AG zu erschließen. Die ersten Versuche den E-Commerce Markt zu erreichen, wurden kontrovers diskutiert. Von einer reinen Onlineplattform als Konkurrenz zu den Filialen wurde abgesehen, da der Vorstand einen Imageverlust vermutet.

1.3.2 Vision Mobile App als Strategiebereiter

Im Rahmen eines von der BV geleiteten Innovationsprogramms wurde die Vision Mobile App ins Leben gerufen. Diese bietet genügend Spielraum für Versuche rund um den E-Commerce, ohne das Kerngeschäft der Brillenmann AG, den Brillenvertrieb, zu gefährden. Nach Freigabe des Omni-Channel-Vertriebs wurde die App entwickelt und veröffentlicht. Die App stellt einen Marketplace für Brillengestelle zur Verfügung, in dem sich der Kunde über Kontaktlinsen informieren und diese dann bestellen kann. Sobald er entsprechende Kontaktlinsen über die App bestellt hat, kann er diese im Turnus über die App nachbestellen. Der Benutzer erhält zudem einen Kontaktlinsenpass und kann diesen als digitale ID nutzen.

1.3.3 Vision 2030 – Mobile, Cloud und Brillen

Mit der App wird nicht nur versucht, Kontaktlinsen gewinnbringend zu verkaufen, sondern ein viel größeres Ziel dahinter wird verfolgt. Die Vision 2030 der Brillenmann Innovation besagt, dass in Zukunft die Brillenmann AG über verschiedene Kanäle und Technologien Brillen beraten und verkaufen wird. Auch die IT in den Filialen soll konsolidiert und in Teilen substituiert werden, sodass Beratungsleistung des Augenoptikermeisters weiterhin vor Ort geschieht, aber das ohne (Backend-)IT vor Ort.

Laut einer Gartner-Studie aus dem Jahr 2015 mit dem Titel „The Enterprise App Explosion“ wird davor gewarnt, dass die Einführung von Apps die Marktwahrnehmung des Unternehmens negativ beeinflusst, wenn diese schlecht oder nur halbherzig das Portfolio und die Professionalität des Unternehmens widerspiegeln.^[8]

Die Vision lautet: Die Kunden können mit dem Augenoptikermeister in der Filiale oder außerhalb mit der gleichen App-Technologie Brillen ausprobieren, anpassen und bestellen. Dieser Vorgang soll neue Käuferschichten adressieren. Der demographische Wandel verändert das Kaufverhalten und erfordert die Digitalisierung des Kundenverhältnisses.^[9]

Die Strategie lautet: Durch die Erfahrungen mit der App das Unternehmen neu auszurichten, um so für die weiteren strategischen Maßnahmen aufgestellt zu sein. Der erste Schritt dazu wurde 2012 getan, indem ca. 6.000 iPads im Rahmen des Projekts Zentrale IT (kurz: Zen IT) in die Filialen ausgerollt wurden.

Sebastian Brillenmann geht so proaktiv auf den Markt zu. Er stellt sich bekannten Wettbewerbern, die behaupten: „ So kauft man Brillen heute “.^[10]

1.4 Herausforderung

Die App wurde in der ersten Version im polnischen Markt erprobt, die ersten Erfahrungen im Betrieb gesammelt und ein Resümee der ersten 90 Tage gezogen. In der Quintessenz wurde festgestellt, dass es an verschiedenen elementaren Stellen zu Problemen kommt, die eine weitere Markteinführung verhindern.

Die größten Probleme bestehen im Rollout der Backend Software, die Anbindung an das SCM und der generelle IT-Betrieb der Software durch den IT-Bereich der Brillenmann AG. Darüber hinaus erfordert die APP stetige Innovationen und neue Releases, um sowohl neue Funktionen bieten, als auch neue Endgeräte unterstützen zu können.

Wie in Abbildung 7 zu erkennen ist, werden die Innovations- und Release-Zyklen immer kürzer, sodass laut Crisp-Research davon auszugehen ist, dass sich die Zyklen im Jahr 2020 im Minutenbereich befinden werden.^[11]

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (Crisp-Research, 2015)

Abbildung 2: Innovations- und Releasezyklen werden kürzer

Die Software wurde im Auftrag der Brillenmann Innovation durch eine externe Anwendungsentwicklung erstellt und in den IT-Bereich der Brillenmann AG übergeben. Der externe Auftraggeber wurde mit der Erstellung beauftragt, um schnell Ergebnisse zu erzeugen, um mit dem Ergebnis die internen Stakeholder überzeugen zu können.

Eine Abstimmung mit dem IT-Bereich über Betriebs- und Rolloutszenarien fand nicht in ausreichender Form statt. Darüber hinaus gab es keine Abstimmungen zwischen der externen Anwendungsentwicklung und dem IT-Betrieb, sodass ein Dilemma, wie in Abbildung 8 gezeigt, zum Tragen kam. Das Dilemma besteht darin, dass die Entwickler ohne Absprache Code über die „Wall of Confusion“ werfen, was einen sinnvollen IT-Betrieb und zudem eine sinnvolle Weiterentwicklung der Software unmöglich macht.^[12]

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (theagileadmin.com, 2016)

Abbildung 3: Sinnbildliche Darstellung des Dev – Ops Dilemmas

Der bestehende IT-Bereich war nicht in der Lage, die Software zu betreuen, weder durch die interne Anwendungsentwicklung noch durch den IT-Betrieb. Aufgrund der nicht vorhandenen Betriebsfähigkeit der APP wurde seitens des IT-Vorstands von einem weiteren Ausrollen in den deutschen Markt vorerst abgesehen. Eine generelle Neuausrichtung des Brillenmann AG IT-Bereichs für die Bereitstellung neuer Anwendungen und deren IT-Betrieb wurde im Jahr 2014 mit dem Programm „fit for future“ (kurz: f4f) beschlossen. Das Programm f4f sieht vor, den bestehenden IT-Bereich der Brillenmann AG so aufzustellen, dass neue Software nicht nur in Eigenregie erstellt, sondern auch effektiv betrieben wird.

Ein wesentlicher Bestandteil ist die Reorganisation des IT-Bereichs und die bewusste Einführung von DevOps, um die genannten Probleme zu überwinden.

1.5 Zielsetzung

Es gibt derzeit wenig Fachliteratur zum Thema DevOps. Die vorhandene Fachliteratur fokussiert sich darauf, das Phänomen DevOps selbst und die „best practices“ nach der Etablierung zu beschreiben. Die Vertiefung ist entweder eine intensive Auseinandersetzung mit der Technologie und blendet die organisatorischen Aspekte aus oder es ist genau umgekehrt.^[13]

Laut der Studie der Firma ca Technologies mit dem Titel „ Assembling the DevOps Jigsaw “ haben bereits 72% aller Unternehmen Aspekte von DevOps implementiert, aber lediglich 20% der Unternehmen nutzen die neuen Möglichkeiten um Mehrwerte für das gesamte Unternehmen zu generieren.^[14]

Es fehlt ein Implementierungs-, Betriebs- und Optimierungsframework, das auf belastbaren Erfahrungen beruht. Dementsprechend kommt es bei der Entwicklung von DevOps in der Community kommt es zu verschiedenen Interpretationen und damit auch zu verschiedenen Implementierungsformen, die einander nicht gleichen und unterschiedlich ausgeprägt sind.^[15]

Auf dieser Basis ergibt sich für diese Master-Thesis die Zielsetzung, anhand der empirischen Vorgehensweise folgende Fragen zu klären:

1. Welche Aspekte eines IT-Bereichs müssen für DevOps analysiert werden?
2. Wie sehen sinnvolle Indikatoren für die Analyse aus?
3. Welche Dimensionen müssen berücksichtigt werden?
4. Wie kann der Erfolg nach der Einführung gemessen werden?
5. Welche Erkenntnisse lassen sich für zukünftige Einführungen ableiten?

Die Zielsetzung lautet daher die Fragen im Rahmen der Konzeption und Einführung von DevOps zu beantworten.

1.6 Vorgehensweise

Für die Zielerreichung wird mit drei Phasen geplant:

Analyse

Der IT-Bereich wird unter verschiedenen Fragestellungen analysiert, um herauszufinden, welche wesentlichen Aspekte die Einführung von DevOps behindern, beziehungsweise fördern. Dazu werden Leistungskennzahlen und Metriken entwickelt, die sowohl eine IST-Aufnahme ermöglichen als auch die Entwicklungen, während und nach der Einführung definierter Änderungen, aufzeigen.^[16]

Konzeption & Einführung

Basierend auf den Ergebnissen der Analyse wird DevOps für die Brillenmann AG anhand aktueller Literatur konzeptioniert und die Einführung geplant. Dazu wird neben den organisatorischen Maßnahmen auch ein Softwareauswahlprozess durchgeführt, der die benötigten Tools für DevOps qualifiziert, orchestriert und dokumentiert.^[17]

Abschließende Bewertung

Im Anschluss wird anhand der initial generierten Leistungskennzahlen das Ergebnis – nach Anpassung der Organisation und der Einführung neuer Prozesse und Tools – gemessen und ein entsprechendes Fazit generiert.^[18]

Die Analyse und Konzeption basiert auf bereits vorhandenen Konzeptionen aus Vorprojekten, die sich mit der Einführung agiler Softwaremethoden beschäftigen. Darüber hinaus gibt es Projekte, die einzelne Softwareablösungen im IT-Betrieb vorsehen. Die Projekte wurden allesamt dem neuen Gesamtprojekt f4f zugeordnet.

Die Arbeiten der Analyse und Konzeption begannen im Jahr 2014, initiiert durch den neuen Leiter der Anwendungsentwicklung und werden ihren Abschluss Mitte 2017 erreichen. Die Analyse, Konzeption und Einführung von DevOps setzt sich zum Ziel, die Forschungsfragen anhand der Brillenmann AG zu klären.

2 GRUNDLAGEN

2.1 IT-Bereich

Der IT-Bereich bezeichnet die Gesamtheit aller IT-Aspekte innerhalb eines Unternehmens. Für die Konzeption und Einführung von DevOps wird der IT-Bereich in vier Dimensionen eingeteilt und näher betrachtet: IT-Organisation, IT-Infrastruktur, Anwendungsentwicklung und IT-Betrieb. Die Dimensionen werden hierzu näher erläutert.

2.1.1 IT-Organisation

Die IT-Organisation ist die Leistungseinheit des Unternehmens, die sich vorrangig mit der Verfügbarkeit von IT-Systemen, deren Herstellung, Verwaltung, Überwachung und Weiterentwicklung beschäftigt.^[19] Entscheidend ist ein praktikables Demand-Management mit den Fachabteilungen.^[20] Die IT-Organisation muss nah an den Fachabteilungen, wie in Abbildung 9 zu sehen ist, agieren, um bedarfsgerecht und wirtschaftlich Systeme und Services anbieten zu können.^[21]

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (detecon.com, 2016)

Abbildung 4: Aspekte eines IT-Bereichs

Dementsprechend sollte die IT-Organisation über tiefgehendes Wissen der Wertschöpfung des Unternehmens und der einzelnen Leistungseinheiten verfügen. Dieses Demand-Management bildet neben dem Supply-Management die wichtigsten Funktionen. Das Supply-Management kümmert sich um die Auswahl, Anbindung und Steuerung verschiedener IT-Serviceprovider.^[22] Dabei ist es irrelevant, ob der IT-Serviceprovider eine eigene Leistungseinheit oder ein externer Provider ist. Die IT-Organisation muss den Bedarf in einem wirtschaftlich sinnvollen Rahmen decken.^[23]

Innerhalb der IT-Organisation sind die IT-Strategie- und Governancefunktionen zusätzlich angesiedelt. Einzelne Leistungseinheiten innerhalb der IT-Organisation beschäftigen sich mit der Ausrichtung der IT und des Alignments am Business.^[24] Aus den erlassenen strategischen Imperativen wird das Unternehmen kontinuierlich mithilfe verschiedener Leistungseinheiten mit IT-Services versorgt und durch Changes sukzessive so ausgerichtet, dass IT den gewünschten Mehrwert für das Unternehmen darstellt.^[25]

2.1.2 IT-Infrastruktur

Die IT-Infrastruktur bezeichnet alle materiellen und immateriellen Güter, die den Betrieb von (Anwendungs-)Software ermöglichen.^[26] Die IT-Infrastruktur beschreibt alle technischen Komponenten und zeigt deren Interaktion untereinander. Diese reziproken Einflüsse und deren Auswirkungen auf die Verfügbarkeit der gesamten IT (vgl. Business Continuity Management) werden ebenso im Rahmen der IT-Infrastruktur behandelt als auch Themen wie die Anbindung verschiedener externer Services und deren Nutzung.^[27]

Die IT-Infrastruktur wird in dieser Ausarbeitung aus technischer Sicht betrachtet, wie in Abbildung 10 dargestellt ist.

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (enzyklopaedie-der-wirtschaftsinformatik.de, 2017)

Abbildung 5: Sichten und Ebenen der IT-Infrastruktur

Die einzelnen Elemente können verschiedenen Ebenen zugeordnet werden, um eine entsprechende Übersicht über deren Funktionen zu ermöglichen.

Bauliche Einrichtungen

Die baulichen Einrichtungen umfassen alle Aspekte zum sicheren Betrieb der IT in adäquat ausgestatteten Räumlichkeiten.

Beispiele: Serverräume, USV-Anlagen, Klimaanlagen, Zutrittskontrolle, etc.^[28]

Hardware

Die Hardware Assets umfassen alle Aspekte für die Bereitstellung der Konnektivität innerhalb der Organisation (LAN) als auch organisationsübergreifend (WAN) und die Bereitstellung der Computing- und Virtualisierungsstruktur.

Beispiele: Switche, Router, WLAN Infrastruktur, Server, Storage Systeme, Backupsysteme, etc.^[29]

Systemsoftware

Die Systemsoftware-Komponente umfasst alle Aspekte, die auf der Hardware installiert sind, um eine Hypervisor-Schicht zur Verfügung zu stellen.^[30]

Beispiele: vmware ESX, Microsoft HyperV, OpenStack, etc.

Gastbetriebssystem

Beim Gastbetriebssystem stehen Betriebssysteme im Fokus, die unmittelbar die Bereitstellung von Anwendungssoftware ermöglichen (vgl. Middleware).^[31]

Beispiele: Microsoft Windows (Server), Ubuntu, CentOS, etc.

2.1.3 Anwendungsentwicklung

Die Anwendungsentwicklung ist ein Teil des IT-Bereichs und beschäftigt sich sowohl mit der Herstellung von Software, deren kontinuierlichen Weiterentwicklung als auch mit deren Einbettung in bestehende Softwarearchitekturen.^[32]

Eine Definition von Helmut Balzert beschreibt das Gebiet als

„ Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.“^[33]

Die Anwendungsentwicklung beinhaltet den gesamten Prozess von der Identifizierung des Bedarfs, bis hin zur Inbetriebnahme einer konkreten Anwendung, zum Teil auch darüber hinaus. Hauptgegenstand ist die Bereitstellung und Einführung einer Anwendungssoftware, teilweise zuzüglich der benötigten Hardware und Netzwerke. Die zu implementierende Anwendung kann entweder eine Individualsoftware oder eine Kombination, Anpassung oder Individualisierung von bestehender Standardsoftware (vgl. Microsoft SharePoint) sein.^[34]

Im Rahmen der Anwendungsentwicklung nehmen verschiedenste Informationskanäle, wie in Abbildung 11 zu sehen ist, Einfluss auf die Entwicklung, sodass das angestrebte Produkt die Anforderungen des Unternehmens erfüllt.

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (Balzert, 2008), S.VI

Abbildung 6: Anwendungsentwicklung eingebettet in den IT-Bereich

Die bereitgestellten Basistechniken oder auch IT-Infrastruktur unterstützt sowohl die Informationsgeber als auch die Anwendungsentwicklung.^[35]

Aufgrund des hohen Aufwandes zur Erstellung und Wartung komplexer Anwendungen erfolgt die Entwicklung durch Anwendungsentwickler anhand eines strukturierten Projektplans.^[36] Dieser Plan unterteilt den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen. Die Anwendung wird somit Schritt für Schritt fertiggestellt. Projekte werden oftmals mit externen Dienstleistungsunternehmen, häufig aber auch als Eigenentwicklung geleistet.^[37] Dementsprechend vielfältig sind auch die Vorgehensweisen bei der Projektentwicklung. Von einer sehr strukturierten Herangehensweise (vgl. Wasserfallmodell) über verschiedene Mischformen bis hin zu sehr flexiblen, offenen Methoden wie der agilen Softwareentwicklung (vgl. SCRUM). Entsprechend wird auch zwischen Top-Down- und Bottom-Up-Ansätzen unterschieden.^[38]

Zur Beschreibung des „Standes der Technik“ des Fachgebiets gibt es verschiedene Quellen, darunter den Guide to the Software Engineering Body of Knowledge (kurz: SWEBOK) der Institute of Electrical and Electronics Engineers (kurz: IEEE) Computer Society.^[39]

2.1.4 IT-Betrieb

Der IT-Betrieb übernimmt die laufende Betreuung von kompletten Systemen oder Teilsystemen. Individuelle Anforderungen des Unternehmens soll der IT-Betrieb schnell und zuverlässig umsetzen. Der Betrieb komplexer Systemlandschaften stellt hohe Anforderungen, dementsprechend müssen umfangreiche Leistungen rund um ein komplexes Großsystems oder mehrerer zusammenhängender Systemen erbracht werden. Zu den Leistungen gehören die Verteilung von Anwendungen, die Unterstützung bei der Virtualisierung der IT-Infrastruktur und bei komplexen Migrationsprojekten.^[40] Daneben zählen plattformübergreifend Beratungs- und Schulungsleistungen rund um die Analyse, den Betrieb und die Optimierung von komplexen Systemlandschaften sowie das "Trouble Shooting" in akuten Problemsituationen zu den Kernbestandteilen des Leistungsportfolios.^[41] Die Fachabteilungen profitieren dabei von dem Erfahrungsschatz aus vielen Betriebsprojekten. Unterstützen muss der IT-Betrieb auch mit prozessorientierten Monitoring der komplexen Systemlandschaften im laufenden Betrieb.^[42]

Der IT-Betrieb kann in verschiedenen Ausprägungsstufen geschehen, wie in Abbildung 12 zu sehen ist. Beginnend bei dem rudimentären einfachen „Überwachen und Melden“ (Level 0), das sich lediglich mit der Weitergabe von Störungen beschäftigt, bis hin zum vollumfänglichen Betrieb (Level 3), der sowohl den ganzheitlichen Betrieb als auch die Wartung und Fortentwicklung des Systems im Fokus hat.^[43]

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (it-administrator.de, 2016)

Abbildung 7: Stufenbild des IT-Betriebs

Der IT-Betrieb beschäftigt sich mit allen Tätigkeiten, die erforderlich sind, um den laufenden Betrieb einer Anwendung aufrechtzuerhalten:^[44]

- Ausrollen von Updates
- Identifikation von Fehlern
- Erweiterungsinstallationen
- Datenverwaltung / Datenbereinigung
- Störungsbeseitigung
- Dateireparatur
- Datensicherung und -Wiederherstellung
- Notfallszenarien
- Hard- und Softwarewartung
- Anwenderbetreuung

2.2 Continuous Integration

Continuous Integration (kurz: CI) setzt sich zum Ziel, kontinuierlich neuen Code in die Anwendung zu integrieren. CI ist keine neue Methode, sondern eine Konsolidierung und Neuausrichtung bestehender Methoden, die teils schon Jahre am Markt sind.^[45] Die CI-Methoden entstammen den Methoden des Extreme Programming (kurz: XP). Die Unternehmen, die auf XP-Methoden gesetzt haben, sehen keine Probleme beim Adaptieren von CI.^[46]

Der neue Code sollte, gemäß der CI-Prozesse, oft und kleinteilig integriert werden. Ist eine Integration des Codes nicht erfolgreich und Bugs sind in der Produktion, können Fehler durch die Kleinteiligkeit einfach lokalisiert werden. Falls der Fehler innerhalb einer kurzen Frist nicht behoben wird, muss der Ausgangszustand wiederhergestellt werden, damit die Produktion nicht gestört wird.

Voraussetzung für die häufige und schnelle Ausführung der Integration ist die vollständige Automatisierung des CI-Prozesses. Die Gesamtdauer sollte wenige Minuten (<10 Minuten) betragen. Wenn der CI-Prozess im einstelligen Minutenbereich stattfindet, werden Pretested Commits eingesetzt. Das bedeutet, dass das Build System die Integration sofort nach einem Commit durchführt. Nur wenn der Pretested Commit erfolgreich ist, werden die Änderungen in der Versionsverwaltung aufgenommen.^[47] Im negativen Fall wird der Entwickler automatisch informiert. Alle wichtigen Applikationen müssen dazu in einer Präproduktions- oder Testumgebung verfügbar sein. Techniken wie CI, Testautomatisierung und kontinuierliche Installation erlauben in Kombination mit agilen Methoden die Entwicklung qualitativ hochwertiger Anwendungen.

Software-Build-Jobs auf CI-Servern ermöglichen ein automatisiertes Testen und Erstellen von „Nightly“- oder „Release“-Builds. Üblicherweise wird dafür nicht nur das Gesamtsystem neu gebaut, sondern es werden auch automatisierte Tests (vgl. Continuous Testing) durchgeführt und Softwaremetriken zur Messung der Softwarequalität erstellt.^[48]

Der gesamte Vorgang wird automatisch ausgelöst durch Einchecken in die Versionsverwaltung. Eine vereinfachte Variante der kontinuierlichen Integration – und häufig ihre Vorstufe – ist der Nightly Build (kurz: NB). In der Praxis trifft man auch auf CI, gepaart mit einem NB, um die Vorteile beider Systeme zu kombinieren.

Der essenzielle Ablauf von CI ist, in Abbildung 13, dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (sogeti.de, 2016)

Abbildung 8: Continuous Integration Modell

- Der Entwickler ändert den Code lokal und checkt ihn in das Version Control System (kurz: VCS) ein.
- Der CI-Server startet den Build-Prozess und der Code wird automatisch kompiliert.
- Der CI-Server startet im Anschluss den Commit Test, der eine Reihe von automatisierten Tests durchläuft.
- Der CI-Server untersucht den Code auf die Nutzung der richtigen Konventionen und speichert die resultierenden Binaries für spätere Phasen. Zum Abschluss wird ein Report erstellt, der an den Entwickler gesendet wird.

Hierbei ist zu erwähnen, dass die lokal von Entwickler ausgeführten Tests häufig den nach dem Check-In auf dem zentralen Server laufenden Tests entsprechen.^[49] Dies hat zum einen den Grund, dass, falls die Tests lokal fehlschlagen, der fehlerhafte Code gar nicht erst in das zentrale VCS und damit an andere Entwickler gelangt oder den Entwicklungsprozess aufhält (vgl. Version Control). Zum anderen bedeutet ein erfolgreicher Testdurchlauf auf der lokalen Entwicklermaschine nicht automatisch, dass der Code auf dem häufig produktionsähnlicheren CI-Server ebenso erfolgreich getestet wird.^[50]

Um dies zu erreichen, umfasst CI Folgendes:

- Entwickler führen mindestens einmal am Tag einen Check-In ihres Codes durch
- Der Code wird bei jedem Check-In gebaut
- Code wird bei jedem Check-In automatisch mit Tests getestet
- Jeder hat Zugriff auf den Build und die Testreports
- Der Build ist schnell, sodass Entwickler schnell Feedback bekommen
- Tests werden in einer herunter skalierten Version der Produktion ausgeführt
- Build-Artefakte werden in versionskontrollierten Artefakt-Repositories abgelegt
- Build-Artefakte werden nach jedem erfolgreichen Build automatisch auf eine Testumgebung überführt

2.3 Continuous Delivery

Wenn ein Unternehmen bereits CI-Prozesse implementiert hat, ist die nächste Evolutionsstufe Continuous Delivery (kurz: CD).^[51] Die Ursache für die Entwicklung von CD ist der Wunsch der Unternehmen, regelmäßig und in kurzen Abständen neue Softwarereleases erstellen und veröffentlichen zu können.^[52]

“...our highest priority is to satisfy the customer through early and continuous delivery of valuable software ” ^[53]

Das hat vor allem wirtschaftliche Vorteile: Man kann nach und nach einzelne Features verkaufen. Die Release-Zyklen können mit Hilfe von CD auf wenige Wochen oder sogar Tage verkürzt werden.^[54]

„After all, software doesn’t bring value unless it is deployed in production ; otherwise it’s just inventory. “ ^[55]

Um das zu ermöglichen, wird der gesamte Entwicklungsprozess weiter automatisiert und neue Methoden werden eingeführt. Der Nukleus von CD ist die sogenannte Deployment Pipeline (kurz: DP). Die DP ist ein Prozess, welcher für die Software bzw. das Projekt einen Build erstellt, diesen testet, staged und final deployed, wie beispielhaft in Abbildung 14 zu sehen ist.

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (alphanodes.com, 2017)

Abbildung 9: Beispielhafte Deployment Pipeline

Jeder einzelne Schritt dieser DP muss schnell ablaufen und dem Entwickler sichtbares Feedback liefern, sobald etwas schiefläuft.^[56] Die DP kann bei jedem Projekt etwas anders gestaltet werden.^[57] Die Prozesse sind chronologisch vom Commit bis zum Release angeordnet und sie läuft soweit wie möglich automatisch ab.^[58]

Nur durch schnelles Feedback können Entwickler auch schnell reagieren und den Bug fixen, bevor andere Team-Mitglieder und die Pipeline betroffen werden.^[59] Das Feedback stellt somit im CD-Modell einen wesentlichen Bestandteil dar, der sowohl aus User- als auch Systemfeedback zu betrachten ist.^[60]

Im CD-Modell, wie in Abbildung 15 dargestellt, sind vor allem die folgenden Maßnahmen und Prozesse wichtig:

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (electric-cloud.com, 2016)

Abbildung 10: Continuous Delivery Modell

Um dies zu erreichen, umfasst CD Folgendes:

- Die Software kann den gesamten Lebenszyklus hindurch deployed werden
- Das Team priorisiert das Sicherstellen von auslieferungsfähiger Software über das Umsetzen neuer Features
- Jedes Teammitglied erhält schnelles, automatisiertes Feedback über den Auslieferungszustand der Systeme und zwar jedes Mal, wenn jemand eine Änderung daran vornimmt^[61]
- Das Unternehmen führt bei Bedarf Deployments jeder beliebigen Version der Software per Knopfdruck durch^[62]
- Es gibt eine enge Arbeitsbeziehung zwischen allen, die am Auslieferungsprozess beteiligt sind (vgl. DevOps)
- Umfassende Automatisierungen aller möglichen Bereiche des Auslieferungsprozesses sind umgesetzt, üblicherweise mit der Deployment Pipeline^[63]

CD ist die Fortführung von CI und der Unterschied zwischen den beiden Methoden besteht darin, dass bei CD der komplette Zyklus automatisiert stattfindet. Automatisierung ist gemeinsamer Bestandteil beider Methoden, dennoch ist die Ausprägung bei CD weiter gefasst.^[64] Es kommen bei CD automatisierte Tests verschiedener Ausprägung hinzu. Dieser Schritt ist elementar, da das Produktionssystem sich somit vollständig auf die vorgelagerten Prozesse verlassen muss. Da alles automatisiert ist (Test, Deployment und Infrastruktursetup), ist das Risiko, dass dabei etwas schiefgeht, gering.^[65]

Bei CD kommt hinzu, dass man schnelles und kontinuierliches Feedback (vgl. Continuous Feedback) bekommt. Das Risiko, dass eine Idee für die Fachabteilung nicht funktioniert, ist reduziert, da der IT-Betrieb schnell Feedback bekommt, anstatt erst Tage oder Wochen später.^[66]

2.4 Continuous Deployment

Nach den Evolutionsstufen CI, CD folgt Continuous Deployment (kurz: CDT). CD und CDT haben in der Fachliteratur die gleiche Abkürzung CD und werden entsprechend häufig synonym verwendet.

Es gibt jedoch einen Unterschied zwischen Beiden:

Bei Continuous Delivery legt man fest wann und ob man mit dem Code in die Produktion geht, oder nicht. Bei Continuous Deployment gibt es diese Regelung nicht.^[67]

Jeder erfolgreiche Build resultiert in einem automatisierten Deployment in die Produktion.^[68] Durch Feature Toggles (kurz: FT) ist es möglich, Code in die Produktion zu geben, ohne die neuen Funktionalitäten zu nutzen. Es ist also Code in der Produktion, der noch unfertig ist, aber über den man bereits in der Produktion erste Erfahrungen machen kann. So kann bereits Feedback über das Deployment der neuen Funktionen gesammelt werden.

2.5 Infrastructure as Code

Die Strategie „Infrastructure as Code“ (kurz: IaC) führt den genannten Automatisierungsgedanken konsequent zu Ende.^[69] Sie fordert, dass der Aufbau und die Anpassung der Infrastrukturkomponenten, analog zum Code der zu installierenden Anwendung, ebenfalls einheitlich in einem Versionsverwaltungssystem vorliegen müssen.

Ziel ist es, die Gesamtheit aller Server bzw. Knoten einer Systemumgebung samt Betriebssystem und Systemkonfiguration auf Knopfdruck von Grund auf neu aufzubauen.^[70] Die wiederholt auszuführenden und oft fehlerträchtigen Nacharbeiten an einem frisch installierten System sollen dadurch gänzlich entfallen. Eine deskriptive Beschreibung der Systemumgebungen ermöglicht eine Vielzahl neuer Anwendungsszenarien, die dem DevOps-Gedanken Rechnung tragen.

Der IT-Betrieb kann auf Verlangen der Anwendungsentwicklung relativ schnell eine neue Testumgebung einrichten, die beispielsweise die genaue IT-Infrastruktur der Produktionsumgebung abbildet.^[71] So können die Entwickler eigenständig die Kompatibilität ihrer neuen Softwarestände prüfen und gegebenenfalls Änderungswünsche an den IT-Betrieb frühzeitig melden.^[72]

Mit IaC unterliegt die Provisionierung der Server und aller relevanten Abhängigkeiten einem transparenten Prozess, der allen Beteiligten gleichermaßen zugutekommt.

Zu den wichtigsten Open-Source-Systemkonfigurationswerkzeugen, die IaC umsetzen, zählen Puppet und Chef. Beide Tools verwenden einen ähnlichen Ansatz, in dem der Soll-Zustand eines Rechnerknotens (Ressourcen, Dienste, etc.) mittels einer Programmiersprache deskriptiv festgelegt wird.^[73]

Die Fehlerquote sinkt drastisch, wenn wiederkehrende und aufwendige Aufgaben nicht mehr von Hand ausgeführt, sondern der Maschine überlassen werden.

2.6 DevOps

DevOps ist eine Wortkombination aus den Begriffen Development (englisch für Entwicklung) und IT Operations (englisch für IT-Betrieb).

Die beiden Bereiche sind in der traditionellen Wahrnehmung grundverschieden und verfolgen gegensätzliche Ziele:

Der IT-Betrieb steht für Betriebsstabilität und Kontinuität:

Die Aufgabe des IT-Betriebs besteht darin, die von der Anwendungsentwicklung erzeugte Software in der Produktion für die Benutzer verfügbar zu machen und dazu zählt auch die Verteilung neuer Softwarereleases und die Sicherstellung des laufenden Betriebs.

Der IT- Betrieb trägt die unmittelbare Verantwortung für die Verfügbarkeit der Software.

Der Erfolg des IT-Betriebs wird daran gemessen, inwieweit die gegebenen Qualitätsanforderungen erreicht werden. Die Erwartungshaltung der Benutzer ist in der Regel die volle Verfügbarkeit der Anwendung.^[74]

Die Anwendungsentwicklung steht hingegen für Innovation und Wandel:

Die Aufgabe der Anwendungsentwicklung ist, von den Fachabteilungen gewünschte, Funktionen schnellstmöglich in die Produktion zu führen. Sobald eine neue Funktion verfügbar ist, soll diese für die Benutzer verfügbar sein.

Die Anwendungsentwicklung trägt die Verantwortung möglichst aktuelle Funktionen für die Benutzer zur Verfügung zu stellen.^[75]

Blame Game

Aus diesen konkurrierenden Zielen entsteht das Blame Game. Die Anwendungsentwickler wollen auf Anforderungen der Fachabteilungen reagieren und neue Funktionen in die Produktion geben, der IT-Betrieb sieht aber dadurch die Verfügbarkeit gefährdet.^[76]

DevOps soll durch gemeinsame Anreize, Prozesse und Tools eine effektivere und effizientere Zusammenarbeit der Bereiche Dev und Ops ermöglichen.^[77]

DevOps baut auf der Automatisierung des Anwendungsentwicklungs- und Bereitstellungsprozesses auf. Die Automation und Transparenz sind wichtige Stützpfeiler für die reibungslose Zusammenarbeit der Abteilungen.^[78]

Dabei kann ein effizienter und risikoarmer Bereitstellungsprozess ohne die automatische Ausführung wichtiger Etappen, wie in Abbildung 16 zu sehen ist, wie die des Builds oder des Deployments in einem komplexen Geflecht aus Kollaboration und Verantwortung nicht funktionieren.^[79]

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (trinimbus.com (1), 2016)

Abbildung 11: DevOps Life Cycle

Mit DevOps sollen die Qualität der Software, die Geschwindigkeit der Anwendungsentwicklung und der Auslieferung der Software, sowie das Miteinander der beteiligten Abteilungen verbessert werden. Vor allem in der frühen Phase der DevOps-Bewegung ist die zwischenmenschliche Komponente stark in den Vordergrund gestellt worden. Für viele Vertreter der Bewegung ist gegenseitiger Respekt die dringlichste Verbesserung im Umgang zwischen Anwendungsentwicklung und dem IT-Betrieb, denn er ist eine Voraussetzung für Vertrauen und gute Zusammenarbeit.

Die Entwicklung einer Software wird stark beeinflusst durch einen Mix speziell aufeinander abgestimmter Tools, Infrastruktur und organisatorischer Prozesse. Je besser die beteiligten Teams, Tools und die Infrastruktur aufeinander abgestimmt sind, desto schneller können Organisationen ihre Software in einer besseren Qualität ausliefern.^[80]

2.6.1 Historie

DevOps ist seit 2009 bekannt. Innerhalb weniger Jahre erreichte das Thema DevOps eine enorme Popularität, nicht zuletzt mit der plakativen Nutzung des DevOps-Begriffs durch die Konfigurationsmanagement-Tools Puppet und Chef.^[81] DevOps ist im Gartner Hype Cycle for Application Services zu finden. Der Gartner Hype Cycle. Der Hype Cycle, aus dem Juli 2016, in Abbildung 17 dargestellt, zeigt, dass DevOps den Gipfel der überzogenen Erwartungen (engl. Peak of Inflated Expectations) verlassen hat und nun in Richtung „Tal der Enttäuschungen“ (engl. Trough of Disillusionment) ist.

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (Gartner (2), 2016)

Abbildung 12: Gartner – Hype Cycle for Application Services, Juli 2016

Technologien kommen im Tal der Enttäuschungen an, weil sie nicht alle Erwartungen erfüllen können und schnell nicht mehr aktuell sind. Die Konsequenz lautet, dass sich die Berichterstattung reduziert.^[82]

DevOps ist in vielen Unternehmen angekommen und wird in vielen Success Stories dargestellt. Verschiedene Beratungsunternehmen springen auf den Zug auf und erzeugen eigene Referenzmodelle und Bewertungsmatrizen (vgl. Capgemini DevOps Maturity Model / vgl. Hewlett-Packard DevOps Maturity Model).^[83] Auch die Online Community trug ihren Anteil zur Verbreitung des DevOps-Gedankens bei. Die Erfolgsgeschichte von DevOps ohne ein Framework führen auch zu einer Reihe von Kontroversen.^[84]

Unter anderem diskutiert man über die Frage, ob die Jobbezeichnung „DevOps“ kompatibel zur ursprünglichen Idee ist. Nicht die Schaffung einer neuen Abteilung mit neuen Rollen steht im Vordergrund, sondern vielmehr die bessere Zusammenarbeit bereits existierender Kräfte im Unternehmen.^[85]

2.6.2 CALMS

Die fünf Grundprinzipien des DevOps bilden das Gerüst der Analyse- und Konzeptionierung: Culture, Automation, Lean, Measurement, Sharing.^[86]

Im Detail lassen sich diese Punkte wie folgt erläutern:

Culture

Als kulturelle Basis der Zusammenarbeit lassen sich gegenseitiges Vertrauen, stetiger Informationsfluss und eine anhaltende Bereitschaft zum Lernen beschreiben. Die Kultur setzt sich mit der zwischenmenschlichen Beziehung von Anwendungsentwicklern und Mitarbeiter des IT-Betriebs mittels richtigen Umgangs auseinander.^[87]

Automation

Für eine erfolgreiche Umsetzung ist die Automatisierung bestimmter Arbeitsvorgänge unabdingbar. Sie beginnt bei der Abbildung einfacher wiederkehrender Tätigkeiten und geht bis zur Vollautomatisierung von Aufbau und IT-Betrieb ganzer Umgebungen (vgl. IaC).^[88]

Lean

Lean setzt auf folgenden Prinzipien auf: Vermeide Verschwendung, generiere Wert, schaffe Transparenz und betrachte die Prozessoptimierung ganzheitlich.^[89]

Measurement

„What gets measured gets improved.”^[90]

Eine erfolgreiche Implementierung von DevOps misst alles, so oft es geht: Leistungskennzahlen, Prozesskennzahlen und sogar Metriken von Personen.

Um Qualität durchgängig zu sichern, sind einheitliche Leistungskennzahlen wichtig. Es sollten nicht nur die gesamte Applikation und ihre Komponenten, sondern auch die dahinterliegenden Prozesse überwacht werden. Eine übergreifende kontinuierliche Verbesserung und für beide Abteilungen nachvollziehbare Metriken sind dabei unabdingbar.^[91]

Sharing

Die Bereitschaft, Wissen zu teilen, voneinander zu lernen und Erkenntnisse proaktiv mitzuteilen, sorgt für die notwendige Basis einer klaren Kommunikation und ist ebenfalls ein wichtiger Aspekt der DevOps-Strategie.

In der Folge ist 2012 ein Akronym entstanden, das besagt:

„ Keep C.A.L.M.S. and carry on!” ^[92]

2.6.3 Mehrwerte

Es gibt eine Reihe von Mehrwerten, die sich nach der Einführung von DevOps ergeben:

- Verkürzte Release-Zeiten^[93]
- Erhöhte Release-Zyklen^[94]
- Erfolgreiche Change-Raten
- Erhöhte Stabilität
- Kostenreduktion

Darüber hinaus hat die Firma Puppets Labs im Jahr 2016 die Mehrwerte, wie in Abbildung 18 zu sehen ist, in vier Kategorien aggregiert.

Abbildung in dieser Leseprobe nicht enthalten

Entnommen aus: (Puppet Labs, 2016)

Abbildung 13: DevOps Mehrwerte

Darüber hinaus sagt die Firma ca, in der Studie „The Worst-Kept Secret to winning in the Application Economy“, dass

“DevOps delivers 18% faster time-to-market and 19% better app quality and performance.” ^[95]

3 ANALYSE DES IT-BEREICHS DER BRILLENMANN AG

3.1 Grundlegendes

Die Brillenmann AG beschäftigt 150 Mitarbeiter im IT-Bereich (71 Interne und 79 Externe), darunter Datenbank- und Applikationsentwickler, aber auch Systemadministratoren und Mitarbeiter im Helpdesk. Der Großteil der IT sitzt in Köln und die Vororttätigkeiten in den Filialen werden durch Fulfillment Partner vorgenommen. Das Organigramm (Stand 2013) sieht den IT-Bereich unter dem Finance & Controlling Vorstand. Der IT-Bereich vereint verschiedene Funktionen auf sich, darunter auch die Bereitstellung von Client- und Serverhardware in den Standorten als auch den Rechenzentrumsbetrieb in der Zentrale. Ein wesentlicher Aspekt ist die Trennung zwischen Infrastruktur und Anwendungen mit entsprechenden Unterbauten. Die Abteilung Infrastruktur beherbergt den beschriebenen IT-Betrieb und bildet den Konterpart zur Anwendungsentwicklung, beheimatet in der Abteilung Anwendungen.

[...]

---

^[1] (Humble, J., 2015)

^[2] Vgl. (McKinsey, 2016)

^[3] Vgl. (Forrester (1), 2015)

^[4] Vgl. (Fraunhofer FIT, 2016), S.12

^[5] Vgl. (Deloitte, 2017)

^[6] Vgl. (zukunftsinstitut.de, 2017); Vgl. (etventure.de, 2016)

^[7] Vgl. (Deloitte, 2017)

^[8] Vgl. (Gartner (1), 2015)

^[9] Vgl. (offenbach.ihk.de, 2017)

^[10] (misterspex.de, 2016)

^[11] Vgl. (Crisp-Research, 2015)

^[12] Vgl. (thisiswhatgoodlookslike.com, 2015); Vgl. (Humble, Kim, Willis, & Debois, 2016), S.18f

^[13] Vgl. (techbeacon.com (1), 2017)

^[14] Vgl. (ca.com (1), 2017)

^[15] Vgl. (upguard.com (1), 2017)

^[16] Vgl. (Swartout, 2014), S.112f

^[17] Vgl. (Bass, Weber, & Zhu, 2015), S.102-104

^[18] Vgl. (Swartout, 2014), S.121f

^[19] Vgl. (detecon.com, 2016), S.6

^[20] Vgl. (Fraunhofer FIT, 2016)

^[21] Vgl. (cio.de (2), 2009)

^[22] Vgl. (Hammerström, 2016)

^[23] Vgl. (Johanning, 2014), S.46

^[24] Vgl. (Johanning, 2014), S.95-96

^[25] Vgl. (Johanning, 2014), S.108-109

^[26] Vgl. (enzyklopaedie-der-wirtschaftsinformatik.de, 2017)

^[27] Vgl. (Rudolph, 2009), S.26

^[28] Vgl. (Rudolph, 2009), S.13-15

^[29] Vgl. (Broadbent & Weill, 1998), S.231f

^[30] Vgl. (Rumpel, 2012), S.89

^[31] Vgl. (Rudolph, 2009), S.34

^[32] Vgl. (Brandt-Pook, 2016), S.156

^[33] Vgl. (Balzert, 2008), S.36

^[34] Vgl. (Brandt-Pook, 2016), S.107

^[35] Vgl. (Balzert, 2008), S.12f

^[36] Vgl. (Brandt-Pook, 2016), S.120

^[37] Vgl. (Brandt-Pook, 2016), S.146

^[38] Vgl. (Brandt-Pook, 2016), S.104f

^[39] Vgl. (computer.org, 2017)

^[40] Vgl. (Pfitzinger & Jestädt, 2016), S.19

^[41] Vgl. (Pfitzinger & Jestädt, 2016), S.72

^[42] Vgl. (Pfitzinger & Jestädt, 2016), S.141

^[43] Vgl. (it-administrator.de, 2016)

^[44] Vgl. (Masak, 2006), S.367

^[45] Vgl. (Duvall, Matyas, & Glover, 2007), S.36

^[46] Vgl. (informit.com, 2016)

^[47] Vgl. (Duvall, Matyas, & Glover, 2007), S.41

^[48] Vgl. (Duvall, Matyas, & Glover, 2007), S.129

^[49] Vgl. (perforce.com, 2017)

^[50] Vgl. (perforce.com, 2017)

^[51] Vgl. (Birkner, 2016)

^[52] Vgl. (Humble & Farley, 2010), S.11

^[53] Vgl. (agilemanifesto.org, 2016)

^[54] Vgl. (Humble & Farley, 2010), S.21

^[55] (Debois, 2011)

^[56] Vgl. (Humble & Farley, 2010), S.105-111

^[57] Vgl. (Farcic, 2016), S.93-94

^[58] Vgl. (Farcic, 2016), S.173

^[59] Vgl. (Humble & Farley, 2010), S.308

^[60] Vgl. (Humble & Farley, 2010), S.28

^[61] Vgl. (Humble & Farley, 2010), S.187

^[62] Vgl. (Humble & Farley, 2010), S.66

^[63] Vgl. (Humble & Farley, 2010), S.25

^[64] Vgl. (scrum.de, 2016)

^[65] Vgl. (datical.com (1), 2016)

^[66] Vgl. (collab.net, 2017)

^[67] Vgl. (puppet.com, 2017)

^[68] Vgl. (Amazon Web Services, 2016)

^[69] Vgl. (Morris, 2016), S.10f

^[70] Vgl. (heise.de (1), 2016)

^[71] Vgl. (upguard.com (2), 2017)

^[72] Vgl. (agileweboperations.com (1), 2017)

^[73] Vgl. (avtcloud.com, 2017)

^[74] Vgl. (Peschlow, 2017)

^[75] Vgl. (Bass, Weber, & Zhu, 2015) S.20-23

^[76] Vgl. (midvision.com, 2017)

^[77] Vgl. (Mann, 2016)

^[78] Vgl. (trinimbus.com (2), 2016)

^[79] Vgl. (Bass, Weber, & Zhu, 2015), S.84

^[80] Vgl. (Debois, 2011), S.2-4

^[81] Vgl. (Puppet Labs, 2016)

^[82] Vgl. (Gartner (2), 2016)

^[83] Vgl. (Capgemini, 2016); (Hewlett Packard Enterprise (1), 2016)

^[84] Vgl. (techbeacon.com (2), 2017)

^[85] Vgl. (Humble, Kim, Willis, & Debois, 2016), S.18-22

^[86] Vgl. (Gartner (4), 2016)

^[87] Vgl. (DevOpsGuys Blog, 2016)

^[88] Vgl. (logentries.com, 2016)

^[89] Vgl. (logentries.com, 2016)

^[90] (entrepreneur.com, 2017)

^[91] Vgl. (logentries.com, 2016)

^[92] (newrelic.com (3), 2016)

^[93] Vgl. (ca.com (2), 2016)

^[94] Vgl. (Puppet Labs, 2016)

^[95] Vgl. (ca.com (3), 2016)