IT-Rezentralisierung

Zentrale und dezentrale Konzepte ergänzen sich

30.06.2000
Aus durchsichtigen Gründen propagieren vor allem Hersteller von Großrechnern und Hochleistungs-Servern die Rezentralisierung der IT. Doch was halten die Anwender von dieser Idee? Brauchen Unternehmen und Verwaltungen nach der Dezentralisierung in den 90er Jahren schon wieder ein neues Basiskonzept für ihre IT? Johannes Kelch* hat sich erkundigt.

Wie bei vielen Schlagworten der IT-Szene handelt es sich auch bei dem Begriff Rezentralisierung - und dem Ableger Re-Hosting - um eine mysteriöse Wortschöpfung. Was ist gemeint? Die Ablösung des Client-Server-Konzepts durch den guten alten Host mit Terminals? Die Umsetzung der Thin-Client-Idee durch Verlagerung von Software, Rechenleistung und Datenhaltung auf zentrale Server? Oder die Ergänzung der gewachsenen IT-Landschaft durch zusätzliche Großrechner?

All das ist möglich, doch ist es auch sinnvoll? Was sagen Anwender zu der Idee der Rezentralisierung? Und gibt es überhaupt Argumente dafür, die Systemarchitektur wieder einmal umzukrempeln? Banken und Versicherungen zählen zu den Unternehmen, die ihre bewährten Großrechner nie abgeschaltet haben, jedoch zusätzlich PCs einsetzen und zumindest in einigen Abteilungen Client-Server-Strukturen nutzen. Sind hier Tendenzen einer Rezentralisierung zu verzeichnen?

Als die Bayerische Vereinsbank und die Hypobank zur Hypo-Vereinsbank fusionierten, wurde die IT der beiden Institute zusammengeführt. Von Rezentralisierung keine Spur. Zur Verwaltung der Bestände dienen - wie früher - die Großrechner in den Rechenzentren; Fachabteilungen nutzen Client-Server-Installationen. Sämtliche Arbeitsplatzrechner in den Filialen wurden üppig mit dem Bankenpaket "BV+" und einer Office-Suite ausgerüstet. Die bayerischen Banker kombinierten Mainframes und Fat Clients, um die Vorteile zentraler und dezentraler Systeme zu verknüpfen.

Doch das bayerische Barock ist in der Informationstechnologie nicht das Maß aller Dinge. Die Anzeichen für grundlegende Veränderungen in der Finanzwelt sind unverkennbar. Sogar in der altehrwürdigen Sparkassenorganisation fährt der Zug in Richtung Rezentralisierung ab.

Dieter Bartl, Bereichsleiter Technologiekompetenzzentrum beim Informatikzentrum der Sparkassenorganisation in Bonn, glaubt, dass die Zukunft nicht nur dem Network-Computing, sondern auch der Rezentralisierung gehört. Die Anwendungen würden auf den Servern zentralisiert, dort ausgeführt oder in Form von Applets an die Arbeitsplatzrechner verteilt. Das Frontend erhalte "eine geringe Funktionalität", es werde künftig "nur noch für die mit Browsern realisierte Benutzeroberfläche zuständig" sein. Bartl weiter: "Network-Computing verbindet die Vorteile der zentralisierten Bereitstellung und Ausführung von Anwendungen sowie der gebündelten Verwaltung der Benutzer und Programme mit der Anwenderfreundlichkeit der bisherigen Client-Server-Lösungen."

So zentral wie möglich und so dezentral wie nötigDer IT-Fachmann der Sparkassenorganisation sagt auch eine Renaissance der Rechenzentren voraus. Diesen komme eine neue Bedeutung bei der Integration von Server-Systemen und Verteilkomponenten für Web-basierte Daten und Anwendungen zu. Außerdem sei es weitaus ökonomischer, Server physisch in Rechenzentren anzusiedeln und nur an wenigen Stellen zentral zu verwalten. Bartl resümiert, der Trend zum Network-Computing sei eine Rückbesinnung auf das Motto "So zentral wie möglich und so dezentral wie nötig".

Bei der dvg Datenverarbeitungsgesellschaft in Hannover, einem Informationsdienstleister der Sparkassen-Finanzgruppe, wird bereits für die von Bartl skizzierte Zukunft Software entwickelt. Die dvg verfolgt ein ehrgeiziges Ziel. Sie will den Vertrieb von Finanzprodukten verschiedener Anbieter (zum Beispiel Versicherungen, Bausparkassen, Aktienfonds) über die Sparkassen auf eine einheitliche Basis stellen.

Die Softwareentwickler haben sich nach Darstellung von dvg-Geschäftsführer Wolfgang Ahrens der "Multikanalfähigkeit" der Vertriebsunterstützung verschrieben.

Egal ob ein Kunde via Internet eine Versicherung abschließt oder ein Bankmitarbeiter in der Filiale einen Bausparvertrag vorbereitet, immer soll eine einfache, leicht bedienbare Technik den Zugriff auf eine einheitliche Datenbasis (Kunden, Konten) gewährleisten. Ausschließen will die dvg unproduktive Systembrüche, etwa wenn der Kunde via Internet nur ein Frontend erreicht, während der Bankmitarbeiter in der Filiale über das Intranet Transaktionen in den Großrechnern ausführen kann.

Multikanalfähigkeit bedeutet in der Konsequenz Vereinheitlichung der verschiedenen Frontends auf einen gemeinsamen Nenner (Browser-Technologie) und Rezentralisierung der Datenhaltung und Anwendungen. Ein "führendes Backend" erledigt den Login-Vorgang (PIN/TAN), begleitet den Beratungsprozess und lässt auf Anforderung Kontoauszüge drucken. Dahinter stehen die Backends der beteiligten Finanzdienstleister. Die Architektur einer "integrierten multikanal- und allfinanzfähigen Backend-Anwendung" zentralisiert den Zugriff auf das Backend, an dem wiederum weitere dezentrale Backend-Systeme angeschlossen sind (siehe Grafik "IT-Struktur bei der DVG").

Bei der dvg hat sich unterdessen ein anderes Systemmodell durchgesetzt. Um Raum zu sparen und den Mitarbeitern aufgabenspezifisch Einzel- oder Teamarbeit zu ermöglichen, gibt es in dem neuen Bürogebäude in Hannover keine festen Arbeitsplätze mehr, sondern Rechner auf Rollwägelchen, die man sich in Einzelbüros, Projekt- und Gruppenräume oder in einen offenen Bereich mit Espresso-Bar schieben kann. Da jeder vierte, oft sogar jeder zweite Mitarbeiter abwesend ist, kommt die dvg mit weitaus weniger Raum aus als bei stationären Büros. Durch dieses "Business-Club-Konzept" spart die dvg nach eigenen Aussagen jährlich 20 Millionen Mark.

Um dieses Konzept zu verwirklichen, hat das Unternehmen die Clients hard- und softwaretechnisch "extrem standardisiert", so Lars Nebert von der Organisationsentwicklung der dvg. Auf den Clients werden über automatische Software-Verteilmechanismen neben dem Betriebssystem Windows NT nahezu alle Anwendungsprogramme lokal installiert. Dagegen sind sämtliche User-Daten - einschließlich der Konfigurationsdateien der Anwendungsprogramme (NT-User-Profile, Browser-Einstellungen, Bookmarks) auf Servern abgelegt.

Nur aufgrund dieser Konstellation können die Beschäftigten an nahezu jedem Arbeitsplatz mit jedem beliebigen Rechner arbeiten, ohne auf ihre gewohnten Daten und Einstellungen verzichten zu müssen. Bei dieser Dezentralisierung der Anwendungen (mit zentraler Wartung) und zentraler Ablage der User-Daten sind laut Nebert die Support-Kosten für die Clients "sehr gering". Er betont: "Es fällt keinerlei Arbeit für Datensicherung, Datenrestauration, Fehlersuche oder manuelle Installationen an."

Zentral versus dezentral - die Debatte, die geprägt war durch den Gegensatz zwischen dem Host-Terminal-Konzept und der Client-Server-Architektur, ist obsolet. Die Anwender kombinieren völlig neu. Sie zentralisieren und dezentralisieren je nach Bedarf, je nach Aufgabe und oft gleichzeitig im gleichen Unternehmen.

E-Business und E-Commerce führen dabei nicht zwangsläufig zu einer zentralistischen Lösung (für Anwendungen und Datenhaltung). Zwar benötigen virtuelle Kaufhäuser und Portale jede Menge zentrale Rechenleistung für Datenbanken und Multimedia, sodass bei alteingesessenen Firmen ebenso wie bei Startups verstärkt Mainframe- und Midrange-Systeme zum Einsatz kommen. Aber das Pendel kann auch im Handel in die andere Richtung ausschlagen. Das gilt vor allem für stark filialisierte Unternehmen oder bei einem eng angebundenen Händlernetz.

Beispiel Smart: Anfang 2000 implementierte der Kleinwagenhersteller Micro Compact Car Smart (MCC) in Renningen eine nagelneue E-Commerce-Lösung. Für Oliver Hack von MCC ist die Eigenentwicklung, das "Interactive Smart Selling System" (IS3), für den Kauf von neuen Autos im Internet "die am weitesten fortgeschrittene Lösung". Smart habe den "Benchmark" für andere Autohersteller gesetzt - eine dezentrale Lösung mit Anbindung an ein zentrales System.

IS3 ist ein Car Configurator, der multimediale Darstellungen, die inhaltliche Beschreibung sowie Informationen zu den Bauteilen, Farben und Baubarkeitsregeln kombiniert. Der Kunde kann sich mit der Software im Internet oder vor Ort beim Händler am Point of Sale seinen individuellen Kleinwagen zusammenklicken. Laut Oliver Hack ist IS3 wegen der Vielzahl der möglichen Kombinationen ein "äußerst komplexes Modul".

Dezentrale Lösung für Smart-HändlerGrößtes Problem bei der Entwicklung war, dass Neuwagen nur über Händler abgesetzt werden können und deren verbindliche Preise beim Verkauf zugrunde gelegt werden müssen. Deshalb läuft IS3 nicht zentral auf der Domain von Smart, sondern auf den Websites der Händler. Jedes einzelne Smartcenter hat sein eigenes IS3. Jeder Händler kann den Car Configurator in einem Punkt ändern, er kann seine individuellen Preise eingeben.

Dieses dezentrale Konzept erfordert jedoch eine Anbindung an das zentrale Warenwirtschaftssystem von Smart, das auf einem Host läuft. Denn sogar bei einem Autohersteller mit kleinem Produktportfolio ändern sich ständig die eingesetzten Bauteile, die verfügbaren Farben, die entwickelten Modellvarianten und die technischen Baubarkeitsregeln. Der Car Configurator kann jedoch als Verkaufsinstrument nur funktionieren, wenn er ausschließlich jene Kombinationsmöglichkeiten zulässt, die auch gebaut werden können. So spielt Smart jeden Tag automatisch per Datenfernleitung Updates mit den aktuellen Änderungen in die dezentral laufenden IS3-Installationen der Händler ein.

Damit ist aber noch nicht die Spitze der Dezentralisierung erreicht. Es kommt noch besser. Will der Kunde online eine Anzahlung leisten, um damit seine Bestellung zu besiegeln und die Produktion auszulösen, landet er - ohne es zu bemerken - auf der Website eines Anbieters (Bibit-Billing-Services), der sich auf die Abwicklung von Zahlungen bei Internet-Geschäften spezialisiert hat. Liegt dessen Zahlungsbestätigung beim Händler vor, gibt dieser die Bestellung in einen Zentralrechner ein, der in der Fabrik in Hambach alle Produktionsaufträge verwaltet.

Anders als bei der E-Commerce-Lösung wurde bei MCC in Renningen die IT intern stark zentralisiert, um einen vollautomatischen Systembetrieb zu erzielen und die Kosten zu minimieren. Eine zentrale Datenbank speichert pro Anwender nicht nur persönliche Konfigurations- und Zugriffsinformationen, sondern auch ein individuelles Portfolio an Programmen. Wie bei der dvg in Hannover gibt es bei MCC keine Zuordnung von PC und Anwender. Eine einmalige Registrierung genügt, um einen neu eingestellten Ingenieur arbeitsfähig zu machen.

Nach der Anmeldung an einem PC ist der User jedoch nicht auf ein standardisiertes Angebot an Hard- und Software begrenzt; er kann alle Anwendungen aus der zentralen Datenbank ziehen, die er für seine spezielle Aufgabe benötigt. Die Smart-Firma kombiniert mit dieser Lösung die Vorteile einer dezentralen Rechenleistung mit dem geringen Administrationsaufwand eines zentralen Systems.*Johannes Kelch ist freier Journalist in München.

TendenzenEinen deutlichen Trend zur Rezentralisierung der IT registriert Michael Zaddach, Senior Manager ISM Consulting und Spezialist für System-Management beim Debis Systemhaus. Vor allem Unternehmen, die verteilte Strukturen aufweisen, zentralisieren unternehmenskritische Anwendungen und die Systemadministration.

Für Zaddach hat sich dieses Konzept bewährt: "Je mehr ich zentral leiste und administriere, desto niedriger ist der Personalaufwand und damit der häufig größte Kostenfaktor." Nicht alles jedoch wird zentralisiert. Office-Programme verbleiben nach den Erfahrungen und auch Empfehlungen von Zaddach auf den Clients, die deshalb nicht ganz dünn sein können. File- und Printserver müssen ebenfalls vor Ort laufen.

Re-Hosting ist für ihn ein fragwürdiges Schlagwort: "Mainframes gab es permanent für Individual- und R/2-Programme." Er sehe jedoch einen Trend zur "Konsolidierung auf Systemebene". Rechenzentren ließen zur "Backend-Optimierung" immer mehr kleine NT-Systeme virtuell auf großen Unix-Maschinen laufen, so der Berater.

Abb.1: IT-Struktur bei der DVG

Architektur einer multikanalfähigen Backend-Anwendung. Quelle: dvg

Abb.2: E-Commerce bei Smart

MCC Smart in Renningen kombiniert in seiner E-Commerce-Lösung zentrale und dezentrale Elemente. Quelle: Kelch