Ansätze im Überblick

Agile und DevOps – Gegner oder Freunde?
Keine Kommentare

Agile und DevOps sind Konzepte und Trends gleichermaßen. Sie stehen für eine maximale Flexibilisierung der Projektarbeit und das Zusammenwachsen von Development und Operations. Gibt es eine Schnittmenge zwischen diesen beiden Ansätzen?

Die agile Vorgehensweise – mit dem Ziel einer geplanten Flexibilität des Entwicklungszyklus – und DevOps – als die Zusammenarbeit von Development und Operations – sind umfassende Bausteine einer Transformation der Informationstechnologie im Allgemeinen und der Softwareentwicklung als wichtige Teildisziplin im Speziellen. In vielen Beiträgen findet man agile Methoden ausführlich beschrieben. Es gibt kaum einen Entwickler, der damit noch nicht in Berührung gekommen ist. Ausgangspunkt war die Notwendigkeit, den Entwicklungsprozess deutlich flexibler zu gestalten. Statt mit ungeplanten Überraschungen durch sich ändernde Anforderungen konfrontiert zu sein, wollte man sich auf diese Ereignisse bestmöglich vorbereiten und damit die Änderung zur Norm erklären. Eine ähnlich simple Erklärung gibt es für DevOps. Konnte man traditionell die Entwicklung einer Software (Development) von ihrem Betrieb (Operations) trennen, ist das schon lange nicht mehr zeitgemäß. Sich immer weiter verkürzende Releasezyklen erfordern ein Zusammenarbeiten über die Grenzen der eigenen Abteilung hinaus. DevOps können wir also verkürzend als eine Kulturrevolution der gesamten IT-Landschaft begreifen. Und an welcher Stelle ist die Schnittmenge zwischen beiden Konzepten? Das wollen wir hier untersuchen. In einer zweiteiligen Artikelserie wollen wir die Zusammenhänge zwischen agilem Vorgehen und DevOps-Ansatz herausarbeiten.

Nach einem kompakten Überblick über die agilen Methoden skizzieren wir den Grundgedanken der DevOps-Bewegung, die mehr mit Organisation als mit Technik zu tun hat. Anschließend geht es darum, die Schnittmengen beider Konzepte herauszuarbeiten und zu erkennen, an welcher Stelle die Chancen, aber auch mögliche Stolpersteine der Zusammenarbeit liegen. Beginnen wir mit den agilen Methoden der Softwareentwicklung.

Flexibilität durch agile Methoden

Bekanntermaßen ist die strikte Abarbeitung eines Entwicklungsvorhabens streng nach Phasen gestaffelt eher schwierig. Das Hauptproblem besteht darin, dass eine vollständige und korrekte Erhebung der Anforderungen zu Projektbeginn nahezu unmöglich ist. Das hat mehrere Ursachen. Die wichtigsten sind:

  • Unvollständigkeit der Anforderungen zu Beginn des Projekts

  • dynamische Änderungen in den Geschäftsmodellen während der Projektlaufzeit

  • lange Projektlaufzeiten, teilweise über mehrere Jahre

Es ist eine Tatsache, dass auch die Kunden und späteren Nutzer einer Software oft nur eine ungefähre Vorstellung davon haben, in welcher Form die Software das bestehende Problem lösen soll. Darüber hinaus ist es schwierig, den Entwicklern der Software diese ungefähren Anforderungen zu vermitteln, sie beispielsweise für diesen Zweck auch vollständig und nachvollziehbar zu dokumentieren. Ein weiteres Problem ergibt sich aus der Dynamik der Geschäftsmodelle: Anforderungen und Rahmenbedingungen, die zum Zeitpunkt der erstmaligen Analyse gelten, sind nicht über die gesamte Projektlaufzeit konstant. Dabei ist zu beobachten, dass das Ausmaß an Dynamik im Laufe der Zeit zunimmt. Da die zu erstellenden Anwendungssysteme immer komplexer und umfangreicher werden, nehmen auch die Laufzeiten der Projekte zu. Das wirkt sich ebenso negativ auf die Möglichkeiten einer umfassenden Planung aus. Je länger die Zeitspanne zwischen dem Projektstart und der endgültigen Bereitstellung der Software ist, desto schwieriger wird es, die dann geltenden Kundenanforderungen zu erfüllen.

Die agilen Methoden sind nicht vom Himmel gefallen, sondern die Folge einer längeren zeitlichen Entwicklung (Abb. 1).

Abb. 1: Entwicklungsmethoden in zeitlicher Folge

Abb. 1: Entwicklungsmethoden in zeitlicher Folge

In den 1980er und frühen 90er Jahren wurde großen Wert auf sorgfältige Projektplanung und formalisierte Qualitätssicherung gelegt. Die Entwicklung erfolgte oft in großen Teams. Im Ergebnis wurde oft mehr Zeit für die Planung aufgewendet als für die tatsächliche Programmentwicklung und die nachfolgenden Tests. Trotz dieses sehr planvollen und stark phasengetriebenen Vorgehens waren die Ergebnisse nicht immer zufriedenstellend. Zu viele Projekte scheiterten oder konnten die Anforderungen und Wünsche der Kunden nicht erfüllen. Als Reaktion wurde ab Mitte der 1990er Jahre erstmals von agilen Methoden gesprochen. Das Ziel war schnell formuliert: Die Entwickler sollten sich verstärkt um ihren eigentlichen Job, die Programmentwicklung, kümmern und nicht mehr so viel Zeit für Entwurf und Dokumentation aufwenden. „Agilität“ steht also für die Fähigkeit, mit Änderungen umzugehen, d. h. schnell und flexibel auf Kundenanforderungen zu reagieren. Änderungen werden nicht mehr als störend aufgefasst, sondern tragen dazu bei, dass das Anwendungssystem frühzeitig in die richtige Richtung gesteuert wird. Ein wesentliches Ziel dieses Vorgehens ist es, in möglichst kurzer Zeit eine erste Version des späteren Endprodukts an den Kunden auszuliefern und schon in sehr frühen Phasen des Entwicklungsprozesses mit Prototypen zu arbeiten. Frühe produktionsfähige Produktversionen sind zwar im Funktionsumfang eingeschränkt, geben jedoch den Anwendern die Möglichkeit, rechtzeitig Feedback zu geben. Dieses Feedback ist wiederum die Ausgangsbasis, um mögliche Modifikationen zeitnah in den weiteren Projektverlauf einzuarbeiten.

Es gibt unterschiedliche Ansätze agiler Entwicklungsmethoden. Scrum gilt heute als sehr weit verbreitet, hat sich vielfach bewährt und ist weithin akzeptiert und stellt zusammen mit Extreme Programming die bekannteste agile Methode dar.

Extreme Programming – oder kurz XP – wurde in den Jahren 1995 bis 2000 von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt. Der Name wurde dadurch geprägt, dass die gut bekannten Praktiken, beispielsweise iterative Entwicklung, „ins Extreme“ gesteigert wurden. Mit XP ist es möglich, mehrere neue Versionen eines Programms an einem Tag zu entwickeln, zu integrieren und zu testen. Ziel ist es, die Entwicklung der Software den gegebenen Bedingungen anzupassen und diese fortlaufend zu verbessern. Die Anforderungen werden in Form von User Stories zusammengefasst und anschließend als eine Folge von Aufgaben implementiert. Welche User Story als nächste in ein Release aufgenommen wird, wird auf Basis der zur Verfügung stehenden Zeit und der zugeordneten Priorität entschieden. Großen Wert wird auf paarweise Zusammenarbeit, d. h. Pair Programming, gelegt. Ergebnisse werden auf diese Weise sofort überprüft. Mit Ihrem Programmierpartner unterstützen Sie sich jederzeit gegenseitig. Statt erst Programmcode zu schreiben und dann umfangreich nach möglichen Fehlern zu suchen, dreht man den Spieß einfach um. Bevor man zum Code schreiben übergeht, werden Tests für die einzelnen Aufgaben entwickelt. Die sollen mit Erfolg abgeschlossen werden, bevor neuer Code in das System integriert wird. Nach Fertigstellung einer Aufgabe ist sie auch sofort in das System zu übernehmen. Diese Art des Vorgehens wird als Test-driven Development bezeichnet. Die Prinzipien von XP sind daher: inkrementelle Planung, einfacher Entwurf und kleine Releases, kollektives Arbeiten, Pair Programming, Test-driven Development und Kunden vor Ort. Mit dem letzten Aspekt ist gemeint, dass ein Kundenbevollmächtigter am Entwicklungsprozess kontinuierlich beteiligt ist und dem XP-Team ständig zur Verfügung steht. Er ist dafür verantwortlich, dem Team die Systemanforderungen mitzuteilen und Akzeptanztests für das System durchzuführen. Der Kunde arbeitet gewissermaßen aktiv am Projekt mit.

Scrum ist die am häufigsten angewandte agile Methode, die als Rahmenwerk für agile Prozesse bekannt ist. Wir stellen sie etwas ausführlicher vor. Dabei handelt es sich nicht um ein Modell, das das agile Vorgehen konkret beschreibt bzw. konkrete Techniken vorgibt. Scrum gibt nur den Rahmen vor. Der Begriff „Scrum“ stammt aus der Sportart Rugby. Dabei stehen sich zwei gegnerische Mannschaften gedrängt gegenüber („Scrum“ = „Gedränge“) und versuchen, den Ball zu erkämpfen. Ein selbstorganisiertes Entwicklerteam steht im Mittelpunkt von Scrum. Der Scrum Master bildet eine Schnittstelle zwischen dem Team und den Produktverantwortlichen. Er sorgt dafür, dass der Entwicklungsprozess reibungslos abläuft. Die Idee ist, dass bei umfangreichen Projekten der Erfolg nur durch regelmäßiges Feedback zu erreichen ist. Dadurch werden die Abweichungen vom Soll schnell erkannt und notwendige Anpassungen ermöglicht. Die gesamte Entwicklung wird in Iterationen mit einer Dauer zwischen einer und vier Wochen strukturiert und durchgeführt. Diese Iterationen werden als Sprints bezeichnet. Die Sprints haben eine feste Dauer und enden unabhängig davon, ob die Aufgabe abgeschlossen werden konnte oder nicht. Die Produktanforderungen des Kunden werden vor dem Sprint in einem Product Backlog gesammelt, das fortlaufend vervollständigt wird. Das Team entscheidet über die Priorisierung der Anforderungen bzw. Aufgaben.

Jeder Sprint endet mit der Überprüfung der Ergebnisse (Sprint Review) und Reflexion der Prozesse (Sprint Retrospective). Am Ende jedes Sprints steht eine lauffähige, getestete und inkrementell verbesserte Software zur Verfügung. Scrum unterscheidet zwischen drei Rollen: Der Product Owner repräsentiert in Scrum die Kundenbedürfnisse. Im besten Fall handelt es sich um den Kunden selbst oder einen vom Kunden bevollmächtigten Vertreter. Er trifft eigenständig und zügig qualifizierte Entscheidungen über das Produkt. Er steuert die Softwareentwicklung und arbeitet mit dem Team während des ganzen Projekts eng zusammen. Der Product Owner koordiniert die Kundenanforderungen und priorisiert sie im Product Backlog. Er definiert Anforderungen und deren Akzeptanzkriterien und nimmt die Arbeitsergebnisse des Teams ab. Der Scrum Master ist der Coach des Teams. Er hilft den Teammitgliedern, Scrum richtig einzusetzen. Dabei ist seine Rolle umso wichtiger, je weniger Erfahrung das Team mit Scrum hat. Der Scrum Master hat im Projekt keine spezifischen Verantwortlichkeiten und Aufgaben, die unmittelbar mit der Umsetzung desselben zu tun haben. Wenn ein Scrum Master seine Arbeit gut macht und das Team richtig zusammenarbeitet, wird er kaum noch benötigt. Das Team hilft sich in allen Situationen selbst. Das Entwicklerteam hat die zentrale Rolle, da es alle Arbeiten ausführt, die zur Umsetzung der Anforderungen notwendig sind. Es ist von Vorteil, wenn die Mitglieder in einem Scrum-Team über ein breites Spektrum an Wissen verfügen. Dieses Wissen darf sich nicht in den Köpfen von Spezialisten konzentrieren, sondern es muss gemeinsames Wissen des gesamten Teams sein oder werden. Die Teammitglieder bezeichnet man auch gerne als „generalistische Spezialisten“. Das Team organisiert sich selbst (Empowered Team), d. h. es entscheidet über eine Vielzahl von Dingen selbstverantwortlich. Hierdurch entsteht eine höhere Identifikation mit dem Projekt und das Verantwortungsgefühl steigt. Insbesondere schätzt das Team selbst die Aufwände für die einzelnen User Stories, und es übernimmt die Verantwortung dafür, dass diese richtig konzipiert sind. Ein wichtiger Punkt ist das Commitment im jeweiligen Sprint auf bestimmte User Stories. Dabei entscheidet das Team, welche und wie viele User Stories es im nächsten Sprint umsetzen kann. Jeder Mitarbeiter kann unabhängig von seiner Position eine der drei Rollen annehmen.

Ein zentrales Merkmal von Scrum ist das feste Inventar von regelmäßigen, kompakten und ergebnisorientierten Meetings. Das sogenannte Sprint Planning ist das Startmeeting für den jeweiligen Sprint und wird in zwei Schritten ausgeführt, nämlich der Festlegung des Inhalts des nächsten Sprints und der Erstellung des Sprint Backlogs. Die Sprint Review wird am Ende jedes Sprints durchgeführt und dient zur Überprüfung und Abnahme des Produktinkrements durch den Product Owner. Dabei muss das Team die Ergebnisse präsentieren und zeigen, dass die von ihm entwickelten Features funktionieren. Durch die regelmäßige Durchführung bekommt es immer sofort ein Feedback und eine Entwicklung in die falsche Richtung kann ausgeschlossen werden. Die Sprint Retrospective zielt im Gegensatz zur Sprint Review auf eine Analyse der Zusammenarbeit während des vorangegangenen Sprints ab. Es ist für die Qualität nicht nur wichtig, dass die Features auch funktionieren, sondern es ist für alle Beteiligten auch äußerst interessant, wie Sie die Ergebnisse erreicht haben. Welchen Programmieransatz haben Sie gewählt? Gibt es vielleicht eine einfachere Lösung zum Ziel? Aus der gemeinsamen Betrachtung zieht man Schlüsse für den nächsten Sprint. Daily Scrums sind tägliche 15-minütige Meetings des Teams unter Beteiligung des Scrum Masters und eventuell des Product Owner. Sie dienen hauptsächlich dem Informationsaustausch des Teams untereinander. Hier wird Ihnen meist kein Sitzplatz zur Verfügung gestellt. Ganz im Sinne der Dynamik und der effizienten Arbeitsweise erfolgt die kurzfristige Zusammenkunft meist im Stehen. Eine Tasse Kaffee ist aber erlaubt.

Grundsätzlich verfolgt jedes Scrum-Meeting das Ziel, die Ergebnisse zu analysieren und die daraus resultierenden Anpassungen unmittelbar umzusetzen. Ein wichtiges Kriterium für den Projekterfolg ist die Teamarbeit. Eine weitgehend reibungslose Zusammenarbeit zwischen den Teammitgliedern wird angestrebt. Bei der Teamgröße sollte man sich daher auf maximal zehn Mitglieder beschränken. Bewährt haben sich Teilteams von durchaus nur sechs Mitgliedern. Diese müssen Programmier-, Projekt- und Teamerfahrung haben. Die Kernfeatures von Scrum sind in Abbildung 2 dargestellt.

Abb. 2: Scrum als bekannteste agile Methode [1]

Abb. 2: Scrum als bekannteste agile Methode [1]

Einige weitere agile Methoden im kurzen Überblick:

  • Unified Process: Es handelt sich um ein iteratives und inkrementelles Framework für Softwareentwicklungsprozesse. Die bekannteste und umfassend dokumentierte Verfeinerung des vereinheitlichten Prozesses ist der Rational Unified Process.

  • Feature-driven Development (FDD): Eine Sammlung von Methoden, Arbeitstechniken, Strukturen und Rollen für das agile Projektmanagement, die den Begriff Feature in den Mittelpunkt stellen; die gesamte Entwicklung wird anhand eines Featureplans organisiert und umgesetzt.

  • Agile Model-driven Development (AMDD): Ist eine agile Version des Model-driven Developments (MDD), ein Ansatz zur Softwareentwicklung, bei dem umfangreiche Modelle erstellt werden, bevor der Quellcode geschrieben wird; bei AMDD erstellen Sie nur minimale Modelle. Diese müssen gerade noch gut genug sein, um die Entwicklung voranzutreiben.

  • Dynamic Systems Development Method (DSDM): Dabei handelt es sich um eine Erweiterung des Rapid-Application-Development-Ansatzes, die die kontinuierliche Einbindung der Anwender betont. Die Methode wurde ursprünglich in den 1900er Jahren in Großbritannien durch das DSDM-Konsortium geschaffen und wird heute noch weiterentwickelt und erfolgreich eingesetzt.

Nach diesem kurzen Abriss zu den agilen Methoden der Softwareentwicklung kommen wir nun zum Grundgedanken von DevOps, dem zweiten Baustein unserer Symbiose moderner Projektsteuerung und -durchführung.

Kein Gerangel um Zuständigkeiten durch DevOps

Die Idee hinter dem Begriff DevOps ist – wie bereits in der Einführung angedeutet – schnell erklärt. Er setzt sich zusammen aus Dev (für Development) und Ops (für Operations), also den IT-Betrieb. Damit wird ein Schulterschluss zwischen den Mitarbeitern beider Bereiche symbolisiert und versucht, den traditionellen Graben zwischen diesen beiden wichtigen Bereichen der IT zu überwinden. Dieser Graben resultiert aus Zielkonflikten, d. h. der Entwicklungsbereich ist stark daran interessiert, die implementierten Features möglichst kurzfristig an die Nutzer der Software auszuliefern. Dem IT-Betrieb ist dagegen vorrangig an einem kontinuierlichen und sicheren Betrieb der gesamten IT-Landschaft gelegen. Die Übernahme von Softwareupdates stellt in diesem Sinne stets einen Eingriff in das laufende System dar und kann dessen Stabilität immer bedrohen. Statt kurzfristiger und häufiger Releases werden lange Laufzeiten und umfassend geplante Updates bevorzugt. Diese Form der Arbeitsteilung scheint überholt. Software hat in der heutigen digitalen Welt einen ganz anderen Stellenwert, als das vor Jahren der Fall war. Statt lediglich ein Werkzeug, ist Software heute oft der Treiber von Innovationen. Unternehmen konkurrieren um die besten Lösungen auf dem Markt und setzen dabei zunehmend auf innovative IT-Lösungen. Damit Software diese Aufgabe erfüllen kann, muss sie zeitnah zur Verfügung stehen. Dieser Trend nimmt weiter zu, denn der Bedarf an speziellen Softwarelösungen steigt stetig.

DevOps zielt also genau darauf ab, die Prozesse in Unternehmen, von der Entwicklung über die Bereitstellung in der Produktion bis hin zur Wartung, so miteinander zu verzahnen, dass die beschriebenen Herausforderungen gelöst werden. Das kann nur dann gelingen, wenn die gegenläufigen Ziele einer iterativen Softwareentwicklung und der Anspruch nach einem sicheren und stabilen Betrieb in Einklang gebracht werden. Die Vorteile von DevOps lassen sich zum Beispiel wie folgt zusammenfassen:

  • Geschwindigkeit: Man ist in der Lage, Kunden Softwarelösungen schneller bereitzustellen.

  • Zuverlässigkeit: IT-Lösungen werden zuverlässiger, wenn sie schneller an sich ändernde Bedingungen angepasst werden können.

  • Zusammenarbeit: Die Trennung zwischen IT-Entwicklung und -Betrieb wird überwunden.

DevOps basiert auch auf neueren technologischen Ansätzen. Dazu gehören Continuous Integration, Continuous Delivery, Microservices und Infrastructure as Code. Diese stehen jedoch nicht im Vordergrund, denn es handelt sich nicht um eine Technik, sondern um eine Kultur. Die Grundpfeiler sind gegenseitiger Respekt und Vertrauen. Angetrieben werden sie von dem gemeinsamen Ziel, das Projekt ständig zu verbessern. Erfolge und Misserfolge werden nicht einzelnen Personen, sondern dem Team zugeschrieben. Voraussetzung ist, dass sich die Personen und das Team als Ganzes stetig den neuen Herausforderungen anpassen. DevOps ist zwar ein Thema, das in der Informationstechnik angesiedelt ist, aber im Kern mit der Entwicklung der Organisation zu tun hat (Changemanagement). Damit ist auch klar, dass DevOps eine Aufgabe des Managements ist und kein technischer Ansatz. Der Lernprozess muss daher von der Managementebene aus initiiert werden, sonst bleibt er stecken. Zwar muss eine DevOps-Strategie stets unternehmens- bzw. projektindividuell umgesetzt werden, aber trotzdem lassen sich grundsätzliche Empfehlungen ableiten:

  • Ziel: Dieses besteht in der schnellen Bereitstellung von qualitativ hochwertigen Softwarelösungen. Dazu müssen Entwickler, Tester und Betriebler gemeinsam an diesem Ziel arbeiten. Es sollte ein durchgehender Prozess aufgestellt werden, der von der Anforderungsdefinition bis zur Überwachung der Produktion reicht. Durchgängigkeit vermeidet Schnittstellen durch Zuständigkeitsbereiche. Mit anderen Worten: Die Verantwortung endet nicht mit der Erledigung der Aufgaben, die zur eigenen Profession passen.

  • Start: Bevor DevOps in der gesamten Organisation umgesetzt wird, muss man die Arbeitsweise an kleineren Vorhaben studieren und ausprobieren. Es ist ratsam, mit einem überschaubaren Projekt und einem kleineren Team zu beginnen. Das Management muss die neuen Wege des Teams ausdrücklich unterstützen. Wie bei jeder Veränderung gilt es, Widerstände zu überwinden.

  • Team: Um erfolgreich ein Projekt auf der Basis von DevOps zu etablieren, wird ein Team aus den richtigen Personen benötigt. Initial kann es sinnvoll sein, die Verantwortlichen zusammenzubringen. Das können zum Beispiel ein Vertreter des Managements, ein Projektmanager, ein Entwicklungsleiter und ein Verantwortlicher aus dem operativen Bereich sein. Das interdisziplinäre Team muss bewusst geformt werden.

  • Tools: Natürlich wird man neue Tools einsetzen. Dennoch: Eine Entwicklung zu DevOps kann man nicht kaufen, d. h., die Anschaffung von Tools löst noch keine Probleme.

  • Fortschritt: Die Entwicklung muss man verfolgen und die erreichten Fortschritte anhand von Kennzahlen, zum Beispiel der Zahl der Releases oder der Zeitdauer von der Anforderung bis zur Produktion eines Features, messen. Diese Kennwerte geben bei aller Unschärfe eine Orientierung über die erreichten Erfolge.

Nachdem wir einen Streifzug durch die agile Softwareentwicklung und das Thema DevOps unternommen haben, untersuchen wir nun die Frage, wie beide Bereiche zusammenhängen.

Im Duo schlagkräftig

Beide Konzepte sind bereits für sich betrachtet mächtig und es bedarf großer Anstrengungen, sie in eine etablierte Arbeits- und Projektkultur zu integrieren. Eine agile Vorgehensweise, zum Beispiel Scrum, und der DevOps-Ansatz können sich ergänzen. Wie könnte denn nun ein solches kombiniertes Vorgehen aussehen? Ausgangspunkt unserer Überlegungen ist Abbildung 3.

Abb. 3: Lücken im Software-Lifecycle [2]

Abb. 3: Lücken im Software-Lifecycle [2]

Wir haben es mit den beiden Bereichen Business und Informationstechnik (IT) zu tun. Business steht stellvertretend für den Anwender, den Kunden und letztendlich auch den Auftraggeber. Dieser möchte mit der Software arbeiten und erhofft sich durch den Einsatz von Software Vorteile bei der Erledigung seines Geschäfts. IT wird, wie gesagt, zunehmend zu einem Business-Innovator und damit immer wichtiger. Die andere Seite wird durch die IT repräsentiert. Für den Kunden spielt Struktur und Organisation der IT keine Rolle. Das Ziel ist die Bereitstellung von Software. Zwischen Business und IT klafft allzu oft eine Lücke (Gap). Diese Lücke resultiert aus mehreren Aspekten. Dem Anwender fällt es schwer, seine Anforderungen genau auszudrücken, und die IT kann aus dieser unspezifischen Formulierung der Anforderungen oft nur ein ungenügendes Bild von der zu entwickelnden Software zeichnen. Wie wir im Abschnitt über die agilen Methoden ausgeführt haben, entsteht die Lücke zwischen beiden Bereichen im Wesentlichen auch aus der Projektdynamik. Anforderungen können erst im Lauf des aktiven Projekts spezifiziert werden bzw. unterliegen sie stärkeren Änderungen. Die Lücke innerhalb der IT beschreibt die unterschiedlichen Zuständigkeiten zwischen Development und Operations.

Die gemeinsame Aufgabe der agilen Arbeitsweise und des DevOps-Ansatzes ist es, diese Lücken zu schließen. Wir nähern uns der Idee, wenn wir uns die Zuständigkeiten der Beteiligten genauer ansehen (Abb. 4).

Abb. 4: Zuständigkeiten der Beteiligten im Software-Lifecycle [2]

Abb. 4: Zuständigkeiten der Beteiligten im Software-Lifecycle [2]

Beginnen wir auf der Seite des Business. Hier werden die Bedeutung und Integration des zu entwickelnden Softwaresystems festgelegt. Mit dem Begriff Enterprise Architecture meint man die grobgranulare IT-Architektur eines Unternehmens, die die Schnittstelle zwischen Geschäftswelt und Technik repräsentiert. Im Allgemeinen geht man davon aus, dass die folgenden Schichten enthalten sind:

  • Prozessarchitektur: Darunter wird die Abbildung der Geschäftsprozesse verstanden

  • Datenarchitektur: Stellt den Informationsfluss und die benötigten Daten für die Ausführung eines Geschäftsprozesses dar

  • Applikationsarchitektur: Es handelt sich um die konkreten Systeme in Form von Anwendungen und Produkt-Suites, d. h. die Zusammenfassung einzelner Anwendungen zu einer gesamten Softwarelösung

  • Technische Architektur: Die technologischen Aspekte umfassen die Hardware, die Netzwerk- und Virtualisierungstechnologie; auf Ebene der Software gehören die Betriebs- und Datenbanksysteme dazu

Einen entscheidenden Einfluss auf die Enterprise Architecture hat das zugrunde liegende Business, das durch die IT unterstützt werden soll. Damit ist auch klar, dass es die eine Enterprise-Architektur nicht gibt, sondern dass ihre konkrete Ausgestaltung durch das geschäftliche Umfeld bestimmt wird. Erweitert man die Enterprise Architecture um genau die spezifischen Elemente aus der geschäftlichen Ebene, so entsteht die sogenannte Business-Enterprise-Architektur. Die zweite Aufgabe auf Businessseite ist das Portfoliomanagement. Darunter versteht man grob formuliert die Zuteilung der finanziellen, sachlichen und persönlichen Ressourcen auf Projekte und Vorhaben.

Kommen wir zum Bereich der IT und beginnen mit den typischen Aufgaben der Entwicklung. Das sind Design und Development. Development beschäftigt sich mit der technischen Umsetzung des Anwendungssystems. Im Ergebnis entstehen lauffähige Applikationen für die unterschiedlichsten Systeme in Form verschiedenster Anwendungsarten. Kernaufgabe ist die Implementierung mit Hilfe von Werkzeugen und Programmiersprachen. Zunehmend wichtiger wird die Gestaltung des User Interface. Die Benutzerschnittstelle einer Anwendung ist der einzige Punkt, mit dem der Nutzer in Berührung kommt. Demzufolge ist die Gestaltung des User Interface für die Akzeptanz eines Softwaresystems von entscheidender Bedeutung. Dieser Vorgang wird hier als Design bezeichnet. Im betrieblichen Umfeld haben wir es oft noch mit grafischen Oberflächen zu tun. Andere Interaktionsmöglichkeiten wie Sprache, Blick- oder Gestensteuerung nehmen jedoch an Bedeutung zu. Die Ausgestaltung des User Interface überlässt man heute nicht mehr dem Zufall, vielmehr findet es im Rahmen eines professionellen Designprozesses statt.

Ebenso sind die Aufgaben der Operations auf der Seite der IT angesiedelt. Nach den ausführlichen Tests der Applikation muss diese zur Nutzung auf den Zielsystemen bereitgestellt werden. Produktionsfähige Versionen des Anwendungssystems werden als Releases bezeichnet. Die fortlaufende Sicherstellung der Betriebsfähigkeit und deren Überwachung erfordert ein Monitoring des Anwendungssystems und ist traditionell auch eine Aufgabe des IT-Betriebs.

Neue Ansätze zur Gestaltung des Entwicklungs- und Bereitstellungsprozesses haben das Ziel, die Aufgaben zusammenzufassen, künstliche Schnittstellen zu beseitigen und für einen viel schnelleren Durchlauf des Softwarelebenszyklus zu sorgen. Die Rede ist von Collaborative Development, Continuous Testing, Continuous Release und Continuous Monitoring and Optimization. Die Bedeutung dieser Schlagworte wird sofort klar, wenn Sie die Weiterentwicklung der Infografik betrachten, wie sie in Abbildung 5 dargestellt ist.

Abb. 5: Zusammenfassung von Prozessen zu kontinuierlichen Zyklen [2]

Abb. 5: Zusammenfassung von Prozessen zu kontinuierlichen Zyklen [2]

Mittels agiler Softwarewareentwicklung und DevOps wird nun versucht, die oben beschriebenen Lücken zu schließen. Bereits aus den Ausführungen zu den agilen Ansätzen hat sich ergeben, dass die Problemlage zwischen Business und IT auf der ungenauen Formulierung der Anforderungen beruht. Das Requirements Engineering stößt an seine Grenzen, wenn es versucht, die Anforderungen an das zu entwickelnde System im Vorhinein generalstabsmäßig zu planen und umzusetzen. Wie man es besser machen kann, zeigen die agilen Methoden, wie zum Beispiel Scrum.

DevOps schließt die Lücke innerhalb der IT und hat sehr viel mit Organisation und Changemanagement zu tun. Werden beide Ansätze umfassend, korrekt und vor allem durchgängig angewendet, dann entsteht eine neue Form des Software-Lifecycle (Abb. 6).

Abb. 6: Agile Methoden und DevOps im Zusammenhang

Abb. 6: Agile Methoden und DevOps im Zusammenhang

Von der Idee über die Erhebung der Anforderungen und das Development bis hin zur Bereitstellung arbeiten alle Beteiligten zusammen. Lücken und Systembrüche werden weitgehend vermieden. Der gesamte Vorgang wird agil gestaltet, sodass Änderungen in den Anforderungen und Rahmenbedingungen kein Dilemma mehr darstellen. Zudem ist die Verantwortung der Beteiligten auf Seiten der IT stets umfassend und nicht an Silos (Development, Operations) gebunden. Vielmehr hat man es mit einem multidisziplinären Team zu tun, dessen Ziel eine schnell verfügbare und qualitativ hochwertige Software ist.

Fazit

Aus Sicht der Autoren passen die agile Arbeitsweise und DevOps wunderbar zusammen. DevOps bietet gewissermaßen den Rahmen für die Zusammenarbeit innerhalb der IT. Es wird nicht mehr danach gefragt, wer zuständig ist, sondern die IT liefert die Innovation für den künftigen Geschäftserfolg. Mit agilem Arbeiten wird dem Umstand Rechnung getragen, dass sich Anforderungen und Bedingungen jederzeit ändern können.

Nach diesen Ausführungen in der Theorie stellt sich natürlich die Frage, wie es in der Praxis aussieht [3]. Mit anderen Worten: Wie groß ist die Lücke zwischen Theorie und Praxis? Diese Frage beantworten wir im kommenden zweiten Teil der Artikelserie. Wir werden Erfahrungen, Hemmnisse und Lösungen unter anderem anhand von Praxisprojekten beleuchten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -