Eleganz der Lösung

Es ist sehr leicht, sich bei der Arbeit in der IT auf große, komplexe Lösungen zu konzentrieren. Es scheint, als müssten genau dort die guten Lösungen liegen – große Lösungen, viel Software, all die neuesten Geräte. Was wir tun, ist aufregend, und es ist sehr leicht, sich von der Dynamik mitreißen zu lassen. Es macht Spaß, anspruchsvolle, große Projekte zu verwirklichen. Zu hören, was andere IT-Fachleute tun, wie andere Unternehmen Herausforderungen lösen, und mit Anbietern zu sprechen, die uns allen große Systeme verkaufen wollen, trägt zusätzlich zur Begeisterung bei, und es ist sehr leicht, den Sinn für Umfang und Ziel zu verlieren; und es ist so verbreitet, übertriebene, überzogene Lösungen für einfache Probleme zu sehen, dass es scheint, als müsste die IT eben genau so sein.

Doch das muss nicht so sein. Komplexität ist der Feind sowohl der Zuverlässigkeit als auch der Sicherheit. Unnötig komplexe Lösungen erhöhen die Kosten sowohl bei der Anschaffung als auch bei der Implementierung sowie bei der Wartung, während sie zugleich im Allgemeinen langsamer und fragiler sind und eine große Angriffsfläche besitzen, die schwerer zu durchschauen und zu schützen ist. Einfache oder, treffender gesagt, elegante Lösungen sind der beste Ansatz. Das bedeutet nicht, dass alle Designs einfach sein werden, ganz und gar nicht. Komplexe Designs sind häufig erforderlich. Die IT ist kaum ein Fachgebiet, dem es an Komplexität mangelt. Tatsächlich wird oft angenommen, dass die Softwareentwicklung das komplexeste aller menschlichen Unterfangen sein könnte, zumindest unter jenen, die in irgendeinem Maßstab betrieben werden. Eine typische IT-Installation umfasst Millionen von Codezeilen, Hunderte oder Tausende von Protokollen, eine große Zahl miteinander verbundener Systeme, Schichten einzigartiger Softwarekonfigurationen, mehr Einstellungen, als ein Team jemals kennen könnte, und erst dann fügen wir die Komplexität von Hunderten oder Tausenden oder Hunderttausenden unberechenbaren, irrationalen Menschen hinzu, die versuchen, diese Systeme zu nutzen, jeder auf seine eigene Weise. Die IT ist ohne jeden Zweifel komplex.

Wichtig ist, anzuerkennen, dass die IT komplex ist, dass sich dies nicht vollständig vermeiden lässt, aber den Fokus darauf zu legen, Lösungen so einfach, so anmutig … so elegant wie möglich zu entwerfen und zu konstruieren. Diese Designidee stammt, zumindest in meinen Augen, aus der Softwareentwicklung, wo komplexer Code als Fehler angesehen wird und einfacher, schöner Code, der leicht zu lesen und leicht zu verstehen ist, als gelungen gilt. Eine der höchsten Auszeichnungen, die einer Softwareingenieurin zuteilwerden kann, ist, dass ihr Code als elegant bezeichnet wird. Wie passend, dass dieses berühmte Zitat Blaise Pascal zugeschrieben wird, nach dem eine der populärsten Programmiersprachen der 1970er- und 1980er-Jahre benannt wurde (schlecht aus dem Französischen übersetzt): “Ich bedaure, dass ich Ihnen einen so langen Brief schreiben musste, doch ich hatte nicht die Zeit, Ihnen einen kurzen zu schreiben.”

Es ist oft weitaus einfacher, komplexe, verschachtelte Lösungen zu entwerfen, als zu ermitteln, welcher einfache Ansatz genügen würde. Ob wir nun in Eile sind oder nicht wissen, wo wir mit einer Untersuchung beginnen sollen – Eleganz ist stets eine Herausforderung. Die Dynamik der Branche treibt dazu, den schwierigeren Weg zu fördern. Es liegt im Interesse der Anbieter, mehr Geräte zu verkaufen, nicht nur, um den ersten Verkauf zu tätigen, sondern weil sie wissen, dass mit mehr Ausrüstung auch mehr Support-Einnahmen einhergehen, und wenn genügend neue, komplexe Ausrüstung verkauft wird, hört der Support-Bedarf auf, linear zu wachsen, und beginnt geometrisch zu wachsen, da zusätzlicher Support nicht nur für die Ausrüstung oder Software selbst benötigt wird, sondern auch für die Konfiguration und Unterstützung von Systeminteraktionen oder zusätzlicher Anpassungen. Die finanziellen Einflüsse hinter der Komplexität sind beträchtlich, und sie enden nicht bei den Anbietern. IT-Fachleute gewinnen viel Arbeitsplatzsicherheit, oder die Illusion davon, indem sie große Bestände an Hard- und Software verwalten, die sich nur schwer nahtlos an einen anderen IT-Fachmann übergeben lassen.

Häufig wird Komplexität derart vorausgesetzt, derart erwartet, dass der Prozess der Auswahl einer Lösung von vornherein mit großer Komplexität als ausgemachter Sache beginnt, ohne dass auch nur in Erwägung gezogen wird, dass eine weniger komplexe Lösung genügen könnte oder – abgesehen von der Frage der Komplexität und der Kosten selbst – sogar überlegen sein könnte. Komplexität ist bisweilen sogar derart vollständig mit bestimmten Konzepten verknüpft, dass mir tatsächlich Ungläubigkeit gegenüber der Vorstellung begegnet ist, eine einfache Lösung könnte eine komplexe in Preis, Leistung und Zuverlässigkeit übertreffen.

Rhetorik ist einfach, doch wie sieht ein Beispiel aus der Praxis aus? Die besten Beispiele, die ich heute sehe, stehen überwiegend im Zusammenhang mit Virtualisierung, sei es im Hinblick auf Speicher oder auf eine Cloud-Verwaltungsschicht oder Software oder einfach die Virtualisierung selbst. Recht häufig sehe ich, dass ein Gespräch, das sich allein um Virtualisierung dreht, bei manchen Menschen sofort die Assoziation hervorruft, man benötige vernetzten, gemeinsam genutzten Blockspeicher, teure Virtualisierungs-Verwaltungssoftware, viele redundante Virtualisierungsknoten und komplexe Hochverfügbarkeitssoftware – nichts davon ist der Virtualisierung wesenseigen, und das meiste davon dient nur selten dem Zweck, das Unternehmen, für das es implementiert wird, zu unterstützen, oder liegt überhaupt in dessen Interesse. Anstatt von den geschäftlichen Anforderungen auszugehen, entspringen diese Vorstellungen überwiegend technologischen Vorannahmen. Es ist einfach, auf Komplexität zu verweisen und den Anschein zu erwecken, ein Problem zu lösen – Komplexität erzeugt ein Gefühl der Behaglichkeit. Filtert man viele Argumente bis auf den Kern, so hört man “Wie sollte es nicht funktionieren, es ist doch komplex?” Komplexität vermittelt die Illusion von Vollständigkeit, davon, ein Problem gelöst zu haben, doch dies kann häufig die Tatsache verschleiern, dass eine Lösung womöglich gar nicht vollständig oder auch nur funktionsfähig ist – das Maß an Komplexität macht dies jedoch schwer erkennbar. Unser Verstand wird dann nicht ohne Weiteres akzeptieren, dass ein einfacherer Ansatz vollständiger ist und ein Problem löst, während eine komplexe Lösung dies nicht tut, weil es sich so kontraintuitiv anfühlt.

Ein gutes Beispiel hierfür ist, dass wir dazu übergehen, über Redundanz statt über Zuverlässigkeit zu sprechen. Zuverlässigkeit ist schwer zu messen, Redundanz ist einfach zu beziffern. Ein Ziegelstein ist äußerst zuverlässig, selbst als einzelner. Es bedarf keiner Redundanz, damit ein Ziegelstein stabil und robust ist. Sein Aufbau ist einfach. Man könnte aus vielen redundanten Stöcken eine tragende Struktur bauen, die bei Weitem nicht so zuverlässig wäre wie ein einzelner Ziegelstein. Spricht man von Zuverlässigkeit – der Wahrscheinlichkeit, dass die Struktur nicht versagt –, so ist klar, dass der Ziegelstein die überlegene Wahl gegenüber mehreren Stöcken ist. Doch wenn man sagt “aber es gibt keine Redundanz, der Ziegelstein könnte versagen, und es gibt nichts, was an seine Stelle treten könnte”, klingt man albern. Wenn wir jedoch über Computer und Computersysteme sprechen, finden wir Systeme vor, die so komplex sind, dass die Menschen nur selten erkennen, wann sie einen Ziegelstein und wann einen Stock vor sich haben, und so konzentrieren sie sich, da sie die Zuverlässigkeit, auf die es ankommt, nicht bestimmen können, auf die leicht zu beziffernde Redundanz, auf die es nicht ankommt. Das gesamte System ist zu komplex, doch die einfache Lösung zu suchen – jene, die den Kern des zu lösenden Problems unmittelbar adressiert – kann die Komplexität verringern und uns am Ende eine weitaus bessere Antwort liefern.

Dies lässt sich sogar bei RAID beobachten. Gespiegeltes RAID ist einfach: Eine Festplatte oder ein Satz von Festplatten ist lediglich eine exakte Kopie eines anderen Satzes. Es ist so einfach. Paritäts-RAID ist komplex, mit Berechnungen über einen variablen Stripe hinweg, der über viele Geräte verteilt ist und der beim Schreiben kodiert und im Falle eines Geräteausfalls dekodiert werden muss. Gespiegeltem RAID fehlt diese Komplexität, und es löst das Problem der Festplattenzuverlässigkeit durch einfache, elegante Kopiervorgänge, die äußerst zuverlässig und sehr gut verstanden sind. Paritäts-RAID ist unnötig komplex, was es fragil macht. Doch indem es das tut und indem es seine eigene Fähigkeit untergräbt, das Problem zu lösen, für das es entworfen wurde, erscheint es zugleich scheinbar zuverlässiger – aufgrund keines anderen Faktors als seiner eigenen Komplexität. Der menschliche Verstand springt unmittelbar zu “es ist komplex, also ist es fortschrittlicher, also ist es zuverlässiger”, doch keine dieser Schlussfolgerungen ist logisch. Komplexität legt nicht nahe, dass etwas fortschrittlicher ist, und fortschrittlich zu sein legt nicht nahe, dass es zuverlässig ist; doch der menschliche Verstand selbst ist komplex und leicht in die Irre zu führen.

Es gibt keine einfache Antwort darauf, wie man Einfachheit findet. Zu wissen, dass Komplexität ihrem Wesen nach schlecht, zu Zeiten jedoch unvermeidlich ist, lehrt uns Achtsamkeit, doch es lehrt uns nicht, wann wir Überkomplexität zu vermuten haben. Wir müssen wachsam sein und stets danach streben zu ermitteln, ob eine elegantere Antwort existiert, und Komplexität nicht allein deshalb als die richtige Antwort akzeptieren, weil sie komplex ist. Wir müssen vorgeschlagene Lösungen hinterfragen und uns selbst hinterfragen. “Ist diese Lösung wirklich so einfach, wie sie sein sollte?” “Ist diese Komplexität notwendig?” “Erfordert dies die Komplexität, die ich vorausgesetzt hatte?”

Bei den meisten Empfehlungen zum Systemdesign, die ich gebe, ist der erste technische Bestimmungsschritt, den ich normalerweise unternehme – nach dem Schritt, nach dem zu lösenden geschäftlichen Bedarf zu fragen –, die Komplexität zu hinterfragen. Lässt sich Komplexität nicht rechtfertigen, ist sie wahrscheinlich unnötig und untergräbt aktiv den Zweck, für den sie gewählt wurde.

“Ist es wirklich notwendig, diese Laufwerke in viele separate Arrays aufzuteilen? Wenn ja, was ist die technische Rechtfertigung dafür?”

“Ist gemeinsam genutzter Speicher wirklich notwendig für die Aufgabe, für die Sie ihn vorschlagen?”

“Rechtfertigt das Unternehmen wirklich den Einsatz verteilter Hochverfügbarkeitstechnologien?”

“Warum ersetzen wir ein einfaches System, das gestern angemessen war, morgen durch ein dramatisch komplexeres System? Was hat sich verändert, das eine wesentliche Verbesserung – bei gleichbleibender Einfachheit – nicht mehr als ausreichend macht, sondern Größenordnungen mehr an Komplexität und mehr an Ausgaben erfordert, die zuvor nicht gerechtfertigt waren?”

Dies sind nur gängige Beispiele; Komplexität existiert in jedem Aspekt unserer Branche. Suchen Sie nach Einfachheit. Streben Sie nach Eleganz. Akzeptieren Sie Komplexität nicht, ohne sie rigoros zu prüfen. Unterziehen Sie sie der sprichwörtlichen Zerreißprobe. Lassen Sie nicht zu, dass sich Komplexität dort einschleicht, wo sie nicht gerechtfertigt ist. Irren Sie nicht zugunsten der Komplexität – im Zweifel scheitern Sie einfach. Eine Lösung zu stark zu vereinfachen führt in der Regel zu einem geringfügigen Versagen, während sie übermäßig komplex zu gestalten ein weitaus größeres Maß an Versagen ermöglicht. Die sicherere Wette liegt bei der einfacheren Lösung. Und wenn eine einfache Lösung gewählt und als unzureichend erwiesen wird, ist es weitaus leichter, Komplexität hinzuzufügen, als sie zu entfernen.