Übertragungstechniken im LAN/Verwendung standardisierter Arbeitsplatztypen sinnvoll

Anbindung an Geschäftsprozesse rechtfertigt erst die IT

01.05.1998

Grundsätzlich sind in der Informationstechnologie die Themenbereiche Geschäftsprozesse, Applikationsarchitektur, Systemarchitektur, Infrastruktur und Betrieb zu berücksichtigen. Abbildung 1 zeigt deutlich die Abhängigkeit dieser Bereiche untereinander.

Die Geschäftsprozesse bilden die Basis für die Aufgaben in einem Unternehmen. Letztere sind hierbei so zu organisieren und zu optimieren, daß eine klare Prozeßstruktur im Unternehmen durch eine entsprechende Aufbau- und Ablauforganisation umgesetzt werden kann. Die Informationstechnik ist allerdings kein Selbstläufer, sondern dient lediglich der Unterstützung der Geschäftsprozesse. Ein DV-System ohne die IT-Anforderungen aus den Geschäftsprozessen besitzt normalerweise keine Lebensberechtigung, da sein Zweck überhaupt nicht definiert ist. Gerade dies wird aber in der Praxis sehr oft realisiert - auf Basis von groben, rudimentären Forderungen. Ausnahmen bestätigen die Regel.

Die Applikationsarchitektur definiert die Gesamtheit der Anwendungen, die im Unternehmen benötigt werden. Hierzu gehört auch die Datenstruktur der benötigten Daten und der Informationsfluß zwischen den Anwendungen. Oft sind die DV-technischen Anforderungen bereits durch bestehende Host-Systeme abgedeckt, die durch Client-Server-Systeme ergänzt wurden.

Die gesamte Microsoft-Produktpalette, etwa MS-Office sorgt weiterhin dafür, daß sich viele Anwendungen durch einfache Server-Strukturen abdecken lassen. Dabei handelt es sich zum Teil um sehr einfache und nur mit hohen Kosten erweiterbare Strukturen.

Als optimal gilt eine Anpassung der Applikationsarchitektur an die Organisation durch die Verwendung standardisierter Arbeitsplatztypen.

Hierbei werden alle Prozesse im Unternehmen so strukturiert, daß drei bis fünf Arbeitsplatztypen alle Anwendungen überall im Unternehmen abdecken. Dieses Ziel läßt sich allerdings nur erreichen, wenn die Konzeption der Systemarchitektur eine klare Struktur der Clients und Server vorsieht. Das erweist sich gerade dann als spannend, wenn zusätzliche Anforderungen wie zum Beispiel Verfügbarkeit und Performance erfüllt werden müssen, die gegebenenfalls den Einsatz redundanter Systeme erzwingen. Ein Beispiel einer solchen Systemarchitektur ist in Abbildung 2 dargestellt.

Als eine aus technischen und wirtschaftlichen Aspekten heraus begründete, mittelfristig sehr wichtig werdende Systemlösung sollte an dieser Stelle die sogenannte netzzentrierte Anwendung oder auch Web-based Application genannt werden. Eine solche Systemstruktur erfordert gegenüber Client-Server ganz andere Lösungen in der Infrastruktur. Hier spielt der mögliche Migrationsaspekt eine sehr große Rolle und muß deshalb unbedingt beachtet werden.

Die Grundlage für das Konzept

Erst aus der Summe aller Anforderungen aus der Applikations- und vor allem der Systemarchitektur ergibt sich die Grundlage für die Konzeption einer schlüssigen Netzwerkinfrastruktur. Abbildung 2 zeigt eine solche Struktur, die aus einem beispielhaften Anforderungsprofil heraus erarbeitet wurde. Hierbei lassen sich die typischen Strukturen eines redundant aufgebauten Systemkonzepts erkennen, die durch eine redundante Infrastruktur idealerweise auch unterstützt wird.

Mit dieser ersten Konzeption können jetzt aufgrund der systemtechnischen Anforderungen realistische Lösungsalternativen erarbeitet werden, das heißt Einsatz von ATM, Gigabit Ethernet, n

100 Mbit/s Ethernet oder auch Token Ring (diese Technik ist immer noch in vielen Bereichen vorhanden) mit 16 Mbit/s oder zukünftig Gigabit Token Ring. Diese Technologien lassen sich zusätzlich mit Unterstützung von Layer-3- oder Layer-4-Switching-Technologien (es gibt Fälle, in denen dies wirklich sinnvoll ist) auf die im Unternehmen vorhandenen organisatorischen Strukturen abbilden.

Nach dieser grundlegenden Designphase können jetzt sämtliche Designregister in der Netzwerkplanungsphase gezogen und schließlich die Realisierung in Angriff genommen werden. Erst nachdem eine schlüssige Gesamtkonzeption erarbeitet und umgesetzt wurde, läßt sich der Erfolg des Gesamtprojekts anhand eines wirtschaftlichen Betriebs beweisen.

Hierbei sind die folgenden Zielsetzungen im Betrieb grundsätzlich zu beachten:

-Gewährleistung der Systemverfügbarkeit im Gesamtsystem,

-optimale Beherrschbarkeit der eingesetzten Technologien, das heißt Handhabbarkeit,

-Sicherstellung eines qualifizierten Supports durch interne und externe Mitarbeiter, gegebenenfalls auch durch Outsourcing,

-Optimierung der Automatisierung operativer und dispositiver Funktionen sowie die

-Optimierung der Total Cost of Ownership (TCO) im Betrieb.

Der Erfolg wird unter anderem an der Sicherstellung der geforderten Geschäftsprozesse durch einen wirtschaftlichen Betrieb aller Komponenten gemessen. Zu diesem Zweck sind neben den organisatorischen Aufgaben auch zusätzliche Systeme erforderlich, die den Serviceaspekt unterstützen.

Dazu eignet sich am besten ein möglichst mächtiges Werkzeug - das Service-Management-System. Dieses besteht aus Komponenten, die einen ganzheitlichen Betrieb der einzelnen Architekturen gewährleisten. Dazu braucht man folgende Systeme:

-Applikationsarchitektur:

Einsatz eines System-Managements mit Ausrichtung auf die Steuerung und Überwachung der Applikationen.

-Systemarchitektur:

Einsatz eines System-Managements mit Unterstützung der Steuerung und Überwachung von PCs, Servern, Datenbanken etc.

-Infrastruktur:

Verwendung eines Netz-Management-Systems.

Ein getrennter Betrieb dieser Systeme ist nicht sinnvoll, weil sie die Fehler ihrer Komponenten ohne Bezug auf das Gesamtumfeld melden. Bei einem Ausfall eines Netzwerksegments an einem Switch würde das Netz-Management selbst Alarm schlagen, gleichzeitig aber auch das System-Management, da an diesem Segment schließlich 40 Rechner in Betrieb sind und jetzt keine Verbindung zu dem Server X mehr haben. Zusätzlich meldet eine überwachte Applikation einen Connectivity-Fehler, da die Verbindung zu einem Client gestört ist.

Das Servicepersonal erhält in solchen Fällen unterschiedlichste Störungsmeldungen, die mit dem eigentlichen Fehler gar nichts zu tun haben. Hier hilft eine sogenannte Correlation Engine, die (siehe Abbildung 3) spezifische Störungsinformationen von allen Systemen aus dem Service-Management-System bekommt und durch vorher eingegebene Regeln feststellt, welche Fehlermeldung tatsächlich die eigentliche Fehlerursache benennt.

Der Aufwand lohnt sich

Erst dann wird dieser Fehler über ein zusätzliches Trouble-Ticketing-System geführt und zum Benutzerservice mit entsprechend ausgearbeiteten Eskalationsprozeduren an die Spezialisten weitergeleitet.

Ein solches Gesamtsystem läßt sich nicht einfach durch den Kauf einzelner Teilsysteme zusammensetzen. Hier sind eine umfangreiche Planung und ein kundenspezifisches Customizing erforderlich. Allerdings lohnt sich der Aufwand, da der Betrieb hierdurch erleichtert und damit letztendlich ein wirtschaftlicher Nutzen erzielt wird.

Die Total Cost of Ownership betrachtet die Kosten, die mit der Investition und dem Betrieb aller Komponenten, hier dem gesamten IT-System, im Zusammenhang stehen. Folgende drei Kategorien stehen im Vordergrund:

-Investitionskosten mit Hard- und Softwarekosten,

-Dienstleistungskosten wie Inbetriebnahme und Customizing sowie

-Wartung, Update und Upgrade.

Hard- und Softwarekosten als Investitionskosten sind mit der Lieferung beziehungsweise Erstellung der Software durch Soft- und Hardwareverkäufer direkt abgedeckt und damit auch am leichtesten zu identifizieren. Schwieriger wird die Definition der Betriebskosten, da diese von der Definition der Service-Level abhängen. Hier sind als Grundlage die Prozesse zu identifizieren, die für den Betrieb wesentlich sind. Auf der Basis dieser Prozesse lassen sich dann die Service-Level zuordnen und definieren.

Dieser Kostenblock beinhaltet nicht nur die externen Kosten wie Wartung, sondern auch die internen Kosten wie Personalkosten und die damit zusammenhängenden Ausgaben für Arbeitsplatz und Arbeitsgeräte (zum Beispiel Netzwerk-Analyzer). Zu diesem Zweck sind alle betrieblichen Tätigkeiten darzustellen und zu bewerten. Auch hier garantiert nur eine vollständige Betrachtung der einzelnen Bereiche ein ganzheitliches, in sich schlüssiges Betriebskonzept.

Angeklickt

Erst kommt die systemtechnische Analyse, dann das Design. Idealerweise können Lösungsvorschläge für eine Netzwerkinfrastruktur erst nach der vollständigen Klärung der Applika- tions- und Systemarchitektur auf Grundlage der Prozesse und deren internen und externen Informationsflüssen erarbeitet werden. Erst nach dieser Phase lassen sich aufgrund der Anforderungen Lösungsalternativen für die Infrastruktur erarbeiten, das heißt Einsatz von ATM, n

100 Mbit/s Ethernet oder Gigabit Ethernet, gegebenenfalls mit Unterstützung von Layer-3- oder Layer-4-Switching. Die Bildung eines IT-Teams ist ein Muß für eine ganzheitliche Unterstützung der Geschäftsprozesse. Leider werden solche Ansätze oft durch die spezifischen Teilinteressen einzelner Abteilungen geradezu wissentlich verhindert: Es gibt Unternehmen, in denen die Netzwerkabteilung nicht mit der Abteilung für Client-Server-Systeme oder der Software-Entwicklung diskutieren darf.

Hartwig Bazzanella ist President und CEO der NCB Informationstechnik AG in Neuhausen, Schweiz.