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.

26.03.2004 - 

Software-Factory als Standard

XP-Migration der Clients wie vom Fließband

In Großunternehmen ist der flächendeckende Wechsel der Clients auf eine neue Betriebssystemplattform wie Windows XP ein aufwändiges Unterfangen. Wer hier möglichst effizient bei der Migration der zahlreichen Applikationen vorgehen will, sollte ein Verfahren wie das der Software-Factory als Standard einsetzen.Von Dieter Masak*

Zur Zeit beschäftigen sich zahlreiche Konzerne mit einer möglichen Migration ihrer Frontends auf Windows XP. Den Kern des Problems stellt die Vielzahl der Applikationen dar, die auf den Desktops der Anwender eingesetzt werden. Über ein gesamtes Unternehmen hinweg betrachtet, reicht ihre Zahl in der Regel bis zu einigen Hundert. All diese Anwendungen sollen natürlich auch in Zukunft auf XP die gleiche Qualität liefern wie bisher.

Oft nutzen IT-Abteilungen derartige Migrationen, um ihren breit gestreuten Fundus an Applikationen zu homogenisieren. Doch selbst bei einer sehr restriktiven Auswahl der zu übernehmenden Anwendungen, bleibt eine hinreichend große Anzahl an Applikationen übrig, die zu übertragen sind. Einfache Installations- und Lauftests dieser Software auf der XP-Plattform liefern relativ schnell einen ersten Überblick über die problematischen Migrationkandidaten sowie über die einfach zu übernehmenden Applikationen.

Diese ersten Tests ermöglichen eine Klassifikation der jeweiligen Applikation in folgende Kategorien:

- direkt migrierbar,

- migrierbar nach Update oder Versionswechsel,

- direkte Softwareänderungen sowie

- nicht migrierbar, also nach einem Alternativprodukt suchen.

Als Testumgebung ist selbstverständlich der zukünftige Hard- und Softwarestandard zu nutzen. Das heißt, es ist im Vorfeld festzulegen, welche Middleware, Datenbank-Clients oder X-Window-Clients für diese "XP-Readiness"-Tests zu verwenden sind. Grundsätzlich gilt: Alle veränderten oder alternativ gewählten Applikationen müssen so lange modifiziert werden und die Testsequenzen erneut durchlaufen, bis sie direkt migrierbar sind.

Begleitend zu den XP-Readiness-Tests ist es sinnvoll, einen "Software-Steckbrief" pro Applikation zu erstellen. Dieser enthält Informationen über die anwenderspezifische Installation und Konfiguration. Derartige Metadaten sind die Grundlage zur Erstellung von Paketen für die spätere Softwareverteilung. Das Ziel ist, eine Menge von Paketen in einem kontrollierten Prozess zu erstellen und damit ein gut plan- und vorhersagbares Deployment-Verfahren implementieren zu können.

Deployment parallelisieren

Als Vorlage für diesen Prozess dient die Software-Factory, eine Implementierung der wohldokumentierten Methode der Factory-Patterns. Das Ziel von Factory-Patterns ist, wiederkehrende Prozesse so hochgradig zu standardisieren und abzuarbeiten, dass es möglich wird, zumindest Teile dieser Vorgänge zu parallelisieren und damit Rationalisierungseffekte zu erzielen.

Für die Software-Factory bildet die zu migrierende Applikation mit allen ihren Bestandteilen ein einziges Paket. Alle Pakete werden wie auf einem Fließband identisch behandelt. Aus Sicht eines einzelnen Pakets wird zunächst die Eingangskontrolle durchlaufen. Hier wird die Vollständigkeit und formale Konsistenz der übergebenen Sourcen (Software und Metainformationen in Form der Dokumentationen beziehungsweise Software-Steckbrief) überprüft. Der Software-Steckbrief ist immanent wichtig für das gesamte Verfahren, da nur er allein den Durchlauf steuert. Einen willkommenen Nebeneffekt bildet der Umstand, dass es hiermit erstmals möglich ist, ein komplettes Software-Inventory zu erstellen.

Die so vorbereitete und wohldokumentierte Software verlässt die Eingangskontrolle und betritt den eigentlichen Prozess. An dessen Ende steht die Paketierung, deren Aufgabe es ist, mit dem jeweiligen Software-Verteilungsverfahren installierbare Pakete zu erstellen. Eine interne Qualitätssicherung sowie eine definierte Übergabe-Schnittstelle zur Qualitätskontrolle durch die abnehmende Organisationseinheit sind die beiden letzten Schritte.

Bei der Eingangskontrolle wird jede Software nach dem zu erwartenden Paketierungsaufwand kategorisiert. In einem Projekt bei einem großen deutschen IT-Dienstleister hat sich die Einteilung in vier Kategorien bewährt.

Eine Besonderheit bildet die erste Kategorie. Diese Applikationen müssen nicht paketiert, sondern nur auf Konformität mit dem Client-Standard überprüft werden. Dazu zählen zum Beispiel Browser-basierende Web-Applikationen oder X-Window-Anwendungen.

Die zweite Kategorie bedeutet direkte Produktkompatibilität. Hier ist nur die Lauffähigkeit der Software auf dem Client, also unter Windows XP, zu verifizieren. Die dritte Kategorie umfasst Software, die zum Beispiel durch ein Update des Herstellers XP-fähig wird. Die vierte Kategorie bildet die nicht migrierbare Software. Hier bleibt die Wahl, die Verwendung des Produkts einzustellen oder sich ein Alternativprodukt zu suchen.

Problem der Infrastruktur

Schwierig ist die Entscheidung, was in einem solchen Verfahren als Applikation und was als Infrastruktur zu bewerten ist. In der Praxis hat sich dafür ein zweistufiges Vorgehen bewährt. Zunächst wird die Infrastruktur, dazu zählen Datenbank-Clients, Browser etc. auf ihre XP-Fähigkeit überprüft. Anschließend werden diese Softwarepakete als fester Bestandteil der zukünftigen Umgebung definiert und die noch ausstehenden Applikationen auf ihre Kompatibilität bezüglich XP sowie der neuen Infrastruktur überprüft. Erst durch diese Trennung ist es möglich, den Übergang zu XP in einem geordneten Ablauf vorzunehmen. (ue)

*Dieter Masak ist zuständig für Technologie bei der Plenum AG in Wiesbaden.

Abb: Softwarefabrik: Applikationen paketieren

Ein "Steckbrief enthält alle für die XP-Migration wichtigen Informationen eines Applikationspakets. Quelle: Plenum