Was mache ich jetzt? Planung für Designänderungen

Sehr häufig sehe ich mich in der Situation, mit Menschen über ihre Systemdesigns, Pläne und Architekturen zu sprechen. Und oftmals findet diese Diskussion zu spät statt, und die Designs sind entweder bereits umgesetzt oder teilweise umgesetzt. Dies kann sehr frustrierend sein, wenn das in Arbeit befindliche Design als für die Situation nicht ideal eingestuft wurde.

Ich verstehe das Gefühl der Frustration, das aus einer solchen Situation entsteht, doch es ist etwas, dem wir in der IT sehr regelmäßig begegnen müssen, und der konstruktive Umgang mit dieser Reaktion ist eine zentrale IT-Kompetenz. Wir müssen in dieser Situation sowohl in technischer als auch in emotionaler Hinsicht zu Meistern werden. Wir sollten uns dadurch nicht lähmen lassen, es ist eine natürliche Situation, die jeder IT-Fachmann regelmäßig erleben wird. Sie sollte weder entmutigend noch lähmend sein, doch es ist sehr verständlich, dass sie sich so anfühlen kann.

Ein wesentlicher Grund, warum wir dies so häufig erleben, liegt darin, dass die IT ein riesiges Feld mit einer großen Zahl von Variablen ist, die in jeder Situation zu berücksichtigen sind. Es ist zudem ein hochgradig kreatives Feld, in dem es zahlreiche praktikable Ansätze für jedes gegebene Problem geben kann. Dass es überhaupt eine einzige „beste“ Option gibt, ist selten der Fall. Normalerweise gibt es viele konkurrierende Optionen. Manchmal sind diese sehr eng miteinander verwandt, manchmal sind diese Optionen drastisch unterschiedlich, was einen sinnvollen Vergleich sehr schwierig macht.

Ein weiterer wesentlicher Grund ist, dass sich Faktoren ändern. Dies kann bedeuten, dass neue Techniken oder Informationen ans Licht kommen, neue Produkte veröffentlicht werden, Produkte aktualisiert werden, sich Preise ändern oder sich geschäftliche Anforderungen kurz vor oder sogar während der Entscheidungs- und Designprozesse ändern. Diese Veränderungsgeschwindigkeit ist nichts, was wir als IT-Fachleute jemals zu kontrollieren hoffen können. Es ist etwas, das wir akzeptieren und so gut wie möglich bewältigen müssen.

Eine weitere Sache, die ich oft übersehen sehe, ist, dass eine Lösung, die zum Zeitpunkt ihrer Erstellung ideal war, möglicherweise nicht ideal wäre, wenn dieselbe Entscheidung heute getroffen würde. Dies stellt in keiner Weise einen Mangel im ursprünglichen Design dar, und doch habe ich viele Menschen erlebt, die darauf so reagierten, als ob es das täte. Das häufigste Szenario, in dem ich Menschen dieses Verhalten zeigen sehe, ist die Abneigung gegen die Verwendung von RAID 5 im modernen Speicherdesign, wobei RAID 6 und RAID 10 aus gutem Grund die beliebten Alternativen sind. Doch diese Abneigung gegen RAID 5, die etwa seit 2009 verbreitet ist, existierte nicht immer, und von Mitte der 1990er Jahre bis fast zum Ende der 2000er Jahre war RAID 5 nicht nur praktikabel, es war sehr häufig die beste Lösung für die gegebenen geschäftlichen und technischen Anforderungen (die zunehmende Abneigung dagegen verlief größtenteils allmählich, nicht plötzlich). Viele Menschen betrachten RAID 5 jedoch verständlicherweise als schlechte Option für heute, wenden aber diese neue Abneigung auf Systeme an, die vor langer Zeit, manchmal vor fast zwei Jahrzehnten, entworfen und implementiert wurden. Das ergibt keinen Sinn und ist eine rein emotionale Reaktion. Dass RAID 5 im Jahr 2002 die beste Wahl für ein Szenario war, bedeutet keineswegs, dass es im Jahr 2015 immer noch die beste Wahl sein wird. Doch ebenso schmälert oder negiert die Tatsache, dass RAID 5 im Jahr 2015 eine schlechte Wahl für ein Szenario ist, in keiner Weise die Tatsache, dass es vor einigen Jahren sehr oft eine ausgezeichnete Wahl war.

Ich wurde viele Male gefragt, was zu tun ist, sobald weniger als ideale Designentscheidungen getroffen wurden. „Was mache ich jetzt?“

Zu lernen, was zu tun ist, wenn Perfektion keine Option mehr ist (als ob sie es jemals wirklich war, bei der gesamten IT geht es um Kompromisse), ist eine sehr wichtige Fähigkeit. Die ersten Dinge, die wir angehen müssen, sind die emotionalen Probleme, da diese alles andere untergraben werden. Wir müssen unser Bestes tun, um einen Schritt zurückzutreten, die Situation zu akzeptieren und rational zu handeln. Das Letzte, was wir tun wollen, ist, eine nicht ideale Situation zu nehmen und die Dinge zu verschlimmern, indem wir versuchen, schlechte Entscheidungen rückwirkend zu rechtfertigen oder in Panik zu geraten.

Zu akzeptieren, dass kein Design perfekt ist, dass es keinen Weg gibt, immer alles vollkommen richtig zu machen, und dass der Umgang damit einfach Teil der Arbeit in der IT ist, ist der erste Schritt. Treten Sie einen Schritt zurück, atmen Sie tief durch. So schlimm ist es nicht. Dies ist keine einzigartige Situation. Jeder IT-Profi, der Designarbeit leistet, durchlebt dies ständig. Sie sollten Ihr Bestes geben, um die bestmöglichen Entscheidungen zu treffen, aber Sie müssen auch akzeptieren, dass dies nur selten möglich ist – niemand hat Zugang zu genügend Ressourcen, um dies wirklich tun zu können. Wir arbeiten mit dem, was wir haben. Also stehen wir nun hier. Was kommt als Nächstes?

Als Nächstes gilt es, die Situation einzuschätzen. Wo stehen wir jetzt? In vielen Fällen ist die Implementierung abgeschlossen, und es gibt nichts weiter zu tun. Die Situation ist nicht ideal, aber ist sie schlecht? Sehr oft besteht der größte Fehler, den ich bei Menschen sehe, die mit einem bereits implementierten Design konfrontiert sind, darin, dass es zu kostspielig ist – typischerweise sind „bessere“ Lösungen nicht besser, weil sie schneller oder zuverlässiger sind, sondern besser, weil sie günstiger, einfacher oder schneller umzusetzen sind. Das ist eine bedauerliche Situation, aber kaum eine lähmende. Welche Zeit oder welches Geld auch immer ausgegeben wurde, muss zum damaligen Zeitpunkt ein akzeptabler Betrag gewesen und genehmigt worden sein. Das Beste, was wir jetzt tun können, ist, aus dem Entscheidungsprozess zu lernen und zu versuchen, die Mehrausgaben in der Zukunft zu vermeiden. Es bedeutet nicht, dass die bestehende Lösung nicht funktionieren oder gar nicht hervorragend funktionieren wird. Es ist lediglich so, dass sie angesichts der involvierten geschäftlichen Anforderungen, vor allem der finanziellen, möglicherweise nicht die perfekte Wahl war.

Es gibt Situationen, in denen ein implementiertes Design die genannten geschäftlichen Anforderungen nicht angemessen erfüllt. Dies ist nach meiner Erfahrung glücklicherweise weniger häufig, da es eine wesentlich schwierigere Situation ist. In diesem Fall müssen wir einige Änderungen vornehmen, um unsere geschäftlichen Anforderungen zu erfüllen. Dies kann sich als teuer oder komplex erweisen. Doch die Dinge sind möglicherweise nicht so schlimm, wie sie scheinen. Oft sind die Reaktionen darauf irreführend, und die Situation kann häufig gerettet werden.

Der erste Schritt, sobald wir uns in einer Lage befinden, in der wir eine Lösung implementiert haben, die die geschäftlichen Anforderungen nicht erfüllt, besteht darin, die geschäftlichen Anforderungen neu zu bewerten. Dies soll nicht bedeuten, dass wir die Anforderungen verfälschen sollten, um sie so zurechtzubiegen, dass sie dem entsprechen, was unser System zu erfüllen vermag, ganz und gar nicht. Aber es ist ein guter Zeitpunkt, um zurückzugehen und zu prüfen, ob die ursprünglich genannten Anforderungen wirklich gültig sind oder ob sie einfach nicht gründlich genug überprüft wurden, oder, was noch wahrscheinlicher ist, zu prüfen, ob sich die geschäftlichen Anforderungen während der Zeit der Implementierung geändert haben. Es kann sein, dass die implementierte Lösung tatsächlich die realen geschäftlichen Anforderungen erfüllt, selbst wenn diese ursprünglich falsch formuliert wurden oder weil sich die Anforderungen im Laufe der Zeit geändert haben. Oder es kann sein, dass sich die geschäftlichen Anforderungen so dramatisch verändert haben, dass selbst eine perfekte Planung ursprünglich hinter den bestehenden Anforderungen zurückgeblieben wäre, und die Tatsache, dass die implementierte Lösung nicht wie erwartet funktioniert, von geringer Bedeutung ist. Ich war sehr überrascht, wie oft diese Überprüfung der geschäftlichen Anforderungen eine als unzureichend geltende Lösung in eine „überdimensionierte“ Lösung verwandelt hat, die tatsächlich mehr kostete als nötig, einfach weil niemand übertriebenen Darstellungen geschäftlicher Anforderungen widersprach oder niemand den finanziellen Wert bestimmter Technologieinvestitionen hinterfragte.

Der zweite Schritt besteht darin, eine neue Technologie-Baseline zu schaffen. Dies ist ein sehr wichtiger Schritt, um zu verhindern, dass die IT in die Falle des Sunk-Cost-Fehlschlusses tappt. Es ist äußerst verbreitet, dass jeder – dies ist in keiner Weise einzigartig für die IT – auf die für ein Projekt aufgewendete Zeit und das aufgewendete Geld blickt und annimmt, dass das Weiterverfolgen des ursprünglichen Pfades, so töricht er auch sein mag, der richtige Weg ist, weil bereits so viele Ressourcen für diesen Pfad aufgewendet wurden. Doch das ergibt natürlich keinen Sinn, denn wie Sie zu Ihrem aktuellen Zustand gelangt sind, ist irrelevant. Was relevant ist, ist die Bewertung der aktuellen Anforderungen der Abteilung und des Unternehmens sowie die Bestandsaufnahme der derzeit verfügbaren Lösungen, Technologien und Ressourcen. Angesichts des aktuellen Zustands kann der beste weitere Kurs bestimmt werden. Jede Berücksichtigung des Aufwands, der zur Erreichung des aktuellen Zustands betrieben wurde, ist lediglich irreführend.

Ein gutes Beispiel für den Sunk-Cost-Fehlschluss findet sich im Schachspiel. Bei jedem Zug ist es wichtig, alle verfügbaren Züge, Risiken und Strategien erneut zu bewerten, denn welche Züge verwendet wurden, um zum aktuellen Zustand zu gelangen, hat keinen Einfluss darauf, welche Züge in der Zukunft sinnvoll sind. Würde man den besten Schachspieler der Welt oder einen großartigen Computer-Schachalgorithmus mitten im Spiel hinzuziehen, bräuchten sie keinerlei Wissen darüber, wie der aktuelle Zustand zustande gekommen ist – sie würden einfach den aktuellen Zustand bewerten und darauf aufbauend eine Strategie entwickeln.

Genauso sollten wir uns in der IT verhalten. Unser aktueller Zustand ist unser aktueller Zustand. Für die strategische Planung spielt es keine Rolle, was sich abgespielt hat, um uns in diesen Zustand zu bringen. Diese Entscheidungen und Kosten interessieren uns nur, wenn wir einen Post-mortem-Prozess durchführen, um festzustellen, wo die Entscheidungsfindung versagt haben könnte, um daraus zu lernen. Über uns selbst und unsere Prozesse zu lernen, ist sehr wichtig. Doch das ist eine ganz andere Aufgabe als die strategische Planung für die aktuelle Initiative.

Das Unglückliche hierbei ist, dass wir unsere Planungsprozesse von Neuem beginnen müssen, diesmal jedoch, so nehmen wir an, mit mehr Material, mit dem wir arbeiten können. Doch dies lässt sich nicht vermeiden. Im schlimmsten Fall stehen keine Budgets mehr zur Verfügung, und es gibt keine Ressourcen, um das fehlerhafte Design zu beheben und die notwendigen Geschäftsziele zu erreichen. Kompromisse sind manchmal notwendig. Mit dem auszukommen, was wir haben, ist manchmal das Beste, was wir tun können. Doch in der überwiegenden Mehrheit der Fälle scheint es, dass eine Kombination aus zusätzlichem Budget oder kreativer Wiederverwendung bestehender Produkte ausreichen kann, um die Situation zu beheben.

Sobald wir einen Zustand erreicht haben, in dem wir unsere Defizite angegangen sind – sei es einfach durch die Akzeptanz, dass wir zu viel ausgegeben oder zu wenig geliefert haben, oder durch Anpassungen, um den Anforderungen gerecht zu werden – haben wir die Gelegenheit, zurückzugehen und unsere Entscheidungsprozesse zu untersuchen. Indem wir dies tun, hoffen wir, als Einzelpersonen und, wenn irgend möglich, auf organisatorischer Ebene zu wachsen, um aus unseren Fehlern zu lernen oder festzustellen, ob es überhaupt Fehler gab. Jedes Unternehmen und jede Einzelperson macht Fehler. Was uns unterscheidet, ist die Fähigkeit, aus ihnen zu lernen und dieselben Fehler in der Zukunft zu vermeiden. Wachstum entsteht in erster Linie aus dem Erleben von Schmerz auf diese Weise, und obwohl es oft unangenehm ist, sich dem zu stellen, haben wir gerade hier die beste Gelegenheit, echten, dauerhaften Wert zu schaffen. Schieben Sie diese Gelegenheit zur Überprüfung nicht auf und überspringen Sie sie nicht, sei es eine harte, persönliche Überprüfung, die Sie selbst durchführen, oder eine formelle, organisatorische Überprüfung, die von dafür geschulten Personen durchgeführt wird, oder etwas dazwischen. Je früher die Entscheidungsprozesse bewertet werden, desto frischer wird die Erinnerung sein und desto eher kann die Kurskorrektur Wirkung zeigen.

Der letzte Schritt, den wir tun können, besteht darin, den Entscheidungsprozess zur Gestaltung eines Ersatzes für die aktuelle Implementierung so bald wie möglich zu beginnen, sobald die Überprüfung des Entscheidungsprozesses abgeschlossen ist. Dies bedeutet nicht zwangsläufig, dass wir beabsichtigen sollten, in naher Zukunft Geld auszugeben oder unsere Designs zu ändern. Ganz und gar nicht. Doch indem wir bei der Entscheidungsfindung äußerst proaktiv sind, können wir versuchen, die Probleme der Vergangenheit zu vermeiden, indem wir uns zusätzliche Zeit für die Planung verschaffen, mehr Zeit für die Anforderungserhebung und Dokumentation, besseren Einblick in Veränderungen der Anforderungen im Laufe der Zeit, indem wir diese Anforderungen regelmäßig erneut betrachten, um zu sehen, ob sie stabil bleiben oder sich verändern, mehr Gelegenheit, die Zustimmung und das Engagement von Management und Kollegen für die Entscheidung zu gewinnen, und ein besseres Verständnis des Problembereichs, sodass wir besser gerüstet sind, das beabsichtigte Design zu ändern oder zu wissen, wann wir es verwerfen und von vorne beginnen sollten, bevor wir es das nächste Mal implementieren. Es könnte uns zudem potenziell eine bessere Chance geben, organisatorisches Wissen zu kodifizieren, das an einen Nachfolger weitergegeben werden könnte, falls Sie selbst beim nächsten Zyklus nicht mehr in der Position der Entscheidungsfindung oder Implementierung sind.

Mit guten, rationalen Prozessen und einem guten Verständnis der Schritte, die im Falle eines weniger als idealen Systemdesigns oder einer weniger als idealen Implementierung unternommen werden müssen, können wir uns von Fehltritten erholen und uns nicht nur, in den meisten Fällen, kurzfristig von ihnen erholen, sondern auch die Organisation vor denselben Fehlern in der Zukunft schützen.