Wir ziehen viele Vorteile aus unserer Informations-Architektur. Der prinzipielle Vorzug der verteilten Verarbeitung ist der, nicht gezwungen zu sein, Information zu zentralisieren. Man bringt die Informationen naeher an die Stelle heran, an der sie benoetigt werden, naeher an die Leute, die wissen, was diese Daten bedeuten und was sie damit anfangen koennen oder tun muessen.
Wir haben festgestellt, dass es das Beste ist, sowohl die Verarbeitung der Daten als auch den Zugriff auf sie zu verteilen. Dadurch wird unser Management-Informationssystem so effizient. Es unterstuetzt die Mitarbeiter, laesst sie besser auf die Anforderungen reagieren.
Auf Unternehmensebene haben wir uns dafuer entschieden, uns auf Updates zu konzentrieren und nicht auf die Datenbanken selbst. Ich habe jeden Versuch eingestellt, die Datenbanken innerhalb des Unternehmens zu normieren. Die deutsche Organisation, die japanische oder die brasilianische - sie muessen ihr eigenes Leben leben.
Ich werde mich um die Normierung der Updates kuemmern, aber ich habe nicht genug Energie fuer die Datenbanken selbst, und ich wuerde zudem auch noch die gesamte Firma hemmen, wenn ich hier eine Normierung herbeifuehren wollte. Jetzt ist jeder selbst fuer seine Datenbank verantwortlich.
Wir haben die Komplexitaet all dessen, was wir tun, reduzieren koennen. Das liegt hauptsaechlich daran, dass wir gesagt haben: "Lasst uns die Systeme lose koppeln." Unter loser Kopplung verstehe ich, dass jedes System sich unabhaengig von anderen entwickeln kann, und dass nur die Schnittstellen zwischen den Systemen definiert sind.
Ich kenne einige Leute, die sich intensiv mit den wirtschaftlichen Gesichtspunkten der Software-Entwicklung beschaeftigt haben. Sie sagen, dass man sowohl die Zeit als auch den Aufwand fuer die Produktion eines Systems drastisch reduzieren kann, indem man die Komplexitaet reduziert. Acht Prozent weniger Komplexitaet in einem Projekt wird den Aufwand um das Zehnfache reduzieren. Wir waren wirklich erfolgreich dabei, die Systeme einfach zu halten.
Wir machen nicht viele komplizierte Dinge, wir versuchen, viele simple Projekte zu realisieren. "Keep it simple" ist immer noch eine der wichtigsten Lebensweisheiten.
Software-Oekonomen sagen, dass man mit einem Viertel der Manpower auskommt, wenn man ein Projekt in zwei gleich grosse Teile teilen kann, die Koordination erfordern. Wir versuchen also, Produktivitaet in unserer Organisation zu gewinnen, indem wir kleinere Projekte in Angriff nehmen und auf die integrierenden Aspekte des Netzwerkes vertrauen, wenn es darum geht, alles zusammenzubringen und die grossen Probleme zu loesen. Zumindest bei uns hat das funktioniert.
Wir bemuehen uns auch um Wiederverwendbarkeit. Wir wollen Code haben, den wir noch einmal verwenden koennen. Also sagen wir den Leuten: "Versucht nicht, das Problem zu loesen. Versucht herauszufinden, von welchem ganz generellen Problem dies eine spezifische Auspraegung ist. Loest das generelle Problem, und dann benutzt dieses Modul wieder und wieder."
Um das zu erreichen, haben wir einen technologischen Rahmen entwickelt, innerhalb dessen wir arbeiten und den wir publizieren und unseren Entwicklern nahebringen. Wir erzwingen also eine gewisse Standardisierung, so dass auch andere Gruppen einen neuen Code leicht wiederverwenden koennen.
Wir machen uebrigens gerade eine weitere Erfahrung. Und das ist die Erkenntnis, dass das groesste Problem zumindest in unserer Welt - aber wohl auch sonst ueberall - darin besteht, die Mitarbeiter auf dem laufenden, immer informiert und gut ausgebildet zu halten.
Als wir unser Mainframe-System einfuehrten, haben wir ueberlegt, wieviel Trainig wir benoetigen duerften, einen Zeitplan entwickelt und begonnen, die Leute zu trainieren. Als das System in Betrieb ging, war theoretisch jeder dafuer ausgebildet. Das einzige Problem war, dass genau das nicht stimmte. Wir haben sie trainiert, aber in einigen Faellen war das sechs, sieben oder acht Monate vor der Inbetriebnahme geschehen. Niemand konnte sich mehr an irgend etwas erinnern.
Wir glauben daher, und alle Studien von Experten bestaetigen uns das, dass Training effektiver ist, wenn man es dann durchfuehren kann, wenn die entsprechenden Kenntnisse benoetigt werden. Wir entwickeln daher zukuenftige Trainingsprogramme ausschliesslich um die Workstations herum, auf denen unser Kommunikationsprogramm basiert.
Wenn jemand im Telefonsupport - und dort arbeiten haeufig Teilzeitkraefte - Hilfe oder Unterstuetzung benoetigt, dann soll er sie auch gleich bekommen. Er muss die Moeglichkeit haben, ein Ikon anzuklicken und sofort eine Videokonferenz mit einem Supervisor aufzusetzen, um die notwendige Kommunikation zu haben.
Wir glauben, dass wir auf diese Weise die Faehigkeiten und den Horizont unserer Mitarbeiter so stark erweitern koennen, dass die Systemkosten nicht mehr ins Gewicht fallen. Wir haben 200 Millionen Dollar in Systeme investiert und 1,3 Milliarden in unsere Mitarbeiter. Wenn ich diese Mitarbeiter um zehn oder 15 Prozent effektiver machen kann, kosten mich die Systeme nichts mehr.
Architektur ist bindend
Ein grosser Vorteil leistungsfaehiger Workstations liegt auch darin, dass man online Videos einspielen und Sprache einbinden kann. So koennen sie die Mitarbeiter auf verschiedenste Arten unterstuetzen. Wir haben noch nicht einmal richtig angefangen, dies als Ressource fuer uns zu nutzen. Es wird aber in den naechsten beiden Jahren einer unserer Schwerpunkte sein.
Um das alles zu managen, mussten wir lernen, Systeme an das eigentliche Geschaeft zu binden. Systeme sollen den Managern ebenso gehoeren wie den DV-Leuten. Wir bringen Faehigkeiten und Verantwortung in die Geschaeftsbereiche. Wir versuchen, das ueber eine dokumentierte Architektur zu koordinieren, an der jeder teilhat.
Wir haben den Mitarbeitern die Architektur erlaeutert, sie ist fuer sie bindend. Wer sich nicht daran haelt, ist weg vom Fenster. Wir haben versucht, zu vermitteln, dass jeder Mitarbeiter einen grossen Freiraum hat, dass aber wir die Regeln bestimmen. Und der Preis der Freiheit ist nun einmal der, dass, wer sie missbraucht, grosse Probleme bekommt. Wenn man hier nicht konsequent ist, steht man eines Tages mit einem System da, mit dem man nichts mehr tun kann und in dem nichts mehr zusammenpasst.
Sun Microsystems erlaubt den Entwicklern nicht, die Systeme im Alleingang zu betreiben. Unsere Erfahrung damit, Systeme von Entwicklern betreuen zu lassen, ist, dass so etwas regelmaessig in einer Katastrophe endet.
Denn irgendwann, vielleicht 18 Monate spaeter und natuerlich mitten in der Nacht, bricht das System zusammen, und keiner weiss, wo die Entwickler sind, wo der Sourcecode ist oder was ueberhaupt passiert ist.
Wir haben uns angewoehnt, geplante Projekte zu hinterfragen. Bei jedem Entwicklungsprojekt, das auf uns zukommt und einen Aufwand von mehr als 25 000 Dollar bedeutet, fragen wir zunaechst einmal nach der Effektivitaet. "Muessen wir das wirklich tun, oder wuerde es nicht vielleicht auch ausreichen, ein Spreadsheet umzuschreiben und so dieses Projekt zu vermeiden? Koennen wir dem Projekt zugrunde liegenden Vorgang nicht anders gestalten, so dass er gleich effektiv, aber billiger ist?" Wir hinterfragen alles, und wir machen eine Menge Modifikationen.
Kuerzlich hatten wir ein Erfolgserlebnis, als wir bei einem Zwei- Millionen-Dollar-Projekt, das jemand haben wollte, in dieser Weise nachgefragt haben. Nach sechs Wochen kamen diese Leute ziemlich kleinlaut zu uns und sagten: "Wir haben herausgefunden, dass wir dieses Projekt ueberhaupt nicht durchzufuehren brauchen. Wir koennen ein Spreadsheet schreiben, das den Job tut und auch allen legalen Anforderungen genuegt. Wir brauchen kein neues System zu bauen."
Ich glaube, dass ich durch die Effektivitaet unserer Systeme insgesamt etwa zehn bis 15 Prozent meines Budgets spare, einfach weil wir einige Dinge nicht tun. Im Jahr 1990 ging es bei 70 Prozent aller Modifikationen auf unserem Mainframe darum, Funktionalitaeten zur Verfuegung zu stellen, die schon existieren. Sie waren schon da, aber die Leute wollten sie anders. Also gingen wir hin und gaben 200 000 Dollar aus, implementierten, testeten etc.
Wir haben das alles gestoppt, und wir haben soviel Effektivitaet dadurch gewonnen, dass diese Verfahrensweise kein Thema mehr ist. Zwar kommt noch ab und zu jemand und wuenscht eine Aenderung, aber dann setzen wir uns zusammen, und meistens kommt dabei heraus, dass es anders besser geht.
Wir haben noch nicht alles erreicht und wir werden niemals fertig sein. Denn ich gehe davon aus, dass sich unser Geschaeftsalltag alle drei Jahre aendert und dass ich bei den Anwendungen von einer Lebensdauer von drei bis vier Jahren ausgehen kann.
Echzeitsysteme bekommen eine voellig neue Bedeutung
Eine grosse Aenderung, die ich kommen sehe, ist die, dass die Kunden zwar weiterhin fragen werden, wann ihre Lieferung kommt. Sie werden aber nicht mehr die Kalenderwoche wissen wollen, sondern die Minute. Und das ist wieder ein grundlegender Wechsel. Echtzeitsysteme bekommen hier eine voellig neue Bedeutung. Praktisch jede Dienstleistungsbranche hat sich bereits so orientiert.
Ich glaube, das wird bei uns nicht anders sein. Wir werden auch in Richtung Echtzeitsysteme gehen muessen. Waehrend wir also unsere Mainframe-Anwendungen ersetzen, und das tun wir gerade, haben wir uns auch entschieden, dass wir sie veraendern werden, so dass sie Echtzeit-Analysen unterstuetzen.
Jedes global operierende Unternehmen muss sich damit auseinandersetzen, dass das Business sich aendert. Vielleicht nicht alle drei Jahre, wie in unserer Branche, aber es werden auch nicht mehr die 15 Jahre sein, auf die die Mainframe-Anwendungen ausgelegt waren. Und selbst, wenn es vier, fuenf oder sechs Jahre sind, wir werden unsere Organisationen und Systeme in einem drastisch verschaerften Tempo weiterentwickeln muessen. Wir sind also noch nicht fertig, und in mancher Beziehung stehen wir gerade erst am Anfang.
*Bill Raduchel ist Chief Information Officer bei Sun Microsystems.