Bild: 21st Century Museum of Contemporary Art, Kanazawa (Ishikawa, Japan), von Saigawasakurabashi, Creative Commons BY-SA

Manifest: © 2013 Jeff Sussna, Ingineering.IT

Übersetzt von Jan Weinschenker. Etablierte englische Fachbegriffe wurden nicht ins Deutsche übersetzt.

Zahlreiche Blogs haben beschrieben, wie Barack Obamas IT-Team das seines Konkurrenten während des Präsidentenwahlkampfs 2012 in dramatischer Art und Weise leistungsmäßig übertroffen hat. Obamas Team lieferte bessere Qualität, bessere Funktionalität und überlegene Ergebnisse für ihre Kampagne – bei signifikant niedrigeren Kosten. Sie erreichten dies unter Verwendung innovativer Werkzeuge und Techniken, wie zum Beispiel Public Cloud Computing [1], DevOps [2], Gameday Testing [3] und Open Source.

Das Vorgehen von Obamas IT-Team erinnert an jene der großen IT-Unternehmen des jungen 21. Jahrhunderts wie Netflix und Facebook. Kritiker haben die Success-Stories dieser Unternehmen als lediglich anwendbar auf nicht-kritische IT-Systeme bezeichnet. Es wäre jedoch schwer, sehr schwer, sich eine Situation vorzustellen, die noch kritischer sein könnte als ein Präsidentschaftswahlkampf. Während der Kampagne 2012 wurde eine Milliarde Dollar investiert, um zu entscheiden, welche Person den Kurs der USA und der ganzen Welt in den kommenden vier Jahren maßgeblich beeinflussen wird. Die Wahl bot weiterhin eine seltene Gelegenheit, den Wettkampf zwischen aktuellen Herangehensweisen und denen des 21. Jahrhunderts zur Lösung vergleichbarer IT-Probleme direkt zu beobachten. Ich denke, aus diesen Gründen dürfen wir auf die Wahl 2012 als das seismische Moment zurückblicken, mit dem die IT des 21. Jahrhunderts aus ihrer Nische kroch und sich eindrucksvoll bewähren konnte.

Was sind also die essentiellen Charakteristiken dieser neuen Art von IT? Wie auch immer wir sie nennen wollen,  “21. Jahrhundert”, “post-industriell”, oder “adaptiv”, was unterscheidet sie von den herkömmlichen Methoden, verkörpert durch die Romney-Kampagne? Ich bin geneigt, diese Frage nicht in Entweder-Oder-Begriffen zu beantworten. Ich orientiere mich an den Zeilen des Agilen Manifestes [4]. Ich biete einen Satz von Strohmann-Argumenten [5] und lade dazu ein, sie weiter zu verfeinern:

1. Wir wertschätzen Belastbarkeit mehr als Stabilität: da sowohl externe Umstände als auch interne Strukturen bei der Verfolgung unserer Ziele komplex sind und sich ständig ändern, ist der Fehlerfall “unser ständiger Begleiter”. Er sollte ganz einfach als erwartetes Ereignis behandelt werden und nicht als Ausnahmefall.
2. Wir wertschätzen die Minimierung der Mean Time To Repair (MTTR) mehr als die Maximierung der Mean Time Between Failures (MTBF): Der unvermeidbare Fehlerfall macht aus der Maximierung der MTBF ein sinnloses Unterfangen. Stattdessen sollte man sich darauf konzentrieren, seine eigene Fähigkeit zu verbessern, Fehlerfälle zu beseitigen. Die dynamische Natur der Märkte bedeutet, dass auch funktionierende IT-Systeme schnell daran scheitern, sich wechselnden Anforderungen anzupassen. Nicht nur der Betrieb, sondern auch die Entwicklung muss es sich zur Aufgabe machen, die MTTR zu minimieren.
3. Wir wertschätzen Elastizität mehr als Planung: Statische Planungen erzeugen oft Lösungen, die sich als unflexibel erweisen, wenn sie mit unvorhergesehenen Situationen umgehen müssen. Elastizität behandelt Unvorhersehbarkeit als Teil des Plans.
4. Wir wertschätzen leichtgewichtige Werkzeuge mehr als umfassende Lösungen: je globaler, umfassender und straffer strukturiert die Dinge sind, desto schwieriger lassen sie sich anpassen, ändern oder reparieren.
5. Wir wertschätzen lose Kopplung mehr als Koordination: je komplizierter die Situation ist, umso mehr Overhead ist notwendig, um sie zu koordinieren, was auch wieder die Koordination an sich erschwert. Die Anpassungsfähigkeit wird gesteigert, wenn man die einzelnen Bestandteile einer Lösung unabhängig voneinander bewegen kann, solange man sie koordinieren muss.
6. Wir wertschätzen kontinuierliche Innovation mehr als Best Practices: der traditionelle Ansatz, Best Practices zu definieren, aufzuschreiben und zu propagieren, kann niemals mit dem kontinuierlichen Wandel mithalten. Stattdessen sollte Innovation selbst ein kontinuierlicher Prozess sein.
7. Wir wertschätzen Vielfalt mehr als Monokultur: gezwungenes Festhalten an einem Satz von Werkzeugen und Praktiken verringert die Chancen zu lernen, zu ändern und sich zu entwickeln – und verlangsamt gleichzeitig die Selektion, Implementierung und Verbreitung neuer Werkzeuge und Praktiken.
8. Wir wertschätzen Open-Source-Communities mehr als hierarchische Organisationen: Das Open-Source-Modell bietet einen Mechanismus zum Ausgleich der offenkundlich im Konflikt stehenden Bedürfnisse nach Zusammenhalt und Flexibilität.
9. Wir wertschätzen gemeinsame Zielsetzung mehr als Vereinzelung und Spezialisierung: Dienstleistung für den Kunden ist das übergeordnete Ziel für alle Mitarbeiter, unabhängig von ihrer Rolle oder ihrer Position im Organigramm. Neue Funktionalität, die Qualität dieser Funktionalität, ihre Bedienbarkeit und die Art und Weise ihrer Kommunikation an die Kunden sind alle untrennbar miteinander verbunden. Und so sollten es auch die Menschen, Prozesse und Werkzeuge sein, die sie ausliefern.

Externe Verweise

[1] Wikipedia-Artikel über Public Cloud Computing

[2] Wikipedia-Artikel über DevOps

[3] Game-Day Testing, ein aufwendiges Verfahren, um ein IT-System unter Real-Bedingungen auf Belastbarkeit und Ausfallsicherheit zu testen. Dabei treten zwei Mannschaften gegeneinander an: die Angreifer, die das System zum Zusammenbruch bringen müssen und die Verteidiger, die ebendies verhindern sollen.

[4] Das Agile Manifest

[5] Wikipedia-Artikel über Strohmann-Argumente