IT im Fluss

IT Infrastruktur im Wandel der Zeit

Aus der Reihe, Beobachtung der letzten Jahre, dieses Mal zum Thema IT Infrastruktur Projekte im Wandel der Zeit. Meine Erkenntnis ist vorweg, dass Organisationseinheiten, die mit der Agilität nicht zu Recht kommen, vor großen Aufgaben stehen. Diesen Faktor Agilität und seine Konsequenzen möchte ich kurz beleuchten.
Über die Jahrzehnte hat sich ein Release Management eingebürgert, dass sich vor allem an dem Takt, dem Release Zyklus, des Betriebssystems orientiert. In der Regel werden und wurden auch immer wieder Betriebssystem Versionen ausgelassen, um den Status von Soft- und Hardware Ausstattung möglichst lange konstant und konsistent zu halten. So kam es in der Regel nur alle vier bis sieben Jahre zu einem Takt und damit Release Wechsel. Standards, wie BS 15000 (vgl.: British Standard 15000), ITIL und ISO 20000, die auf die selben Inhalte abstellen, finden hier ihre Anwendung. ITIL beschreibt konkret das Release und Change Management. Alle Normen und Best Practice Anleitungen beschreiben den Release Wechsel als Prozess. Das setzt aber voraus, dass Prozesse implementiert und gelebt werden. Alles im allem lag dem ganzen Vorgang eine überschaubare Dynamik zu Grunde, die sich hier entwickeln kann. Analogien fallen mir einige ein. Bildlich hat das zum Beispiel Saint Exupéry in seinem kleinen Prinzen treffend dargestellt. Die Riesenschlage, die einen Elefanten verschlungen hat. Das wird nun einige Zeit dauern, bis der verdaut ist und so lange ist auch Ruhe.

Anlass

Der Taktgeber ist weiterhin die technologische Entwicklung von Betriebssystem und Standard Anwendungen. Der Takt ändert sich aber hier massiv, weil Konzerne, wie Microsoft zum Beispiel, agil geworden sind. Software Entwicklung ist nicht mehr ein stufenweiser, mehrjähriger, Zyklus, sondern ist jetzt monatlich getaktet. Teams von Microsoft produzieren monatlich für das Betriebssystem, aber auch für alle anderen Produkte und Leistungen, Updates – monatliche Patches. Zusätzlich kommen noch halbjährlich funktionale Upgrades dazu. An diesem Vorgehen orientieren sich immer mehr Hersteller von Standardsoftware. Ein durchgängiger fester Versionsstand ist somit gar nicht mehr möglich. Ein einfrieren von Soft- und Hardwarekombinationen, um sie vor allem in einem Release Prozess managen zu können ist somit hinfällig geworden. Die Schlange bekommt jetzt nicht mehr alle paar Jahre eine Riesenportion zum Verdauen vorgeworfen, sondern laufend kleine Häppchen.

Die bereits erwähnte Vorgehensweise, wie das Auslassen einer Version des Betriebssystems, geht in der Regel nur zeitlich stark beschränkt. Ausdehen kann man den Zyklus auf die ursprünglichen vier bis sieben Jahre nicht mehr. Es sind nur mehr ein paar Monate üblich. Dafür gibt es mehrere Gründe, einerseits drängen die Hersteller, durch verkürzte Support Zeiträume und aber auch die Abhängigkeiten der einzelnen Systemkomponenten untereinander, zu einem Upgrade. Werden Cloud Dienste genutzt, dann ist man dem Release Management des Cloud Betreibers ausgeliefert. Jeder Anbieter von Clouddiensten verfolgt seine eigene Updatepolitik, Ein Verzahnung mit anderen Anbietern, um Updates abzustimmen, sie vielleicht auch zu synchronisieren, erfolgt nicht.

Kleine Organisationseinheiten beherrschen diese Beschleunigung in der Regel besser, da sie meist universeller aufgestellt sind. Anders gesagt, das „Mädchen für Alles“, kann nur mit dem Strom schwimmen. Arbeitsteiliges Vorgehen, ein Ergebnis einer prozessorientierten Organisation, führt zur Segmentierung von Wissen, Fähigkeiten und Aufgaben. Das ist auch das Ziel, das mit der Professionalisierung und Prozessorientierung der Organisation und IT bezweckt wird. So kommt es aber jetzt auch zu dem weiter oben beschriebenen statischen Release Management. So ein phasenorientes Vorgehen ist meist nicht agil genug, um die Änderungsrate durch die externen Dienstanbieter zeitnah abbilden zu können.

Alternativen

• Verdrängen sie die Komplexität der IT-Systeme:
  Jede Individualisierung, jede Anpassung, senkt die Integrationsfähigkeit. Hinzukommen noch die eingesetzten Schnittstellen. Zusammengefasst steigt die Komplexität der Architektur, nimmt die Beherrschbarkeit und Konsistenz der IT Umgebung ab. Hier liefert die Lean Methode einen brauchbaren Ansatz – alles ausserhalb des Wertstroms ist auszulassen. In dem Zusammenhang wird oft das KISS Prinzip (vgl.: keep it simple, stupid) genannt. Griffiger ist für mein Dafürhalten, Konvention vor Konfiguration.
  Die Komplexität nimmt zumindest nicht zu, wenn sie sich auf das betriebswirtschaftliche Notwendige konzentrieren. Die Chance, Möglichkeit, besteht sie, die Komplexität, an den externen Cloud Dienstanbieter auszulagern, zu verdrängen.
• Unterstützen sie die Flexibilität der Organisation:
  Die Flexibilisierung ist dem Druck der laufenden Veränderung (vgl.: Udatezyklen etc.) geschuldet. Eine starre Prozessorientierung kann keinen Erfolg haben. Bedingt besonders durch gleichzeitige, aber in unterschiedlichen Phasen befindliche, Updates von Systemen.
  Hinzukommen noch zusätzlich Faktoren, wie, dass die Entwicklung nicht durch die Organisation selbst erfolgt. Somit gibt es keine Erfahrungen und es ist auch kein Wissen im Vorfeld gebildet worden. Ein weiterer Faktor ist, dass zwischen Projekt und Betrieb kein klarer Übergang mehr möglich ist. Damit ist ein Übergang mit Auflösung der Abhängigkeit und Prüfbarkeit der Qualität und Quantität aller Lieferungen und Leistungen in ihrer Gesamtheit gemeint.
  Es gibt Ansätze, um eine stärke Verzahnung verschiedner Organisationselemente zu erreichen (vgl.: DevOps …) Aber das ist eine andere Geschichte.
• Machen sie die IT Mitarbeiter zu Generalisten:
  Methodenkompetenzen, Wissen über Modelle, Normen, und vor allem produktunabhängiges Fachwissen sind eine Voraussetzung, um mit der Geschwindigkeit der Veränderung mithalten zu können. Die reine Produktkenntnis ist nur mehr in immer kürzer werdenden Zeiträumen einsetzbar.
• Vermeiden sie den Mangel an Dokumentation, Schulung und Schulungsunterlagen
  Die immer kürzer werdenden Zyklen der Entwicklung und damit der Updates können gar nicht anders, als zu diesem Mangel führen. Der Mangel an Zeit schlägt sich vor allem nieder in fehlender Aktualisierung der Dokumentation, fehlenden Schulungsunterlagen und fehlender Einschulung der Mitarbeiter.
  Schulung und Dokumentation sind vor allem deshalb sinnvoll, um eine nachhaltige Benutzerakzeptanz zu schaffen. Der oft anzutreffende Ansatz von tolleriertem Versuch und Irrtum im Umgang mit Soft- und Hardware durch den Benutzer ist nicht zielführend. Der Benutzer beherrscht zwar Standardsoftware, aber damit abgebildete organisationseigene Prozesse, sind meist individuell. Wenn der Ablauf, die Form, dem Benutzer nicht eindeutig klar ist, dann führt das zu Resignation und Verweigerung in letzter Konsequenz. Da reicht schon eine undokumentierte Veränderung der Funktionalität. Die Funktion an sich bleibt erhalten, aber die Umwelt (vgl.: Benutzerergonomie, Haptik … ) wird geringfügig verändert.
  Wenn also im Vorfeld die Zeit fehlt, dann kann nur durch den Ausbau und Intensivierung der eigenen, internen, Betreuungsleistung dieses negative Moment abgefangen werden. Den Hebel zu finden, um das Wissen in die Organisation nachhaltig zu bringen ist eine spannende Aufgabe und individuell zu gestalten. Immer ein Ohr für die Kundenbedürfnisse zu haben – erfordert ein hohes Maß an Flexibilität. In diesem Fall ist der Kunde der IT Organisationseinheit die Organisation selbst – im Fall der undokumentierten und ungeschulten Veränderung.
• Nutzen sie ihre Erkenntnisse
  Die oben angesprochene Betreuung der Benutzer, durch zum Beispiel Help Desk und Schlüsselbenutzer, sollte nicht als reiner Kostenfaktor gesehen werden. Das individuelle Wissen, das hier entsteht, sollte in dem Fall institutionalisiert und wiederverwendbar werden. Planung, Steuerung und Kontrolle können diese wertvollen Informationen sinnvoll nutzen, zum Beispiel bei der Falsifikation von Hypothesen. Je durchgängiger das Architekturkonzept ist, desto effizienter ist eine Plan- und Steuerbarkeit.

Schlussbemerkung

Schliessen möchte ich mit einer Aussage, die ich schon an anderer Stelle getätigt habe.

In Bewegung bedeutet für mich vor allem geistig mobil zu bleiben. Meine Tätigkeiten verändern sich mit der Veränderung der Unternehmen, die ich berate – hie und da fällt ein Beratungsmandat weg und ein neues kommt hinzu.

Stefan Schreiner – Über mich

Bewegung ist Agilität im Umgang mit Anforderungen und ein Bekenntnis zu lebenslangen Lernen. Das betrifft nicht nur mich als Unternehmer und Berater, sondern alle Organisationen heutzutage.