Skip to main content

Erste Schritte mit der Anwendungskompatibilität in einer Windows-Bereitstellung

In diesem Artikel werden die ersten Schritte des Evaluierungsprozesses zu den Auswirkungen der Anwendungskompatibilität im Bereitstellungsprojekt erklärt. Sie werden erfahren, wie Inventarlisten erstellt, wie Anwendungen priorisiert und wie die Anwendungen identifiziert werden, die in einem bestimmten rollenbasierten Bereitstellungsabbild enthalten sein sollen.

Inhalte des Artikels:


Erste Schritte mit der Anwendungskompatibilität in einer Windows-Bereitstellung

Wenn Sie bereits an einem Projekt zur Bereitstellung eines Betriebssystems gearbeitet haben, haben Sie die Anwendungskompatibilität möglicherweise als Ursache für die größten Herausforderungen der Bereitstellung in Erinnerung. Die Anwendungskompatibilität kann den größten Aufwand erfordern, die meiste Zeit in Anspruch nehmen und eines der größten Hindernisse sein. Wenn Sie zum ersten Mal an einem Projekt zur Bereitstellung eines Betriebssystems arbeiten, haben Sie vielleicht alle möglichen Horrorgeschichten über die Anwendungskompatibilität gehört. Möglicherweise haben Sie aber überhaupt nichts vernommen und sind vom Umfang der Aufgaben überrascht. In welcher Situation Sie sich auch immer befinden mögen, durch eine gründliche Planung können Sie den Projektverlauf wesentlich besser vorhersehen und verwalten.

Dabei dürfen Sie nicht vergessen, dass es sich bei der Anwendungskompatibilität in erster Linie um einen Risikomanagementvorgang handelt. Je höher der Prozentsatz von potenziellen Anwendungen mit Fehlern (statistisch gesehen), desto mehr Aufmerksamkeit sollten Sie proaktiven Tests schenken. So können Sie sicherstellen, dass es sich bei diesen Anwendungen nicht um kritische Anwendungen handelt. Wenn dieser Prozentsatz sinkt, reduziert sich auch die Anzahl von Anwendungen, für die sich umfassende Tests lohnen. Wenn Sie nun von Windows XP mit Benutzern migrieren, die hauptsächlich lokale Administratoren sind, sollten Sie erwarten, dass bei einem gewissen Prozentsatz von Anwendungen potenziell Fehler auftreten. Planen Sie daher entsprechend, um mehr in die Verwaltung des Risikos zu investieren. Wenn Sie bereits die Arbeit für die Migration zu Windows 7 abgeschlossen haben, sollten Sie erwarten, dass bei sehr wenigen Anwendungen Fehler auftreten. Planen Sie in diesem Fall geringere Investitionen, da das Risiko niedriger ist. (Wie immer gilt: Vertrauen ist gut, Kontrolle ist besser.)

Am Anfang des Anwendungsrisikomanagements steht ein eingehendes Verständnis der Ausmaße der Risiken. Dies setzt wiederum voraus, dass Sie die vorhandenen Anwendungen kennen. Als Erstes müssen Sie das Portfolio verwalteter Anwendungen erstellen oder aktualisieren. Falls Sie kein Portfolio besitzen, sind Sie sicherlich nicht der einzige. Dies ist der perfekte Zeitpunkt, eines zu erstellen. Idealerweise führen Sie die Liste auch nach Abschluss des Bereitstellungsprojekts weiter, um Ihre Flexibilität zu verbessern. Die Liste enthält alles, wofür Sie Verantwortung übernehmen, um die Funktionsfähigkeit Ihrer Umgebung während des Übergangs sicherzustellen. Sie stellen gewissermaßen Versicherungspolicen für diese Anwendungen aus. Folglich müssen Sie auch das Ausmaß des von Ihnen versicherten Risikos verstehen.

Dieses Dokument erklärt die Schritte, mit denen Sie sich auf Anwendungskompatibilitätstests und Evaluierungen während eines Windows 8-Bereitstellungsprojekts vorbereiten. In vielen Fällen sind die beschriebenen Prinzipien jedoch allgemeingültig und können auf Migrationen beliebiger Plattformen angewendet werden. Nach der Lektüre dieses Dokuments sollten Sie eine klare Vorstellung davon haben, wo Sie mit der Evaluierung der Auswirkungen der Anwendungskompatibilität auf Ihr Bereitstellungsprojekt beginnen. Darüber hinaus werden spezifische Fähigkeiten und Techniken vermittelt, die Sie für den Einstieg und effektives Arbeiten benötigen.

Zurück zum Anfang


Herausforderungen der Anwendungskompatibilität

Im Zentrum der Herausforderungen der Anwendungskompatibilität steht das Gesetz der großen Zahlen. Organisationen können zehntausende oder sogar hunderttausende von Desktops besitzen. An jedem Endpunkt können dutzende von Apps installiert sein, und Sie wissen vielleicht noch nicht einmal, was installiert ist (insbesondere, wenn Benutzer lokale Administratoren sind). Bis Sie jeden einzelnen dieser Desktops untersucht haben, können hunderte, tausende oder sogar zehntausende einzigartiger Apps auf allen Desktops zusammen installiert sein. Und das sind nur die Windows-Apps. Wenn Sie die Webanwendungen hinzunehmen, müssen Sie jede einmalige Website in der ganzen Welt in Ihre Planungen einbeziehen. Denn es ist durchaus möglich, dass ein paar wenige Web-Apps von verschiedenen Orten innerhalb und außerhalb der Organisation Teil des einen oder anderen produktiven Workflows im Unternehmen geworden sind. Die Zahlen steigen ins Unermessliche. Wenn Sie nicht aufpassen, enden Sie angesichts der großen Anzahl von sich ändernden Komponenten vor Angst wie gelähmt.

Daher müssen Sie eine pragmatische Herangehensweise wählen. Und genau aus diesem Grund habe ich Ihr Angebot oben als Versicherungspolice bezeichnet. Während sich die Umgebung und die Welt ändern, versichern Sie, dass einige der verwendeten Anwendungen auch in Zukunft ausgeführt werden können. Allerdings ist es Ihnen gegenüber nicht sonderlich fair, dass sich die Versicherung auf jede beliebige Anwendung erstrecken soll, die jeder beliebige Benutzer installieren kann, oder auf jede beliebige Website, die ein Benutzer findet und aufruft, unabhängig von der Qualität oder Dauerhaftigkeit. Hier ist das Definieren von Kategorien erforderlich. Welche der von Ihnen versicherten Software soll unabhängig von den Änderungen sofort funktionieren? Die Gewährleistung dieser Software wird für Sie teurer, da Sie eine strukturierte Überprüfung ausführen müssen. Für die meisten kritischen Anwendungen ist dies jedoch erforderlich.

Als Nächstes stellt sich die Frage, welche der versicherten Software funktioniert und ob Sie auftretende Fehler ggf. beheben? Es entstehen weiterhin Kosten, wenn Fehler auftreten. Sie zahlen aber nur für die fehlerhaften Apps und nicht für alles (selbst wenn die Mehrheit wahrscheinlich funktioniert). Ebenso gibt es Apps, für die Sie keine Gewährleistung übernehmen: Benutzer dürfen sie verwenden, erhalten beim Auftreten von Fehlern aber keine Unterstützung von Ihnen. Schließlich gibt es eine Kategorie von Apps, deren Verwendung Sie für nicht wünschenswert halten. Um die Verwendung dieser Apps zu verhindern, ergreifen Sie möglicherweise einige Maßnahmen.

Übersicht über die Schritte

Dieses Framework verändert Ihre Denkweise, sobald Sie es anwenden. Sie sind vielleicht bereit, die Funktionsweise einer bestimmten Version einer Anwendung zu gewährleisten. Aber soll sich diese Gewährleistung mit der höchsten Vereinbarung zum Servicelevel auf jede einzelne Version beziehen, die ein beliebiger Benutzer zufällig ausführt? In den meisten Fällen lautet die Antwort „nein“. Stattdessen möchten Sie einen Prozess ausführen, der festlegt, in welche Anwendungen Sie mehr investieren sollten, diese Investition für das Risikomanagement ausführen und anschließend zu der neueren Plattform migrieren.

Sie hoffen, dass Sie das Risiko einer Geschäftsunterbrechung aufgrund eines Anwendungsfehlers verwalten. Viele der ausgeführten Anwendungen sind mit Windows 8 kompatibel (insbesondere, wenn Sie bereits Windows 7 ausführen). Bei einigen können jedoch Probleme unterschiedlicher Schweregrade auftreten, von einer App, die „irgendwie komisch aussieht“, bis zu einer Menüoption, die nach einem Anwendungsabsturz nicht mehr funktioniert.

Wo sollen Sie da anfangen? Unsere erfolgreichsten Kunden gehen folgendermaßen vor:

  1. Ermitteln Sie die Anwendungen, die Sie in Ihre Planungen einbeziehen möchten: Beginnen Sie mit den Anwendungen, die Sie bereits zentral verwalten. Fügen Sie beliebige Anwendungen hinzu, die Sie noch nicht zentral verwalten.
  2. Rationalisieren Sie die Anwendungen, um sicherzustellen, dass das Portfolio verwalteter Anwendungen nicht so groß geworden ist, dass es nicht mehr verwaltet werden kann. Kategorisieren und priorisieren Sie, um Ihr Anwendungskompatibilitätsprojekt voranzutreiben.
  3. Testen Sie die Anwendungen, um zu überprüfen, ob die benötigte Geschäftsfunktion weiterhin wie gewünscht auf der neuen Plattform funktioniert.
  4. Beheben Sie alle ermittelten Probleme. Dieser Vorgang umfasst möglicherweise die Verwendung integrierter Kompatibilitätsfeatures der Plattform, das Ändern einer Richtlinie zum Zulassen des fehlerhaften Verhaltens, das Aktualisieren oder Ersetzen einer App und manchmal sogar das Entfernen der App.

Dieser Artikel konzentriert sich auf die ersten beiden Schritte: das Ermitteln und Rationalisieren. Am Ende des Prozesses können Sie Ihr Budget aufstellen und die Entwicklung des Projekts planen. Daher ist es sehr wichtig, die Schritte korrekt auszuführen.

Zurück zum Anfang


Anwendungsermittlung

In der Vergangenheit wurde die „Anwendungsermittlung“ als „Anwendungsinventar“ bezeichnet: Der Wechsel zum Begriff „Anwendungsermittlung“ wurde mit einer bestimmten Absicht vollzogen. Nach unseren Erfahrungen hatten Kunden bei dem Begriff „Inventar“ die Vorstellung, dass absolut alles, was in der Umgebung ausgeführt wurde, gefunden werden musste, und dass die vollständige Liste in einen Rationalisierungsprozess integriert werden musste. Tatsächlich wäre dies für installierte Windows-Anwendungen gar nicht vollkommen abwegig. (Das größte uns persönlich bekannte Inventar installierter Windows-Anwendungen umfasst 130.000 Anwendungen. Das ist natürlich zu groß. Für eine Rationalisierung ist es jedoch nicht zu groß.) Eine Plattformmigration zu einer neuen Version von Windows enthält normalerweise jedoch auch immer eine neue Version von Internet Explorer. Wie lang ist die Liste einzigartiger URLs, zu denen alle Mitglieder einer Organisation navigieren? Unendlich lang! Viele Kunden aktualisieren während der Migration auch ihre Version von Microsoft Office (Chris Jackson bespricht die Mathematik einer vollständigen Bestandsaufnahme und Rationalisierung von Office-Dokumenten in seinem TechNet Magazine-Artikel „ Microsoft Office: Die Mathematik von Office Compatibility“. Sie sehen, häufig macht es keinen Sinn, wirklich alles zu finden. Gleichzeitig möchten Sie die Elemente ermitteln, die während der Migration ein echtes Geschäftsrisiko darstellen.

Der Prozess ist von zahlreichen Faktoren abhängig, darunter:

Verwaltete oder nicht verwaltete Umgebung: Ermittlungen können in verwalteten Umgebungen viel einfacher durchgeführt werden. Das liegt daran, dass Sie generell steuern können, welche Anwendungen auf verwalteten Computern installiert werden. Daher kennen Sie sie bereits. Sie beginnen mit einer Liste unterstützter und genehmigter Anwendungen. Dazu führen Sie aus, auf wie vielen Computern die Anwendungen installiert sind (und vielleicht sogar, wie häufig sie verwendet werden). Da nicht verwaltete Umgebungen eine größere Herausforderung darstellen, wird das Projekt häufig gestartet, ohne die verwendeten Anwendungen zu kennen. Insbesondere sind oft diejenigen Anwendungen unbekannt, die von den Benutzern alleine installiert (und manchmal sogar erstellt) wurden. In vielen Organisationen findet sich eine Mischung: Sie besitzen einige zentral verwaltete und unterstützte Anwendungen und eine Anzahl von Anwendungen, die als Ausnahme behandelt werden (und viele, die sie noch nicht einmal kennen).

Zentralisierte oder autonome IT: Organisationen mit einer zentralisierten IT-Infrastruktur sind bei der Anwendungsermittlung im Vorteil, da sie alle Abteilungen innerhalb der Organisation kennen und zu ihnen Kontakt haben. Dezentral organisierte IT-Infrastrukturen können flexibler sein. Die Ermittlung erfordert jedoch eine größere Koordination, wenn Informationen und Strategien über Organisations-, Kostenstellen- und geografische Grenzen hinweg konsolidiert werden.

Verfügbare Inventarisierungstools für das Asset Management: Organisationen mit einer verwalteten Umgebung besitzen häufig bereits ein Software Asset Management-Tool, wie Microsoft Asset Inventory Service (ein Tool, das über Microsoft Desktop Optimization Pack für Software Assurance verfügbar ist) oder Microsoft System Center Configuration Manager. Dieses Tool enthält möglicherweise bereits die Liste der Software, die aktiv verwaltet wird. Einige Kunden entscheiden sich dafür, eine separate Liste mit verwalteter und unterstützter Software zu führen, wie Microsoft SharePoint oder Microsoft Excel. Diejenigen, die zurzeit die ausgeführte Software nicht kennen, oder die befürchten, dass die Inventur verwalteter Software unvollständig ist, suchen häufig nach zusätzlichen Tools zum Erstellen oder Ergänzen der Liste. Unkomplizierter ist es, einfach die Geschäftseinheiten zu befragen. In einigen Organisationen kann eine zusätzliche Vorbereitung der Befragung die Beteiligung der Geschäftseinheiten an dieser Maßnahme erheblich verbessern. Das Anwendungskompatibilitäts-Toolkit von Microsoft stellt aus diesem Grund ein Inventursammlungstool für installierte Windows-Anwendungen (sowie Web-Add-Ins) bereit.

Umfang: Bei der Anwendungsermittlung muss die Anzahl von Computern in einer Organisation sicherlich berücksichtigt werden, allerdings nicht ausschließlich. Die Variabilität der verwendeten Software wird auch durch die Anzahl von einzigartigen Rollen bestimmt. Je nach Anzahl kann sich der erforderliche Arbeitsaufwand zum Sicherstellen, dass alle Geschäftsfunktionen nach der Migration weiterhin funktionieren, erhöhen. Wenn höchst autonome Benutzer vorhanden sind, die ihre eigene Software installieren können, gibt es möglicherweise sogar beträchtliche Variationen innerhalb einer Rolle. In diesem Fall kann die Ermittlung eine Herausforderung sein, welche der Variationen für die Organisation relevant sind und welche nur unnötige Komplexität hinzufügen.

Manuelle Ermittlung

In einer idealen Welt sollten die Geschäftseinheiten auf Sie zukommen und nicht umgekehrt. Schließlich möchten die Geschäftseinheiten, dass Sie Anwendungen in einer sich schnell verändernden Technologieumgebung gegen Fehler absichern Sollten sie Ihnen nicht zumindest mitteilen, was versichert werden soll? Die Chancen sind jedoch (noch) sehr gering, dass dies passiert. Sie müssen also die Initiative ergreifen.

In sehr kleinen Organisationen empfiehlt es sich, mit den einzelnen Benutzern zu sprechen, sich vielleicht die Startmenüs anzusehen, um zu erfahren, was sie installiert haben, und darüber zu sprechen, welche Apps kritisch sind und welche einfach vorhanden sind.

In den meisten Organisationen ist es jedoch vollkommen unpraktisch, mit jedem einzelnen Benutzer zu sprechen. Es bietet sich in derartigen Situationen an, aus jeder Abteilung oder Rolle einen Repräsentanten zu wählen, der über die erforderliche Software zur Bewältigung der anfallenden Aufgaben berichtet. Diese Rolle kann viele Namen haben, zum Beispiel „Abteilungskoordinator (Technologie)“. Es muss allerdings unbedingt jemand sein, der nicht nur über geschäftliche, sondern auch über die zugrundeliegenden IT-Kenntnisse verfügt. Mit dieser Person (oder diesen Personen) können Sie die Liste der erforderlichen Anwendungen zusammenstellen, die zur Ausführung der Abläufe im Zusammenhang mit dem bestimmten Unternehmensaspekt erforderlich sind.

Nach dem Fertigstellen der Liste können Sie formale Prozesse zum Hinzufügen, Überprüfen und Löschen von Anwendungen zu bzw. aus dieser Masterliste einrichten. Diese Prozesse sollten so reibungslos wie möglich ablaufen, um die Teilnahme der Geschäftsseite des Unternehmens an Ihren Software Asset Management-Bemühungen zu fördern.

Automatisieren des Ermittlungsprozesses

Da im Verlauf der Anwendungsermittlung Softwarewerte mit Geschäftswerten abgeglichen werden, kann dieser Prozess normalerweise nicht vollständig automatisch ausgeführt werden. In vielen Umgebungen kennen geschäftliche Anwender und Abteilungskoordinatoren jedoch unter Umständen nicht alle Faktoren, auf denen der Erfolg des Unternehmens beruht. Wenn Sie den ersten Schritt zur Umsetzung von Software Asset Management-Praktiken in Ihrer Organisation unternehmen, ist das Verwalten des Risikos, dass etwas übersehen werden könnte, ein Zeichen für eine gesunde Partnerschaft zwischen Unternehmen und Technologie.

In einer verwalteten Umgebung können Sie möglicherweise eine aktualisierte Liste installierter Anwendungen für die gesamte Organisation und für jede Abteilung erhalten. Diese Liste kann als brauchbarer Ausgangspunkt für die Gespräche dienen.

Wenn Ihr Anwendungsportfolio nicht zentral verwaltet wird, sollten Sie sich aber überlegen, welche Tools Sie bei der Zusammenstellung der Liste und dem Gespräch unterstützen könnten. Viele Kunden wählen das Anwendungskompatibilitäts-Toolkit, das diese Funktion als kostenlosen Download von Microsoft anbietet. Das Application Compatibility Manager-Tool (eines der anderen nützlichen Tools zur Problembehandlung und Wartung von Anwendungen) kann das Anwendungsinventar von einem Teil oder der Gesamtheit des Unternehmens erfassen.

Zurück zum Anfang


Rationalisieren von Anwendungen

Während Sie zusammen mit dem Unternehmen ermitteln, welche Anwendungen als verwaltete oder unterstützte Anwendungen klassifiziert werden sollen (verwaltete Anwendungen werden vor der Änderung besonderen Regressionstests unterzogen, unterstützte Anwendungen jedoch nicht, ihnen steht bei Fehlern in der neuen Umgebung aber Support zur Verfügung), müssen Sie klare Entscheidungen fällen, welche Anwendungen zu welcher Liste gehören.

Die erste Überprüfung der ermittelten Anwendungen ist ziemlich einfach:

Anwendungsversion: Es gibt in Ihrer Organisation mehrere Versionen einer Anwendung, darunter auch veraltete und nicht unterstützte Versionen. Während einige Organisationen unter gewissen Umständen mehrere Versionen unterstützen, verwalten die meisten jedoch nur eine Version aktiv. Dabei handelt es sich in der Regel um eine neuere oder sogar die aktuelle Version. Durch die Auswahl einer einzigen Standardversion können Sie auch Ihre Supportkosten reduzieren.

Anwendungsredundanz: In Ihrem Unternehmen gibt es mehrere Anwendungen, die die gleichen Aufgaben erfüllen. Die meisten Organisationen entscheiden sich möglicherweise unter bestimmten Umständen, mehrere Anwendungen zu unterstützen, aber nur eine aktiv zu verwalten. Durch die Auswahl einer einzigen Standardanwendung können Sie die Kosten pro Lizenz durch höhere Mengenrabatte reduzieren. Darüber hinaus können Sie die Supportkosten senken, indem nur ein Supportvertrag beibehalten werden muss.

Anwendungsnotwendigkeit: Es gibt Anwendungen, die keine Bedeutung für die alltäglichen Abläufe in der Organisation haben. Häufig handelt es sich dabei um das Resultat vergangener Änderungen an der Organisationsstrategie. Diese Anwendungen wurden im Anschluss nicht gelöscht. Die meisten Organisationen entfernen die Anwendungen einfach und entscheiden sich nur gelegentlich unter außergewöhnlichen Umständen für die Unterstützung (aber nicht für die aktive Verwaltung).

Keine Anwendung: Wenn Sie Ihren Rationalisierungsprozess auf Basis einer automatisch generierten Liste starten, werden sich auf dieser Liste viele „Anwendungen“ befinden, die in Wirklichkeit überhaupt keine Anwendungen sind. Zumindest sind es keine für Sie relevanten Anwendungen. Viele Softwaretreiberpakete hinterlassen Installationskomponenten an Orten, an denen die meisten Inventarisierungstools suchen, wie in der Softwareliste. Vor Ihren Gesprächen sollten Sie diese aus Ihrer Liste löschen. Vielleicht entdecken Sie auch Anwendungen, die für Sie niemals relevant sein werden und nicht in das Gespräch zur Rationalisierung mit den Geschäftsleuten eingebracht werden müssen. Dazu können Spiele oder Online-Glücksspielanwendungen gehören, die häufig von Benutzern installiert werden.

Nachdem Sie die offensichtlichen Kandidaten entfernt haben, können Sie nun mit der gekürzten Liste produktive Gespräche mit dem Unternehmen führen. In diesen Gesprächen sollten Sie überprüfen, ob die Liste vollständig ist, und sicherstellen, dass Sie ein angemessenes Maß an Risikomanagement auf diese Anwendungen anwenden, indem Sie die Wichtigkeit jeder Anwendung verstehen. Im Folgenden werden einige häufig verwendete Prioritätsstufen (gelegentlich finden sich auch unterschiedliche Bezeichnungen) aufgelistet, die berücksichtigt werden sollten:

Geschäftskritisch: Eine Anwendung, deren Fehler den Ablauf einer Abteilung, Rolle oder sogar der gesamten Organisation unterbricht. Die Bedingungen für diese Priorität werden nur selten erfüllt, und nur wenige Anwendungen eines Kunden fallen in diese Kategorie. Geschäftskritische Anwendungen verfügen häufig über Vereinbarungen zum Servicelevel (SLAs), in denen festgelegt ist, dass Supportmitarbeiter in diesem Fall innerhalb von 15 Minuten oder schneller reagieren müssen. Geschäftskritische Anwendungen gehören immer in die Kategorie „verwaltet“ und erfordern vor einer Migration strukturierte Tests.

Hohe Priorität: Eine Anwendung, die für eine Abteilung oder die gesamte Organisation wesentlich ist. Ein Fehler in einer Anwendung mit hoher Priorität kann die Arbeit einer Abteilung oder die Ausführung einer einzelnen Geschäftsfunktion einer Organisation unterbrechen. Bei einem Fehler in einer Anwendung mit hoher Priorität kann das Geschäft der Organisation weiter betrieben werden, eine oder mehrere Abteilungen könnten jedoch schwer beeinträchtigt sein. Eine typische SLA für eine Anwendung mit hoher Priorität wird in Stunden gemessen. Anwendungen mit hoher Priorität gehören normalerweise immer in die Kategorie „verwaltet“ und erfordern vor einer Migration strukturierte Tests.

Wichtig: Eine wichtige Anwendung wird häufig verwendet, führt jedoch bei einem Fehler nicht zur Unterbrechung der Arbeit. SLAs für wichtige Anwendungen werden in der Regel in Tagen gemessen. Wichtige Anwendungen fallen normalerweise in die Kategorie „unterstützt“ und beruhen – abgesehen von Ausnahmefällen – eher auf organischen und Pilottests als auf formalen Tests.

Optional: Eine genehmigte Anwendung, die nur begrenzt verwendet wird und nicht in direktem Zusammenhang mit einer zentralen Geschäftsfunktion steht. Anwendungen aus dieser Kategorie werden in der Regel nicht durch ein SLA abgedeckt, und der Support würde anhand des Prinzips „bestmöglich“ erfolgen. Optionale Anwendungen fallen höchstens in die Kategorie „unterstützt“. Zur Fehleridentifizierung werden organische und Pilottests anstatt formaler Tests herangezogen.

Die Zuweisung von Prioritätsstufen zu Anwendungen ist häufig ein subjektiver Prozess und unterliegt daher regelmäßigen Überprüfungen. Wir empfehlen formale Software Asset Management-Methoden, nach denen ein Team oder Komitee das Anwendungsportfolio überwacht, auch zwischen Betriebssystembereitstellungen.

Die Erweiterung Ihrer Software Asset Management-Kenntnisse hat noch weitere Vorteile. Beispielsweise stellen viele Kunden fest, dass sie ihre Lizenzierungskosten besser optimieren und das Risiko von Vertragsstrafen für das Ausführen nicht lizenzierter Software reduzieren können. Als positiv wird auch befunden, dass vorhandene Investitionen optimiert und effektiver genutzt werden können.

Identifizieren geschäftskritischer Anwendungen

Einige geschäftskritische Anwendungen sind einfach zu identifizieren und andere nicht. Wenn die Organisation ihr Geschäft über eine Internetpräsenz betreibt, sind Textverarbeitungs-, Bildbearbeitungs- und Seitenkodierungsanwendungen möglicherweise geschäftskritisch. Die Kategorisierung als geschäftskritisch ist darüber hinaus von der Rolle abhängig. In einem Callcenter ist eine Anwendung, die die Serverstabilität überwacht, möglicherweise geschäftskritisch, während andere Abteilungen sie als überhaupt nicht wichtig betrachten würden.

Wenn die Organisation über einen Notfallwiederherstellungsplan (Disaster Recovery Plan, DRP) oder einen Geschäftskontinuitätsplan (Business Continuance Plan, BCP) verfügt, sollten die geschäftskritischen Anwendungen bereits in diesen Plänen identifiziert worden sein.

Zu den Kriterien für die Identifizierung geschäftskritischer Anwendungen zählen u. a.:

  • Die Anwendung dient einer primären Funktion der Organisation, wie eine Textverarbeitungs- oder Layoutanwendung in einem Verlagsunternehmen.
  • Ein Ausfall der Anwendung hat erhebliche finanzielle Auswirkungen auf das Unternehmen.
  • Wenn die Anwendung außerhalb der Geschäftszeiten ausfällt, wird innerhalb von Minuten ein verantwortlicher Mitarbeiter informiert.

Identifizieren von Anwendungen mit hoher Priorität

Anwendungen mit hoher Priorität lassen sich in der eigenen Abteilung vielleicht leicht identifizieren. In anderen Abteilungen ist dies jedoch schwierig. Manchmal können Sie eine Anwendung mit hoher Priorität anhand des Prozentsatzes der Computer ermitteln, auf denen sie installiert ist; dies kann jedoch auch irreführend sein. Beispielsweise ist eine Anwendung, die intern für die Überwachung des Toners in den Laserdruckern des Unternehmens entwickelt wurde, möglicherweise auf allen Computern installiert, wird jedoch nur von sehr wenigen Personen verwendet (oder als relevant betrachtet). Wenn die Organisation über einen Notfallwiederherstellungsplan oder einen Geschäftskontinuitätsplan verfügt, sind die Anwendungen mit hoher Priorität möglicherweise bereits in diesen Plänen identifiziert.

Zu den Kriterien für die Identifizierung von Anwendungen mit hoher Priorität zählen u. a.:

  • Die Anwendung wird während der überwiegenden Zeit der Geschäftszeiten verwendet.
  • Die Anwendung wird von einem großen Prozentsatz der Benutzer der Organisation verwendet.
  • Ohne die Anwendung wäre es für die Organisation oder Abteilung schwierig, das Geschäft normal zu betreiben.
  • Ohne die Anwendung wären alltägliche Abläufe beeinträchtigt, und es sind möglicherweise messbare finanzielle Auswirkungen erkennbar.

Zurück zum Anfang


Zuordnen von Anwendungen zu Rollen

Das Benutzerrollenkonzept kann dazu dienen, einen optimalen Bereitstellungsplan für das Betriebssystem festzulegen. Benutzer einer bestimmten Rolle verwenden häufig dieselbe Software. Sie werden positive Auswirkungen feststellen, wenn Sie nach Abschluss der Anwendungskompatibilitätsarbeiten nur für diese Rolle mit der Bereitstellung beginnen und nicht warten, bis die Arbeiten für die gesamte Software der Organisation abgeschlossen sind: Nicht nur die Arbeitsmoral des Teams wird gestärkt (das auf eine Erfolgsmetrik stolz sein kann), sondern es wird auch ein wichtiger Lerneffekt für nachfolgende Rollen zu verzeichnen sein, die ansonsten von der Bereitstellung nicht profitiert hätten.

Zu den häufig definierten Rollen/Teams gehören:

  • Personalwesen
  • Information-Worker
  • IT-Supportdesk
  • Marketing
  • Entwicklung
  • Executive

Es gibt natürlich Anwendungen, die für alle Rollen Standard sind. Beispiele hierfür sind E-Mail- und Antivirenanwendungen.

Bereitstellungsrollen können auch priorisiert werden, um den Aufwand für das Testen der Anwendungskompatibilität zu reduzieren. Rollenbasierte Konfigurationen für kritische Abläufe sollten am intensivsten getestet werden, und Rollen mit niedrigerer Priorität können weniger intensiv getestet werden. Dadurch wird das Konzept einer intelligenten Investition in das Risikomanagement unterstützt, das auf dem tatsächlichen Risiko beruht und nicht auf einem teuren und letztendlich nicht erreichbaren Streben nach Perfektion.

Zurück zum Anfang


Nächste Schritte

Der in diesem Dokument beschriebene Prozess sollte einen Anwendungskatalog für die Organisation hervorbringen, der nach erforderlichen Tests, spezifischen Benutzerrollen und danach, welche Anwendungen mit Windows 8 bereitgestellt werden, priorisiert ist. Dieser Katalog stellt Ihnen die Informationen für die nächsten Schritte im Prozess bereit. Auf der Basis der Informationen im Anwendungskatalog sollten als Nächstes die folgenden Schritte durchgeführt werden:

  • Zusammenstellen des Teams: Wenn Sie den Arbeitsaufwand für die Organisation ermittelt haben, müssen Sie ein Team zusammenstellen, das nicht nur die erforderlichen technischen, sondern auch die geschäftlichen Entscheidungen trifft. Die Größe und der Aufgabenbereich des Teams sind von der Größe und dem Umfang der Bereitstellung abhängig. Möglicherweise sind Sie der Projektleiter, der Testleiter und allgemeine Informationsquelle zugleich. Größere Organisationen benötigen ein formaleres Team mit gut definierten Rollen. Anleitungen für das Zusammenstellen von Teams finden Sie im Microsoft Deployment Toolkit.
  • Erstellen eines Testplans: Die verwalteten Anwendungen, die Sie formal testen, erfordern einen strukturierten Plan zur Durchführung der Tests. Wie hoch ist der Arbeitsaufwand für das technische Team, um Kompatibilitätsprobleme zu ermitteln? Wie werden Benutzerakzeptanztests verwaltet? Diese Faktoren beeinflussen die Schnelligkeit und die Kosten erheblich.
  • Erstellen einer Testumgebung: Verwaltete Anwendungen benötigen eine Umgebung, in der Anwendungskompatibilitätstests ausgeführt werden können. Häufig ist dies das gleiche Labor, in dem auch die Bereitstellungsabbilder getestet werden. Ziehen Sie die Verwendung von Virtualisierungssoftware wie Microsoft Hyper-V als Alternative zu dedizierten Computern in Erwägung, um den größten Teil der Anwendungstests durchzuführen. Dadurch werden Hardwarekosten gesenkt und Zurücksetzungen der Umgebung für die nächste Anwendung vereinfacht.
  • Beheben: Identifizieren Sie die Anwendungen mit Kompatibilitätsproblemen, und finden Sie die entsprechenden Lösungen. Testen Sie die Lösungen, um sicherzustellen, dass die Probleme wirklich behoben wurden. In der Dokumentation zum Anwendungskompatibilitäts-Toolkit finden Sie Informationen zur Lösung von Kompatibilitätsproblemen.
  • Pilottests: Identifizieren Sie die Mitglieder der Gruppe für den Pilottest der Bereitstellung. Sie sollten Personen aus allen größeren Rollen in der Organisation auswählen, sodass Sie nützliches Feedback zu Anwendungen erhalten, insbesondere zu den Anwendungen, die unterstützt (aber nicht verwaltet) werden und daher vor der Pilotphase keinen formalen Tests unterzogen wurden. Machen Sie sich Gedanken zur Rolle des höheren Managements in der Pilotgruppe. Führungskräfte, die technisch erfahren sind, möchten möglicherweise einen dedizierten Computer für die Pilottests verwenden.
  • Abnahme von Anwendungen: Notieren Sie bei der Überprüfung der verwalteten Anwendungen durch Benutzerakzeptanztests jede Abnahme. Sobald alle von einer Rolle verwendeten Anwendungen zertifiziert sind, können Sie mit den Pilotbereitstellungen beginnen und diese langsam ausweiten, bis die gesamte Bereitstellung abgeschlossen ist.
  • Bereitstellung: Nach der Zertifizierung aller verwalteten Anwendungen wird der Prozess mechanisch. Setzen Sie die Bereitstellung fort, bis Sie alle Computer in der Organisation erreicht haben.

Es können auch weitere Aufgaben zu erledigen sein, abhängig von den Anforderungen und der Kultur der Organisation. Die von Ihnen getroffenen Entscheidungen zur Priorität von Anwendungen und Tests können zudem von der Struktur der Organisation beeinflusst werden. Möglicherweise sollten Sie einen Schritt hinzufügen, in dem die Liste der mit dem Betriebssystem bereitgestellten Anwendungen erneut evaluiert wird, um festzustellen, ob es neue Anwendungen gibt, die hinzugefügt werden sollten.

Diese weiteren Schritte werden in anderen Dokumentationen detaillierter erläutert, wie zum Microsoft Deployment Toolkit.

Zurück zum Anfang

Wichtige Aufgaben

Der Autor

Foto von Chris JacksonChris Jackson, auch als „ The App Compat Guy“ bekannt, ist Principal Consultant und Technical Lead des Windows Application Experience SWAT-Teams. Jackson ist ein weithin anerkannter Experte auf dem Gebiet der Windows-Anwendungskompatibilität. Die von ihm verfassten technischen Dokumente sowie seine Schulungs- und Dienstangebote werden bei Microsoft und auch in anderen Unternehmen genutzt und basieren auf langjähriger praktischer Erfahrung mit Unternehmenskunden und unabhängigen Softwareanbietern.

Er ist Autor und Mitautor einer Vielzahl von technischen Dokumenten und Artikeln zur Anwendungskompatibilität und schreibt Beiträge für das TechNet Magazine. Jackson ist auch Redner auf wichtigen Branchenkonferenzen auf der ganzen Welt, einschließlich TechEd, IT Forum und Microsoft Management Summit.

Verwandte Ressourcen

Bleiben Sie auf dem Laufenden