Virtuelle Desktops erreichen 100% Reifegrad nur durch das gesamte Ökosystem
Warum ein Virtual-Desktop-Projekt selten an der Desktop-Technologie scheitert — und fast immer daran, dass es als isoliertes Endpoint-Projekt statt als Ökosystem behandelt wird.
Die Reihenfolge ist kein Zufall
Die Frage „AVD, Windows 365 oder Citrix?“ ist meistens die falsche erste Frage. Die Technologiewahl ist wichtig — aber sie ist nur eine von sieben Schichten, die zusammen entscheiden, ob ein Digital-Workplace-Projekt wirklich seinen vollen Reifegrad erreicht oder auf halbem Weg stehen bleibt.
Das folgende Bild fasst die Grundidee zusammen: Desktops stehen im Zentrum — aber alles, was sie umgibt, entscheidet über Erfolg oder Frust im Betrieb.
Man beginnt nicht bei den Desktops. Man beginnt bei der Identität:
- Tenant-Absicherung & Identitäten — das Fundament. Hybrid, Cloud-only oder Multi-Cloud entscheidet, wie alles Weitere aufgebaut wird.
- Infrastruktur (ALZ/CAF) — Landing Zone, Netzwerkdesign, Governance, bevor der erste Desktop überhaupt existiert.
- Desktops — Technologie & Personencluster — erst jetzt kommt die Technologiefrage, und zwar differenziert nach Nutzergruppe statt pauschal für alle.
- Absicherung & Konfiguration — Intune, Compliance, Defender for Endpoint.
- Automatisierung & Bereitstellung — Infrastructure as Code für Admins, plus ein Self-Service-Portal, über das User Ressourcen selbst anfordern können, statt jeden Handgriff per Ticket zu beantragen.
- Tools & Produktivität — Microsoft 365, Teams, SharePoint, Power Platform.
- Daten & Hybrid-Integration — wenn Daten nicht in die Cloud dürfen: On-Prem-Anbindung, Azure Local, VPN/ExpressRoute.
Jede Schicht baut auf der vorherigen auf. Wer bei Schritt 3 anfängt, weil „die Technologieentscheidung dringend ist“, baut auf einem Fundament, das noch nicht steht.
Warum das kein reines IT-Projekt ist
Der Teil, der in Projektplänen am häufigsten fehlt: Ein Virtual-Desktop-Projekt zieht sich durch praktisch jedes Team im Unternehmen — Identity, Infrastruktur, Security, Endpoint, Automatisierung, Service Desk, und nicht zuletzt die Endanwender selbst, deren Akzeptanz am Ende über Erfolg oder Ablehnung entscheidet.
Die technische Referenzarchitektur
Für alle, die es konkreter brauchen: Dieselbe Struktur, aber mit den tatsächlichen Azure-Komponenten pro Schicht — von Entra ID und Conditional Access über die ALZ-Bausteine bis zu Terraform-Pipelines und Azure Local.
Was als Nächstes kommt
Für Management- oder Kundenpräsentationen ist eine Executive-Version im High-Level-Format — wie oben gezeigt — oft der richtige Einstieg. Für die technische Diskussion mit Architekten und Engineers eignet sich die Technical-Reference-Architecture-Version mit den konkreten Azure-Komponenten. Beide Perspektiven ergänzen sich: Die eine erklärt das Warum, die andere das Wie.
Stand: August 2026