Die Unternehmen müssen sparen und sehen daher auch bei ihren IT-Systemen wieder genau auf die Kosten. Dabei spielen neben Anschaffungskosten vor allem auch die versteckten Kosten eine wichtige Rolle. Eine umfassende informationstechnische Infrastruktur wie J2EE beeinflusst die TCO eines Unternehmens auf vielfältige Weise.

Was kostet eine Infrastruktur?

Die Anschaffungskosten sind heute in der Regel nicht mehr das entscheidende Thema. Die Ausgaben für Lizenzen oder Geräte sind im Verhältnis zu den meisten IT-Budgets eher von untergeordneter Bedeutung. Außerhalb des Protokolls kann man erfahren, dass „Server heute nichts mehr kosten“ – was ja nur die Kehrseite der Erkenntnis ist, da sich Systeme nicht mehr über den Preis verkaufen lassen. Dennoch haben die wenigsten Unternehmen Geld zu verschenken, umso weniger, als dass die Anschaffungskosten oft die einzigen sind, die sie konkret ermitteln können. Eingesparte Lizenzen oder CPUs gelten dann sogar als Indikatoren einer kostenbewussten IT, was allerdings nicht notwendigerweise der Fall sein muss. Sofern dies jedoch in einer Unternehmensführung so gesehen wird, kann es für einen IT-Leiter durchaus überlebenswichtig sein, die eine oder andere Lizenz mehr zu sparen, vielleicht sogar trotz besserer eigener Einsicht.

Eine weitaus größere Rolle als der Preis spielen für die Anwender der Post-New-Economy jedoch Faktoren wie die Zukunftsfähigkeit einer Technologie oder auch die Zuverlässigkeit eines Anbieters. Wer sich hier verschätzt, kann später vielleicht nicht mehr aufrüsten oder steht gar ohne Support da und muss ihn teuer nachkaufen. Eine wirklich konsequente TCO-Rechnung müsste solche Risiken auch erfassen, schließlich enthalten die großen Namen wie IBM, Microsoft, Sun, Compaq oder Borland auch eine Art Versicherungsprämie gegen die Risiken des Marktes. Wichtig ist die Orientierung der Hersteller an allgemeinen Standards. Da J2EE nicht das fertige Produkt eines bestimmten Herstellers ist, sondern die Standardisierung der Kommunikation zwischen Komponenten, ist die Bindung an den falschen Hersteller zumindest bei der grundlegenden Architektur-Entscheidung kein Problem.

Der große Vorteil einer in Schichten – Präsentationslogik, Applikations- und Datenbank-Server – unterteilten Architektur besteht in der besseren Skalierbarkeit. Kein Unternehmen kann seine Systeme von Anfang an so dimensionieren, dass alle Eventualitäten abgedeckt sind. Skalierbarkeit bedeutet hier Flexibilität. Das Wachstum des Unternehmens, die Änderung der Prozesse, die Integration neuer Anwendungen usw. lassen sich durch Ausbau der Systeme mit der selben Infrastruktur abdecken. Oft wird übersehen, dass auch Skalierbarkeit ihren Preis hat; sie bedeutet immer auch eine nachträgliche Änderung der Systeme, deren Kosten nicht von Anfang an klar sind. Ein weites Feld für versteckte Kosten aller Art.

Leistung um jeden Preis

Die entscheidende Frage ist dabei, ob der erreichte Zuwachs an Leistung zu proportionalen oder überproportionalen Kosten erfolgt. Die Systeme werden zwar leistungsfähiger, aber die TCO schnellen nach oben. Wenn man für eine Verdopplung der Anzahl von Transaktionen einen fünffachen Preis zu bezahlen hat, dann darf man hinter den Begriff der Skalierbarkeit schon ein kleines Fragezeichen setzen. Wenn man die richtige Technologie und Architektur einsetzt, lässt sich ein annähernd proportionaler Kostenverlauf nämlich durchaus realisieren.

Performance und Durchsatz von Anwendungen sind Schlüsselfaktoren der Skalierbarkeit und mittelbar auch der TCO. Wenn eine Applikation auf einem gegebenen Server mehr Transaktionen pro Sekunde verarbeiten kann, ist sie automatisch kostengünstiger als eine andere, weil man weniger Lizenzen, weniger CPUs oder weniger Memory benötigt – auf einer Maschine kann man ja mehr Transaktionen ausführen. Jede Verbesserung der Skalierbarkeit bei gegebener Systemausstattung kommt daher den TCO unmittelbar zugute. So lässt sich beispielsweise in einer J2EE-Architektur die Skalierbarkeit durch die Partitionierung von Applikationsservern verbessern, wie es der Borland Enterprise Server vorsieht.

Damit können „virtuelle Application Server“ auf einem physikalischen Rechner ablaufen, die auch individuell konfiguriert und verwaltet werden können. Unternehmen haben damit die Möglichkeit, mehrere J2EE-Anwendungen logisch und physikalisch voneinander getrennt zu halten. Der Vorteil der Partitionierung gegenüber dem Ablaufen mehrerer Instanzen eines Application Servers auf einem Rechner besteht in den deutlich geringeren Hardwareanforderungen – beispielsweise für CPUs oder RAM – sowie in der Möglichkeit, Basisdienste gemeinsam zu nutzen. Die TCO beeinflusst dies in zweifacher Weise: zum einen durch den geringeren Ressourceneinsatz. Man benötigt weniger Server, wenn ein EJB-Container statt 256 MB nur noch 64 MB Memory benötigt; so kann man durch Partitionierung, die Kostenentwicklung in einem Skalierungsprozess proportional halten. Zum anderen können durch die bessere Nutzung der Ressourcen bei gegebener Hardware beispielsweise duplizierte Instanzen von Anwendungen eingesetzt werden, was die Ausfallwahrscheinlichkeit reduziert.

Versteckte Kosten

Erfahrungsgemäß sind die Kosten für die Implementierung und den Betrieb eines IT-Systems deutlich größer als die Entwicklungs- oder Anschaffungskosten. Die mittlerweile mehrjährige Diskussion um TCO hat auch gezeigt, dass man nahezu jedes Projekt zu Tode rechnen kann, wenn man nur lange genug rechnet und dabei immer neue Faktoren einbezieht. Andererseits haben sich genügend ernst zu nehmende Kostenfaktoren ergeben: von der Schulung der Mitarbeiter über den Stand-By-Support durch die Kollegen bis zu den unproduktiv verbrachten Stunden vor abgestürzten Systemen und finsteren Bildschirmen. Vor versteckten Kosten bleiben natürlich auch J2EE-Landschaften nicht verschont, zumal in vielen Unternehmen ein fundiertes J2EE-Know-how erst aufgebaut wird. Auch das Lehrgeld, das dabei unvermeidlich zu zahlen ist, fließt in die TCO ein.

Grundsätzlich gilt jedoch auch hier, dass die versteckten Kosten umso niedriger sind, je stabiler das jeweilige System läuft – und dass die Aufrechterhaltung eines stabilen Betriebes Geld kostet. Mit dem Vordringen von J2EE in geschäftskritische Anwendungsbereiche steigen diese Kosten. Können sie reduziert werden, also der „Stabilitätsaufwand“ gedrückt werden, wirkt sich das positiv auf die TCO aus. Hier bietet sich insbesondere der Einsatz von Tools für Monitoring und Management an. Für die heute üblichen komplexen Anwendungslandschaften werden auch komplexe Steuerungssysteme benötigt. Verteilte Applikationen oder auch Komponenten laufen auf verschiedenen Applikationsservern im Netz und sind nicht ohne Aufwand zu verwalten. Dabei erlauben viele Werkzeuge eine Administration nur auf Prozessebene, nicht aber auf der Ebene der Komponenten, so dass deren Status nicht kontrolliert werden kann. Während die Applikation als Ganzes den Eindruck munteren Arbeitens erweckt, sind womöglich schon die ersten Komponenten abgestützt.

Unterm Strich

Die Kosten für den Stillstand von Applikationen lassen sich meist nicht schätzen. Bei geschäftskritischen Anwendungen bedeutet der Systemausfall eine Unterbrechung des Geschäftsbetriebes und wird mit dem entstehenden Umsatzausfall nur sehr unzureichend erfasst. Verlorene Kundenbeziehungen, Imageschaden, Regressforderungen usw. können ein Unternehmen letztlich ruinieren. Wie soll man solche Kosten aber in die TCO einfließen lassen? Auch Sicherheit um jeden Preis würde – ernst genommen – das Ende des Geschäftsbetriebes bedeuten. So lässt sich nicht alles eindeutig quantifizieren, nicht nur bei den Kosten, sondern auch auf der Seite des Nutzens, auf den es schließlich ankommt. Bessere Skalierbarkeit, Stabilität oder Performance sind unbestrittene Stärken einer J2EE-Architektur; sie lassen sich in den seltensten Fällen in Euro und Cent zusammenzählen.

Borland

D-63225 Langen

Telefon: (+49) 06103/979-0

www.borland.de