Suche
Im Spannungsfeld von Agilität, Mobilität und Elastizität verändern sich Unternehmen

New School of IT – IT muss neu gedacht werden

Volker Gruhn, Thomas Franz
shutterstock_176510126
©Shutterstock/ wavebreakmedia

Was haben Google mit einer Bank, Instagram mit einer Versicherung oder Facebook mit einem Telekommunikationsunternehmen gemeinsam? Die Frage deutet es schon an: Mehr, als es auf den ersten Blick scheint. „Digitale Unternehmen“: Unter diesem Stichwort können all die genannten Firmen und Branchen einsortiert werden. Die Verarbeitung von Informationen – ohne dass andere Produktionsmittel oder -verfahren eingesetzt werden müssen – ist das bestimmende Element ihrer Geschäftstätigkeit. Aber allen digitalen Gemeinsamkeiten zum Trotz gibt es zwischen diesen Unternehmen große Unterschiede in der Wahrnehmung und Wertschätzung der IT.

In relativ jungen Firmen mit vergleichsweise neuen Geschäftsmodellen ist IT der zentrale Enabler und das zentrale Produktionsmittel. In alteingesessenen und etablierten Unternehmen kommt der IT dagegen oft noch die Rolle eines reinen Serviceerbringers zu. Hier wissen Fachbereiche genau, was sie wollen. Sie sind es, die die Merkmale der Lösung festlegen; IT muss dann nur noch bauen oder beschaffen. Ein weiterer Unterschied betrifft den Reifegrad und den Lebenszykluszustand von Anwendungslandschaften. In etablierten digitalen Unternehmen sind diese oft über Technologiegenerationen hinweg gewachsen und allein schon deshalb nicht beliebig veränderbar. Junge digitale Unternehmen profitieren dagegen von – zumindest anfänglich – nahezu beliebigen Gestaltungsmöglichkeiten im Hinblick auf ihre IT.

Agilität: das Ende der Gemütlichkeit

Das Serviceerbringermodell funktioniert auch – mehr oder weniger – gut; zumindest solange es nicht erforderlich ist, disruptive Innovationen auf der Basis von IT umzusetzen. Aber neue digitale Produkte, neue Vertriebswege – oft unter Ausschluss klassischer Vermittler –, neu fragmentierte Geschäftsprozesse oder neue Formen der Kooperation mit Partnern erfordern genau das: IT-gestützte Innovationen, die etablierte Geschäftsmodelle ablösen oder zumindest ergänzen. Dann wird IT zum Business Enabler. Das bedeutet, dass IT-Abteilungen mit Fachbereichen zusammenarbeiten müssen, um das Potenzial von Technologien aufzuzeigen. Sie müssen sich in Märkte einarbeiten, um essenzielle Anforderungen zu verstehen und zu bewerten. Auf der anderen Seite sind Fachbereiche dazu aufgefordert, die Chancen neuer Technologien zu beurteilen.

Das gemütliche Modell der langsamen und kontinuierlichen Verbesserung von Produkten und Prozessen kommt im Fall der disruptiven Innovationen an seine Grenzen. Stattdessen wird die Bereitstellung von IT flexibler, dynamischer, agiler. Ein Phänomen, das Eric Ries in seinem Buch „The Lean Startup“ als wesentliches Merkmal junger digitaler Unternehmen charakterisiert.

Mobilität: Wer extern auf Daten zugreifen will, muss sich intern ändern

Ein wichtiger Treiber für diesen Innovationsdruck ist Mobilität. Für immer mehr Menschen ist es selbstverständlich, ortsunabhängig Daten und Anwendungen zur Verfügung zu haben. Für viele Daten und Anwendungen ist diese mobile Nutzung – jenseits des Zeitgeists und aller Moden – auch sinnvoll. Vor Ort erfasste Daten, die zentral benötigt werden, relevante Details zu Ort und Zeit von Ereignissen, der Zugriff auf Information aus der Ferne – das sind Beispiele dafür, wie mobile Lösungen zu höherem Durchsatz, höherer Geschwindigkeit und höherer Produktivität beitragen. Mobile Anwendungen können aber schon deshalb sinnvoll sein, weil Anwender mit ihnen Leerzeiten überbrücken oder Langeweile vermeiden.

Aus Sicht von digitalen Unternehmen bedeutet dieser Trend: Sie müssen mindestens ausgewählte Daten und Anwendungen mobil bereitstellen. Alleine diese Tatsache ist oftmals Auslöser für einen Innovationsschub. Um Vertriebs- und Servicemitarbeiter mobil zu unterstützen, um Kunden unterwegs zu informieren und ihnen die Möglichkeit zu geben, mobile Transaktionen auszulösen, müssen Produkte, Dienstleistungen und Geschäftsprozesse angepasst werden. Und selbst wenn diese nicht zwangsweise angepasst werden müssten, bietet sich hier die Chance auf durchgängige, medienbruchfreie Prozesse, auf situativ einzukaufende Produkte und auf neue Vertriebswege. So löst Mobilität Veränderungen nicht nur außen an den Schnittstellen aus, sondern sie wirkt auch weit in das Unternehmen hinein.

Aufmacherbild: Old school vs new school von Shutterstock / Urheberrecht: wavebreakmedia

[ header = Seite 2: Elastizität: unflexibel war gestern ]

Elastizität: unflexibel war gestern

Eine mobilere und agilere Welt erfordert nicht nur eine dynamischere IT. Lösungen müssen auch schneller bereitgestellt werden und besser mit den Anforderungen der Nutzer skalieren. Ob zehn oder 10 000 Kunden eine neue mobile Anwendung akzeptieren, ist im Vorfeld schwer zu planen, zumindest wenn es um Anwendungen geht, die sich an den Endkonsumenten richten. IT-Verantwortliche werden also zunächst nur wenig Infrastruktur vorhalten; diese muss im Erfolgsfall hochskaliert werden. Für die Rechenzentren und Betriebsabteilungen klassischer digitaler Unternehmen keine einfache Aufgabe. Denn bisher waren Robustheit und Zuverlässigkeit die entscheidenden Werte des IT-Betriebs, nicht Flexibilität und Skalierung. Jetzt stehen die hier und da barocken Beschaffungs- und Installationsroutinen den neuen Prozessen im Weg.

Diese Elastizität von Infrastrukturen ist ein weiteres Merkmal junger digitaler Unternehmen, die in einem innovativen Umfeld unterwegs sind.

Agilität – Mobilität – Elastizität: Wenn digitale Unternehmen das vorhandene Innovationspotenzial erschließen wollen, sind das die drei Kernthemen, denen sie sich stellen müssen. Die New School of IT beschreibt ein Leitbild der Enterprise-IT, das den neuen Anforderungen gerecht wird (Abb. 1).

Abb. 1: Die New School of IT im Überblick (Quelle: adesso AG)

[ header = Seite 3: New School of IT – eine neue Denkschule ]

New School of IT – eine neue Denkschule

Ein zentrales Element der New School of IT ist die gezähmt-agile Softwareentwicklung: Im Kern geht es darum, dass es pro Unternehmen und pro Projekt ein optimales Verhältnis von plangetriebenen zu agilen Elementen gibt. 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: Diese Faktoren lassen das Pendel eher in Richtung plangetriebener Verfahren ausschlagen.

Aber ganz ohne agile Elemente kommt im innovativen Kontext kaum ein Projekt aus. Der Grund dafür liegt in der zu entwickelnden Software. Sie fällt oft in die Kategorie der Informationssysteme und ist damit ein soziotechnisches System. Diese enden nicht an der Oberfläche des Bildschirms, sondern an der hinteren Schädeldecke des Anwenders. Solche Systeme lassen sich nicht vollständig, zumindest nicht mit sinnvollem Aufwand, beschreiben. Anforderungen, die erst spät im Entwicklungsprozess erkannt werden und berücksichtig werden müssen, sind die Regel. Daneben gibt es aber auch zu frühe Anforderungen. Solche, die es in den Anforderungsstatus geschafft haben, die bei näherer Betrachtung aber eigentlich überflüssig sind. Ihr konsequentes Eliminieren sorgt für schlanke Software und damit für geringere Kosten bei Erstellung und Wartung. Entsprechende Techniken zur kontinuierlichen Re-Priorisierung sind ein wichtiges Merkmal aller agilen Methoden.

Die gezähmte Agilität aus dem Kern der Softwareentwicklung/Development (Dev) wirkt in zwei Richtungen: Nach „vorne“ in Richtung Anwender, Kunden und Auftraggeber, kurz ins Business (Biz). Und nach „hinten“ in Richtung IT-Betrieb/Operations (Ops). Diese beiden Richtungen werden im Folgenden erörtert.

Business + Development = BizDev

„Vorne“ – an der Stelle im Prozess, an dem Entwicklung und Business aufeinandertreffen, um neue Software zu planen – ist die Kommunikation zwischen den Beteiligten das größte Problem. Hier treffen unterschiedliches Know-how, unterschiedliche Arbeitsweisen und unterschiedliche Zielsetzungen aufeinander. Ein Instrument, um die Kommunikation zwischen den Beteiligten zu erleichtern, ist der so genannte Interaction Room. Dabei handelt es sich um einen echten, begehbaren Projektraum. Die Wände des Raums haben eine zentrale Funktion im Prozess. Sie dienen zur Visualisierung von Prozessen und zur Darstellung von Projektdetails. Auf ihnen sehen die Projektmitglieder, was sonst nur schwer zu erfassen ist. Hier werden die Zusammenhänge von Prozessen, Daten und IT-Systemen deutlich. Die wichtigsten Aspekte des Projekts werden jeweils auf einer Wand dargestellt:

  • Objektwand für fachliche Objektmodelle
  • Statuswand für Backlog und Projektfortschritt
  • Prozesswand für die Modelle der Geschäftsprozesse, die das neue Softwaresystem einmal unterstützen soll
  • Integrationswand für die existierenden Softwaresysteme, mit denen das zu erstellende System integriert werden muss

Das Interaction-Room-Team besteht aus Anwendern und Entwicklern, die unter der Anleitung eines Moderators zusammenarbeiten. Gemeinsam ermitteln sie in Abstimmungsrunden Lösungen für die zentralen Themen und Fragestellungen des Projekts. Das Team visualisiert dies durch die Zuordnung von Symbolen – sogenannten Wertannotationen – zu einzelnen Aspekten des Projekts. So erarbeiten sich die Experten, unabhängig von ihrem individuellen Fachgebiet, Schritt für Schritt die Prozesse (Abb. 2).

Abb. 2: Beispiel für die offene, nicht IT-fixierte Beschreibung von Prozessen (Bild: adesso AG)

Der Interaction Room verzichtet zugunsten der Einfachheit auf ein komplexes Regelwerk. Über einige Punkte müssen sich die Teammitglieder klar sein, damit sie im Interaction Room zusammenarbeiten können:

Abstraktion: Die Arbeit an den begrenzten Wänden zwingt zur Konzentration auf die wichtigsten Punkte. Der entsprechend hohe Abstraktionsgrad sorgt dafür, dass das Team sich nicht in Detailfragen verliert.

Wertorientierung: Kritisches von Unkritischem zu unterscheiden, ist einer der Schlüssel zu einem erfolgreichen Projekt. Häufig wird zu viel Zeit in einfache, leicht verständliche Prozesse investiert. Zeit, die bei der Beantwortung der eigentlich entscheidenden Fragen fehlt. Durch die Zuordnung von Wertannotationen als Indikator für die Bedeutung von Prozessen wird dieses Problem im Interaction Room gelöst.

Inkonsistenz: Pragmatismus vor syntaktischer Genauigkeit – im Interaction Room geht es nicht um die exakte Beschreibung der Prozessmodelle, sondern um die inhaltliche Auseinandersetzung mit den Themen. So wird sichergestellt, dass sich die Fachabteilungen genauso in den Entwicklungsprozess einbringen können wie die IT-Experten, die bei formalen Fragen häufig einen Wissensvorsprung haben.

Ungewissheit: Kaum ein Teammitglied versteht auf Anhieb alle Elemente des Projekts. An einigen Stellen wird es notwendig sein, sich tiefer einzuarbeiten oder teamexterne Fachleute hinzuzuziehen. Durch die Zuordnung von Ungewissheitssymbolen zu kritischen Punkten wird der Wissenstand des Teams visualisiert und es können die passenden Maßnahmen ergriffen werden (Abb. 3).

Abb. 3: Symbole, die die Projektbeteiligten in verschiedenen Durchgängen an die Aktivitäten der Prozessmodelle kleben (Bild: adesso AG)

 

[ header = Seite 4: Exkurs: der Interaction Room im Einsatz ]

Exkurs: der Interaction Room im Einsatz

Der Ansatz des Interaction Rooms hat sich bereits in mehreren Unternehmens-IT-Projekten bewährt. So hat die Versicherungsgruppe Barmenia dieses Instrument bei der Vorbereitung der SEPA-Umstellung eingesetzt. Mit dem Projekt wurde sichergestellt, dass in der IT alle nötigen Vorbereitungen für den einheitlichen Europäischen Zahlungsraum (SEPA – Single European Payment Area) getroffen werden. Das Team bestand aus einem Projektmanager, der die Funktion des Moderators wahrnahm, aus Barmenia-Fachleuten unterschiedlicher Abteilungen (IT und Nicht-IT) sowie einem externen Interaction-Room-Experten.

Die Aufgabe des SEPA-Interaction-Room-Projekts war es, alternative Lösungsansätze für einzelne Aspekte der SEPA-Umstellung zu erarbeiten. Im Zweitagesrhythmus trafen sich die Experten in dem Projektraum, um einen Aspekt des Projekts zu erarbeiten und Entscheidungsvorlagen zu entwickeln. Diese legte das Team dann einem Managementkomitee vor, das die geeignetste Alternative für die Umsetzung auswählte.

Wie im Interaction Room gearbeitet wird, kann anhand der Modellierung von Geschäftsprozessen erläutert werden. Zunächst strukturierte und bewertete das Interaction-Room-Team die erfassten Prozesse. Zu diesem Zweck befestigten sie in mehreren Abstimmungsrunden Annotationen – Symbolaufkleber – auf dem Modell des Prozesses. So wurde Zug um Zug offensichtlich, an welchen Stellen noch Diskussionsbedarf bestand. Die Entscheidung über besonders kontroverse Punkte wurde dann in so genannten Breakout-Sessions vorbereitet. Die Teilnehmer dieser Sessions konnten sich im Detail mit den Themen auseinandersetzen.

Zum Abschluss eines Meetings bewertete jeder Teilnehmer, zu welchen Sachverhalten noch zu wenig Detailkenntnis im Interaction-Room-Team verfügbar war. Sie kennzeichneten die entsprechenden Aktivitäten mit Symbolen. Anschließend erarbeiteten sie, welche Maßnahmen nötig waren, um diese Defizite auszugleichen.

Der Interaction Room ist ein geeignetes Projektwerkzeug, um das agile Konzept in der Zusammenarbeit zwischen IT und Anwendern zu fördern. „Hinten“, wo die Softwareentwicklung die Lösung produziert und der Betrieb einen reibungslosen Zugriff garantiert, ist ein anderer Ansatz notwendig.

[ header = Seite 5: Development + Operations = DevOps ]

Development + Operations = DevOps

Die agile Softwareentwicklung stellt eingefahrene Verhaltensweisen und Arbeitsaufteilungen auf den Kopf: Während es vor ein paar Jahren noch ausreichte, alle sechs Monate ein großes Update zu veröffentlichen, wird Software heutzutage – Scrum, Sprints und Spikes sei Dank – im Wochen-, Tages- oder sogar Stundenrhythmus aktualisiert. Will ein Unternehmen von den Vorteilen der agilen Konzepte profitieren, muss der IT-Betrieb sich an die Schlagzahl aus der IT-Entwicklung anpassen.

Hier zeigen sich die Zielkonflikte zwischen den beiden Bereichen: Der eine hat die Vorgabe, zügig und kreativ passende Lösungen zu entwickeln und zum Einsatz zu bringen. Der andere hat eine stabile Verfügbarkeit zu garantieren und benötigt dafür stabile Strukturen. Dieser inhärente Zielkonflikt war bisher sinnvoll und ist institutionell dadurch verankert, dass es getrennte Abteilungen gibt, die jeweils einen der beiden Aspekte – Entwicklung oder Betrieb – verantworten.

Aber die Zeiten haben sich geändert: Die aufbauorganisatorische Verankerung des Konflikts zwischen Entwicklung und Betrieb ist nicht mehr angemessen. Das liegt einerseits an digitalen Innovationen, die auf strukturelle Änderungen von Prozessen, Architekturen und Infrastrukturen hinauslaufen. Andererseits an mobilen Anwendungen, die sich aufgrund ihrer geringeren Komplexität schneller weiterentwickeln lassen. Die klassische Trennung führt zu zähen Prozessen und – im ungünstigsten Fall – zu Verschleißerscheinungen bei den handelnden Personen.

Für die Entscheider in den Unternehmen bieten sich zwei Ansatzpunkte, um an der Schnittstelle zwischen Entwicklung und Betrieb für mehr Agilität zu sorgen: organisatorische und technische Maßnahmen. Organisatorisch sorgt das Einsetzen von gemeinsamen Teams aus Entwicklung und Betrieb (DevOps) für mehr Agilität im Prozess. Technisch spielt die Automatisierung der Prozesse zur Inbetriebnahme eine wichtige Rolle.

DevOps-Teams sind gemeinschaftlich verantwortliche Teams, die sich aus Entwicklern und Betriebspersonal zusammensetzen. DevOps ist eine Philosophie, das Konzept einer von gegenseitigem Aufgabenverständnis und Akzeptanz geprägten, organisationsübergreifenden Zusammenarbeit von Anwendungsentwicklung und IT-Betrieb.

Automatisierung bedeutet, auf Knopfdruck sowohl Software als auch Entwicklungs-, Test- und Produktivumgebungen zur Verfügung stellen zu können. Aufgrund der langen Zeiträume zwischen zwei Releases war so ein auf Geschwindigkeit ausgelegter Prozess bisher nicht rentabel. Zuviel ändert sich in der Zwischenzeit an der Struktur der Zielumgebung, sodass die IT-Experten einen automatisierten Prozess trotzdem wieder überarbeiten und an die neuen Strukturen anpassen müssten. Solche eher statischen Rahmenbedingungen führen zu verstärkter „Handarbeit“ in der IT. Solche stark taylorisierten Prozesse sind von jedem einzelnen Mitarbeiter abhängig. Jede unvorhergesehene Veränderung – Krankheit, Kündigung – kann zu Problemen bis hin zum Stillstand führen.

Updatezyklen von Wochen, Tagen oder Stunden erfordern grundlegend andere Prozesse. Jetzt sind Installationsroutinen gefragt, die permanent überprüfen, ob die veränderte Software in Betrieb genommen werden kann, ganz im Sinne von „Continuous Integration“ und „Continous Delivery“. Moderne Continuous-Delivery-Lösungen beherrschen die Adressierung heterogener Infrastrukturen bis hin zur automatisierten Bereitstellung von Umgebungen und deren Integration in die vorhandene IT-Infrastruktur (beispielsweise wie Puppet oder Chef). Zum Content Delivery 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 (zum Beispiel Jenkins) des gesamten Prozesses: von der Verfügbarkeit neuen Quellcodes bis hin zu der Inbetriebnahme des entsprechenden Softwareupdates in der Produktivumgebung.

[ header = Seite 6: Business + Development + Operations = BizDevOps ]

Business + Development + Operations = BizDevOps

Auf der einen Seite rücken also Entwicklung und Business enger zusammen. Auf der anderen Seite Entwicklung und Betrieb. BizDevOps-Teams – eine durchgängige Verantwortlichkeit von Entwicklung über Betrieb bis hin zum Geschäft – werden am Ende dieser Entwicklung stehen. Das bedeutet für das Zielbild der New School of IT:

  • Innovative Geschäftsmodelle benötigen eine Projektkultur, die die Aufbauorganisation dominiert – oder gleich eine veränderte Aufbauorganisation. Nur dann können Prozesse so beschleunigt werden, wie es agile Konzepte erfordern.
  • Alle Beteiligten müssen sich darauf einlassen, im Angesicht von Ungewissheit zu arbeiten. Die gute alte Zeit vermeintlich vollständiger Spezifikationen und finaler Festlegungen, die nur noch exekutiert werden müssen, kommt nicht wieder.
  • Technologische Kompetenzen müssen häufiger erneuert werden und halten weniger lange. Das lässt sich in gewissen Teilen durch den Zukauf externer Experten kompensieren. Die Kenntnis einer Programmiersprache und eines Transaktionsmonitors wird zukünftig kein ganzes Berufsleben tragen. Lebenslanges Lernen wird zur persönlichen Verantwortung.
  • Kommunikative Fähigkeiten gewinnen an Bedeutung und werden zum zentralen Erfolgsfaktor. In BizDevOps-Teams sprechen Menschen miteinander, die das in stärker taylorisierten Prozessen bisher kaum mussten. Das bedeutet, dass reine Technikexpertise ohne Verständnis der Branche an Bedeutung verliert. Das wirklich zentrale und dauerhaft relevante Wissen ist das Anwendungswissen.
  • Alle – inklusive externer Lieferanten – sind dazu aufgefordert, schlanke Software schnell zu erstellen. Das hat Auswirkungen auf die kommerziellen Konzepte zur Zusammenarbeit mit Externen und auf die internen Incentive-Modelle. Bei der Lieferantenauswahl muss darauf geachtet werden, dass auch der IT-Dienstleister Domänenwissen mitbringt. In Einzelfällen wird ein solcher Lieferant sogar so in Prozesse eingebunden, dass er einen Teil des Erstellungs-, Betriebs- und Geschäftsrisikos übernimmt.

Fazit

Die New School of IT hat weitreichende Auswirkungen auf Rolle, Kompetenzen und Gestaltung der Unternehmens-IT. Aber da hört ihr Einfluss nicht auf, sie wirkt über die Grenzen der IT hinaus. Agiles Vorgehen, Freude an Innovation und die Konzentration auf den Anwendernutzen wirken auf IT-unterstützende und viele andere Prozesse eines Unternehmens. Die New School of IT strahlt also auf das ganze digitale Unternehmen aus. Das bringt ein paar Risiken und viele Chancen mit sich. Und es erfordert von allen Beteiligten eine aktive Begleitung des anstehenden Veränderungsprozesses.

Geschrieben von
Volker Gruhn
Volker Gruhn
Prof. Dr. Volker Gruhn gründete 1997 die adesso AG mit und ist heute Vorsitzender des Aufsichtsrats. Er ist Inhaber des Lehrstuhls für Software Engineering an der Universität Duisburg-Essen. Sein Forschungsschwerpunkt in diesem Bereich bezieht sich auf mobile Anwendungen. Prof. Dr. Gruhn ist Autor und Coautor von rund 200 nationalen und internationalen Veröffentlichungen und Konferenzbeiträgen.
Thomas Franz
Thomas Franz
Dr. Thomas Franz ist Entrepreneur, Wissenschaftler und Technologieexperte für die adesso AG. Er interessiert sich für Methoden der agilen Geschäftsentwicklung wie Lean Startup und insbesondere dem Zusammenspiel mit neuen technologischen Treibern.
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.