Die Wahl der Softwareversion für die Bereitstellung

Etwas, das ich in IT-Kreisen sehr häufig diskutiert sehe, ist „welche Version der Software soll ich installieren“. Dies kann auf eine Datenbank, eine Anwendung, Firmware oder, wahrscheinlich am häufigsten, Betriebssysteme zutreffen, und mit dem bevorstehenden Support-Ende für Windows XP hat das Thema einen Fieberhöhepunkt erreicht.

Es gibt im Grunde zwei Seiten dieser Diskussion. Die eine Seite ist der Ansicht, dass stets die neueste und vermutlich beste Software verwendet werden sollte. Die andere ist der Meinung, dass Software reifen muss, und verfolgt einen „Abwarten und Beobachten“-Ansatz oder betrachtet sogar jede Version als ein anderes Produkt und nicht als ein Kontinuum der Entwicklung.

Beide Ansätze haben ihre Vorzüge, und keiner sollte gänzlich ohne den anderen bestehen. Software blind und wahllos zu aktualisieren ist nicht klug, und Patches und Updates ohne Grund zu vermeiden ist ebenfalls nicht klug. Eine sorgfältige Abwägung der Faktoren sowie Verständnis für den Softwareentwicklungsprozess sind wichtig, die man bei diesen Entscheidungen im Hinterkopf behalten sollte.

Zunächst gibt es zwei völlig unterschiedliche Szenarien zu berücksichtigen. Das eine ist die Aktualisierung aktueller, vorhandener Software. Dabei wird angenommen, dass der gegenwärtige Zustand der Dinge „funktioniert“, wobei die anerkannte Möglichkeit besteht, dass „funktioniert“ eine entdeckte Sicherheitslücke einschließen kann, die ein Update erfordert, um sie zu schließen. Das andere Szenario ist eine Neubereitstellung, bei der derzeit nichts vorhanden ist und wir bei null beginnen.

Beginnen wir mit dem zweiten Fall, da es weitaus einfacher ist, dazu Orientierung zu geben.

Im Falle neuer Softwarebereitstellungen (oder neuer Betriebssysteme) verwenden Sie stets die aktuelle, neueste Version der Software, es sei denn, es besteht eine klar bekannte technische Einschränkung, die dies verhindert ?? etwa bekannte Fehler oder Software-Inkompatibilitäten.

Software ist nicht wie andere Arten von Produkten, schon gar nicht in der heutigen Welt der Online-Patch-Veröffentlichungen und Updates. Ich vermute, dass die Denkweise, alte Softwareversionen seien gegenüber aktuellen vorzuziehen, aus einer Kombination von physischen Produkten (Uhren, Autos, Geschirr, Möbel, Wein), bei denen ein bestimmtes Jahr oder Modell aus verschiedenen Gründen einem neueren Modell überlegen sein kann, und von althergebrachten Methoden der Softwareauslieferung herrührt, bei denen fertige Softwareprodukte einfach ??über die Mauer geworfen wurden? und der Endzustand schlicht der Endzustand war, ohne irgendwelche vernünftigen Möglichkeiten für Updates, Patches oder Fehlerbehebungen. Keiner dieser Fälle trifft auf moderne Unternehmenssoftware zu (mit den allerseltensten Ausnahmen).

Die Softwareentwicklung ist grob gesehen ein Kontinuum. Bei normalen Entwicklungsprozessen wird neue Software auf alter Software aufgebaut, entweder direkt (durch das Erstellen von Updates für eine bestehende Codebasis) oder indirekt (durch eine Neuentwicklung auf Grundlage der Erkenntnisse, die beim Erstellen einer früheren Version der Software gewonnen wurden). Der Gedanke dabei ist, dass jede nachfolgende Softwareversion der ihr vorangehenden überlegen ist. Dies ist natürlich nicht garantiert; es gibt durchaus Konzepte wie Regressionsfehler und schlicht schlechte Entwicklung, doch im Großen und Ganzen verbessert sich Software im Laufe der Zeit – besonders, wenn wir von Enterprise-Class-Software sprechen, die in Unternehmen eingesetzt wird und sich in aktiver Entwicklung befindet. Neue Software ist nicht nur die nächste Phase der alten Software, sie repräsentiert in nahezu allen Fällen auch den aktuellen Stand der Patches, Fehlerbehebungen, Updates und, falls erforderlich, Änderungen in Ansatz oder Technik. Neue Software aus qualitativ hochwertigen Werkstätten ist fast ausnahmslos besser als alte Software. Software entwickelt sich weiter und reift.

Über die Qualität der Software selbst hinaus gibt es das Konzept der Investition in die Zukunft. Software ist nichts, was für immer im Regal liegen kann. Sie muss bis zu einem gewissen Grad aktuell bleiben, sonst hört sie auf zu funktionieren, weil sich die Plattform, auf der sie läuft, ändert, ein neuer Umstand ans Licht kommt, Sicherheitslücken entdeckt werden oder sich die Anforderungen ändern. Alte Software zu installieren bedeutet, dass eine Investition in die Vergangenheit getätigt wird, eine Investition in das Installieren, Erlernen, Verwenden und Unterstützen alter Technologie. Dies nennt man „technische Schuld“. Diese alte Technologie mag Jahre oder gar Jahrzehnte halten, doch alte Software verliert mit der Zeit an Wert und wird zunehmend teurer im Support, sowohl für die Anbieter, falls sie sie weiterhin unterstützen, als auch für die Endanwender, die sie unterstützen müssen.

Dasselbe Konzept der technischen Schuld gilt für die betreffenden Softwareanbieter. Mit der Erstellung von Software und insbesondere mit der Pflege mehrerer Versionen dieser Software sind sehr hohe Kosten verbunden. Softwareanbieter haben einen starken Anreiz, den Support für ältere Versionen zu reduzieren, um Ressourcen auf aktuelle Software-Releases zu konzentrieren (dies ist ein wesentlicher Grund dafür, warum SaaS-Bereitstellungen so beliebt sind: Der Anbieter kontrolliert die verfügbaren Versionen und kann ältere Versionen durch Updates eliminieren). Wenn Kunden Support für alte Versionen benötigen, müssen die Kosten irgendwo aufgefangen werden, und oft werden sie sowohl in Form von finanziellen Auswirkungen auf alle Kunden als auch in Form einer verminderten Konzentration auf das neue Produkt aufgefangen, da Entwicklungsteams aufgeteilt werden müssen, um sowohl das Patchen alter Versionen zu unterstützen als auch die neue zu entwickeln. Je mehr Aufwand in alte Versionen fließen muss, desto weniger Aufwand kann in neue Verbesserungen gesteckt werden.

Innerhalb des Rahmens dessen, was ich bereits gesagt habe, ist es wichtig, über die Reife des Codes zu sprechen. Oft wird die Code-Reife als Grund für die Bereitstellung von „altem Code“ angeführt, doch ich denke, dass dies ein Missverständnis der IT bezüglich der Softwareentwicklungsprozesse ist. Wenn wir über eine veröffentlichte Codezeile nachdenken, macht sie die bloße Tatsache, dass sie veröffentlicht und im Einsatz ist, nicht wirklich reifer. Code verändert sich nicht im freien Feld, er liegt einfach dort. Seine Reife ist an dem Tag, an dem er veröffentlicht wird, „eingefroren“. Wird er gepatcht, dann ja, würde er nach der Veröffentlichung „reifen“. Spätere Versionen derselben Software, basierend auf derselben Codebasis, aber aktueller, sind wahrhaft der reifere Code, da er in höherem Maße überprüft, aktualisiert, getestet usw. wurde als die frühe Veröffentlichung desselben Codes.

Dies ist kontraintuitiv im Vergleich zu, sagen wir, einem Auto, bei dem jede Veröffentlichung eine frische Sache mit neuen Gelegenheiten für mechanische Probleme und unterschiedlichen Zuverlässigkeitsbedenken ist – wo das Abwarten einiger Jahre die Chance bietet, zu sehen, welche Zuverlässigkeitsprobleme zutage treten. Software ist nicht so. Daher würde Sie das Konzept des Wunsches nach reiferer Software dazu drängen, das „Neueste und Beste“ statt des „Bewährten und Erprobten“ bereitzustellen.

Wenn wir uns Softwareversionsnummern eher wie Lebensalter vorstellen, wird dies deutlich. Linux 3.1 ist, was die Softwarereifung betrifft, viel älter als Linux 2.4. Es hat ein Jahrzehnt zusätzlicher Entwicklung hinter sich.

Verwenden wir ein reales Beispiel, das heute sehr relevant ist. Sie befinden sich in einem Betrieb, der gerade dabei ist, seinen ersten Server bzw. seine ersten Server zu installieren. Windows Server 2012 R2 ist soeben erschienen. Sollten Sie Windows Server 2008, 2008 R2 (2010), Server 2012 oder Server 2012 R2 (Ende 2013?) installieren?

Für viele Betriebe klingt es so, als sprächen wir über irgendwo zwischen zwei und vier gänzlich unterschiedliche Produkte, die wahrscheinlich jeweils unterschiedliche Gründe für ihre Wahl haben. Dies ist im Großen und Ganzen unzutreffend. Jede neuere Version ist schlicht ein Upgrade, Update, Patch und Funktionszuwachs gegenüber der vorherigen. Jede einzelne ist wiederum fortschrittlicher und reifer als die ihr vorangehende. Jede neue Version profitiert von der Arbeit, die an der ursprünglichen Veröffentlichung ihres Vorgängers geleistet wurde, sowie von Fehlerbehebungen, Patches und Funktionsergänzungen, die in der Zwischenzeit zwischen der ursprünglichen Veröffentlichung und der Nachfolge-Veröffentlichung vorgenommen wurden. Jede neue Veröffentlichung ist in Wirklichkeit eine „Minor Release“ der vorhergehenden. Wenn wir uns die Kernel-Revisionsnummern statt der Marketing-Namen der Releases ansehen, ergibt es vielleicht mehr Sinn.

Windows Server 2008 war Windows NT 6.0. Windows Server 2008 R2 war Windows NT 6.1, offensichtlich eine kleinere Revision oder gar ein „Patch“ der vorherigen Veröffentlichung. Windows Server 2012 war Windows NT 6.2 und unser aktuelles Windows Server 2012 R2 ist Windows NT 6.3. Würden wir die Revisionsnummern statt der Marketing-Namen verwenden, klingt es geradezu verrückt, absichtlich eine alte, weniger reife, weniger aktualisierte und weniger gepatchte Version zu installieren. Wir wollen die neuesten Updates, die neuesten Fehlerbehebungen und wollen, dass die neuesten Sicherheitsprobleme behoben wurden.

Bei neuen Softwarebereitstellungen gilt: Je neuer die installierte Software, desto besser die Gelegenheit, die neuesten Funktionen zu nutzen, und desto mehr Zeit, bevor die unvermeidliche Veralterung ihren Tribut fordert. Jede Software altert, daher gibt die Installation neuerer Software die beste Chance, dass diese Software am längsten Bestand hat. Sie bietet die beste Flexibilität für die ungewisse Zukunft.

Diesem Gedankengang zu folgen könnte uns zu dem Gefühl verleiten, dass auch die Bereitstellung von Vorab- oder gar Beta-Software sinnvoll wäre. Und obwohl es bestimmte Fälle geben mag, in denen dies sinnvoll ist, etwa in „Testgruppen“, um Software zu prüfen, bevor sie unternehmensweit freigegeben wird, ist dies im Allgemeinen nicht der Fall. Es liegt in der Natur von Vorab-Software, dass sie nicht unterstützt wird und Code enthalten kann, der niemals unterstützt werden wird. Die isolierte Verwendung solchen Codes kann von Vorteil sein, doch für den allgemeinen Gebrauch ist davon abzuraten. Es gibt wichtige Prozesse, die zwischen Vorschau- oder Beta-Veröffentlichungen und den endgültigen Veröffentlichungen von Code befolgt werden, ganz gleich, welchen Reifegrad das Gesamtprodukt aufweist.

Das bringt uns zur anderen Situation, jener, in der wir vorhandene Software aktualisieren. Dies ist natürlich ein gänzlich anderes Szenario als eine Neuinstallation, und es sind sehr, sehr viel mehr Faktoren beteiligt.

Einer der größten Faktoren in den meisten Situationen ist der der Lizenzierung. Die regelmäßige Aktualisierung von Software kann Lizenzgebühren verursachen, die in die Gleichung aus Nutzen und Kosten einbezogen werden müssen. Manche Produkte, wie die meiste Open-Source-Software, haben diese Kosten nicht und können aktualisiert werden, sobald neue Versionen verfügbar sind.

Der andere wirklich große Faktor bei der Aktualisierung von Software ist ein menschlicher Aufwandskostenfaktor für das Aktualisieren – anders als bei einer Neuinstallation, bei der der Aufwand der Installation effektiv ein Nullsummenspiel zwischen alter und neuer Software ist. In Wirklichkeit lässt sich neue Software tendenziell leichter installieren als alte Software, schlicht aufgrund von Verbesserungen und Weiterentwicklungen. Eine einzige Softwareversion ein Jahrzehnt lang zu pflegen bedeutet, dass während dieser Zeit keine Ressourcen für Upgrade-Prozesse aufgewendet wurden. Während dieser Zeit jährlich zu aktualisieren bedeutet, dass zehnmal Ressourcen eingesetzt wurden, um separate Upgrades durchzuführen. Das macht es viel schwieriger, die Aktualisierung kostenmäßig zu rechtfertigen. Doch es geht um mehr als nur den Aufwand des Aktualisierungsprozesses selbst; es gibt auch die fortlaufende Schulung, die für Endanwender erforderlich ist, die durch ständige Upgrades gezwungen werden, mehr Veränderungen häufiger zu erleben.

Dies mag die Aktualisierung von Software wie etwas Negatives klingen lassen, doch das ist sie nicht. Es ist schlicht eine Gleichung, bei der jede Seite abgewogen werden muss. Regelmäßige Updates bedeuten oft kleine, schrittweise Änderungen statt großer Sprünge, was es den Endanwendern ermöglicht, sich natürlicher anzupassen. Regelmäßige Updates bedeuten, dass Aktualisierungsprozesse oft einfacher und vorhersehbarer sind. Regelmäßige Updates bedeuten, dass die technische Schuld stets im Griff gehalten wird und die Vorteile der neueren Versionen – seien es Funktionen, Effizienzgewinne oder Sicherheitsverbesserungen – früher verfügbar sind, sodass sie über einen längeren Zeitraum genutzt werden können.

Wenn wir jedoch das aus den beiden obigen Szenarien Gelernte zusammennehmen, lässt sich hier eine weitere wichtige Erkenntnis gewinnen. Ist die Entscheidung zur Durchführung eines Updates einmal getroffen, lautet die Frage oft: „Auf welche Version aktualisieren wir?“ In Wirklichkeit ist jedoch jedes Update, das über einen standardmäßigen Patching-Prozess hinausgeht, eigentlich wie eine miniaturhafte „Neue-Software“-Kaufentscheidung, und die Logik, warum wir bei einer Neuinstallation „immer“ die neueste verfügbare Version installieren, gilt auch hier. Wenn wir also ein Update durchführen, sollten wir fast immer so weit aktualisieren, wie wir können – hoffentlich auf die aktuelle Version.

Um das Microsoft-Beispiel erneut anzuwenden, können wir eine Organisation heranziehen, die heute Windows XP im Einsatz hat. Das Unternehmen beschließt, in einen Update-Zyklus auf eine neuere Version zu investieren, nicht nur in fortgesetztes Patchen. Es gibt mehrere Versionen der Windows-Desktop-Plattform, die noch aktiv von Microsoft unterstützt werden. Dazu gehören Windows Vista, Windows 7, Windows 8 und Windows 8.1. Eine Aktualisierung auf eine der weniger aktuellen Versionen führt zu weniger Zeit bis zum Lebensende dieser Version, was das organisatorische Risiko erhöht; die Verwendung älterer Versionen bedeutet fortgesetzte Investitionen in bereits alte Technologien, was eine Zunahme der technischen Schuld bedeutet, sowie weniger Zugang zu neuen Funktionen, die sich, sobald verfügbar, als nützlich erweisen könnten. In diesem speziellen Beispiel gelten neuere Versionen zudem als sicherer und benötigen weniger Hardwareressourcen.

Jedes Unternehmen muss für sich die richtige Balance für Update-Zyklen vorhandener Software finden. Jedes Unternehmen und jedes Softwarepaket ist anders. Enterprise-Software wie Microsoft Windows, Microsoft Office oder eine Oracle-Datenbank folgt diesen Modellen sehr gut. Kleine Softwareprojekte und solche, die nahe dem maßgeschneiderten Bereich liegen, mögen einen dynamischeren und unvorhersehbareren Veröffentlichungszyklus haben, werden aber im Allgemeinen dennoch den meisten dieser Regeln folgen. Erwägen Sie, Verständnis für den Softwareentwicklungsprozess aufzubringen, um zu begreifen, wie Sie und Ihr Softwareanbieter am besten zusammenarbeiten können, um Ihrer Organisation den größten Wert zu liefern, und verbinden Sie dies mit Ihrem Bedürfnis, die technische Schuld zu reduzieren, um Ihre Softwareinvestition auf die bestmögliche Weise für Ihre Organisation zu nutzen.

Doch die Faustregeln sind verhältnismäßig einfach:

Streben Sie bei Neubereitstellungen oder Aktualisierungen die neueste vertretbare Softwareversion an. Nutzen Sie jede Bereitstellungsgelegenheit, um technische Schuld so weit wie möglich zu beseitigen.

Wenn Software bereits vorhanden ist, wägen Sie Faktoren wie menschlichen Aufwand, Lizenzkosten, Umgebungskonsistenz und Kompatibilitätstests gegen Vorteile bei Funktionen, Leistung und technischer Schuld ab.