Vor Kurzem war ich in einem Kundenprojekt und man diskutierte über einen Wechsel von DSM zu SCCM. Obwohl die technische Ebene starke Bedenken äußerte wurde auf Wunsch der (neuen) IT-Leitung in einer Arbeitsgruppe über eine Woche über ein Für und Wider eines Umstiegs auf SCCM gesprochen.
Der Kunde setzt DSM bereits seit der Version 5.0 ein, automatisiert deutlich mehr als 15.000 Clients mit weit über 1.000 Projekten.
Obwohl man recht schnell eine Menge technischer Argument für DSM gefunden hatte gab es unzählige Diskussionsrunden und „Bestrebungen“ eine Migration auf SCCM zu verargumentieren.
Eins dieser Argumente war „Zukunftssicherheit“.
Zitat „… wechseln wir auf SCCM oder gehen wir irgendwann mit DSM unter…“
Ich gebe zu, dass ich es so noch nie betrachtet hatte und kurzzeitig konnte ich den Gedankengang nachvollziehen. Wenn man aber etwas länger drüber nachdenkt stellt sich doch die folgende Frage:
Was ist Zukunftssicherheit?
Ich denke, dass „Zeitdauer“ sicher ein wichtiger Bestandteil dieser Betrachtung ist. Hier stellt sich meines Erachtens die Frage in welchen Zeiträumen wir generell in der IT denken. Während meines Studiums sagte ein Professor wir sollten keine Projekte planen deren Implementierungszeit länger benötigt als der Wunsch des Kunden Bestand hat. Sowohl DSM als auch SCCM werden für den Rollout von Betriebssystemen und Anwendungen verwendet. Meiner Erfahrung nach haben die meisten Kunden jedes zweite Betriebssystem ausgerollt. D.h. wer z.B. früher NT4 eingesetzt hat, hat Windows 2000 übersprungen und ist auf Windows XP gewechselt. Danach hat man Vista ausgesetzt und auf Windows 7 migriert.
Die Langlebigkeit solcher IT Projekte hat sicherlich vielerlei Gründe. Zum einen benötigt der reine Rollout eines neuen Betriebssystems einfach seine Zeit. Meist wird mit dem Rollout eines neuen Betriebssystems auch die zum Einsatz kommende Software auf eine neuere Version aktualisiert oder zumindest muss die bestehende auf Lauffähigkeit in der neuen Umgebung überprüft werden. Diese Testphase kann je nach Umfeld mehrere Monate in Anspruch nehmen. Und letztlich müssen die Mitarbeiter ggf. auf das neue Betriebssystem und die zum einsatzkommenden Anwendungen geschult und vorbereitet werden.
Da also bei einem Wechsel wie eben beschrieben nahezu alle Tätigkeiten wie Vorbereiten, Testen, Ausrollen, Mitarbeiter Schulen durchgeführt werden müssen ist ein Wechsel des Softwareverteilungswerkzeugs zu diesem Zeitpunkt sicher einfacher und sinnvoller als im Laufenden Betrieb einer intakten Umgebung.
Diesen Punkt betrachtend kann man also zusammenfassend festhalten, dass eine Evaluierung eines neuen Softwareverteilungslösung frühzeitig durchgeführt werden sollte und nicht unmittelbar vor einem geplanten Rollout, denn dann ist es eigentlich bereits zu spät oder zumindest deutlich kostspieliger. Viele in der Vorbereitungsphase erarbeiteten Lösungen müssen erneut implementiert, getestet und abgenommen werden.
Laut Microsoft soll Windows 10 das letzte Windows Betriebssystem sein. Ob dies eine entscheidende Änderung der bisherigen Vorgehensweise mit sich bringen wird ist noch unklar. Ob durch den Updatezwang mehr oder weniger immer auf dem aktuellen Current Branch For Business sein zu müssen die Rollouts tatsächlich reduziert werden oder sogar noch erhöht wird die Zukunft zeigen.
Das Argument „Zukunftssicherheit“ wurde wie folgt begründet:
„SCCM wird es sicher immer geben, DSM hingegen könnte irgendwann vom Markt verschwinden.“ Dieser Argumentation entgegen zutreten ist sehr schwierig. Schließlich hat die NetSupport GmbH das Produkt NetInstall bereits 1999 zwischenzeitlich an InstallShield veräußert, allerdings wurde dies später rückabgewickelt. 2007 wurde die gesamte Firma an FrontRange verkauft und FrontRange selbst wurde 2015/16 an einen anderen Investor weiterverkauft und dort mit der Firma Lumension zu HeatSoftware fusioniert. Tatsächlich ist das Argument „wie lange gibt es noch DSM“ somit durchaus valide.
Andererseits.
Angenommen DSM würde morgen vom Markt verschwinden. Was würde dies letztlich bedeuten? Kurzfristig doch eher wenig. Schließlich ist es nicht so, dass das Produkt aus diesem Grund plötzlich nicht mehr funktionieren würde.
Fehlerbehebungen
OK, es würde keine Fehlerbehebungen mehr geben. Das ist natürlich nicht optimal aber andererseits – es gibt kaum einen Fehler für den sich nicht ein Workaround finden lässt. Auch bisher wurden Fehler nicht über Nacht behoben sondern in einem der nächsten Patch-Releases. Es gibt Workarounds, die sich sogar über Jahre halten.
Neues OS / neue Technologien
Das Thema neues OS haben wir oben bereits beleuchtet. Neue Technologien werden in großen Unternehmen nicht über Nacht eingeführt. Steht ein großer Umbruch an kommt es wie bereits beschrieben zu Evaluierungen, Planungen und Rollouts und diese können dann genutzt werden um auf ein neues „Trägermedium“ zu wechseln.
Lizenzen
Auch die fehlende Möglichkeit Lizenzen nachzukaufen wäre nicht kritisch. Zumindest die momentane Implementierung ist so, dass das Produkt auch im Fall einer Unterlizensierung problemlos weiterfunktioniert. Lediglich die Administrationskonsole „nervt“ mit entsprechenden Hinweisen – die Clients funktionieren aber uneingeschränkt weiter.
Zusammengefasst gilt:
Das Thema Zukunftssicherheit ist ein valides Argument. Die Konsequenzen sind aber gering.
Jemand, der heute darüber nachdenkt zu wechseln kann das in ein paar Jahren ja genauso machen. Vermutlich heißt es nun aber… „je später wir umsteigen umso schwerer wird es. Also besser jetzt“. Diese Meinung teile ich nicht. Sicherlich gibt es einige Kenngrößen die darauf deuten, dass ein späterer Umstieg umfangreicher ist. Hierzu dürfte allein schon die mit hoher Wahrscheinlichkeit weiterhin zunehmende Anzahl von Endgeräten sprechen.
Wie wir aber in den folgenden Teilen der Blog-Serie feststellen werden ist der Funktionalitätsunterschied zwischen SCCM und DSM sehr groß. Ein frühzeitiger Umstieg bedeutet entweder einen freiwilligen Verzicht auf bereits vorhandene Funktionen und Komfort oder (eigentlich eher „und“) einen deutlich erhöhten Aufwand und damit Personalbedarf.
Etwas flapsig formuliert: Ist es besser (im Zweifelsfall) nur noch wenige Jahre eine starke Funktionalität oder lange Schrott zu haben.
Ausweg
Man kann sicherlich bei der Paketierung versuchen Lösungen zu finden, die später leichter zu migrieren sind. Damit kann man die vorhandene Zeit gut nutzen um einem späteren Rollout den Weg zu ebnen. Man sollte aber DSM nicht kastrieren und die vorhanden Möglichkeiten künstlich weglassen nur um besser migrieren zu können.
Fazit
Sicherlich kann man oben zwischen den Zeilen rauslesen, dass mir das Argument Zukunftssicherheit widerstrebt. Dennoch muss ich hier festhalten, dass dies einen weiteren Sieg für SCCM darstellt. Das Ganze wird hierbei noch durch die „selbsterfüllende Prophezeiung“ verstärkt – je mehr Kunden auf Grund dieses Arguments auf SCCM wechseln, desto schneller wird ein Produkt wie DSM tatsächlich vom Markt verschwinden. Es hängt letztlich sehr stark von den Kunden selbst ab.
Zwischenstand SCCM : DSM (2:0)
