New School of IT

Softwareentwicklung zwischen Flexibilität und Planung
Kommentare

Soll ein IT-Projekt mit planbaren Terminen umgesetzt oder soll die Software flexibel entwickelt werden? Soll die Dokumentation möglichst lückenlos sein oder das Projektteam möglichst schnell? Zwischen planorientierten und agilen Konzepten der Softwareentwicklung scheinen unüberbrückbare Differenzen zu liegen. Für IT-Experten lohnt es sich aber, einen genaueren Blick auf das Thema zu werfen. Denn die Kombination beider Ansätze kann dafür sorgen, dass bessere Software schneller entwickelt wird – und das zuverlässig.

Beide Ansätze bringen Vorteile mit sich: Auf der einen Seite ist Softwareentwicklung immer auch ein Entdeckungsprozess. Dass alle Anforderungen an eine neue Lösung bereits zu Projektbeginn vollständig auf dem Tisch liegen, hat mit der Realität in Unternehmen wenig zu tun. Es kommt vor, dass sich Anpassungen erst spät im Projektablauf ergeben. Zuvor bereits definierte Anforderungen erweisen sich im Nachhinein als unnötig. Ein gewisses Maß an Flexibilität ist somit notwendig, auch in durchgeplanten Projekten. Auf der anderen Seite steht Flexibilität ohne Grenzen im Widerspruch zu Lieferterminen oder Budgetplänen. Unternehmen benötigen aber planerische Sicherheit, um Softwareprojekte auf- und umsetzen zu können. Agilität muss so eingesetzt werden, dass sie zu den Anforderungen von Unternehmen passt. Agilität muss gezähmt werden. Wenn dies gelingt, dann entfaltet sie ihre volle Wirkung. Unternehmen stehen vor der Frage, welchen Grad an Unvollständigkeit sie akzeptieren können: Planung und Flexibilität müssen im richtigen Verhältnis zueinander stehen.

New School of IT – IT muss neu gedacht werden

Es geht aber nicht nur um die Arbeitsweise in und die Organisation von IT-Abteilungen. Es geht auch darum, welchen Stellenwert der ganze Bereich im Unternehmen genießt. Bestimmen die Fachabteilungen die unternehmerische Ausrichtung und die IT-Experten werden zu Erfüllungsgehilfen degradiert? Oder gelingt es ihnen, aus den Veränderungen, mit denen Unternehmen aktuell umgehen müssen – neue Vertriebskanäle, neue Wettbewerber, neue Ansprüche der Zielgruppen –, Kapital zu schlagen und der IT die Bedeutung zu geben, die ihr zusteht?

Dabei steht die IT nicht nur einer Reihe von mehr oder weniger relevanten Einzelthemen gegenüber. Aktuell kommen drei Faktoren zusammen, die sich gegenseitig verstärken und für radikale Veränderungen nicht nur in IT-Abteilungen, sondern im ganzen Unternehmen sorgen: Mobilität von Anwendern, Elastizität von IT-Infrastrukturen und Agilität in der Softwareentwicklung (Abb. 1). Die so genannte „New School of IT“ analysiert die Zusammenhänge zwischen diesen Treibern und leitet daraus Handlungsempfehlungen für Entscheider ab. Auswirkungen, die sich aus dem Trend zu agilem Projektdesign und agiler Softwareentwicklung ergeben, beschreibt der Artikel im Folgenden genauer.

Abb. 1: Die „New School of IT“

Abb. 1: Die „New School of IT“

 

Wie agil darf’s denn werden?

Wie das richtige Verhältnis von Planung und Flexibilität aussieht, ist von mehreren Faktoren abhängig. Selbst bei vergleichbaren Unternehmen – ähnliche Branche, ähnliche Anwendungslandschaften, ähnliche Vertriebswege, ähnliche Produkte – kann die Mischung eine andere sein. Entscheidend ist die persönliche Einstellung wichtiger Projektbeteiligter zu dem Thema: Je agil-affiner sie sind, desto größer der agile Anteil in der Projektarbeit. Indikatoren sind auch die Größe des Projekts, seine Bedeutung, die Dynamik des Umfelds, die Unternehmenskultur und das Branchen-Know-how der Entwicklungsmannschaft.

Barry Boehm und Richard Turner erläutern in ihrem Buch „Balancing Agility and Discipline: A Guide for the Perplexed“, dass die Rahmenbedingungen eines Projekts dieses Verhältnis maßgeblich beeinflussen. Große Projekte und Organisationen, hohe Bedeutung der geplanten Anwendung, Klarheit der Anforderungen verschieben das optimale Verhältnis tendenziell in Richtung plangetriebener Verfahren. Darüber hinaus gibt es zwei weitere, wichtige Faktoren: Der Zustand der Anwendungslandschaft und die Frage, ob ein anstehendes Projekt mit großer Wahrscheinlichkeit zu strukturellen Veränderungen der Anwendungslandschaft führt. Die Suche nach dem optimalen Verhältnis von Planung zu Agilität kann zeitaufwändig und nervenaufreibend sein. Aber mit den geeigneten Werkzeugen und Konzepten lässt sich die Suche verkürzen. Neben DevOps und Continuous Integration/Continuous Delivery bietet sich hier der Interaction Room als Konzept an.

Entwicklung und Betrieb: Da wächst zusammen, was zusammen gehört

Noch vor ein paar Jahren wurde alle paar Monate ein neues, großes Softwarerelease veröffentlicht. Heutzutage, Scrum und Sprints sei Dank, denken Entwickler in Tagen: Updates sind kein Ereignis, sondern ein Dauerzustand. Will ein Unternehmen von den Vorteilen agiler Konzepte profitieren, dann muss der IT-Betrieb mit der IT-Entwicklung Schritt halten können. In klassischen IT-Organisationen folgen beide Bereiche aber unterschiedlichen Idealen: kreative Lösungen zügig zu entwickeln und schnell zum Einsatz bringen auf der einen, stabile Verfügbarkeit und stabile Strukturen auf der anderen Seite. Solange es zwei getrennte Abteilungen gab, die jeweils einen der beiden Aspekte – Entwicklung oder Betrieb – verantworteten, waren das auch sinnvolle Zielsetzungen.

Die Aufstellung der IT bringt Nachteile mit sich. Ein Nachteil, der angesichts immer kürzerer Releasezyklen besonders stark ins Gewicht fällt, ist der Organisationsaufbau – er ist nicht flexibel genug. Probleme mit der Software führen dazu, dass erst über mehrere Hierarchiestufen hinweg geklärt werden muss, ob die Software oder der Betrieb der Software fehlerhaft ist. Bei solchen Prüfprozessen geht Wissen über technische und inhaltliche Details verloren. Die Analyse des Fehlers wird durch diesen Know-how-Verlust unnötig kompliziert. Die Folge sind Systeme, die bei Problemen länger als notwendig nicht richtig funktionieren. Das ist kein tragbarer Zustand angesichts der hohen Anforderungen an die Verfügbarkeit von Kundenportalen oder mobilen Lösungen. Die aufbauorganisatorische Lösung dieses Problems ist einfach und heißt DevOps. Dahinter steckt die Idee, dass für bestimmte Anwendungen gemischte Teams aus Development und Operations verantwortlich sind. Kommt es zu Problemen, kümmert sich das ganze Team darum, diese möglichst schnell zu lösen. Denn das Management misst das ganze Team an der Verfügbarkeit der Lösung oder des Service. In DevOps-Organisationen gibt es keine „andere Abteilung“ mehr, der man im Zweifel den Schwarzen Peter zuschieben kann. Welche Organisationsform beziehungsweise welche Mischung von Organisationsformen für ein Unternehmen geeignet sind, lässt sich nur bei genauer Betrachtung des Einzelfalls entscheiden. Allerdings gibt es Indikatoren, die anzeigen, ob die Tendenz eher in Richtung DevOps oder in Richtung klassische CIO-Organisation geht (Abb. 2). Das sind Indikatoren wie:

• Systeme, die sich nur langsam verändern und die kaum strukturellen Anpassungen ausgesetzt sind. Sie sind keine Auslöser für die Einführung von DevOps-Strukturen. • Ähnliches trifft auf Anwendungen zu, die Teil einer hochintegrierten IT-Landschaft sind. Hier ist es in der Regel schwierig, die Reichweite von Änderungen vorherzusagen. Denn bei Anpassungen müssen nicht selten ganze Landschaften oder zumindest erhebliche Teile komplett eingeführt werden. Die daraus resultierende Komplexität der Gesamtverantwortung kann für ein einziges DevOps-Team zu groß werden. • DevOps eignen sich für Strukturen mit klaren Trennlinien in Form nur lose gekoppelter, asynchroner, integrierter Dienste. Diese Voraussetzungen sind in jüngeren IT-Systemen gegeben. Dies trifft insbesondere auf oberflächenintensive und kundensichtbare Systeme am Anfang ihres Lebenszyklus zu. In einem derartigen Umfeld können DevOps-Teams bestens funktionieren. • Mobile Anwendungen sind von Natur aus geeignete Kandidaten für eine DevOps-Organisationsform: Sie verändern sich schnell und müssen permanent verfügbar sein. Genauso wichtig wie die IT-Organisation sind auch die Systeme zur Veröffentlichung von Software. Sie spielen eine entscheidende Rolle, wenn es darum geht, agil entwickelte Software in der Frequenz in Betrieb zu nehmen, in der sie veröffentlicht wird.

Abb. 2: CIO-DevOps-Organisation

Abb. 2: CIO-DevOps-Organisation

Automatisch agil: Continuous Integration und Continuous Delivery

Ziel ist es, sowohl die Software als auch die Entwicklungs-, Test- und Produktivumgebungen automatisiert zu produzieren und bereitzustellen. In vielen Organisationen war ein solch hohes Maß an Automatisierung bisher nicht notwendig. Wer pro Jahr nur wenige Releases veröffentlicht, für den lohnt sich der damit verbundene Aufwand nicht. Ein weiteres Argument, das gegen einen höheren Automatisierungsgrad sprach: Wenn zwischen zwei Softwareupdates mehrere Monate liegen, verändert sich mit hoher Wahrscheinlichkeit die Struktur der Zielumgebung. Der automatisierte Prozess müsste somit erneut überarbeitet werden, damit er zu den neuen Strukturen passt.

Eher statische Rahmenbedingungen in der IT fördern also die „Handarbeit“. Diese personalintensiven Prozesse bringen einige Nachteile mit sich. Insbesondere sind sie stark von einzelnen Mitarbeitern abhängig. Unvorhergesehene Abwesenheiten, der Verlust von Kompetenzträgern oder unterschiedlich qualifizierte Fachleute können für Probleme sorgen oder sogar für den Prozessstillstand. Wenn zwischen zwei Updates aber nicht mehrere Monate, sondern nur ein paar Tage oder Stunden liegen dürfen, müssen die IT-Betriebsprozesse grundlegend überdacht werden. Es sind Installationsroutinen gefragt, die permanent prüfen, ob sich veränderte Software in Betrieb nehmen lässt. Dieser Ansatz liegt „Continuous Integration“ und „Continuous Delivery“ zugrunde.

Im Gegensatz zu den ersten Ansätzen der Automatisierung mit ihrem begrenzten Funktionsumfang bieten die aktuellen Lösungen wie Puppet oder Nexus inzwischen sehr vielfältige Möglichkeiten. Sie reichen von der Adressierung heterogener Infrastrukturen bis hin zur automatisierten Bereitstellung von Umgebungen und deren Integration in die vorhandene IT-Infrastruktur (Puppet oder Chef). Dazu gehören auch Tools für die Umsetzung von Monitoring- und Logging-Mechanismen, für das automatisierte Testen, für die Verwaltung von Softwarekomponenten (zum Beispiel Nexus) und für die Orchestrierung des gesamten Prozesses (beispielsweise Jenkins).

Das Bereitstellen von Infrastruktur wird zu einem Prozess, der sich mit den gleichen Methoden und zum Teil sogar mit den gleichen Werkzeugen unterstützen lässt wie die Softwareentwicklung. Beispiele dafür sind die Versionierung von Code für die Infrastruktur oder das Entwickeln von Design Pattern für bestimmte Infrastrukturaufgaben wie das Aufsetzen eines Webservers. Ein flexibleres Vorgehen in Softwareentwicklung und -betrieb erfordert auch eine andere Kommunikationskultur der Beteiligten. Um schnell reagieren zu können, müssen im agilen Umfeld Fachleute zusammenarbeiten, die bisher durch Abteilungsgrenzen voneinander getrennt waren.

Der Kommunikation einen Raum geben: Interaction Room

Wie können Fach- und IT-Abteilungen bei der Entwicklung von Lösungen für wettbewerbskritische Geschäftsprozesse besser zusammenarbeiten? Wie gelingt es den Beteiligten, die kritischen Elemente des Projekts zu identifizieren? Das sind zentrale Fragestellungen im Prozess der Erstellung von Informationssystemen. Als Antwort darauf wurde von paluno – The Ruhr Institute for Software Technology – und adesso das Konzept des Interaction Room entwickelt. Die beiden Ziele, verbesserte Kommunikation und Fokussierung auf Kernthemen, lassen sich durch ein einfaches Regelwerk und den Aufbau des Raums erreichen. Denn das Konzept des Interaction Room nimmt den Begriff „Room“ wörtlich: Er ist ein realer Raum mit realen Wänden (Abb. 3). Diese Wände spielen für den Einsatz im Projekt eine entscheidende Rolle. Sie dienen der Visualisierung von Prozessen und der Darstellung von Projektdetails. Sie helfen dabei, Probleme zu erkennen.

Abb. 3: Schematische Darstellung des Interaction Room

Abb. 3: Schematische Darstellung des Interaction Room

 

Fachabteilungen verfügen über detailliertes Wissen zu Arbeitsabläufen und Strukturen; IT-Abteilungen über das Know-how für die Entwicklung und für den Betrieb der Systeme. Beide Seiten müssen einander verstehen. Dieses Verständnis wird durch unterschiedliche Ziele, Arbeitsweisen und Vorstellungswelten, aber auch durch unterschiedliche Fachsprachen erschwert. Der Interaction Room ist ein Medium, durch das Fach- und IT-Experten besser miteinander kommunizieren können. Erreicht wird dies durch die offene, nicht IT-fixierte Darstellung von Prozessen. Diese erlaubt es auch den Vertretern aus den Fachabteilungen, sich in die Diskussionen einzubringen. Ohne ein Medium wie den Interaction Room werden relevante Themen schnell auf einem technischen Niveau diskutiert, dem Nicht-IT-Experten nur schwer folgen können.

Der Interaction Room ist aber nicht nur ein Instrument zur Verbesserung der Kommunikation, er schärft auch den Blick des Teams für die relevanten Projektthemen. Er wirkt einem Phänomen entgegen, dass in umfangreichen Softwareprojekten immer wieder zu beobachten ist: In Probleme, die einfach zu verstehen sind, wird unverhältnismäßig viel Zeit investiert. Den Kernthemen, die erst erarbeitet werden müssen, wird im Vergleich dazu wenig Zeit geschenkt. Dies kann bedeuten, dass das Expertenteam über eine Erfassungsmaske ausgiebig nachdenkt, die zu modellierenden Geschäftsprozesse aber zu oberflächlich betrachtet.

Das Instrument des Interaction Room gibt es, neben der Variante für die „klassische Softwareentwicklung“, auch für zwei weitere Einsatzszenarien: den „Interaction Room für Mobile“ und den „Interaction Room für Organisationsentwicklung“. Der Interaction Room for Mobile berücksichtigt explizit die Besonderheiten mobiler Konzepte wie Kontext der Anwendung, Customer Journeys oder Personas. Der Interaction Room für Organisationsentwicklung eignet sich für die Harmonisierung von Geschäftsprozessen, selbst dann, wenn IT erst einmal keine Rolle spielt. Indem unterschiedliche Fachabteilungen deutlich machen, was ihnen besonders wichtig ist, können sie ihre Vorstellungen der Organisation solcher Prozesse abgleichen.

Von Biz über Dev bis Ops: Alles gehört zusammen

Die oben beschriebenen DevOps-Strukturen sind, so mutig der Schritt weg von herkömmlichen CIO-Organisationen wirkt, erst der Anfang. Business und IT müssen immer mehr zusammengedacht werden: Denn das zunehmende Business Alignement der IT, die wachsende IT-Kompetenz in den Fachabteilungen und die Kommoditisierung des Betriebs sorgen dafür, dass Umstrukturierungen nicht an den Bürotüren der IT-Abteilungen aufhören. Im nächsten Schritt wird es notwendig sein, dass Business, Development und Operations – BizDevOps – bei Softwareentwicklung und -betrieb zusammenarbeiten. Schon heute ist diese Organisationsform in Start-ups verbreitet, die auf die Lean-Startup-Methode setzen. Über diese jungen Firmen hinaus wird BizDevOps in Zukunft eine wichtige Rolle spielen – auch in klassischen Unternehmen.

Aufmacherbild: A man and a woman working together at a single computer von Shutterstock / Urheberrecht: Pictofigo

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -