Anbieter zum Thema
Mögliche Sackgassen sind aus heutiger Sicht:
- Fehlende Kompatibilität der Lösungen zwischen Herstellern
- Die notwendige Infrastruktur erreicht nicht den notwendigen Reifegrad
- Die Technologien erweisen sich als zu komplex für eine Massennutzung
- Die Orchestrierungs-Ebene kann so nicht umgesetzt werden
- Die technologischen Risiken sind also signifikant, alles andere wäre auch verwunderlich. Einsparungen in der angesprochenen Dimension fallen eben nicht als Wunder vom Himmel.
Aber das ist gar nicht das dominierende Problem!

Wir hatten zum Beispiel die Diskussion um die bei Harvard entwickelte Balanced Scorecard in den 90er Jahren. Die hat sich im großen Stil nie durchgesetzt. Dabei ist sie im Kern unverzichtbar für jede Service-Organisation.
Man mag ihr vielleicht einen anderen Namen geben, aber inhaltlich wird man große Teile umsetzen müssen, auch wenn das Abstraktionsniveau auf den ersten Blick abschreckend ist.
Die Kernfragen sind:
- Sind unsere Rechenzentren wirklich organisatorisch so weit, dass sie ihre Leistungen in Form eines Service-Katalogs anbieten können?
- Ist es gewünscht, dass Kunden aus den Abteilungen sich selber ihre Ressourcen Applikationen auswählen und starten?
- Ist ein Rechenzentrum wirklich in der Lage, einen Preise für alle diese Services zu nennen und auch verbrauchsabhängig zu berechnen?
- Ist der Kunde gewillt, eine Trennung zwischen Preis und Ressource zu akzeptieren?
Die Service-Spezifikation ist die Basis
Die Service-Spezifikation ist das Fundament jeder erfolgreichen Service-Erbringung. Das Dilemma des Kunden darf dabei nicht unterschätzt werden. Dabei geht es gar nicht um die wenigen großen Anwendungen eines Unternehmens wie SAP oder Email. Es geht um die manchmal tausenden von kleinen Spezialanwendungen, die auch im Kern das eigentliche Problem sind. Kaum ein Unternehmen hat Probleme damit, Exchange effizient zu betreiben (oder sollte es Probleme damit haben, dann ist das schnell lösbar). Was passiert mit der Vielzahl der kleineren Applikationen? Beispiel aus der Vergangenheit: eine Abteilung hat Geld für ein Projekt und sagt dem RZ: „Kauf mal einen Server und Speicher für diese Applikation und bring sie zum Laufen“. In Zukunft müsste kein Server mehr gekauft werden, sondern ein Template müsste aufgesetzt werden, damit der Kunde seine Applikation eigenständig aktivieren, starten, optimieren und terminieren kann. Der Kunde bezahlt einen Preis für eine Leistung, die er nun nicht mehr bildlich greifen kann.
Damit ist eine Reihe von Fragen verbunden:
- Werden gerade bei den vielen Projekt-basierten Server-Installationen die Kunden bereit sein, auf „ihren“ Server, also speziell auf den Nachweis einer von ihrem Geld gekauften Ressource zu verzichten?
- Lohnt sich der Aufwand der Automatisierung und Template-Erzeugung wirklich für jede kleine Applikation?
- Wer berechnet eigentlich den Preis und wie erfolgt die Abrechnung?
Neben den technischen Hürden hat das Software Defined Data Center eine hohe technologische Hürde. Die ist nicht unlösbar, aber wie gesagt, dieses Problem der Schaffung und Umsetzung von Service-Katalogen ist nicht neu. Und bisher hat es kaum funktioniert. In diesem Sinne wird es Zeit, sich von der Technik-Diskussion zu lösen und eine Service-Diskussion zu starten.

Damit kommen wir auch zum Fazit und den Empfehlungen von ComConsult Research:
- Die Technologien, die sich um den Begriff Software Defined Data Center ranken, werden in Stufen relevant für den Markt werden. Im Moment gehen wir von einem Zeitrahmen von drei bis fünf Jahren aus.
- Gerade zu Beginn dieser Phase werden Projekte je nach Ziel aufwendiger und kostenintensiver sein als später mit einem höheren Reifegrad der Produkte.
- Ein Einstieg in die Technik ohne die Festlegung eines langfristigen Zieles wird aller Voraussicht nach scheitern. Das Software Defined Data Center unterstellt implizit eine komplette Service-Orientierung der IT-Infrastruktur. Mit der Service-Orientierung sind eine ganze Reihe sehr komplexer Fragen verbunden.
- Konsequenterweise startet dann auch der Einstieg in das Software Defined Data Center nicht mit der Technik, sondern mit den organisatorischen Zielsetzungen: Wie stellt man sich das Rechenzentrum in fünf Jahren vor?

Dr. Jürgen Suppan gilt als einer der führenden Berater für Kommunikationstechnik und verteilte Architekturen. Unter seiner Leitung wurden in den letzten 25 Jahren diverse Projekte aller Größenordnungen erfolgreich umgesetzt. Sein Arbeitsschwerpunkt ist die Analyse neuer Technologien und deren Nutzen für Unternehmen. Er leitet das internationale Labor von ComConsult Research Ltd. in Christchurch, das die Technologieentwicklung in Asien, Australien, den USA und Europa analysiert und für Kunden bewertet. Gleichzeitig ist er Inhaber der ComConsult Akademie, der ComConsult Research GmbH und der ComConsult Technology Information Ltd.
(ID:42367468)