Sun Microsystems startet Feldzug gegen die Komplexität

Papadopoulos über die Kosten für den Übergang zu einer Middleware-Architektur und sein Fortschrittsbericht über den Stand, auf dem sich viele in diesem Prozess Begriffene befinden: Wenn man nicht an einer Überbrückung der Kluft arbeitet, wird man stürzen und als Unternehmen scheitern. Ab einem bestimmten Zeitpunkt werden jene, die nicht an einem Wechsel arbeiten, in den alten Bahnen gefangen sein. Da es keine Möglichkeit geben wird, hier neue Werte zu schaffen, gehen sie einem bitteren Ende entgegen. Wir befinden uns in einem Phasenwechsel, wo 80 bis 90 Prozent der Entwickler sich in der neuen Welt befinden. Sie arbeiten mit Java oder mit .Net, wenn sie nicht mit Java arbeiten. Während also 80 bis 90 Prozent der Entwickler mit Middleware arbeiten, tun 80 bis 90 Prozent der installierten Systeme dies nicht. Dort laufen SAP und die alten Client-Server-Anwendungen. SAP und andere unabhängige Softwareanbieter haben ihre Entwickler recht massiv auf Java eingeschworen. Das aber gehört zur Welt von morgen. Es muss zunächst noch einen Wechsel bei den installierten Systemen geben, bevor das Middleware-basierte, so genannte Utility-Computing Realität wird.

Zwischen den Zeilen: Die Entwickler bilden stets die Speerspitze, wenn Umwälzungen in der Software-Architektur bevorstehen. Der Trend hin zur Middleware wird von Entwicklern angeführt, die für die Entwicklungs-Abteilungen der großen Konzerne und unabhängige Softwareanbieter arbeiten, die ERP-, SCM- und CRM-Software herstellen. Trotz der Tatsache, dass sich viele Entwickler auf dem richtigen Weg befinden, kann man von deren Arbeit nur profitieren, wenn es ausreichend vorausschauende IT-Manager gibt, die begreifen, warum eine Vereinheitlichung auf so hoher Ebene Vorteile bietet und weshalb ihre alten Systeme dem Fortschritt im Wege stehen. Da das gesamte Ökosystem der IT sich von den individuell gestalteten Systemen fortbewegt, werden alle, die sich der Veränderung widersetzen, mehr und mehr isoliert dastehen, was laufende Verbesserungen und Unterstützung betrifft. Einige Unternehmen begeben sich möglicherweise auch ihres Einflusses auf Anbieter und der damit verbundenen Ersparnisse, die dann jenen ihrer Konkurrenten zugute kommen, die schneller gehandelt haben. So würde die mögliche Rolle finanzieller Erwägungen in der Wettbewerbslandschaft noch betont.

Papadopoulos darüber, warum Utility Computing derzeit ein Trugbild ist: In der IT gibt es keinen Vorteil durch Massenproduktion, wo sich mit wachsendem Volumen die Fixkosten deutlich amortisieren. Utility Computing muss sich die Frage stellen, wie man 1.000 Server und 10.000 Plattenlaufwerke bereitstellen kann, die nicht auch 1.000 oder 10.000 Administrationseinheiten benötigen. Dazu bräuchte ich ein System, dass sich um den Faktor 1000 (oder 10.000) skalieren lässt: je größer, desto besser. Momentan ist Utility Computing nichts als ein Trugbild. Wenn nicht an den systembedingten Problemen gearbeitet wird, gerät man in die perverse Lage, wo schon eine Verdoppelung der Leistung zu einem Ausfall führen würde. Wenn die zugrunde liegende Architektur nicht stimmt, entwickeln sich auch die Betriebskosten anders. Es sollte anders herum sein. Man sollte sagen können „Der Umfang hat sich verdoppelt und die Wachstumszyklen bereiten keinerlei Probleme.“ Wachstumszyklen sollten praktisch keine Kosten verursachen.

Zwischen den Zeilen: Im Allgemeinen präsentieren Anbieter ihren Kunden Utility Computing auf dreierlei Wiese: (1) als eine rein technologische Angelegenheit, wo die Technologie sich wie die Stromversorgung bedarfsorientiert verhält, es jedoch keine eingebaute Abrechnungsfunktion gibt, (2) als Abrechnungsmodell, innerhalb dessen die Technologie sich weniger wie eine sich dynamisch selbst anpassende Versorgung mit Rechenleistung verhält, sondern die Bereitstellung der Technologie vom Anbieter auf Verbrauchsbasis in Rechnung gestellt wird, und (3) einer Kombination aus beidem, wo das Abrechnungsmodell in die Versorgungstechnologie integriert ist.

Die meisten Befürworter des Utility Computing, einschließlich Papadopoulos, sind sich darüber einig, dass die dritte Form des Utility Computing das größte Potenzial zur Veränderung der IT-Landschaft und der Gesamtkosten für den Betrieb eines Rechenzentrums aufweist. Aber Papadopoulos glaubt, dass die Idee ihrer Zeit noch voraus ist, auch wenn Anbieter wie Sun sich bereits um echtes Utility Computing bemühen.

Andererseits haben Unternehmen, die dabei sind, die Middleware-Ebene zu vereinheitlichen und diese Ebene als Erfüllungsort für die Anbieter von Lösungen und als die Zielebene für Entwickler definiert haben, eine größere Aussicht darauf, von den Vorteilen des Utility Computing zu profitieren, wenn es einmal zur Verfügung steht. Der Grund dafür ist, dass Utility Computing bei der Verteilung von Rechenleistung über ein Netzwerk ein hohes Maß an Standardisierung benötigen wird und dass Standardisierung fast synonym mit der Vereinheitlichung ist, die nur auf der Middleware-Ebene erreicht werden kann.

Andere Formen des Utility Computing werden auf den unteren Ebenen der Hierarchie erhältlich sein (unterhalb der Middleware-Ebene), es wird sich aber um nicht-standardisierte Formen mit beschränktem Einsatzgebiet handeln. Middleware-basiertes Utility Computing wird eine weit größere Flexibilität bei der Bereitstellung, beim Kauf und Verkauf und beim Handel mit Rechenleistung über Netzwerke erlauben. Bis dieser Tag kommt, ist eine Vereinheitlichung für die zweite der drei Formen des Utility Computing (das Abrechnungsmodell) noch immer zwingend erforderlich.