Aufrufe
vor 1 Jahr

02 | 2017 public

  • Text
  • Verwaltung
  • Transformation
  • Entwicklung
  • Digitale
  • Unternehmensarchitektur
  • Digitalen
  • Anforderungen
  • Organisation
  • Fachverfahren
  • Mitarbeiter
Schwerpunkt: Agilität und digitale Transformation

WAS IST DEVOPS? Dev Ops

WAS IST DEVOPS? Dev Ops OPERATIONS: ZIELE DES IT-BETRIEBS DevOps ist ein Kunstwort, bestehend aus den Begriffen Development und Operations. Der seit 2008 verwendete Begriff setzt sich zusammen aus dem Wortbestandteil „Dev“, der die Softwareentwicklung (Development) repräsentiert, und „Ops“, der für den IT-Betrieb (Operations) steht. Die Kombination zu „DevOps“ symbolisiert intuitiv einen Schulterschluss zwischen Softwareentwicklung und IT-Betrieb. Und tatsächlich ist das der Grundgedanke von DevOps und der Auslöser der dazugehörigen Bewegung: ein Zusammenrücken der beiden, in der traditionellen Wahrnehmung grundverschiedenen Bereiche Softwareentwicklung und IT-Betrieb. Einerseits ist die Wortschöpfung DevOps sehr griffig. Andererseits birgt sie große Interpretationsspielräume, was zu Missverständnissen führen kann. Aktuell sieht die DevOps-Bewegung ihre Hauptaufgabe darin, die vielen Interpretationen zu kanalisieren und eine klare Definition von DevOps zu formulieren. Um zu wissen, warum dieser Schulterschluss notwendig ist, ist ein Verständnis des zugrunde liegenden Interessenkonflikts zwischen Dev (Entwicklung) und Ops (IT-Betrieb) nötig. DEVELOPMENT: ZIELE DER SOFTWAREENTWICKLUNG Ziele des IT-Betriebs sind Stabilität und Sicherheit der Anwendungen und Infrastruktur durch wenige Releases bis hin zur Release-Vermeidung. Die Aufgabe des IT-Betriebs besteht darin, die von der Entwicklung gelieferten Funktionen in Form von Software auf der Produktivumgebung für die Endnutzer verfügbar zu machen. Dazu zählen das Deployment im Rahmen neuer Software- Releases und gleichzeitig die Sicherstellung des laufenden Betriebs gemäß den definierten Qualitätsanforderungen und Rahmenbedingungen. Der Betrieb trägt also die unmittelbare Verantwortung für die dauerhafte Verfügbarkeit der Anwendungen und deren Sicherheit. Der Erfolg wird daran gemessen, inwieweit die formalen Qualitätsanforderungen erreicht werden – meist in Form von definierten Service Levels und KPI, die in den Service Level Agreements dokumentiert sind. Da der Endnutzer in der Regel die volle Verfügbarkeit und Sicherheit der Anwendungen erwartet, ist es oberste Priorität des IT-Betriebs, diese im Rahmen der Service Levels sicherzustellen. Ziel der Entwicklung ist die Komplettierung neuer Features durch schnelle und häufige Releases. Die Aufgabe von Softwareentwicklern besteht darin, die vom Auftraggeber gewünschten Funktionen und Features möglichst schnell umzusetzen. Durch die Entwicklung wird eine neue Funktion verfügbar, durch die sich ein potenzieller Mehrwert für die Endnutzer ergibt. Je häufiger und schneller neue Features entwickelt und komplettiert werden, desto schneller kann dem Endnutzer also auch ein Mehrwert zur Verfügung gestellt werden. Gleichzeitig bedeutet ein schneller Entwicklungsprozess, zügig auf gesetzliche und Kundenanforderungen reagieren zu können. Daher wird dies in vielerlei Hinsicht positiv wahrgenommen – ebenso wie Entwickler, die diesen Anspruch erfüllen können. Oft wird der Mehrwert einer Funktion allerdings schon bei der ersten Abnahme durch den Auftraggeber anerkannt und nicht erst dann, wenn diese dem Endnutzer letztendlich zur Verfügung steht. Der Grund hierfür ist einfach: Bis zum nächsten Release kann es schon mal ein paar weitere Tage dauern. Dadurch ist es allerdings für die Entwickler auch weitestgehend irrelevant, ob die neuen Funktionen/Features tatsächlich auf dem Produktionssystem verfügbar sind oder nicht. Aus diesen Gründen geht der IT-Betrieb entsprechend vorsichtig mit Veränderungen um. Abhängigkeiten zwischen verschiedenen Software-Deployments werden ausgiebig getestet und Deployments in Release-Paketen gebündelt. Insgesamt werden die Anforderungen an die Dokumentation und Tests sehr hoch angesetzt, bevor es überhaupt zu einem Deployment kommt. Servicebeeinträchtigungen sollen schnell beseitigt beziehungsweise von vornherein möglichst ausgeschlossen werden können. Dies führt zu einer nachweislichen Entschleunigung der anfänglichen schnellen Softwareentwicklung. Die Gründe hierfür sind nachvollziehbar, denn ist die Verfügbarkeit einer Anwendung erst einmal beeinträchtigt, fällt das direkt auf den Betrieb zurück. Die Folge: eine stark negative Wahrnehmung durch die Auftraggeber, besonders wenn die Nutzer der Anwendung ein „Problem“ melden, noch bevor die verwendeten Monitoring-Systeme Alarm schlagen. Um die Wahrscheinlichkeit für unerwartete Ausfälle zu minimieren, setzt der Betrieb deshalb oft alles daran, den Zustand einer stabil laufenden Anwendung vor Änderungen zu schützen: durch wenige, gebündelte und ausgiebig getestete und dokumentierte Releases. 32 | .public 02-17 | Moderne Verwaltung

BLAME GAME: DER TRADITIONELLE KONFLIKT ZWISCHEN ENTWICKLUNG UND BETRIEB Der Vergleich zeigt, dass beide Einheiten entgegengesetzte Anreize haben. Die Entwicklung ist an schnellen und häufigen Releases interessiert, der Betrieb hingegen würde Releases am liebsten vermeiden. Beide Seiten verfolgen damit jedoch das gleiche Ziel, nämlich ihren eigenen Wert für das Unternehmen oder die Behörde unter Beweis zu stellen. Genau das führt aber regelmäßig zu Konflikten, denn in der Regel treffen Dev und Ops unter Zeitdruck aufeinander, zum Beispiel beim Deployment eines neuen Releases, oder wenn es ein Problem, wie beispielsweise einen Systemausfall, gibt. Dann beginnt oft das typische „Blame Game“, bei dem beide Lager sich gegenseitig die Schuld an der Situation geben. Wer solche Situationen noch nicht erlebt hat, kann sich glücklich schätzen. Wer das Blame Game hingegen kennt, weiß: Schuldzuweisungen bringen nichts – die Zeit würde besser in die Lösung des Problems investiert. DER IT-BETRIEB ALS FLASCHENHALS Seit die Softwareentwicklung verstärkt auf agile Methoden setzt, eskaliert die Situation immer häufiger, denn agile Methoden setzen auf kontinuierliche Interaktion zwischen Auftraggebern und Entwicklern sowie auf kurze Release-Zyklen. In der Regel setzt sich die damit einhergehende Philosophie aber nicht in den Betrieb fort. Die Vorteile agiler Methoden werden ausgebremst. Software-Releases werden zwar in kurzen Iterationen erstellt, der geschaffene Mehrwert wird aber erst viel später auf der Produktivumgebung sichtbar. Die immer kürzer werdenden Release- Zyklen offenbaren den Betrieb zunehmend als Flaschenhals auf dem Weg der Software zum Endnutzer. Außerdem erhöhen häufig stattfindende Releases das Potenzial für das direkte Aufeinandertreffen zwischen Softwareentwicklung und Betrieb. Doch nun ist ein neuer Aspekt hinzugekommen, der den Handlungsbedarf besonders in der öffentlichen Verwaltung verschärft und schnelles Umdenken erfordert: die digitale Transformation. DIE TRADITIONELLE UMSETZUNG VON GESETZEN UND VERWALTUNGSPROZESSEN UND IHRER IT-ARCHITEKTUR Blame Game – zwei Beispiele Die Entwicklung gibt ein neues Release zum Deployment an den Betrieb weiter, dem es jedoch nicht gelingt, die Software auf der Produktivumgebung lauffähig zu machen. Als der Betrieb die Entwickler kontaktiert und die auftretenden Fehler beschreibt, blocken diese ab: Die Software laufe auf der Entwicklungsumgebung fehlerfrei, der Fehler müsse beim Betrieb liegen. Beide Seiten schieben sich den schwarzen Peter zu. Nach Krisensitzungen und Unstimmigkeiten zwischen den Abteilungen ergibt eine Untersuchung, dass sich Entwicklungs- und Produktivumgebung in einem wichtigen Detail unterscheiden. Das war keiner der beiden Seiten vorher bewusst. Betrachtet man das bisherige „Geschäftsmodell“ und die IT-Architektur der traditionellen Fachabteilungen in den Behörden und ihrer Behörden-IT, stellt man fest, dass der Fokus bisher vor allem auf der Bereitstellung und dem Einsatz langlebiger Verfahren lag. Zunehmender Kostendruck erforderte jedoch eine Standardisierung der Verfahren. Dies hatte Auswirkungen auf die zugrunde liegende, zumeist monolithische IT-Architektur, um die Verfügbarkeit der Verfahren sicherstellen zu können. Host-Anwendungen und später klassische Datenbank- oder JEE-Anwendungen waren das Maß der Dinge und Basis der sogenannten Systems of Records. Im Produktivsystem taucht ein Performance-Problem auf. Unter großem Druck arbeiten die Entwickler mehrere Nächte durch und liefern schließlich einen Patch. Der Betrieb fürchtet jedoch, dass der Patch die Stabilität des Systems gefährden könnte, da er Änderungen an einer kritischen Komponente umfasst. Deshalb wird zunächst eine genaue Qualitätskontrolle auf einer Testumgebung verlangt, um die Lösung in realistischen Testszenarien zu überprüfen. Doch die benötigte Last lässt sich in der Testumgebung nicht adäquat darstellen. Einen Monat später ist der Patch noch immer nicht eingespielt. Die Entwickler sind enttäuscht, da „es ja offenbar doch nicht so eilig war“. + Rate of Change - DevOps traditionell Systems of Innovation Systems of Differentiation Systems of Records Abbildung 1: Fokus der Release-Strategien im Schichtenmodell der IT-Architektur, Quelle: Gartner - + Governance Moderne Verwaltung | .public 02-17 | 33

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum