GEGENSÄTZE ZIEHEN SICH AN ODER WIE MAN MIT DEVOPS ERFOLGREICH BRÜCKEN BAUEN KANN

Transkript

1 Einleitung und Zielformulierung DevOps hat sich in der IT-Welt der letzten Jahre als populärer Oberbegriff für die notwendige Zusammenarbeit der Softwareentwicklung (Development) und des IT-Betriebs (Operations) etabliert. Inzwischen werden zahlreiche Methoden und Produkte unter diesem Namen entwickelt und vermarktet, obwohl noch kein einheitliches Verständnis zu diesem Thema herrscht. Die DevOps Analysen gehen von der Beschreibung der grundsätzlichen Probleme, die am Übergang zwischen der Softwareentwicklung und dem IT-Betrieb entstehen aus, analysieren mögliche Ursachen dieser Probleme und schlagen anschließend Lösungsansätze mit technischem Schwerpunkt vor. Ziel des vorliegenden Artikels ist, die bisherige Betrachtung von DevOps in der Fachliteratur um eine Perspektive zu erweitern, die bisher nicht im Fokus der Autoren war. Gleichzeitig möchten wir aufzeigen, warum diese Erweiterung notwendig ist, um die wesentlichen Spannungsfelder und Probleme in der Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb identifizieren und lösen zu können. Anschließend geben wir einen Ausblick eines möglichen Lösungsansatzes und zeigen den Mehrwert dieses Lösungsansatzes für die IT-Organisationen auf. Problemstellungen, Ursachen und bisherige Lösungsansätze Bei der Übergabe der entwickelten Software (Applikation) aus der Entwicklung in den IT-Betrieb treten häufig Probleme auf, die mit Hilfe des DevOps Ansatzes adressiert werden sollen. Zu den wichtigsten gehören z.b. 1 : Die Softwareentwicklung und der IT-Betrieb verfolgen konträre Ziele (z.b. Time-to-Market, kurze Release-Zyklen vs. Stabilität und Verfügbarkeit). Die Zuständigkeiten und Verantwortungen in der Wechselwirkung zwischen den beiden Bereichen sind unklar. Der Grad der zugelassenen Flexibilität, bzw. der erforderlichen Standardisierung ist nicht eindeutig definiert. Softwarelösungen werden unreif oder ohne vorherige Abstimmung dem Betrieb übergeben. Bedingt durch die Tatsache, dass IT-Organisationen aktuell mit diesen konkreten Problemen konfrontiert werden, sind in der Fachliteratur auch mögliche Ursachen weitestgehend bekannt 2 : Die immer stärkere Spezialisierung innerhalb der Softwareentwicklung und des IT-Betriebs hat den Nachteil, dass die Fachexperten in eigenständigen Organisationseinheiten arbeiten und somit der Gesamtüberblick verloren geht. Die in den Bereichen gelebten Prozesse basieren oft auf Frameworks, die zueinander nicht passen (z.b. Scrum und agile Methoden in der Softwareentwicklung bzw. ITIL-Prozesse wie Change und Incident Management im IT- Betrieb). Es herrscht eine mangelnde Kommunikation und Kooperation zwischen der Softwareentwicklung und dem IT- Betrieb, da die jeweiligen Aufgaben und Ziele gegenseitig nicht verstanden werden. Folgende Ziele sollen durch die Etablierung der DevOps Philosophie in den IT-Organisationen erreicht werden: Den Time-to-Market für die Release-Zyklen verkürzen. Den Aufwand und die Kosten für die in Produktivnahme, den Betrieb und die Betreuung reduzieren. Proaktiv vor Betriebsstörungen schützen und diese schnell beseitigen. Um die o.g. Probleme und deren Ursachen beheben zu können, werden in der Fachliteratur vor allem technische Lösungen vorgeschlagen, die einerseits zu einem gemeinsamen und einheitlichen Prozess- und Zielverständnis und andererseits zu einer optimierten Abstimmung zwischen der Softwareentwicklung und dem IT-Betrieb führen sollen. So wird z.b. der Einsatz spezieller Kommunikations- und Kollaborationswerkzeuge empfohlen, die das Automatisieren des Release Managements und die Verbesserung der Zusammenarbeit zwischen den Softwareentwicklern und den IT-Administratoren unterstützen. 1 Quelle: Gemeinsam produktiv werden, Udo Pracht 2 Quelle: Gemeinsam produktiv werden, Udo Pracht Robert Schulze (UDF) Cezar Adam (UDF) September 2014 Seite 1 von 6

2 Sicht auf DevOps in der Fachliteratur In der bisherigen Betrachtung von DevOps werden die Begriffe Entwicklung und Betrieb uneinheitlich und mit unterschiedlicher Bedeutung verwendet: a) für die Bezeichnung der Bereiche der Aufbauorganisation und b) als Aufgabenfelder, welche fachspezifische Kompetenzen und Skills zusammenfassen. Um hier Klarheit zu bekommen, stellen wir DevOps aus beiden Sichten kurz dar. Entwicklung und Betrieb als Bereiche der Aufbauorganisation Die Ausarbeitungen zu DevOps gehen davon aus, dass die Bereiche Entwicklung und Betrieb einer IT-Organisation in getrennten Organisationseinheiten angesiedelt sind. Abbildung 1: Entwicklung und Betrieb als Bereiche der Aufbauorganisation Das DevOps Spannungsfeld greift demnach, laut dieser Betrachtung, genau an der Schnittstelle zwischen den Bereichen Entwicklung und Betrieb. Um die IT-Services dem Kunden ohne Einschränkungen bereitstellen zu können, ist eine reibungslose Zusammenarbeit zwischen diesen Organisationseinheiten notwendig. Entwicklung und Betrieb als Aufgabenfelder Bei dieser Sichtweise auf DevOps wird unterstellt, dass die entwickelten Applikationen (Software) auf einer Infrastruktur bereitgestellt und anschließend betrieben werden. Somit werden gemäß dieser Betrachtungsweise auf der (Applikations-) Softwareebene lediglich Entwicklungsaufgaben durchgeführt, während auf der Infrastrukturebene ausschließlich Betriebsaufgaben wahrgenommen werden. Das DevOps Spannungsfeld kommt in diesem Fall bei der Übergabe von Mitarbeitern aus der Softwareentwicklung an Mitarbeiter, welche die Infrastruktur betreiben, zum Tragen. Abbildung 2: Entwicklung und Betrieb als Aufgabenfelder Robert Schulze (UDF) Cezar Adam (UDF) September 2014 Seite 2 von 6

3 GEGENSÄTZE ZIEHEN SICH AN ODER Zusammenlegung der beiden Sichten Aufbauorganisation und Aufgabenfelder Aus der Zusammenlegung der beiden zuvor vorgestellten Sichten resultiert, dass das in der Fachliteratur beschriebene DevOps Spannungsfeld bei der Übergabe einer entwickelten Software aus dem Bereich Entwicklung an die Infrastruktur des Bereiches Betrieb, zustande kommt. Abbildung 3: Zusammenlegung der Ebenen Aufbauorganisation und Aufgabenfelder Unserer Meinung nach, sind diese Sichten auf DevOps unvollständig und demnach nicht ausreichend, um die richtigen Ursachen der Probleme in der Schnittstelle Entwicklung Betrieb identifizieren und lösen zu können. DevOps - integriert im Lebenszyklus-Ansatz von IT-Services Bevor wir den DevOps Lösungsansatz der UDF erläutern, stellen wir eine weitere Sicht im Zusammenspiel EntwicklungBetrieb vor, die in den Ausarbeitungen zu DevOps noch nicht berücksichtigt wurden: der Lebenszyklus von IT-Services. Hier werden Entwicklung und Betrieb als zwei Phasen der Wertschöpfungskette von IT-Organisationen betrachtet, in denen bestimmte Aufgaben, sowohl auf Software- als auch auf Infrastrukturebene, für jede Phase anfallen. Die bisherigen DevOps Analysen lassen, durch die starre Trennung Entwicklung=Software und Betrieb=Infrastruktur, zwei Aufgabenfelder unberücksichtigt: Während der Entwicklungsphase werden verschiedene Aufgaben auch auf der Infrastrukturebene wahrgenommen (z.b. die Bereitstellung von zusätzlichem SAN-Speicher für ein Testsystem). Während der Betriebsphase fallen weiterhin Aufgaben auf der Softwareebene an (z.b. das Einspielen eines Patches). Indem wir den Lebenszyklus-Ansatz von IT-Services mit der aufbauorganisatorischen Sicht von DevOps zusammenführen, stellen wir schnell fest, dass einzelne Organisationseinheiten sowohl Aufgaben während der Phase Entwicklung, als auch während der Phase Betrieb, wahrnehmen können (z.b. die Organisationseinheiten E1 und B1 in der Abbildung 5). Abbildung 4: DevOps und der Lebenszyklus-Ansatz von IT-Services Robert Schulze (UDF) Cezar Adam (UDF) September 2014 Seite 3 von 6

4 Durch die zusätzliche Betrachtung des Lebenszyklus von IT-Services, kann das DevOps Spannungsfeld weiter präzisiert werden: Flexibilität vs. Stabilität als konträre Zielsetzungen beim Phasenübergang aus der Entwicklungsphase in den Betrieb. Oft ist die Abstimmung bezüglich der zu übergebenden Produktreife unpräzise. Es treten Kommunikationsprobleme zwischen den Organisationseinheiten der Software- und Infrastrukturebene auf, da Zuständigkeiten und Verantwortungen nicht geklärt sind und eine Grauzone zwischen den Aufgaben der beiden Bereiche existiert. Der DevOps Lösungsansatz von UDF In der folgenden Abbildung ist die in den heutigen IT-Organisationen geschätzte Verteilung der Aufwände in FTE 3 für Entwicklungs- und Betriebsaufgaben auf der Software- und Infrastrukturebene beispielhaft visualisiert. Selbstverständlich können diese Werte je nach Art der angebotenen IT-Services variieren und sollten in erster Linie der Veranschaulichung dienen. Abbildung 5: Geschätzte Verteilung der Aufwände nach Entwicklungs- und Betriebsaufgaben auf den Ebenen Software und Infrastruktur Die obere Abbildung stellt die wesentliche Ursache der DevOps Problematik in den IT-Organisationen dar: In der Entwicklungsphase ist unabhängig von der Art der angebotenen IT-Services der größte Anteil der FTE für Softwareentwicklungsaufgaben tätig und verfolgt demnach die Ziele Time-to-Market und möglichst viele Releases. Dagegen ist die Mehrheit der FTE in der Betriebsphase mit dem Betrieb der IT-Infrastruktur beschäftigt und verfolgt die Ziele Stabilität und Verfügbarkeit. Die Kernaufgabe von DevOps ist unserer Meinung nach, die effiziente und reibungslose Verknüpfung der Entwicklungs- und Betriebsaufgaben (Aufgabenfelder) über die gesamte IT-Wertschöpfungskette (Ablauforganisation) mit den Organisationsstrukturen des Unternehmens (Aufbauorganisation). Diese Aufgabe stellt gleichzeitig eine der größten Herausforderungen in den heutigen IT-Organisationen dar. 3 FTE= Vollzeitäquivalent Robert Schulze (UDF) Cezar Adam (UDF) September 2014 Seite 4 von 6

5 Auch, wenn die Entwicklung und der Betrieb auf den ersten Blick konträre Ziele verfolgen, haben sie in der Regel ein übergeordnetes, gemeinsames Ziel: dem internen und/oder externen Kunden so effektiv und effizient wie möglich, sowohl individuelle als auch Standard IT-Services, gemäß seiner Qualitätserwartungen bereitzustellen. Durch die immer komplexeren und facettenreicheren IT-Anwendungen und Infrastrukturen, erweist sich für die IT-Organisationen die Erreichung dieses Ziels als immer schwieriger. Darüber hinaus sind für das Erreichen des Ziels folgende Voraussetzungen notwendig: In der Ablauforganisation herrscht ein gemeinsames Prozessverständnis zwischen Entwicklung und Betrieb. Die Entwicklungs- und Betriebsaufgaben, sowohl auf Software- als auch auf Infrastrukturebene, sind entlang der gesamten Wertschöpfungskette identifiziert und transparent beschrieben. Für diese Aufgaben sind die Zuständigkeiten und Verantwortungen klar definiert und zugewiesen. Diese grundlegenden Voraussetzungen bilden den Kern des DevOps Lösungsansatzes von UDF: die Flexibilisierung der IT-Organisation mit Hilfe von Servicemodellen. Ein Servicemodell ist ein in der IT-Organisation festgelegtes Strukturmodell, welches die Zusammensetzung der Fähigkeiten und Ressourcen der Aufbau- und Ablauforganisation, abhängig von der Art des angebotenen IT-Services, organisiert. In den folgenden Abbildungen sind zur Erläuterung der Unterschiede zwei mögliche Beispiele für Servicemodelle abgebildet: ein -Standardservice bzw. ein Full Service für eine Individualsoftware. Abbildung 6: Verteilung der Aufwände nach Entwicklungs- und Betriebsaufgaben anhand der Servicemodelle - Standardservice und Full Service Der -Standardservice ist eine hoch standardisierte Dienstleistung der IT-Organisation, die von vielen Kunden genutzt wird. Der höchste Anteil der Aufgaben (geschätzt bei 80 bis 90%) fällt, sowohl in der Entwicklungs- als auch in der Betriebsphase, auf der Infrastrukturebene an. Demnach sind entsprechende Fähigkeiten und Skills der Mitarbeiter erforderlich. Da die hohe Verfügbarkeit und die Stabilität des Systems im Vordergrund stehen, gehören das Pflegen und die Wartung der Infrastruktur zu den Hauptaufgaben dieses Servicemodells. Um dieses Servicemodell anzubieten, werden in der Ablauforganisation standardisierte Prozesse (z.b. Incident Management, Request Fulfillment) sowie in der Aufbauorganisation spezialisierte Funktionen (z.b. ein Service Desk) benötigt. Andererseits ist der Full Service für eine Individualsoftware eine hoch spezialisierte IT-Dienstleistung, wo der Hauptanteil der Aufgaben (ca. 70 bis 80%) auf der Softwareebene erbracht wird. Neben den reinen Entwicklungsaufgaben (Programmierung), fallen hier auch Aufgaben wie z.b. Beratung und Konzepterstellung, Angebotserstellung, Robert Schulze (UDF) Cezar Adam (UDF) September 2014 Seite 5 von 6

6 Datenmodellierung an, die sehr unterschiedliche Skills von den Mitarbeitern erfordern. Da die Softwareentwicklung unter Umständen ganz tief in die Infrastruktur hineingreifen kann (z.b. auf der Datenbank- oder Middleware-Ebene), werden bei diesem Servicemodell schlanke Prozessabläufe (z.b. agile Softwareentwicklung) in der Ablauforganisation und Teams mit breitem Fachwissen in der Aufbauorganisation benötigt. Servicemodelle helfen an dieser Stelle, den komplexen Ablauf von der Kundenanforderung, über die Erstellung der Services in der Entwicklungsphase, bis zur Wartung der Infrastruktur und der Software in der Betriebsphase, auf den drei identifizierten Ebenen (Aufgabenfelder, Aufbauorganisation, Ablauforganisation) sinnvoll zu organisieren und somit die Wertschöpfung der IT-Services zu optimieren. Durch die Definition und Etablierung von Servicemodellen, werden die zuvor beschriebenen Ziele von DevOps erreicht und darüber hinaus auch weitere Vorteile für die IT-Organisation generiert: Servicemodelle helfen die komplexen Abläufe bei der Service Erbringung zu strukturieren, indem sie Leistungen ähnlicher IT-Services bündeln und in gleicher Weise organisieren. Somit kann der Time-to-Market der einzelnen Release-Zyklen erheblich verkürzt werden sowie die Störungen im Betrieb schnell beseitigt werden. IT-Organisationen können mit Hilfe von Servicemodellen ein differenziertes Serviceportfolio flexibel und kostengünstig betreiben. Das führt gleichzeitig zur Reduzierung des Aufwands und der Kosten für die in Produktivnahme, den Betrieb und die Betreuung von IT-Services. Servicemodelle können, sowohl für die Analyse bestehender IT-Services mit vorhandener IT-Architektur als auch für neue oder zu ändernde IT-Services mit neuer oder zu erweiternder IT-Architektur, eingesetzt werden. Mit Hilfe von Servicemodellen kann eine IT-Organisation strategische Vorgaben organisieren und weiterhin flexibel auf Kundenbedürfnisse und Anforderungen reagieren. Die Art und Weise wie eine IT-Organisation ihre Servicemodelle definiert und den Kunden zur Verfügung stellt, hängt sehr stark von der Geschäftsstrategie und vom Serviceportfolio ab. Schlussfolgerung Aufgrund unserer langjährigen Projekterfahrung in IT-Organisationen unterschiedlicher Größe und Organisationsstruktur, konnten wir die wichtigsten Herausforderungen der Unternehmen in Bezug auf DevOps miterleben. Um DevOps effizient einzuführen, sind wir der Meinung, dass Unternehmen sich als Erstes mit den ablauf- und aufbauorganisatorischen Wechselwirkungen zwischen Entwicklung und Betrieb auseinandersetzen müssen, bevor Sie Geld und Zeit in zusätzliche Werkzeuge investieren. Erst wenn die Entwicklungs- und Betriebsaufgaben entlang der Wertschöpfungskette klar und transparent mit den entsprechenden Verantwortungen und Zuständigkeiten zugeordnet und gelebt werden, sind die Voraussetzungen erfüllt, um im nächsten Schritt auch technische Optimierungen mit hoher Erfolgswahrscheinlichkeit zu initiieren. Für weitere Fragen oder ein persönliches Gespräch stehen Ihnen unsere Berater gerne zur Verfügung! Robert Schulze Telefon: Cezar Adam Telefon: Robert Schulze (UDF) Cezar Adam (UDF) September 2014 Seite 6 von 6