Erreicht ein System eine kritische Größe, etwa hinsichtlich der Anzahl von Codezeilen, der Menge der zu verarbeitenden Daten, der Schnittstellen oder Hardwarekomponenten, versagen herkömmliche Steuerungs- und Kontrollmechanismen. Spezielle Organisationen wie das Militär, in diesem Fall besonders das amerikanische Verteidigungsministerium, haben sehr große Systeme aus diversen Hardwareplattformen mit unzähligen Softwarekomponenten im Einsatz. Auch das Internet oder große Organisationsnetze, wie sie in der Forschung und in Konzernen zu finden sind, entwickeln eine Eigendynamik, die sie grundlegend von kleineren Systemen unterscheidet. Derartige Strukturen werden auch als Ultra Large Scale Systems (ULS-Systeme) bezeichnet. Die reine Größe eines solchen Systems verändert alles.

Die ständig zunehmende Komplexität heutiger IT-Systeme lässt sich schon damit erklären, dass nahezu jede Organisation inzwischen Internet-Technik nutzt, deren Einsatz sich im Rahmen von Serviceorientierung künftig noch deutlich verstärken wird. Bei einem ausgelagerten Service ist es jedoch nicht mehr möglich, zu sagen, wie stark seine Abhängigkeiten in andere Organisationen hineinreichen und wo er überall genutzt wird. Seiteneffekte und unvorhersehbares Verhalten werden immer häufiger beobachtet, die Kontrollmöglichkeiten schwinden.

Das Internet ist ein Paradebeispiel für ein ULS-System, aber auch global agierende Großkonzerne bewegen sich mit ihren IT-Infrastrukturen unaufhaltsam in diese Richtung. Die heute oft empfohlene Service-orientierte Architektur (SOA) beschleunigt die Entwicklung, da eine SOA eine sehr große Zahl unabhängiger beziehungsweise austauschbarer Services enthält und damit eine deutlich erhöhte Komplexität besitzt. Es ist anzunehmen, dass durch eine SOA der ULS-Zustand früher erreicht wird als durch das Wachstum einer vergleichbaren klassischen Anwendungsarchitektur.

Analogie zum Städtebau

Für das Verständnis von ULS-Systemen lässt sich der Vergleich mit einer Stadt heranziehen. Eine Software zu entwickeln kann zum Beispiel mit dem Entwurf und dem Bau von einzelnen Gebäuden oder Infrastrukturkomponenten wie dem Telefon- oder Stromnetz verglichen werden. Eine ganze Stadt entsteht jedoch (bis auf wenige Ausnahmen) nicht am Reißbrett. Vielen individuellen und gemeinschaftlichen Bedürfnissen wird über einen nicht begrenzten zeitlichen Rahmen hinweg Rechnung getragen. Diverse Kräfte wirken, zum großen Teil unvorhersehbar, auf die Stadt ein und formen sie.

Noch etwas anderes zeigt die Analogie: Für den Entwurf und das Wachstum einer Stadt ist das Wissen über das Design eines Gebäudes relativ unwichtig. Ähnlich ist es in ULS-Systemen: Die Fähigkeit, Software zu entwickeln, spielt dort nur eine untergeordnete Rolle, zumindest aus Systemsicht. ULS-Systeme entwickeln sich ähnlich ökologischen Systemen dadurch, dass sie eine Gemeinschaft von untereinander abhängigen und konkurrierenden Subsystemen in einer komplexen und sich verändernden Umgebung bilden. In einem ULS-System wird es Wettbewerb um limitierte Ressourcen wie Bandbreite, Speicherplatz, CPU und Ähnliches geben. Folglich muss in einer solchen Umgebung ein Regelwerk gelten, um eine effektive Nutzung aller gemeinsamen Ressourcen überhaupt erst zu ermöglichen. In einer Stadt entspricht dies den Baugesetzen, Parkverbotszonen, Halteverboten oder Einbahnstraßen.

Alles im Fluss

Baugesetze können jedoch auf die bereits errichteten Gebäude nicht immer angewendet werden. Analog leuchtet es ein, dass sich neue Richtlinien auch nicht über die gesamte Landschaft eines ULS-Systems erstrecken werden. Das heißt: Nicht nur das System selbst, auch die Richtlinien, Bewertungen und Maßnahmen ändern sich ständig.

Traditionell verstehen wir die Systementwicklung als technikzentriert, meistens im Top-down-Ansatz, und als kontrollierten Prozess der Softwareprogrammierung. Im Gegensatz dazu müssen die Elemente in einem ULS-System stets als eine Kombination aus Menschen und Software (in manchen Fällen auch Hardware) auf allen Ebenen verstanden werden. Das Internet ist größer als alle anderen Softwaresysteme, seine Entwicklung und Regelung erfolgt dezentral. Selbst der Betrieb ist massiv dezentralisiert. Die am Internet beteiligten Stakeholder sind so vielfältig, dass sie stark unterschiedliche und zum Teil widersprüchliche Interessen und Ziele haben.

Das Internet ist ein erfolgreiches System, zu jeder Zeit befindet sich jedoch ein beachtlicher Teil davon im fehlerhaften Zustand. Diese Konsequenz muss auch für die IT großer Organisationen befürchtet werden, wenn sie sich in Richtung ULS-Systeme entwickelt und die Werkzeuge zur erfolgreichen Steuerung und Kontrolle ab einem bestimmten Schwellenwert nicht mehr ausreichen. Eine Komplexitätszunahme erfolgt immer exponentiell, so dass derart wachsende Systeme mit einfachen Ursache-Wirkungs-Beziehungen nicht mehr zu steuern sind. Nicht die Größe ist also das eigentliche Problem eines ULS-Systems, sondern die Geschwindigkeit, mit der es sich verändert.

Durch die Hintertür

IT-Verantwortliche mögen der Meinung sein, dass ihnen kein ULS-System ins Haus steht. Doch es gibt eine Reihe treibender Kräfte, die eine Eigendynamik und ein Komplexitätswachstum in der IT bewirken, so dass ein schleichender Wandel in Richtung ULS-System stattfindet. Wichtige Faktoren sind zum Beispiel:

• Die geografische und organisatorische Verteilung führt zu Matrix- und Netzwerkorganisationen, in denen die einzelnen Bereiche lokale Entscheidungsbefugnisse haben, so dass es zu unabhängigen und widersprüchlichen Entscheidungen und Anforderungen an das Gesamtsystem kommt.

• Durch die Dezentralisierung der IT, aber auch durch eine "Geiz-ist-Geil"-Mentalität der Einkaufsabteilungen werden Hard- und Software eines Anwenderunternehmens heterogen.

• Business Process Outsourcing (BPO) und die Nutzung von Services diverser Provider führen zu stark heterogenen Subsystemen und erhöhen die Gesamtkomplexität.

• Service-orientierte Architekturen sowie

• Commercial off the Shelf Software (COTS = kommerzielle Standardsoftware) importieren zusätzliche Fehlerquellen und sorgen für inkompatible Architekturen.

Ist ein ULS-System erst einmal entstanden, sind viele Mechanismen, die aus kleineren Systemen bekannt sind, nicht mehr anwendbar. Da das Gesamtsystem nicht mehr angehalten werden kann, sind neue Mechanismen zur kontinuierlichen Evolution und deren Steuerung während der Laufzeit notwendig. Auch in einem ULS-System existieren unterschiedliche Anforderungen. So haben infrastrukturelle Services eine andere Stellung als rein applikative. Folglich müssen auch unterschiedliche Mechanismen für Entwicklung und Deployment greifen.

Speziell die Orchestrierung ist sehr viel komplexer als in einer SOA. In einem ULS-System kann nicht mehr von Fehlerfreiheit oder Stabilität genutzter Services ausgegangen werden. Aufgrund der permanenten Evolution verändern sich diese laufend. Die einzig mögliche Steuerung für ein Wohlverhalten von Services kann über allgemein gültige Policies oder Incentives funktionieren. Neue Formen der Entwicklung, zum Beispiel Algorithmic Mechanism Design, bei dem eine Software andere Software entwirft, sind in einem ULS-System möglich, ohne dass zur Zeit die Auswirkungen davon bekannt wären. Bei genauerer Betrachtung der Mechanismen zur Einführung neuer Elemente dürfte das Gesamtsystem weniger von Adaption als viel stärker von Assimilation auf Systemebene geprägt sein.

Wie kann ein ULS-System bewertet werden? Welches sind die sinnvollen und messbaren Größen, um eine Aussage über seinen "Gesundheitszustand" zu treffen? Die Steuermechanismen sind Regeln und Policies, aber jede Steuerung versagt, wenn nicht klar ist, was eigentlich zu steuern und zu messen ist. Solche Größen können nur noch statistischer Natur sein, so zum Beispiel die Anzahl der Hosts.

Unsere heutigen Ansätze zur IT-Governance gehen von einer zentralen Kontroll- und Steuerinstanz aus - zwar existieren auch föderale Ansätze, diese sind jedoch nur Replikationen des Zentralgedankens. In einem ULS-System sind jedoch solche zentralen Mechanismen überhaupt nicht mehr möglich. Für eine IT-Governance würden sich sehr viel stärker Mechanismen aus dem soziokulturellen Bereich anbieten, etwa die Art und Weise, wie soziale Organisationen auf globaler Ebene zusammenarbeiten. Ein Beispiel wäre auch die Schwarmintelligenz von Bienen- und Ameisenvölkern, wo einfache Elemente ein sehr emergentes Gesamtsystem erzeugen. Über die Mechanismen der wettbewerbsfreien sozialen Kollaboration und ihre Auswirkungen auf die Struktur eines Systems ist allerdings wenig bekannt.

Autarke Services

Auch auf Seiten der Architektur müssen Konsequenzen aus der Unbeherrschbarkeit eines ULS-Systems gezogen werden. Eine Möglichkeit, den Komplexitätstod zu vermeiden, ist es, jedes einzelne Element (Service) des Systems als eine "Viable Software" zu implementieren. Ein Viable System Model (VSM) ist rekursiv aufgebaut und wiederholt damit seine eigene Struktur auf jeder Abstraktionsebene des Gesamt- oder Subsystems. Jede einzelne Instanz eines VSM ist allein überlebensfähig und kann sich selbständig auf eine veränderte Umgebung und damit auch auf Fehler anderer Services oder Bediener einstellen. Nur so lässt sich ein ULS-System lebensfähig erhalten.