Von der Unternehmensstrategie zum virtuellen Desktop — TOGAF in der Praxis
Viele AVD-, Intune- und Multi-Vendor-Projekte kommen trotz sauberer Technik nicht dort an, wo sie sollen. Häufig übersehen wird dabei ein Perspektivwechsel: weg von der Microsoft-CAF-Brille, hin zur TOGAF-Unternehmens-Brille. Dieser Artikel zeigt anhand dreier Praxisbeispiele — bis hinein in den KI-Zeitalter-Alltag — wo genau der Unterschied liegt.
Warum braucht es überhaupt eine Architekturmethode?
Die meisten IT-Projekte in deutschen Unternehmen beginnen mit einem Satz wie diesem: „Wir wollen auf AVD migrieren.“ Oder: „Wir führen jetzt Intune ein.“ Das klingt nach einem klaren Plan — ist aber in Wahrheit Schritt 3 von 5. Die Schritte 1 und 2 wurden einfach übersprungen.
Genau das passiert in IT-Projekten jeden Tag. Die Technik ist sauber. Das Ergebnis trotzdem nicht.
TOGAF ist die Antwort auf dieses Problem. Es ist kein IT-Framework, sondern ein Denkwerkzeug für Entscheider. Es zwingt dazu, vom Business aus zu denken — und erst dann zur Technik zu kommen. Die Methode dahinter heißt ADM (Architecture Development Method) und durchläuft mehrere Phasen, bevor überhaupt ein Produkt wie AVD oder Intune ausgewählt wird.
Wofür?
Welches Geschäftsproblem lösen wir? Welche Menschen arbeiten wie? Welche Prozesse müssen laufen — egal von wo?
Womit?
Welche Anwendungen brauchen wir? Welche Daten müssen wo verfügbar sein? Wer darf auf was zugreifen?
Wie?
Erst jetzt kommt die Technik. AVD oder Citrix? Intune oder Co-Management? Hybrid Join oder Cloud-Only?
Zwei Brillen, ein Unternehmen — TOGAF und CAF im Vergleich
Viele Microsoft-Partner und IT-Berater kennen das Cloud Adoption Framework (CAF). Es ist ein sehr gutes Werkzeug. Aber es ist eine andere Brille als TOGAF. Das wird oft verwechselt. Wer beide Brillen kennt und weiß, wann er welche aufsetzt, trifft bessere Entscheidungen.
TOGAF
TOGAF schaut von oben aufs ganze Unternehmen. Es fragt: Was sind unsere Geschäftsziele? Welche Fähigkeiten brauchen wir dafür? Wie hängt IT mit Business zusammen? Es ist herstellerneutral — AVD, Citrix, oneClick, VMware sind alles gültige Antworten, je nach Kontext.
- Blickrichtung: Top-Down, vom Geschäft zur Technik
- Geltungsbereich: Gesamtes Unternehmen, alle Domänen
- Herstellerbezug: Neutral — Microsoft, Citrix, AWS möglich
- Sprache: Business-orientiert, CIO/CFO-tauglich
- Zentrale Frage: „Warum tun wir das?“
Microsoft CAF
Das CAF schaut aus Azure heraus. Es fragt: Wie baue ich eine saubere Landing Zone? Wie setze ich Governance, Security und Betrieb in Azure um? Es ist produkt- und herstellernah — gedacht für Unternehmen, die bereits entschieden haben, mit Microsoft zu gehen.
- Blickrichtung: Bottom-Up, von der Plattform zur Umsetzung
- Geltungsbereich: Microsoft-Ökosystem (Azure, M365)
- Herstellerbezug: Microsoft-spezifisch
- Sprache: Technisch-operativ, IT-Architekt-tauglich
- Zentrale Frage: „Wie setzen wir das sauber um?“
Die beiden Brillen schließen sich nicht aus — sie ergänzen sich. TOGAF beantwortet warum, CAF beantwortet wie. Wer nur CAF kennt, baut sauber — aber vielleicht das Falsche. Wer nur TOGAF kennt, plant klug — aber setzt nichts um. Die Kombination ist die eigentliche Stärke.
AVD durch die TOGAF-Brille
Ein Unternehmen mit 800 Mitarbeitenden möchte seine alten Citrix-Farmen ablösen. Der IT-Leiter sagt: „Wir wollen auf AVD.“ Die TOGAF-Brille fragt: „Moment — lass uns erst prüfen, ob AVD überhaupt die richtige Antwort ist. Und wenn ja, wie es aussehen muss.“
Wofür wollen wir das eigentlich?
In Phase A wird die Vision formuliert. Nicht technisch, sondern geschäftlich. Beispiel: „Wir müssen bis 2027 ortsunabhängiges Arbeiten für 800 Mitarbeiter ermöglichen, die Compliance-Anforderungen der ISO 27001 erfüllen und die IT-Kosten pro Arbeitsplatz um 20 % senken.“ Aus diesem Satz ergeben sich später alle technischen Entscheidungen — oder werden verworfen, weil sie nicht zur Vision passen.
Wer arbeitet wie — und von wo?
Jetzt wird das Unternehmen in User-Personas zerlegt. Nicht in Abteilungen, sondern nach Arbeitsverhalten. Beispiel: 200 Außendienstmitarbeiter mit Laptop und Heimnutzung, 300 Sachbearbeiter mit festem Desk-Setup, 150 Entwickler mit hohen CPU-Anforderungen, 100 Gastnutzer mit temporärem Zugriff, 50 Führungskräfte mit mobilen Geräten. Jede Persona stellt andere Anforderungen an den Desktop.
Welche Anwendungen und Daten brauchen diese Menschen?
Phase C definiert, was auf dem Desktop laufen muss. Legacy-Windows-Anwendungen? Browser-Apps? CAD-Software? Branchenlösungen? Wo liegen die Daten? Dürfen sie die EU verlassen? Brauchen Außendienstler Offline-Zugriff? Erst wenn diese Fragen beantwortet sind, wird klar, ob AVD überhaupt passt — oder ob für bestimmte Personas Windows 365 sinnvoller ist, für andere Citrix bleibt, und für Entwickler vielleicht ein hybrider Ansatz nötig ist.
Welche Technologie trägt das alles?
Erst jetzt — in Phase D — kommt AVD ins Spiel. Und zwar nicht als Selbstzweck, sondern als logische Folge der drei Phasen davor. Pooled Host Pools für die 300 Sachbearbeiter (kosteneffizient, ähnliches Nutzungsmuster). Personal Desktops für die 150 Entwickler (hohe CPU-Anforderungen, eigene Tools). Windows 365 für die 100 Gastnutzer (einfache Bereitstellung, fester Preis). FSLogix für Profile. Entra ID als Identitätsbasis. Azure Files oder ANF für Storage. Jede Entscheidung lässt sich auf eine Zeile aus Phase A, B oder C zurückführen.
Für die konkrete Plattformwahl und den Funktionsvergleich zwischen AVD, Windows 365, Citrix DaaS und weiteren Lösungen: DaaS Maps und DaaS Funktionsumfang.
Was macht das CAF an dieser Stelle anders?
Das Microsoft CAF würde an dieser Stelle direkt in der Ready-Phase starten: Landing Zone aufbauen, Azure Subscription Design, Management Groups, Policies, Networking-Topologie. Das ist technisch absolut sauber — aber es setzt voraus, dass die Entscheidung „wir nehmen AVD“ bereits gefallen ist. TOGAF stellt genau diese Entscheidung erst infrage und leitet sie her.
In einem gut aufgestellten Projekt laufen beide Methoden nacheinander: Erst TOGAF Phase A–D, um die Zielarchitektur zu begründen. Dann CAF, um die Microsoft-Umsetzung sauber zu bauen. TOGAF Phase E–H (Opportunities, Migration, Implementation Governance, Architecture Change) übernehmen dabei die übergeordnete Programmsteuerung — CAF liefert die technische Umsetzung darunter.
Intune + AVD durch die TOGAF-Brille
Das zweite Beispiel zeigt, warum Architekturdenken besonders bei mehreren zusammenhängenden Produkten seinen Wert entfaltet. Intune und AVD sind für die meisten Unternehmen keine zwei getrennten Projekte mehr — sie sind zwei Seiten derselben Workplace-Architektur. Das CAF betrachtet sie getrennt. TOGAF betrachtet sie als ein Ganzes.
Wir wollen einen einheitlichen digitalen Arbeitsplatz.
Die Vision ist jetzt breiter als in Beispiel 1. Es geht nicht mehr nur um den virtuellen Desktop, sondern um das gesamte Arbeitsplatz-Erlebnis. Eine Konstrukteurin soll am Firmen-Notebook im Büro genauso produktiv sein wie abends zuhause am AVD-Desktop — mit denselben Apps, denselben Daten, denselben Sicherheitsregeln. Das ist ein Business-Ziel, kein Produktziel.
Wie bewegen sich Menschen zwischen Geräten?
Die User-Journey-Analyse wird jetzt zweidimensional. Eine Vertriebsmitarbeiterin startet morgens am Notebook mit Outlook, geht tagsüber in die AVD-Session für die CRM-Anwendung und beendet den Tag abends am Tablet mit Teams. Diese drei Endpunkte müssen ein Erlebnis ergeben. Aus Sicht der Mitarbeitenden ist es egal, wo die Session läuft. Aus Sicht der Architektur ist es alles andere als egal.
Eine Identität, geteilte Daten, konsistente Apps.
Jetzt wird klar, warum Intune und AVD zusammengehören: Sie teilen sich Identität (Entra ID), Datenquellen (OneDrive, SharePoint, Azure Files) und Sicherheitsregeln (Conditional Access, Defender, DLP). Wer Intune und AVD als separate Projekte denkt, baut zwei parallele Identitäts-, Daten- und Security-Strukturen. Wer sie zusammen denkt, baut einen kohärenten Stack, in dem eine Conditional-Access-Regel einmal definiert wird und überall greift — egal ob der User am Surface oder am Cloud-PC sitzt.
Intune + AVD + Entra ID als eine Architektur.
Der gemeinsame Stack besteht aus mehreren Ebenen: Entra ID als einheitliche Identitätsbasis. Intune verwaltet sowohl physische Endpunkte (Notebooks, Tablets, Smartphones) als auch die AVD Session Hosts selbst — seit Intune Management for AVD ist das möglich. Conditional Access entscheidet an einer zentralen Stelle, wer wann worauf zugreifen darf. Defender for Endpoint liefert Sicherheit über alle Endpunkte. Microsoft Purview sorgt für konsistente Datenklassifizierung und DLP. Das ist keine Addition von zwei Produkten — das ist eine durchgezogene Architektur.
Welche dieser Bausteine welche Controls in ISO 27001, TISAX, NIST CSF und BSI IT-Grundschutz abdecken, zeigt das Compliance Mapping im Detail.
Warum trennt das CAF hier, was zusammengehört?
Das Microsoft CAF behandelt Intune und AVD in unterschiedlichen Szenarien: Intune fällt unter das Modern Work / Endpoint-Management-Szenario, AVD hat ein eigenes CAF-Scenario. Jedes für sich ist hervorragend dokumentiert — aber das CAF macht es dem Anwender leicht, sie als zwei getrennte Projekte zu denken.
TOGAF zwingt in Phase B und C dazu, die User Journey quer durch alle Endpunkte zu denken. Das führt automatisch zu einer integrierten Architektur, in der Intune und AVD nicht zwei Produkte sind, sondern zwei Module eines gemeinsamen Workplace-Stacks. Der Unterschied zeigt sich spätestens im Betrieb: Zwei parallele Projekte erzeugen zwei parallele Support-Strukturen, zwei Governance-Modelle und zwei Security-Konzepte. Eine integrierte Architektur erzeugt ein Betriebsmodell.
Multi-Vendor + KI — AVD, Citrix, Omnissa und Copilot
Das dritte Beispiel ist das, wo TOGAF gegenüber dem CAF seinen größten Vorteil ausspielt. Ein Konzern mit gewachsener VDI-Landschaft (Citrix im Bestand, AVD in neueren Regionen, Omnissa Horizon in R&D) bekommt einen neuen Auftrag aus dem Vorstand: „Wir führen Copilot ein.“ Das CAF + AI CAF hat darauf nur eine Antwort: Microsoft-Stack. TOGAF hat eine bessere — weil eine differenziertere.
Wie wird der Arbeitsplatz KI-fähig, ohne die Plattformvielfalt zu zerstören?
Die wichtigste Erkenntnis in Phase A: Die Plattformvielfalt ist kein Bug, sondern ein Feature. Citrix hat historische, technische und regulatorische Gründe. Omnissa (ehemals VMware Horizon) ist in R&D-Bereichen oft wegen on-premises-GPU-Workstations und strengerer Compliance-Anforderungen gesetzt. AVD wurde in neueren Regionen bewusst gewählt. „Alle auf AVD migrieren, dann Copilot drauf“ ist die naive CAF-Antwort — TOGAF stellt sie in Frage. Das Geschäftsziel ist nicht „Microsoft-überall“, sondern „KI-fähig-überall“.
Wer braucht welche KI auf welcher Plattform?
Jetzt werden Personas, KI-Bedarf und Plattform in eine Matrix gelegt — und dabei wird klar: Ein Sachbearbeiter auf Citrix braucht Copilot genauso wie ein Sachbearbeiter auf AVD. Ein Data Scientist braucht GPU-Workstations, egal ob Azure ML oder lokal. Ein Konstrukteur im R&D-Bereich auf Omnissa darf aus TISAX-Gründen keine Prototypendaten in Cloud-KI geben.
Die typische Persona-Landkarte: Knowledge Worker auf AVD oder Citrix (Copilot für Text, Mail, Slides). Data Scientist auf AVD mit GPU-Pool (Azure ML, Azure AI Foundry). Konstrukteur auf Omnissa Horizon (KI-gestütztes CAD, aber on-premises). Sachbearbeiter auf Citrix (Copilot via Browser/Outlook). Frontline Worker auf Mobile (Copilot-Chat, Teams-KI). R&D-Forschung auf isolierten Omnissa-Systemen (eigene Modelle, keine externen APIs). Sechs Personas, drei Plattformen, mindestens vier KI-Ansätze — alles gleichzeitig und nebeneinander.
Welche Daten dürfen in welche KI?
Phase C wird bei KI ungleich wichtiger als bei klassischen VDI-Projekten. Drei Datenschichten müssen differenziert werden: Graph-Daten (M365-Kontext für Copilot — TISAX-konform, DSGVO-konform, Tenant-intern). Eigene Trainings-/Inference-Daten (Azure AI Foundry, private Endpoints, eigene Modelle). Hochsensible Daten (Prototypen, Patientendaten, Forschung — diese dürfen nicht in Cloud-KI). Dazu kommt die Responsible-AI-Schicht: Governance-Policies, Audit-Trails nach EU-AI-Act Artikel 12/13, Klassifizierungs- und Blockierregeln per Microsoft Purview.
Der Lohn dieser Phase: ein AI-Gateway-Konzept, in dem pro Persona und pro Datenklasse festgelegt ist, welche KI wann unter welchen Bedingungen angesprochen werden darf. Dieser Layer ist plattformübergreifend — er gilt für Copilot auf AVD genauso wie für Copilot auf Citrix oder für lokale Modelle auf Omnissa.
Drei VDI-Plattformen, vier KI-Ansätze, ein Governance-Layer.
Der differenzierte Zielstack: AVD bekommt GPU-Pools (NV-Serie) für Data Scientists und rechenintensive Workloads. Citrix DaaS bleibt für Legacy-Apps und Bereiche, wo HDX-Protokoll-Optimierung oder bestehende Investments das begründen; Copilot läuft dort via browserbasierter M365-Integration. Omnissa Horizon bleibt für R&D und regulierte Bereiche mit lokalen GPU-Workstations; KI läuft hier on-premises mit eigenen Modellen. Copilot for M365 wird per Persona lizenziert, nicht pauschal. Azure AI Foundry / Azure OpenAI mit Private Endpoints für firmeneigene Modelle. Lokale NPU-Laptops (Copilot+ PCs) als Drittgerät für Außendienst.
Darüber liegt der gemeinsame Governance-Layer: Entra ID als Identitätsanker über alle drei VDI-Plattformen, Conditional Access als einheitliche Zugangskontrolle, Microsoft Purview für Datenklassifizierung und DLP, Defender for Endpoint für Sicherheit, ein AI-Gateway als Policy-Durchsetzungspunkt. Keine Plattform wird zwangsmigriert. Kein Use Case wird unterdrückt. Aber alles steht unter einer Governance.
Warum das CAF dieses Szenario strukturell nicht abbilden kann
Das Microsoft CAF und das AI CAF sind beide Microsoft-only. Sie kennen weder Citrix noch Omnissa als gleichwertige Plattformen. Wer diesem Framework folgt, landet zwangsläufig bei „AVD überall plus Copilot überall“ — und ignoriert damit bestehende Investitionen, regulatorische Gründe und die Tatsache, dass „alle auf eine Plattform“ häufig das falsche Zielbild ist.
Das AI CAF ergänzt zwar Data Strategy, Responsible AI und AI Skilling als neue Dimensionen — aber es geht weiterhin davon aus, dass die darunterliegende VDI-Schicht homogen Microsoft ist. Genau hier öffnet sich ein Orchestrierungs-Gap: CAF beantwortet „wie setze ich Microsoft-Cloud um?“, AI CAF beantwortet „wie setze ich Microsoft-AI um?“. Aber keine der beiden Frameworks beantwortet „wie orchestriere ich KI über mehrere Plattformwelten?“. TOGAF ist genau dort die passende Brille — weil es herstellerneutral ist und strukturell nichts gegen Heterogenität hat.
Die Konsequenz in der Praxis: Ein Projekt, das nur mit CAF/AI CAF geführt wird, erzeugt bei Multi-Vendor-Realität entweder unrealistische Migrationspläne oder blinde Flecken — oft beides. TOGAF-geführte Projekte liefern stattdessen eine Architektur, die mit der Realität arbeitet statt gegen sie.
Warum bringt uns dieser Perspektivwechsel weiter?
Die TOGAF-Brille ist kein Selbstzweck. Sie liefert konkrete Vorteile, die sich in Projekten messbar auswirken — von der ersten Entscheidung bis zum Betrieb.
Entscheidungssicherheit für C-Level
Ein CIO oder CFO will keine AVD-Feature-Liste sehen. Er will wissen, warum AVD das Richtige ist, was es kostet, was es spart und wie es sich in die Unternehmensstrategie einfügt. TOGAF liefert genau diese Begründung — in der Sprache des Managements.
Vermeidung von Tech-First-Fehlentscheidungen
Es kommt regelmäßig vor, dass Unternehmen AVD einführen und erst Jahre später merken, dass Windows 365 für einen erheblichen Teil der User passender gewesen wäre. TOGAF-Phasen B und C fangen solche Fehlentscheidungen früh ab — durch Persona-Analyse, bevor die Technologie fällt.
Einheitliche Architektur statt Produktsilos
Besonders bei zusammenhängenden Produkten wie Intune und AVD entstehen durch CAF-Silodenken getrennte Projekte. TOGAF erzwingt die übergreifende Sicht — und damit eine Architektur, die im Betrieb später deutlich weniger Komplexität und Doppelstrukturen verursacht.
Nachvollziehbare Entscheidungen in Audits
In regulierten Branchen (Automotive, Finanzen, Gesundheit) müssen Architekturentscheidungen dokumentiert und begründbar sein — TISAX, ISO 27001, BSI IT-Grundschutz. TOGAF liefert diese Nachvollziehbarkeit automatisch, weil jede technische Entscheidung auf eine Business-Anforderung zurückgeführt wird. Die konkreten Control-Mappings auf Microsoft-Technologien sammelt das Compliance Mapping.
Herstellerunabhängigkeit als Verhandlungsvorteil
Wer in Phase A und B herstellerneutral denkt, kann in Phase D mehrere Anbieter gegeneinander antreten lassen — Microsoft, Citrix, VMware, oneClick. Das stärkt die Verhandlungsposition und hält die Architektur offen für Wechsel, falls sich Rahmenbedingungen ändern. Zu souveränen Alternativen siehe Datensouveränität.
Roadmap statt Einzelprojekte
TOGAF Phase E und F liefern eine mehrjährige Roadmap, in der sich einzelne Projekte wie AVD- oder Intune-Einführungen einordnen lassen. Unternehmen sehen nicht mehr nur das nächste Projekt, sondern das Zielbild für drei bis fünf Jahre.
Dieser Artikel ist Teil von Workplace Decoded.
Ich teile Analysen, Frameworks und Vergleiche zum digitalen Arbeitsplatz — herstellerneutral und evidenzbasiert. Wer hier weiterdenken möchte, findet den Austausch am schnellsten über LinkedIn.
Auf LinkedIn vernetzen → Alle Architektur-ArtikelOder per E-Mail: kontakt@sofianesalmi.com