|
Hintergründe zu Softwarekonflikten
Konflikte in Softwarepaketen
Die Begriffe „Konfliktbehebung", „Konfliktvalidierung" und „Konfliktlösung" werden im Kontext der Softwarepaketierung und in verschiedenen Softwarelösungen unterschiedlich interpretiert: So finden wir bei einigen Werkzeugen Regelverstösse im Softwarepaket umfassenden und in sich abgeschlossenen lokalen Design als Ursache von Konflikten (ICE-Konflikte). In anderen Tools wird von Softwarekonflikten gesprochen, wenn eine bestimmte Datei aus einem Softwarepaket mit einer gleichbenannten Datei anderer Version aus einem anderen Softwarepaket in einer gemeinsamen Umgebung zur Installation kommt. Solche Tools erkennen diese Situation und schlagen beim Repaketierungsprozess oder bei nachfolgenden Konfliktmanagementoperationen ein Ersetzen der niedriger versionierten Datei im entsprechenden Softwarepaket vor. Und nicht zuletzt wird allgemein von Softwarekonflikten gesprochen, wenn im Softwarepaket COM-Komponenten verwendet werden, die sich über die Funktion DllRegisterServer() oder über anders implementierte Registrierungs- mechanismen (bspl. Registry-Tabelle aus der MSI-Datei) bei der Installation registrieren. Werden solche COM-Komponenten schliesslich gemeinsam von verschiedenen Programmen verwendet, können durch das Überschreiben von bestehenden Registrierungswerten mit neuen Referenzen, dem Überschreiben bestehender COM-Komponenten mit nicht wirklich durchgängig kompatiblen Versionen dieser gemeinsamen Dateien oder dem Löschen von auf die DLL oder OCX bezogenen Registrierungsverweisen während der Deinstallation oder dem Upgrade eines Softwareproduktes Probleme entstehen, die ebenfalls unter dem Begriff „Softwarekonflikte" zusammengefasst werden und allgemein als DLL-Hölle bekannt sind (DLL-Hell). Natürlich gibt es noch viele weitere Ausprägungen von Softwarekonflikten in Softwarepaketen. Ihnen gemeinsam ist die Tatsache, dass sie sich erst im späteren Verlauf, in der gemeinsamen Verwendung verschiedener Softwareprodukte oder im Zusammenspiel von Softwareelementen mit dem Betriebssystem, sowie während oder nach Veränderung des Installationsstatus (Installation, Deinstallation, etc.) zu einem Problem manifestieren.
Die Folgen sind ganz unterschiedlicher Natur. Diese können im Einzelfall bedeuten, dass sich eine Software gar nicht erst erfolgreich installieren lässt, in anderen Fällen führen sie hingegen zum kompletten Versagen bestimmter Software oder auch nur zum Versagen bestimmter Funktionen, sowie zu fehlerhaften Auswirkungen nach Ausführung bestimmter Funktionen aus diesen Softwareprodukten. Dieses Verhalten lässt sich allgemein auf der gesamten Infrastruktur oder möglicherweise auch nur unter bestimmten Konstellationen im Unternehmen beobachten.
Wie wir nun gesehen haben, sind die Ausprägungen vielfältig und vielmals ist die nachträgliche Analyse, wie auch deren Konfliktidentifikation ein immens schwieriger und zeitaufwendiger Prozess, welche zudem das Verständnis komplexer Zusammenhänge erfordert! Dies ist auch der Grund, warum nicht selten die Ursache von Problemen im Verborgenen bleibt und man dem Thema „Softwarekonflikte in Softwarepaketen" gelegentlich zu wenig Beachtung schenkt: Weil man vergangene Störfälle aufgrund von Softwarekonflikten nicht eindeutig als deren Folge erkannt hat. Umso wichtiger erscheint ein professionelles Software-Konfliktmanagement, welches ein proaktives Lösen von Problemsituationen anstrebt und die Auswirkungen von Softwarekonflikten bereits im Keim ersticken lässt!
Konfliktmanagement mit dem Conflict Explorer
Wenn wir Softwarekonflikte aus Softwarepaketen kategorisieren, unterscheiden wir folgende Hauptgruppen:
- Konflikte aufgrund von Regelverstössen beim Design eines Softwarepakets unter Berücksichtigung lokaler, meist auf das Softwarepaket beschränkter Regeln (z.B. ICE-Konflikte, Internal Consistency Evaluators)
- Konflikte aufgrund globaler Designfehler und –konstellationen im Verbund mehrerer Softwarepakete oder im Zusammenspiel zwischen Software und Betriebssystem.
Der Conflict Explorer 2009 ermittelt und löst Konflikte, die zu der zweiten beschriebenen Gruppe gehören. Nun kann man diese zweite Gruppe weiter unterteilen (folgende Aufzählung ist hierbei nicht abschliessend):
- Konflikte aufgrund gemeinsam verwendeter Ressourcen (Softwarepaket zu Softwarepaket oder Softwarepaket zu Betriebssystem), welche bei der Deinstallation oder beim Upgrade eines Softwarepakets entfernt werden und dadurch zu problematischen Situationen führen.
- Konflikte aufgrund gemeinsam verwendeten Ressourcen mit unterschiedlichem Inhalt (content), wie beispielsweise INI-Dateieinträge, die in verschiedenen Softwarepaketen unter dem gleichen Dateinamen identische Schlüssel (Key) verwenden, aber unterschiedliche Werte aufweisen. Auch in mehreren Softwarepaketen verwendete gleiche Registrierungsschlüssel mit unterschiedlichen Werten gehören zu dieser Gruppe.
-
Konflikte aufgrund eines fehlerhaften Komponentendesigns, unter Berücksichtigung globaler Regeln (unterschiedlicher KeyPath bei „identischen" Komponenten mit gleicher ComponentId, unterschiedliche Ressourcen „gleicher" Komponenten, etc.)
Der Conflict Explorer 2009 unterstützt das Konfliktmanagement von Konflikten aus all diesen drei Bereichen in der jetzt verfügbaren oder in zukünftigen Versionen. Genaue Angaben zu den zurzeit unterstützten Konfliktarten finden Sie unter im Conflict Explorer Handbuch, im Kapitel 5.4 Konfliktarten.
Überschaubare Investitionen und transparente Anpassungen, die die Qualität Ihrer Software- pakete signifikant verbessern, zahlen sich aus!
Bei einer Gesamtbetrachtung der Kosten innerhalb eines Applikations-Lebenszyklus lässt sich feststellen, dass qualitativ hochwertige und robuste Softwarepakete mit einem deutlich geringeren Gesamtaufwand zu Buche schlagen, als solche, die nicht diesen Standards entsprechen. Die Investitionen, die für den Mehrwert zu tätigen sind, stehen insbesondere mit dem Einsatz des Conflict Explorers 2009 in keinem Verhältnis zu den Kosten, die ohne den Einsatz eines Software-Konfliktmanagements entstehen können. Denn ein Softwarebereitstellungsprozess ohne effektives Software-Konfliktmanagement kann letztlich schnell zum unkalkulierbaren Risiko heranwachsen.
In Gesprächen mit Vertretern aus der Softwarepaketierung trifft man hin und wieder auf die Aussage, man hätte bisher keine Probleme mit Softwarekonflikten gehabt. Tatsächlich bestätigt sich aber in den allermeisten dieser Fälle, dass man in der Softwarepaketierung selbst nur nichts direkt von den Auswirkungen von Softwarekonflikten wahrgenommen hat.
In Szenarien, wo Computerbenutzer in einem Unternehmen ein Fehlverhalten in einer Software feststellen, versuchen diese zunächst oft selbst Hand anzulegen, um dem Fehler auf den Grund zu gehen. Dies ist ja an sich noch nichts verwerfliches. Bis die von Problemen geplagten Benutzer schliesslich zum Hörer greifen, um dem Unternehmenssupport anzurufen vergehen mitunter wertvolle Minuten bis Stunden. Bereits in dieser Phase entstehen einem Unternehmen nicht unerhebliche Kosten. Wenn auch der Unternehmenssupport nach einer Weile keine Lösung gefunden hat, wird in vielen Fällen eine Neuinstallation der betroffenen Software veranlasst oder beauftragt und nicht selten wird sogar das komplette System neu installiert. Über den Imageverlust der Informatikdienstleistungen gegenüber dem Kunden wollen wir hier mal gar nicht sprechen. Viel schlimmer wiegen die Kosten aller Aufwände aller Beteiligten (Benutzer, Unternehmenssupport, für Softwareverteilung und Installationen zuständige Bereiche, etc.), die in der Summe eines Unternehmens (Konfliktsituationen entstehen in der Regel mehrfach) dramatische Grössen annehmen können. Das Besondere an der ganzen Geschichte ist, dass häufig das Team der Softwarepaketierung selbst gar nichts von diesen Auswirkungen mitbekommt, geschweige denn deren Ursachen kennt. Und für die Einzelfälle, wo man die Ursache dennoch klar lokalisieren konnte, wird schliesslich eine Nachkorrektur des betroffenen Softwarepakets unerlässlich; entstehen also wiederum neue Kosten.
Mit dem Einsatz des Conflict Explorers 2009 wird nicht zuletzt die Tragweite bewusst, wenn man auf die integrierte, vornehmlich proaktiv ausgeführte, automatische Korrektur der Softwarekonflikte verzichten würde. In einem mittleren Unternehmen mit dreistelligem Softwarepool finden wir denn auch öfters Softwarepakete mit mehreren 1000 Einzelkonflikten zu anderen Softwarepaketen oder zum Betriebssystem. Erfahrungen, die wir in einem grösseren Unternehmen machen konnten, zeigten, dass dort unbehandelt etwa 25-30% aller Softwarepakete Softwarekonflikte aufwiesen. Dieser Wert ist natürlich abhängig von der Anzahl an importierten und verwendeten Softwarepaketen und steigt mit der Grösse des zum Einsatz kommenden Softwarepools an.
Wie sinnvoll ist der Einsatz des Conflict Explorer 2009, wenn bereits andere Windows Installer-Entwicklertools mit Konfliktfeatures eingesetzt werden?
Die meisten Windows Installer-Entwicklertools verwenden interne und lokale Konsistenzprüfungen (Internal Consistency Evaluators, ICE), um eine Paketvalidierung durchzuführen. Eine ICE-Validierung prüft die Datenbank des Pakets auf Einträge, die einzeln gültig sind, aber möglicherweise im Kontext der gesamten lokalen Datenbank ein falsches Verhalten verursachen könnten.
Der Conflict Explorer 2009 erweitert die Prüfungsalgorithmen von lokaler Ebene auf die Unternehmensebene oder auf andere globale Sichten und ermöglicht die Darstellung von potentiellen Konflikten im heterogenen Desktopumfeld. Zudem ermöglicht der Conflict Explorer 2009 eine automatisierte Konfliktlösung, die in Form einer robusten Transformdatei zum Windows Installer Paket hinzugefügt wird. Die Beschaffenheit dieser Anpassungen richtet sich nach Best-Practice Regeln und ist transparent und problemlos ohne weiteren Anpassungsbedarf für alle Arten von Windows Installer Paketen anwendbar. Ausserdem unterscheidet er sich im Vergleich mit ähnlich gelagerten Tools in vielen Merkmalen, die sich zum Ziel gesetzt haben, den Software-Paketierer mit seinen Bedürfnissen im Zentrum zu sehen und die erfolgreiche Anwendung nicht zu Lasten der Softwarebereitstellungszeit umzusetzen. Der Conflict Explorer 2009 kann unabhängig verwendet werden. Er lässt sich aber ebenso elegant in bestehende Umgebungen in den Softwarebereitstellungsprozess integrieren. Zudem erweitert er allfällig bestehende Software-Konfliktmanagementlösungen mit professionellen Funktionen, die so bisher nirgendwo zu finden sind.
Weitere Features finden Sie unter Features and Highlights
|
