From corporate strategy to the virtual desktop — TOGAF in practice
Many AVD, Intune and multi-vendor projects fail to arrive where they should, despite clean engineering. What is often missed is a change of perspective: away from the Microsoft CAF lens, towards the TOGAF enterprise lens. Using three practical examples — reaching into everyday life in the age of AI — this article shows exactly where the difference lies.
Why do we need at all an architecture method?
Most IT projects in German companies begin with a sentence like this: „We want to migrate to AVD.“ Oder: „We are introducing Intune.“ That sounds like a clear plan — but it is in fact step three of five. Steps one and two were simply skipped.
That is exactly what happens in IT projects every day. The engineering is clean. The result is not.
TOGAF is the answer to that problem. It is not an IT framework but a thinking tool for decision-makers. It forces you to think from the business outwards — and only then to arrive at the technology. The method behind it is called ADM (Architecture Development Method) and runs through several phases before a product such as AVD or Intune is chosen at all.
What for?
Which business problem are we solving? Which people work how? Which processes have to run — from wherever?
With what?
Which applications do we need? Which data has to be available where? Who may access what?
How?
Only now does the technology arrive. AVD or Citrix? Intune or co-management? Hybrid join or cloud-only?
Two lenses, one company — TOGAF and CAF compared
Many Microsoft partners and IT consultants know the Cloud Adoption Framework (CAF). It is a very good tool. But it is a different lens from TOGAF. The two are often confused. Anyone who knows both lenses, and when to put on which, makes better decisions.
TOGAF
TOGAF looks down on the whole company. It asks: what are our business goals? Which capabilities do we need for them? How does IT connect to the business? It is vendor-neutral — AVD, Citrix, oneClick and VMware are all valid answers, depending on context.
- Direction of view: Top-down, from business to technology
- Scope: The whole company, all domains
- Vendor tie: Neutral — Microsoft, Citrix, AWS all possible
- Language: Business-oriented, suitable for CIO and CFO
- Central question: „Why are we doing this?“
Microsoft CAF
The CAF looks outwards from Azure. It asks: how do I build a clean landing zone? How do I implement governance, security and operations in Azure? It is close to the product and the vendor — meant for companies that have already decided to go with Microsoft.
- Direction of view: Bottom-up, from platform to implementation
- Scope: Microsoft ecosystem (Azure, Microsoft 365)
- Vendor tie: Microsoft-specific
- Language: Technical and operational, suitable for IT architects
- Central question: „How do we implement this cleanly?“
The two lenses do not exclude each other — they complement each other. TOGAF answers why, the CAF answers how. Know only the CAF and you build cleanly — but perhaps the wrong thing. Know only TOGAF and you plan wisely — but implement nothing. The combination is the real strength.
AVD through the TOGAF lens
A company with 800 employees wants to replace its old Citrix farms. The head of IT says: „We want to go to AVD.“ The TOGAF lens asks: „Hold on — let us first check whether AVD is the right answer at all. And if so, what it has to look like.“
What do we actually want it for?
In phase A the vision is formulated. Not technically, but commercially. For example: „By 2027 we have to enable location-independent working for 800 employees, meet the compliance requirements of ISO 27001 and cut IT costs per workplace by 20 per cent.“ Every later technical decision follows from that sentence — or is discarded because it does not fit the vision.
Who works how — and from where?
Now the company is broken down into user personas . Not into departments, but by working behaviour. For example: 200 field staff with laptops and home use, 300 case handlers with a fixed desk setup, 150 developers with high CPU demands, 100 guest users with temporary access, 50 executives with mobile devices. Each persona places different demands on the desktop.
Which applications and data do these people need?
Phase C defines what has to run on the desktop. Legacy Windows applications? Browser apps? CAD software? Industry-specific systems? Where does the data sit? May it leave the EU? Do field staff need offline access? Only once these questions are answered does it become clear whether AVD fits at all — or whether Windows 365 makes more sense for certain personas, Citrix stays for others, and developers perhaps need a hybrid approach.
Which technology carries all of this?
Only now — in phase D — does AVD enter. And it does so not as an end in itself but as the logical consequence of the three preceding phases. Pooled host pools for the 300 case handlers (cost-efficient, similar usage pattern). Personal desktops for the 150 developers (high CPU demands, their own tools). Windows 365 for the 100 guest users (simple provisioning, fixed price). FSLogix for profiles. Entra ID as the identity foundation. Azure Files or ANF for storage. Every decision traces back to a line from phase A, B or C.
For the actual platform choice and the feature comparison between AVD, Windows 365, Citrix DaaS and other solutions: DaaS Maps and DaaS feature analysis.
What does the CAF do differently here?
At this point the Microsoft CAF would start directly in the ready phase: build the landing zone, Azure subscription design, management groups, policies, network topology. That is technically impeccable — but it presupposes that the decision „we are taking AVD“ has already been made. TOGAF first questions exactly that decision and then derives it.
In a well-run project both methods run one after the other: first TOGAF phases A to D to justify the target architecture. Then the CAF to build the Microsoft implementation cleanly. TOGAF phases E to H (opportunities, migration, implementation governance, architecture change) take on the overarching programme control — with the CAF delivering the technical implementation beneath it.
Intune + AVD through the TOGAF lens
The second example shows why architectural thinking proves its worth especially with several interrelated products . For most companies Intune and AVD are no longer two separate projects — they are two sides of the same workplace architecture. The CAF treats them separately. TOGAF treats them as one whole.
We want one consistent digital workplace.
The vision is now broader than in example 1. It is no longer only about the virtual desktop but about the entire workplace experience. A design engineer should be just as productive on the company notebook in the office as on the AVD desktop at home in the evening — with the same apps, the same data, the same security rules. That is a business goal, not a product goal.
How do people move between devices?
The user journey analysis now becomes two-dimensional. A sales representative starts the morning on a notebook with Outlook, moves into an AVD session for the CRM application during the day and ends the evening on a tablet with Teams. Those three endpoints have to add up to one experience . From the employee’s point of view it does not matter where the session runs. From the architecture’s point of view it matters a great deal.
One identity, shared data, consistent apps.
Now it becomes clear why Intune and AVD belong together: they share identity (Entra ID), data sources (OneDrive, SharePoint, Azure Files) and security rules (Conditional Access, Defender, DLP). Treat Intune and AVD as separate projects and you build two parallel identity, data and security structures. Treat them together and you build one coherent stack in which a Conditional Access rule is defined once and applies everywhere — whether the user is on a Surface or a Cloud PC.
Intune + AVD + Entra ID as one architecture.
The shared stack consists of several layers: Entra ID as the single identity foundation. Intune manages both physical endpoints (notebooks, tablets, smartphones) and the AVD Session Hosts themselves — possible since Intune management for AVD. Conditional Access entscheidet an einer zentralen Stelle, wer wann worauf zugreifen darf. Defender for Endpoint delivers security across all endpoints. Microsoft Purview ensures consistent data classification and DLP. This is not two products added together — it is one architecture carried through.
Which of these building blocks cover which controls in ISO 27001, TISAX, NIST CSF and BSI IT-Grundschutz is shown by the Compliance Mapping im Detail.
Why does the CAF separate what belongs together?
The Microsoft CAF treats Intune and AVD in unterschiedlichen Szenarien: Intune falls under the modern work and endpoint management scenario, AVD has a CAF scenario of its own. Each is excellently documented in itself — but the CAF makes it easy to treat them as zwei getrennte Projekte zu denken.
In phases B and C, TOGAF forces you to think the user journey across all endpoints . That leads automatically to an integrated architecture in which Intune and AVD are not two products but two modules of one shared workplace stack. The difference shows up in operations at the latest: two parallel projects produce two parallel support structures, two governance models and two security concepts. An integrated architecture produces one operating model.
Multi-vendor + AI — AVD, Citrix, Omnissa and Copilot
The third example is where TOGAF plays its greatest advantage over the CAF. A group with a grown VDI estate (Citrix in place, AVD in newer regions, Omnissa Horizon in R&D) receives a new instruction from the board: „We are introducing Copilot.“ The CAF plus AI CAF has only one answer to that: the Microsoft stack. TOGAF has a better one — because it is a more differentiated one.
How does the workplace become AI-capable without destroying platform diversity?
Die wichtigste Erkenntnis in Phase A: Platform diversity is not a bug but a feature. Citrix is there for historical, technical and regulatory reasons. Omnissa (formerly VMware Horizon) is often fixed in R&D areas because of on-premises GPU workstations and stricter compliance requirements. AVD was chosen deliberately in newer regions. „Migrate everyone to AVD, then put Copilot on top“ is the naive CAF answer — TOGAF questions it. The business goal is not „Microsoft everywhere“ but „AI-capable everywhere“.
Wer braucht welche KI auf welcher Plattform?
Now personas, AI need and platform are laid into a matrix — and it becomes clear: a case handler on Citrix needs Copilot just as much as a case handler on AVD. A data scientist needs GPU workstations, whether Azure ML or local. A design engineer in R&D on Omnissa may, for TISAX reasons, keine Prototypendaten in Cloud-KI geben.
Die typische Persona-Landkarte: Knowledge Worker on AVD or Citrix (Copilot for text, mail, slides). Data Scientist on AVD with a GPU pool (Azure ML, Azure AI Foundry). Konstrukteur on Omnissa Horizon (AI-assisted CAD, but on-premises). Sachbearbeiter auf Citrix (Copilot via Browser/Outlook). Frontline Worker auf Mobile (Copilot-Chat, Teams-KI). R&D-Forschung on isolated Omnissa systems (own models, no external APIs). Six personas, three platforms, at least four AI approaches — all at once and side by side.
Which data may go into which AI?
With AI, phase C becomes far more important than in classic VDI projects. Three data layers have to be distinguished: Graph data (the Microsoft 365 context for Copilot — TISAX-compliant, GDPR-compliant, internal to the tenant). Own training and inference data (Azure AI Foundry, private endpoints, own models). Highly sensitive data (prototypes, patient data, research — these may not go into cloud AI). On top comes the responsible-AI layer: governance policies, audit trails under EU AI Act articles 12 and 13, classification and blocking rules via Microsoft Purview.
The reward of this phase: an AI gateway concept, in which it is defined per persona and per data class which AI may be addressed when and under which conditions. This layer spans platforms — it applies to Copilot on AVD just as to Copilot on Citrix or to local models on Omnissa.
Three VDI platforms, four AI approaches, one governance layer.
Der differenzierte Zielstack: AVD bekommt GPU-Pools (NV-Serie) for data scientists and compute-heavy workloads. Citrix DaaS bleibt for legacy apps and areas where HDX protocol optimisation or existing investments justify it; Copilot runs there via the browser-based Microsoft 365 integration. Omnissa Horizon bleibt for R&D and regulated areas with local GPU workstations; AI runs on-premises here with its own models. Copilot for M365 is licensed per persona, not across the board. Azure AI Foundry / Azure OpenAI with private endpoints for the company’s own models. Lokale NPU-Laptops (Copilot+ PCs) as a third device class for field staff.
Above it lies the gemeinsame Governance-Layer: Entra ID as the identity anchor across all three VDI platforms, Conditional Access as unified access control, Microsoft Purview for data classification and DLP, Defender for Endpoint for security, and an AI gateway as the policy enforcement point. No platform is force-migrated. No use case is suppressed. But everything stands under one governance.
Why the CAF structurally cannot represent this scenario
The Microsoft CAF and the AI CAF are beide Microsoft-only. They recognise neither Citrix nor Omnissa as equal platforms. Follow that framework and you inevitably end up at „AVD everywhere plus Copilot everywhere“ — ignoring existing investments, regulatory reasons and the fact that „everyone onto one platform“ is frequently the wrong target picture.
The AI CAF does add data strategy, responsible AI and AI skilling as new dimensions — but it still assumes that the underlying VDI layer is homogeneously Microsoft. Exactly here a Orchestrierungs-Gap: the CAF answers „how do I implement the Microsoft cloud?“, the AI CAF answers „how do I implement Microsoft AI?“. But neither framework answers „how do I orchestrate AI across mehrere platform worlds?“. TOGAF is precisely the right lens there — because it is vendor-neutral and has structurally nothing against heterogeneity.
The practical consequence: a project run only with the CAF or AI CAF produces, in a multi-vendor reality, either unrealistic migration plans or blind spots — often both. TOGAF-led projects instead deliver an architecture that works with reality statt gegen sie.
Warum bringt uns dieser Perspektivwechsel weiter?
The TOGAF lens is not an end in itself. It delivers concrete advantages that show measurably in projects — from the first decision to daily operations.
Decision confidence for the C-level
A CIO or CFO does not want to see an AVD feature list. They want to know why AVD is the right thing, what it costs, what it saves and how it fits the corporate strategy. TOGAF supplies exactly that rationale — in the language of management.
Avoiding tech-first mistakes
It happens regularly that companies introduce AVD and only realise years later that Windows 365 would have suited a substantial share of users better. TOGAF phases B and C catch such mistakes early — through persona analysis, before the technology is chosen.
Einheitliche Architektur statt Produktsilos
Especially with interrelated products such as Intune and AVD, CAF silo thinking produces separate projects. TOGAF forces the joined-up view — and with it an architecture that later causes considerably less complexity and duplication in operations.
Nachvollziehbare Entscheidungen in Audits
In regulated industries (automotive, finance, healthcare) architectural decisions have to be documented and justifiable — TISAX, ISO 27001, BSI IT-Grundschutz. TOGAF supplies that traceability automatically, because every technical decision is traced back to a business requirement. The specific control mappings onto Microsoft technologies are collected in the Compliance Mapping.
Vendor independence as a negotiating advantage
Think vendor-neutrally in phases A and B and you can let several providers compete in phase D — Microsoft, Citrix, VMware, oneClick. That strengthens your negotiating position and keeps the architecture open to change should conditions shift. On sovereign alternatives see data sovereignty.
Roadmap statt Einzelprojekte
TOGAF phases E and F deliver a multi-year roadmap into which individual projects such as AVD or Intune rollouts can be placed. Companies no longer see only the next project but the target picture for three to five years.
This article is part of Workplace Decoded.
I share analyses, frameworks and comparisons on the digital workplace — vendor-neutral and evidence-based. If you want to think further about this, LinkedIn is the quickest route to a conversation.
Auf LinkedIn vernetzen → Alle Architektur-ArtikelOder per E-Mail: kontakt@sofianesalmi.com