Buchkritik: A new Seat At The Table oder Warum der CIO kein Platz am Tisch des Top-Managements verdient

Was Rolle spielt eigentlich der CIO im Kontext von Agilität und Digitalisierung?

Eine Frage, die mich und sicherlich auch viele andere bewegt ist folgende: Welche Rolle spielt der IT-Manager, der Entwicklungsleiter oder der CIO eigentlich im Kontext von agilen Arbeitsformen? Ist der Manager wirklich nur Coach, Ratgeber und ansonsten derjenige, der sich am Besten aus allem raushält und den Müll wegbringt? So sieht beispielsweise der Scrum-Prozess für das Management überhaupt keine Prozessrolle vor.

Mit Interesse habe ich daher das Buch von Mark Schwartz „A Seat At The Table“ gelesen, der versucht die Rolle des CIO vor dem Hintergrund Agilität und Digitalisierung neu zu positionieren. Natürlich mit der Absicht, dem CIO wirklich einen glaubwürdigen Sitz beim Top-Management zu verschaffen. Dazu werden einige, scheinbar haarsträubende Thesen aufgestellt, die aber eine nähere Betrachtung wert sind.

Ich habe mir in diesem Text vorgenommen, zunächst einige Grundbegriffe zu erläutern, weil ich ehrlich gesagt nicht weiß, ob man jeden Begriff einfach so ohne Kontext voraussetzen kann. Nach der Begriffsbestimmung geht es ans Eingemachte und ich beschreibe 5 Thesen aus dem Buch, die mich inspiriert oder zum Nachdenken gebracht haben. Ich sage eines vorweg, ich stimme (noch) nicht allen Positionen vorbehaltlos zu, aber sie regten zumindest ich gehörig zum Nachdenken an..

Fangen wir mal mit einigen Begriffen an:

IT-Management: Betrieb vs. Entwicklung?

Wenn man sehr vereinfacht die Aufgaben einer IT-Abteilung in einer Organisation beschreiben will, dann verbleiben gerade einmal zwei Hauptaktivitäten:

a) Die Bereitstellung und der (sichere, stabile, etc.) Betrieb von IT-Lösungen . b) Die Entwicklung von neuen IT-Lösungen

Beide Aktivitäten sind organisatorisch oft getrennt und die Trennung wird sogar in der klassischen IT-Literatur ausdrücklich empfohlen.

Beide Aktivitäten, also Betrieb und Entwicklung verfolgen naturgemäß sehr unterschiedliche Ziele:

• Der Betrieb versucht Veränderungen an der IT zu kontrollieren und auf das notwendige Minimum zu reduzieren zum Zweck der Stabilität und Verfügbarkeit.
• Die Entwicklung möchte zeitnah Lösungen für das Geschäft bereitstellen und ist an häufigen Veränderungen der IT interessiert (Time to market).

Wir haben hier also einen Zielkonflikt, der sich manchmal sogar in der Mentalität der handelnden Personen niederschlägt. Oft genug hatte ich in der Vergangenheit den Eindruck, dass beide Parteien kaum oder gar nicht kommunizieren. Manchmal mögen sich Betrieb und Entwicklung noch nicht einmal besonders.

Agile Softwareentwicklung

Im Jahr 2018 muss man den Begriff Agilität kaum noch kommunizieren aber dennoch, ich erläutere einfach mein Verständnis: Nach vielen schweren Krisen in Softwareprojekten suchten IT-Experten im Jahr 2001 nach Auswegen und Ideen zur Verbesserung der Software-Entwicklung. Es wurde das Agile Manifest mit 4 Werten und 12 Prinzipien erarbeitet. Agil bedeutet nicht schnell, sondern steht für eine Arbeit in interdisziplinären Teams, die in kleinen Zyklen selbstorganisiert und selbstreflektierend arbeiten. In vielen Frameworks für Agile Entwicklung ist der IT-Manager nur ein Randthema. Entweder ist er nur ein Kümmerer für die Teams oder er sorgt für „Rahmenbedingungen“ bzw. Leitplanken. Aber ansonsten soll er sich heraushalten. Technische Kenntnisse sind weder erforderlich noch gewünscht.

DevOps - IT-Betrieb und Entwicklung Hand in Hand

Ermutigt durch den Erfolg der agilen Methoden und der dramatischen Veränderung der Software-Entwicklung Beispielsweise durch die Container-Technologie entstand die DevOps Bewegung. Die Idee ist der Zusammenschluss von Entwicklung (Development) und Betrieb (Operations) zu einer Einheit, den DevOps (Dev+Ops). Bei DevOps handelt es sich nicht um ein Framework mit genauen Prozessbeschreibungen, wie ITIL oder SCRUM, sondern wirklich nur eine Philosophie. Es gibt sogar Menschen die sagen, dass es für DevOps keine organisatorischen Veränderungen bedarf. Da bin ich wiederum eher skeptisch.

Maßgebend sind aber folgende Ideen:

• Es wird kontinuierlich und immer in die Produktion ausgerollt.
• Es wird kompromißlos automatisiert. Und zwar alles ohne Ausnahme.
• Mitarbeiter aus Entwicklung, Test und Betrieb arbeiten als ein interdisziplinäres Team. und sind alle für das Verhalten der Software beim Kunden verantwortlich.

DevOps ist in meinen Augen der dramatischste Schritt seit dem Agilen Manifest. Es wird nicht mehr nur ein Teilausschnitt einer Entwicklungsphase betrachtet, sondern alle Aspekte der Entwicklung und des Betriebes von IT-Lösungen.

Für ein DevOps Team besteht die Welt nicht aus Atomen, sondern aus Bits. Das vollständige Produkt steht in einer Versionsverwaltung und lässt sich bis hin zum Kunden „auf Knopfdruck“ generieren. Damit ist Software und die Infrastruktur zum Betrieb der Software gemeint. Ohne neue und moderne Virtualisierungstechniken, wäre dieser Ansatz gar nicht denkbar.

Wer ist überhaupt dieser Mark Schwartz?

Mark Schwartz ist und war langjähriger CIO in verschiedenen Unternehmen. Zuletzt arbeitete er als CIO in der US Bundesbehörde für Einwanderung und Immigration. Er geht der Frage nach, wie kann man den Business Value, also den Wertbeitrag der IT wirklich messen kann und wie Agile Methoden erfolgreich im IT-Management genutzt werden kann.

Nun aber zu den 5 inspirierenden Punkten:

These 1: Exakte Spezifikationen sind kritisch und sollten vermieden werden.

Wir haben alle gelernt: Gute Angebote kann die IT nur bereitstellen, wenn es exakte Anforderungen, Spezifikationen oder Requirements gibt. Je exakter und besser diese formuliert sind, desto besser entspricht das Ergebnis den Anforderungen. Das bestreitet auch keiner.

Das Problem liegt woanders: In einer zunehmend komplexeren Welt kann im Vorfeld keiner exakt beschreiben , was zum Zeitpunkt X wirklich benötigt wird. Selbst wenn das gelingen würde, wäre die Anforderung zum Zeitpunkt X+1 wieder anders.

Schwartz sagt daher, dass man statt von Spezifikationen eher von Annahmen oder Thesen reden sollte, und die Lerneffekte der Realität angepasst werden sollten. Exakte Spezifikationen festigen das Verhältnis der IT als Dienstleister und bilden die Gefahr, dass Business Value (Geschäftswerte) verringert werden.

Für mich spannend: Mit der Kritik an den Spezifikationen hebelt Schwartz auch gleich mal das gesamte Fundament des IT Service Managements, welches auf klaren Spezifikationen, Vereinbarungen und Service Level Agreements basiert.

Mit der agilen Brille betrachtet: Stimmt, User Stories sind eben keine exakten Spezifikationen, sondern Geschichten. Eine Geschichte ist keine exakte Spezifikation, sondern eine Umschreibung eines antizipierten Nutzens.

These 2: Make or Buy ist heute völlig anders zu denken: Make ist das neue Buy! (oder Software killt the Hardware-Star)

Weiterhin ist es bei allen Entscheidungen wichtig zu prüfen, ob eine Lösung gekauft, bezogen oder selbst entwickelt wird. Das kennt man als Make or Buy. Die klassische IT-Lehre sagt: Der Kauf sollte stets bevorzugt werden. Die Gründe dafür liegen (scheinbar) auf der Hand:

• Eine Lösung am Markt kann beschafft und nach Konfiguration und Einrichtung sofort genutzt werden.
• Die Risiken der Nutzung sind im Vergleich zu einer Neuentwicklung ungleich geringer, da die Lösung sich ja schon am Markt bewährt hat.
• Die Kosten sind kalkulierbar

Mark Schwartz behauptet, das Gegenteil ist jetzt der Fall. Heute sollte für alle IT-Anwendungen, die in irgendeiner weise für das Unternehmen angepasst werden müssen, neu entwickelt werden. Sogar CRM-Systeme.

Das hört sich völlig verrückt an, aber es gibt in der Tat sehr überzeugende Argumente, die für Organisationen aber einer gewissen Größe (zu der Mark Schwartz nichts sagt), zutreffen können:

• Fangen wir an mit dem Problem der Spezifikationen. Zunächst werden diese erhoben aber bleiben diese auch endlos gültig? Nein, das Unternehmen verändert sich, die Anforderungen ändern sich. Reagiert der Lieferant dann wie gewünscht? Natürlich nicht, er verfolgt völlig andere Ziele, da der Hersteller natürlich andere Kunden gewinnen möchte. Anforderungen für firmenspezifische Anforderungen verhallen.

• Viel wichtiger für mich ist das von Mark Schwartz angeführte Argument der Gesamtkosten. Eine gute Integration der Lösung in das Gesamtunternehmen ist zwingen für die Digitalisierung erforderlich. Schnittstellen, Integration und oft auch der Betrieb treiben die Kosten hoch. Am Ende ist es oft so, dass die bezogene Lösung sich nur schlecht in die anderen Unternehmensprozesse integrieren lässt, weil erforderliche Schnittstellen fehlen.

• Das dritte Argument kann ich als Techniker nachvollziehen. Die gegenwärtige Softwareentwicklung sieht ganz anders aus, als noch vor 10 Jahren. Wir nutzen einen riesigen Schatz an guten und einsatzfähigen Open-Source-Lösungen, Frameworks und Komponenten. Diese Open-Source-Produkte sind ja bereits da und können genutzt werden. Vor diesem Hintergrund wird niemand bei Null anfangen, sondern er nimmt eine (und wahrscheinlich mehrere) Open-Source Lösungen als Grundlage.


• Cloudbasierende Ansätze ermöglichen es heute die Infrastruktur als Software abzubilden. In der extremsten Form des Serverless Computing spielt die Hardware überhaupt keine Rolle mehr. Software hat gewonnen und die Hardware besiegt. Die Hardware wurde so weit wegabstrahiert und virtualisiert, dass diese auf Knopfdruck neu generiert wird.

Natürlich wird es auch weiter den Kauf von Software geben, denn es gibt in der auch stabile Anforderungen. Das sind die klassischen Abrechnungssysteme, Office und Basissoftware, oft auch als Commoditysysteme bezeichnet, aber die starke Argumentation für eine Individualentwicklung hat mich verblüfft.

These 3: Die Idee der internen IT als Dienstleister verhindert optimale Lösungen für das Business

Die Grundannahme des IT-Managements ist das Paradigma des internen Service Provider. Die IT liefert dem Business, als dem Rest des Unternehmens definierte Services in definierten Qualitäten. Oberstes Ziel des Ganzen ist es, die IT-Kosten in den Griff zu kriegen und auf der anderen Seite ein stabiles und sicheres IT-System aufzubauen.

Mark Schwartz führt hier aus, dass die schlimmste Form des Dienstleistergedankens die interne Verrechnung von IT-Leistungen ist. Bei der internen Verrechnung soll eine Transparenz zwischen intern erbrachten Leistungen und der am Markt erhältlichen Leistungen erbracht werden. Also Inhouse-IT versus IT-Dienstleister.

Was ist daran falsch, dachte ich mir? Nun, die Kritik von Schwartz setzt hier auf mehreren Ebenen an.

• Ein Punkt dabei ist, dass die IT wieder in eine bewusste Abgrenzung zum Rest des Unternehmens geht. Anstatt am Wertbeitrag und neuen Geschäftsmodellen gemeinsam zu arbeiten geht sie wieder auf Distanz.
• Aus Kollegen werden Geschäftspartner die sich manchmal zähneknirschend auf irgendwelche Vereinbarungen einigen. Diese werden dann im schlimmsten Fall in Service Level Agreements gegossen und zementiert. Zufrieden ist am Ende keiner.

Für mich ist der Gedanke einer völligen Distanzierung zur Service Provider Idee zunächst sehr merkwürdig. Wie kommt es eigentlich dazu? Gut, dazu muss man mal auf die großen IT-Firmen schauen. Ich kann mir auch nicht vorstellen, dass bei Amazon oder Facebook eine neue Idee an die IT-Abteilung angetragen wird und mit dieser über einen neuen Service oder Change-Request verhandelt wird. Digitalisierung und IT ist die Basis des Geschäftsmodells und eine EInheit.

Hier setzt Mark Schwartz an und sagt, dass mittlerweile doch jede Firma in jeder Branche ein Technikshop geworden ist. IT & Digitalisierung machen ca. 30% des Geldeinsatzes aus, wenn man alle Tätigkeiten zusammennimmt. Ein Großteil des Geldes wird laut Schwartz vernichtet, weil es Abgrenzung statt zusammenarbeit gibt. Schaut man auf die neuesten Initiativen von Daimler Benz oder Otto, erscheint diese Argumentation plausibel. Selbstfahrende Autos oder attraktives E-Commerce wird nicht über Service Design von ITIl erarbeitet, sondern Hand in Hand von IT-Leuten, Fachexperten und in enger Abstimmung mit Kunden.

Learning 4: Der CIO sollte aufhören sich für seine IT zu rechtfertigen.

Alle Beratungshäuser sagen, der CIO sitzt am Tisch des TOp-Managements, wenn er den Mehrwert der IT darstellen kann. Zuvor sollte er sich durch eine Reihe von erfolgreichen Projekten aber bewähren. Die Mehrwerte der IT soll er über Kennzahlen darstellen: Beispielsweise Verfügbarkeit, Kosten, Stabilität oder Projekte, die in Zeit und Budget und mit Zufriedenheit der Ergebnisse abgeschlossen wurden.

Auch in der aktuellen CIO-Studie von Ernst & Young, „Die DNA des CIO“ wird genau das empfohlen. E&Y sagt dann aber auch, dass gerade mal 20% der CIO wirklich auf der C-Ebene arbeiten. Woran liegt das?

Schwartz sagt, das ständige Aufzeigen des MEhrwertes der IT durch Kennzahlen, PRäsentation oder sonst irgendwas hilft keinem. Die IT bleibt in der Hausmeisterrolle. Sie hält das LIcht am Leuchten und sollte möglichst nichts kostne.

Das einzige was zählt ist die Ausgestaltung der Geschäftsziele durch IT. Die Verlagerung der Argumentation geht also von der Rechtfertigug hin zur Gestaltung. Das bedeutet, dass die IT in die Abteilungen muss und dort mit unterstützt.

Learning 5: Keine Planung der Welt verhindert Risiken, Experimente tun es.

Für mich nicht neu, aber wichtig. Eine der Kerndisziplinen der IT ist das Management von Risiken, Bedrohungen oder Gefahren. Ich halte das Managen dieser Dinge für sehr wichtig. Mark Schwartz widerspricht und sagt, die wahren Probleme lassen sich nicht durch Planung verhindern, man muss diese Probleme prüfen. Statt Risiken durch Planung zu vermeiden, sollten diese durch Experimente geprüft werden.

Diese Aussage steht im EInklang mit dem Lean Management. Das Lean Management verlangt genau das. Die empirische Prüfung von Thesen. Eine wichtige Methode ist das sogenannte A/B Testing. Wenn man zwischen zwei Alternativen sich entscheide muss, kann man diese Alternativen mit sogenanten Minimalprodukten ausprobieren. Machen also vor planen.

Mein Resümee

Aus meiner Sicht ist das buch von Mark Schwartz ein erster Schritt in eine neue Diskussion für die IT, aber noch keine abschließende Lösung. Viele Ideen und Thesen passen für Organisationen einer gewissen Größenordnung. Voraussetzung ist Mut. Der Mut neues zu wagen und der Mut, die Digitalisierung als Fundament des heutigen Geschäftsmodells zu begreifen.

Dazu gehört eine fundamentale Einsicht, an der in Deutschland wir noch etwas zu knabbern haben:

Digitalisierung eats the world##

Und das bedeutet nicht, dass wir neue Hardware oder schnellere Maschinen brauchen, sondern die Zukunft liegt in den Mädels und Jungs, die Digitalisierung und Software so richtig gut können