Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Bill Raduchel, DV-Chef bei Sun, berichtet von seinen Erfahrungen (Teil 1)

Rightsizing bedeutet im Kern Reduzierung der Komplexitaet

02.04.1993

Ehrlich gesagt gab es einen ganz einfachen Grund, warum wir anfingen, uns mit Client-Server-Systemen auch fuer unsere eigenen DV-Abteilungen zu beschaeftigen: Wir bauen und verkaufen diese Dinge. Es war also nicht so, dass wir einfach dasassen und uns fragten, welchen Weg wir denn nun einschlagen sollten. Wir wussten so einigermassen, welcher Weg das war.

Wann immer ich Zweifel hatte, dachte ich an einen Freund, der eines Tages zu einem bekannten Minicomputer-Hersteller ging, um bei der Loesung eines von dessen DV-Problemen zu helfen. Sechs Monate hat er die Probleme analysiert, bevor er dem Management seine Ergebnisse praesentierte. Er empfahl die Anschaffung von sechs Mainframes. Es war sein letzter Arbeitstag dort.

Ich habe daraus gelernt, dass objektive Antworten nicht immer erkennbar die richtigen sind. Wir haben mit einer Minicomputer- Loesung angefangen, die wir weltweit einsetzten, bis wir ein Umsatzvolumen von ungefaehr 300 Millionen Dollar hatten. Damals sagte uns jeder, dass diese Loesung am Ende ihrer Leistungsfaehigkeit sei und dass wir etwas anderes brauchten.

Also machten wir uns auf, um ein System zu suchen, das uns bis zu einigen Milliarden Dollar Umsatz wuerde begleiten koennen. Das Team sah sich um und kam mit einer sehr nachdruecklichen Empfehlung zugunsten einer Mainframe-Loesung (von Amdahl; Red.) zurueck. Diese wollten wir innerhalb eines Jahres einsatzbereit haben. Leider wurden drei Jahre daraus, und als wir das System 1989 zum erstenmal hochfuhren, wussten wir ganz genau, dass es inzwischen obsolet geworden war.

Das grundlegende Problem in unserem Geschaeft ist der staendige Wandel. Als wir ein 300-Millionen-Dollar-Unternehmen waren, haben wir jedes Produkt - jede Workstation und jeden Server - kundenspezifisch gefertigt. Japaner bekamen ein japanisches Netzteil, Englaender ein englisches und Amerikaner ein amerikanisches.

Heute bauen wir etwa 50 000 bis 60 000 Systeme pro Quartal, und darunter sind vielleicht noch 100 kundenspezifische. Als wir ein Unternehmen mit 300 Millionen Dollar Umsatz und auftragsgebundener Fertigung waren, haben wir ein Management-Informationssystem installiert.

Wir haben dieses System noch heute, machen aber inzwischen vier Milliarden Dollar Umsatz. Und einmal ganz ehrlich - das ist eines der Dinge, die uns noch einmal umbringen werden.

Jeder redet heute ueber Rightsizing oder Downsizing oder Upsizing, je nachdem, wo man gerade ist.

Ich habe ziemliche Schwierigkeiten mit diesem Begriff Rightsizing, denn obwohl er populaer ist und sogar politisch korrekt sein mag, weiss ich eigentlich nicht genau, was er bedeutet. Ich habe zunaechst einmal eines herausgefunden: Rightsizing bedeutet nicht unbedingt, die Groesse eines Computers zu veraendern.

Es gibt relativ kleine Mainframes, und es gibt relativ grosse Server. Wir verkaufen Server, die so gross und leistungsfaehig sind wie die meisten Mainframes - in vielen Faellen sogar noch leistungsfaehiger. Wenn Sie also auf verteilte Server umsteigen, steigen Sie nicht unbedingt auf kleinere Systeme um. Auf preisguenstigere, ja, aber nicht unbedingt auf kleinere.

Rightsizing bedeutet auch nicht, eine Organisation oder ihre Personalstaerke zu veraendern, und meistens hat es auch nichts mit Verkleinerung einer Datenbank zu tun. Im Gegenteil - Rightsizing fuehrt nach meiner Erfahrung eher zu groesseren Datenbanken als sie fuer Mainframe-Loesungen typisch sind.

Letztlich bin ich zu dem Schluss gekommen, dass Rightsizing im Kern auf eine Reduzierung der Komplexitaet hinauslaeuft: Man versucht, die Loesung nicht komplexer zu machen, als das Problem es erfordert. Und das ist wirklich ein Dilemma fuer die Entwickler. Immer wieder sind wir in Versuchung, aus dem, was fuer unseren Kunden eine kleine und unwichtige Aenderung ist, ein umfangreiches Systemprojekt zu machen.

Global Accounts als Herausforderung

Auch bei Sun haben wir dadurch gewonnen, dass wir beim Einsatz unserer Systeme ein grosses Mass an Komplexitaet loswurden, einfach indem sich immer diejenigen mit einem Problem beschaeftigen, die sich damit am besten auskennen.

Wie bereits gesagt, wir hatten nicht unbedingt den Ansatz: "Es ist wichtig fuer Sun, in den naechsten fuenf Jahren ein Rightsizing- Programm durchzuziehen." Wir wollen lediglich versuchen, Computer auf jede moegliche Art fuer unser eigenes Geschaeft einzusetzen.

Drei Dinge machen unser Unternehmen fuer einen DV-Mann zu einer Herausforderung. Das erste ist die Tatsache, dass wir seit zwei Jahren mit sogenannten Global Accounts arbeiten. Das Prinzip ist einfach: Ein Kunde hat weltweit die gleichen Einkaufsbedingungen. Aus administrativer Sicht dagegen, also aus Sicht der DV, ist so etwas ein Alptraum, da Sie ganz ploetzlich kein deutsches System mehr haben koennen, kein amerikanisches und kein franzoesisches oder japanisches System. Alle muessen verbunden werden.

Unsere Vertriebsorganisation arbeitet mit Provisionen. Ein Umsatz in Deutschland kann heute dazu fuehren, dass fuer jemanden in Los Angeles eine Provision faellig wird, moeglicherweise auch noch fuer einen Mitarbeiter in Tokio und einen in Sydney. Wir muessen daher Umsaetze, Produkte und Seriennummern ueber mehrere Laender hinweg verfolgen, da der Account Manager fuer einen solchen Kunden ohne weiteres in Frankfurt, in Stockholm oder in Tokio sitzen kann.

Der erste grundlegende Wandel, mit dem wir fertig werden muessen, ist also die Tatsache, dass wir nicht mehr mit lokalen Systemen arbeiten, die auf der finanziellen Ebene - hauptsaechlich auf Berichtsebene - miteinander kommunizieren, sondern mit Systemen, die weltweit auf der Ebene von Transaktionen zusammenarbeiten muessen.

Eine zweite Herausforderung ist die Tatsache, dass die Kunden aus unterschiedlichen Gruenden nicht gleichmaessig ueber das Quartal verteilt ordern und dass wir nicht gleichmaessig verkaufen. Am letzten Tag eines Kalenderquartals haben wir nicht selten einen Auftragseingang, der zehnmal hoeher ist als sonst. Manchmal kommen an einem solchen Tag sechs bis sieben Prozent des Quartalsumsatzes herein.

Aus der Sicht eines DV-Mannes ist auch diese Situation ein Alptraum, da er fuer einen einzigen Tag im Quartal ein System unterhalten muss, das das sechs-, sieben- oder achtfache der normalen Last verarbeiten kann. Ausserdem benoetige ich ein hohes Mass an Zuverlaessigkeit, denn wenn das System am letzten Tage eines Quartals ausfaellt, haben wir ein echtes Problem. Dass wir solche grossen Spitzenkapazitaeten vorhalten muessen, hat sehr grossen Einfluss darauf, wie wir unsere Systeme entwickeln, verwalten und aendern.

Die dritte Herausforderung besteht darin, dass wir komplette Auftraege ausliefern - es zumindest versuchen. Der Kunde will komplette Systeme und nicht einzelne Komponenten, die er an seinem Wareneingang zusammensetzen muss.

Noch immer haben wir ungefaehr 20 000 Lagerprodukte im Angebot, aus denen ein Kundenauftrag bestehen kann. 35 davon machen ueber 90 Prozent unseres Systemumsatzes aus. Die anderen 19 965 verkaufen wir unter Umstaenden nur einmal im Quartal.

Mein groesstes Problem dabei ist die Tatsache, dass mein Mainframe sehr monolithisch ist - er behandelt alle Artikel gleich. Ich glaube, ich verbringe mindestens zehnmal soviel Zeit wie eigentlich noetig, um meine Fertigungs- und Distributionsoperationen zu managen, einfach aus dem Grunde, dass 35 Produkte praktisch den gesamten Umsatz machen, ich sie aber nicht anders behandeln kann als all die anderen, die wir anbieten muessen.

Die Computerindustrie ist nicht statisch. Das Geschaeft und seine Praktiken veraendern sich staendig. Wenn ich vorausschaue, baue ich meine Plaene auf der Annahme auf, dass der durchschnittliche Lebenszyklus unserer Geschaeftsmethoden etwa drei Jahre ist. Manche halten etwas laenger, aber den Luxus einer Anwendung, die ich 15 oder 20 Jahre einsetzen kann, kenne ich nicht.

Was wir getan haben, hat sich fuer uns ausgezahlt. Zum Beispiel haben wir mit unserem Mainframe begonnen, als wir etwa 1,3 oder 1,4 Milliarden umsetzten. Die Leute, die uns die Maschine verkauften, rechneten damals damit, dass wir sie alle sechs oder neun Monate gegen eine neue auswechseln wuerden. Wir haben diese Maschine heute noch. Wir haben einiges daran ausgetauscht, aber die Basismaschine ist noch die gleiche.

Wir haben darauf heute bei vier Milliarden Umsatz mehr freie Kapazitaet als damals mit zwei Milliarden. Wenn ich den Stecker unseres Mainframes endgueltig ziehen werde - so etwa in 18 Monaten - dann wird es immer noch die gleiche Maschine sein, und wir werden sie nicht aufgeruestet haben.

Wir haben einige Anwendungen entwickelt, mit denen wir sehr schnell, direkt und kosteneffektiv auf Kundenwuensche eingehen koennen. "SO Tool" heisst die Software, mit der wir den Hardwareservice verfolgen. Mit ihr arbeiten in den USA taeglich 400 Leute und noch einmal so viele in der ganzen Welt, wenn sie den Hoerer abnehmen und einen Kunden am Apparat haben, der sagt: "Ich habe ein Problem. Ich brauche einen Techniker."

Teilprojekte oft sinnvoller

Wir haben das mit einem kleinen Team gemacht, das seine Arbeit eigenstaendig organisiert hat. Unsere Ziele haben wir mit 750 000 Dollar in einem Jahr und mit sechs Leuten erreicht.

Tatsaechlich habe ich fuer mich eine kleine Regel aufgestellt: Wenn wir fuer ein Projekt mehr als ein Jahr, mehr als zehn Mitarbeiter und mehr als eine Million Dollar braeuchten, sollten wir uns ueberlegen, ob wir dieses Projekt wirklich richtig angehen.

Wir machen natuerlich auch groessere Dinge, aber wir teilen sie gerne in Teilprojekte auf, die unterhalb dieser Grenzen liegen, und wir versuchen zudem, den Aufwand fuer die Koordination moeglichst gering zu halten.

Kleine Projekte sind viel kosteneffektiver, benoetigen weit weniger Koordination, koennen von den Beteiligten selbst gemanagt werden und sich eng an den Kundenbeduerfnissen orientieren.

Die zweite Anwendung kommt gerade heraus, und sie hat langfristige Auswirkungen auf das Unternehmen. Wir haben unsere Mitarbeiter gefragt: "Wie verbringt Ihr Eure Zeit? Wofuer wendet Ihr sie auf?" Das Ergebnis war nicht gerade ueberraschend: Sie verbringen einen enormen Teil ihrer Zeit mit der Suche nach Informationen.

Wir haben uns entschlossen, alle Informationen, die unsere Mitarbeiter benoetigen, in ein koordiniertes Framework zu bringen. Wir verwenden dafuer die Answerbook-Technologie unseres Betriebssystems Solaris, die fuer die Online-Dokumentation entwickelt wurde. Es erlaubt Volltextsuche in Hypertext und Grafiken.

Was wir erreicht haben, ist die Moeglichkeit, Informationen in einem standardisierten und konsistenten Format auf jedem Desktop im Unternehmen zur Verfuegung zu stellen.

Dieses Projekt hat uns etwas mehr als ein Jahr gekostet, da es einen grossen Designaufwand erforderte. Aber wir sind unter einer Million Dollar geblieben. Wir glauben, dass das System nicht weniger als eine halbe Arbeitsstunde pro Tag und Mitarbeiter einsparen kann, die sonst verschwendet waere.

Wir moechten im Laufe der Zeit immer mehr Wissen in das System bringen und seine Wissensbasis so ausbauen, dass in drei Jahren jeder Mitarbeiter die Gewissheit hat, dort online praktisch jede Information zu finden, die er fuer seinen Job benoetigt.

Es geht beim Rightsizing darum, dass wir die Art und Weise aendern, in der wir arbeiten. Wir kommen weg von grossen Projekten. Wir kommen hin zu kleinen, die besser kontrolliert werden koennen, in denen die Leute mehr Eigenverantwortung haben und naeher am Kunden sind, dem sie ja letztlich dienen sollen. Und gleichzeitig koennen wir das alles zusammenhalten, indem wir die System-Tools und eigene Entwicklungen benutzen.

Gespart haben wir auch beim Auftragszyklus. Darunter verstehen wir die gesamte Zeit von der Plazierung eines Auftrages durch den Kunden bis zur Bezahlung. Waehrend dieser Zeit muessen wir Kapital binden, um die Wuensche des Kunden zu erfuellen. Dieser Zyklus ist ein extrem wichtiger Faktor der Profitabilitaet, der Liquiditaet, der Kundenzufriedenheit und der Qualitaet.

Wir haben diese Zeitspanne waehrend der letzten drei Jahre um 25 Prozent reduzieren koennen, von 240 auf 180 Tage. In einer anderen Masseinheit ausgedrueckt, entspricht das 500 Millionen Dollar Barmitteln in unserer Bilanz, die wir dadurch einsparen konnten, dass wir unsere Geschaeftspraktiken geaendert haben. Um das zu erreichen, mussten wir vieles modifizieren, was nicht an erster Stelle ein DV-Thema ist. Aber wir haben diese Veraenderungen ermoeglicht, indem wir nur die zentralen Aufgaben auf dem Mainframe gelassen haben.

Ich rede von Rightsizing vor allem als der Verteilung von Zustaendigkeiten und Faehigkeiten mit dem Ziel, Probleme mit Hilfe von Informationstechnologie zu loesen. Fuer uns war das wirklich das eigentliche Thema: Lasst uns die Informationen verteilen, statt sie in einem Zentrum zu sammeln. Lasst uns Informationssysteme benutzen, um die Informationen dorthin zu bringen, wo sie gebraucht werden, damit die Leute vor Ort ihre Probleme loesen koennen. Denn die Probleme stellen sich vor Ort, und dort ist auch das Wissen zu ihrer Loesung konzentriert.

Wir bauen vor allem auf Kooperation und auf Teilen, nicht auf Zentralisierung und Kontrolle. Dabei aehnelt unsere Installation insgesamt aber mehr der klassischen Mainframe-Installation als einer PC-Umgebung. Kein System laeuft als individueller Desktop. Alle zusammen bilden ein koordiniertes System. Dass die einzelnen CPUs beim Benutzer auf dem Schreibtisch stehen, ist eine Aeusserlichkeit.

Der Mainframe als virtuelle Netzressource

Wir haben unser Ziel in vier Schritten erreicht. Der erste Schritt war der Aufbau des Netzwerks. Dann haben wir den Mainframe praktisch zu einer virtuellen Ressource in diesem Netzwerk gemacht. Als naechstes haben wir alle Datenbankabfragen vom Mainframe auf lokale Sun-Systeme vor Ort verlagert. Und schliesslich haben wir alle unsere neuen Systeme um diese verteilten Kopien der Datenbank herum gebaut.

Wir haben 20 000 CPUs in unserem Netzwerk. Einmal hat einer unserer Ingenieure einen Daemon durchs System geschickt, um die Maschinen zu zaehlen. Es hat drei Tage gedauert, und er kam auf ueber 19 900. Die Zahl hat sich mittlerweile sicher geaendert.

Auf dem Netzwerk laufen ueber 300 Unix-Anwendungen. Insgesamt haben wir etwa 330 Anwendungen, die wir als kritisch fuer das Unternehmen klassifizieren. Etwa 25 davon laufen auf dem Mainframe, der Rest auf Unix-Servern und im Netz.

Als zweites haben wir uns gesagt: "Okay, jetzt haben wir diesen Mainframe. Machen wir ihn doch zu einer virtuellen Ressource dieser Workstations." Also haben wir einige Server angeschlossen. Alle Workstations in unserem Netzwerk koennen als RJE-Station, als 3070-Terminal, als multiple 3070-Terminals oder als Print Receiver arbeiten.

Wir haben eine Anwendung namens "Viewmaster" geschrieben, die den gesamten Print-Output vom Mainframe nimmt und im Netzwerk elektronisch verbreitet. So sparen wir uns die Versendung einer ganzen Menge Papier.

Als dritten Schritt haben wir uns einmal unsere Daten angeschaut. Dabei haben wir bemerkt, dass kaum ein Mainframe-Zugriff wirklich einen Update der Datenbank zum Ziel hatte. Die Mitarbeiter haben vor allen den Status von Auftraegen abgefragt und gelegentlich ein paar Analysen ausgefuehrt. Es ging um Management-Informationen, um die Planung von Nachfrage und Umsatz und solche Dinge. Dafuer braucht man aber keine Realtime-Daten.

Wir haben also solche Informationen vom Mainframe herunterkopiert und ein File daraus gemacht. Wir haben eine Kopie in Europa, eine in Japan, eine in der Abwicklung, eine im Marketing und eine im Vertrieb installiert. Mittlerweile haben wir rund ein Dutzend Kopien weltweit.

Datenbank nicht an den Mainframe gebunden

Dann haben wir eine weitere Anwendung, "Sunray", geschrieben, welche die Extraktion der Daten vom Mainframe verwaltet, sie auf kontrollierte und automatisierte Weise an lokale Empfaenger verteilt sowie die lokalen Datenbanken aktualisiert. Wir fuehren also alle Updates auf dem Mainframe durch, und jeden Morgen beginnen wir mit Japan.

Praktisch alle Abfragen werden jetzt auf diese Weise erledigt. Die Mainframe-Abfragen sind beinahe auf Null zurueckgegangen, und die einzigen, die ihn noch benutzen, sind die Produktionsplaner und diejenigen, die mit unserem System fuer die Materialplanung arbeiten.

Wenn wirklich jemand einmal Realtime-Daten braucht - nun, es haengt ja jeder am Netzwerk, und jeder Knoten kann ein 3270- Terminal sein. Also muss man nur ein Icon anklicken, um sich die Realtime-Daten holen zu koennen. Wir haben dafuer aber nur sehr wenig Bedarf.

Das Resultat all dieser Schritte: Wir haben den groessten Teil der Informationen und der Verarbeitung auf lokale Systeme verlagert. Vermutlich mehr als 95 Prozent aller Standardzugriffe erfolgen nun auf preiswerteren Servern in preiswerteren Umgebungen. Dadurch haben wir uns wahrscheinlich drei Mainframe-Upgrades erspart.

Aber noch wichtiger ist, dass wir alle diese neuen Systeme um lokale Kopien der Datenbank herum gebaut haben. Sie sind nicht an den Mainframe gebunden, und sie laufen auf Sun und auf Unix. Die Mitarbeiter koennen sie verwalten; sie haben das Beste aus zwei Welten.

Unsere europaeischen und japanischen Beschaeftigten arbeiten heute mit der jeweiligen lokalen Kopie der Datenbank. Sie tun so gut wie nichts mit dem Mainframe, ausser dass sie die Updates durchreichen, um sicherzustellen, dass diese alle notwendigen internen Prozesse durchlaufen und wir das Produkt so fertigen koennen, wie der Kunde es haben will.

Als wir unser Rightsizing-Projekt besprachen, gab es vier Vorteile, die ich als versteckt bezeichnen will, da sie zu Beginn nicht offensichtlich waren: Skalierbarkeit, Separierbarkeit, Singularitaet und Geschwindigkeit.

Skalierbarkeit ist wichtig, weil sie uns zwei Dinge erlaubt. Unter Skalierbarkeit verstehen wir die Moeglichkeit, unsere Anwendungen auf kleinen Workstations oder auf grossen Servern laufen zu lassen. Es ist die gleiche Umgebung - Hardware wie Software.

Ein Design wandert um den ganzen Globus

Das ist aus zwei Gruenden sinnvoll. Frueher waren wir gezwungen, Anwendungen erstens fuer den PC, zweitens fuer Minicomputer und drittens fuer Mainframes zu entwickeln. Heute verwenden wir nur noch ein Design und skalieren dieses ueber den gesamten Globus. Wir nehmen einfach ein kleineres oder ein groesseres System - wie es gerade gebraucht wird.

Fuer mich war das ein Riesenschritt, denn ich musste mich vorher ja auch darum kuemmern, wie alle diese Systeme zusammenarbeiten und wie wir den gemeinsamen Kern erhalten.

Dass ich jetzt ein Design verwenden und einfach skalieren kann, indem ich verschieden grosse Systeme nutze, spart eine Menge Aufwand und Kosten beim Betrieb und bei der Koordination.

Der zweite Nutzen der Skalierbarkeit ist, dass alle Systeme, die ich schreibe, und praktisch alle kommerziellen Systeme, die ich kenne, letztlich aus Front-ends und Back-ends bestehen. Wenn man fuer beide in der gleichen Umgebung auf dem gleichen System entwickeln kann, spart man in der Entwicklung um einen Faktor bis zu 10.

Der Vorteil unserer Umgebung liegt darin, dass die Mitarbeiter am Front-end wie am Back-end die gleichen Compiler und die gleiche Entwicklungsumgebung haben.

Um viele sonst moeglichen Probleme braucht man sich so gar keine Gedanken zu machen. Und ist es nicht logisch, dass man spart, wenn man nur einmal kodieren, einmal debuggen, einmal testen und einmal warten muss?

Der zweite versteckte Vorteil unseres Rightsizing-Konzepts ist die Separierbarkeit. In meiner Mainframe-Umgebung muss ich etwa die Haelfte der Ressourcen aufwenden, um die Zugriffe auf die Maschine, die Zuteilung und die Verwendung der anderen Ressourcen zu koordinieren. Also haben wir den Beschaeftigten gesagt: "Macht das auf euren Servern. Sie gehoeren euch." Die Leute verwalten ihre Ressourcen selbst, ihre Last und ihr Scheduling. So bekommen wir eine hoehere Effizienz und mehr Zuverlaessigkeit mit einem geringeren Mass an Komplexitaet, als wir sie in einer Mainframe- Umgebung haetten.

Wir haben die Leute auch davon ueberzeugen koennen, dass man Software modular aufbaut. Ich glaube, bei jedem unserer neuen Projekte stammen etwa 75 Prozent des Codes aus anderen Projekten. Wir koennen 75 Prozent unserer Software wiederverwerten. Ich haette gern einen hoeheren Wert, aber 75 Prozent ist schon wesentlich mehr, als viele andere Unternehmen erreichen. Wir werden unseren Leuten also weiterhin sagen:

Macht die Software so, dass sie sich an verschiedenen Orten und in verschiedenen Umgebungen einsetzen laesst.

Der dritte Erfolg unseres Vorgehens ist Singularitaet. Das heisst, dass wir nur ein einziges, sehr kosteneffektives Netzwerk betreiben muessen. Unsere Gesamtkosten pro Desktop belaufen sich ungefaehr auf 5000 Dollar pro Jahr. Gewiss, wir kaufen zu internen Kosten. Aber es ist ein Inklusivpreis, alle Hardware und alle Software sind inklusive. Und das ist hauptsaechlich deswegen moeglich, weil wir nur ein Netzwerk betreiben muessen.

In diesem Netz habe ich einen Mainframe, Minis, Workstations, PCs und Server, aber alle diese Komponenten arbeiten auf die gleiche Weise. Dadurch spare ich eine Menge Geld. Ich glaube ohnenhin nicht, dass wir insgesamt eine teure Organisation betreiben. Die meisten unserer Kunden sagen mir, dass ich um einen Faktor zwischen 2 und 8 guenstiger arbeite als sie mit der gleichen Systemumgebung.

Wir koennen das, weil wir uns prinzipiell auf datenlose Desktops stuetzen. Taeten wir das nicht, waeren unsere Kosten wahrscheinlich um eine Zehnerpotenz hoeher. Datenlose Desktops bedeutet, dass die Daten nicht auf dem Desktop liegen und die Anwendungen auch nicht. Beide werden auf zentralen Servern gehalten. So koennen wir alle Daten sichern, wir koennen sie schuetzen. Das bringt Vorteile in der Systemadministration. Allein der datenlose Betrieb ermoeglicht es uns, die doppelte Anzahl von Maschinen zu unterstuetzen.

Server verbreitet weltweit Anwendung

Ausserdem ermoeglicht es den vierten Vorteil unseres Systems, seine hohe Geschwindigkeit. Alle Software wird ueber die zentralen Server verbreitet. Wenn ich eine neue Anwendungssoftware installiere, kann ich sie auf einen Server in Milpitas, Kalifornien laden, und innerhalb von 24 Stunden steht sie weltweit jedem zur Verfuegung - ohne dass ich noch eine Hand ruehren muesste.

Soviel also zu den Dingen, die normalerweise eine Menge Zeit und Aufwand erfordern, wenn man ein Netzwerk betreibt. Wir haben diesen Aufwand reduziert, und dazu sind noch alle Daten gesichert. Vor unbefugtem Zugriff geschuetzt liegen sie auf Servern. Wir haben die Sicherheit und die Kontrollmoeglichkeiten, die man eher von einer Mainframe-basierten Umgebung erwarten wuerde.

(wird fortgesetzt)

*Bill Raduchel ist Chief Information Officer bei Sun Microsystems.