Questions that come before the technology decision
Most workplace projects fail not on the platform but on questions asked too late. These are the questions that actually come up in architecture workshops — with answers that make a decision possible.
Where things are heading — and why that gets settled first
A workplace strategy does not start with the platform but with the question of how people should be working in three years.
Where does a workplace strategy start, if not with choosing a platform?
With the way people work. Until you know which user groups exist, how they work and what should change, every platform decision is a bet.
In practice: first find out how work actually happens — not according to the org chart, but in reality. Which applications run for how long, where waiting times arise, which routes users take around IT. From that come Personas, from the personas requirements, and only then a delivery model.
The reverse — platform first, requirements afterwards — regularly leads to licensing features nobody uses while the real bottlenecks remain.
How many personas make sense — and how do you know there are too many?
The number is not the criterion. What matters is whether you can justify in one sentence why each group gets exactly this delivery model — and whether that justification rests on something you actually measured.
If the justification is the same for every group, it is not a persona structure but a rollout with labels. Conversely: if two personas produce the same technical requirements, operationally they are not two.
What changes at the workplace when agents take over tasks?
The session loses its role as the carrier of the work. An agent producing a report needs no eight-hour session with a profile and cache — it needs short compute time, a few API calls and limited data access.
For the architecture that means the question of the right desktop platform remains, but a second one appears alongside it — where agent-driven tasks run and how both stay under one governance. In detail in the nautical chart.
How far into the future should a workplace strategy reach?
Further than the licence agreement, shorter than the limit of what can be forecast. A horizon of three to five years holds; anything beyond that is speculation.
More useful than a fixed target state is the question of which decisions are reversible and which are not. An identity model binds for longer than a protocol choice — the care taken should differ accordingly.
ALZ, CAF and the question of what gets built first
Frameworks do not supply an architecture. They supply an order of work — and that is the real value.
What does an Azure landing zone actually do — and what does it not?
A landing zone defines the structure workloads grow into: subscriptions, network topology, naming conventions, policies, role model, logging. It is the groundwork that makes later migrations cheap.
What it does not do: it replaces neither requirements analysis nor an operating organisation. A technically clean landing zone without clear responsibilities leads to policies being circumvented rather than followed.
More on this in the Klartext edition on Azure Landing Zones.
How do TOGAF and the Microsoft Cloud Adoption Framework relate to each other?
They do not contradict each other, they work at different levels. TOGAF describes a methodical cycle from vision to change management and is platform-independent. The CAF describes implementation in Azure — concrete, but tied to one vendor.
In practice TOGAF supplies the structure for requirements, baseline and target architecture; the CAF supplies the building blocks for implementation and operations. Work only with the CAF and you get a good Azure environment without a rationale. Work only with TOGAF and you get a rationale without an implementation.
The mapping in detail: TOGAF in practice.
What do virtual desktop projects actually fail on?
Rarely on desktop technology. Often on the fact that a virtual desktop project is run as an isolated endpoint undertaking although it touches an ecosystem: identity, network, application delivery, profile management, security policies, operating processes.
If one of those layers stays immature, it caps the result — however well the platform was chosen. In detail in the maturity article.
When is a proof of concept worth it — and when is it wasted time?
A PoC is worth it when there is a specific uncertainty that can only be settled by measurement: does a particular application behave stably under multi-session? Is a site’s connectivity enough for the chosen protocol?
It is wasted when it is only meant to show that an established platform works at all. That is known. A PoC without abort criteria defined in advance is also almost always passed — and therefore proves nothing.
The details that decide it in operations
What looks the same in a presentation differs considerably day to day.
When does multi-session make sense — and when does the maths tip over?
Multi-session shares one host among several users and so lowers the cost per workplace — as long as usage profiles are similar and peaks are spread out. Typically suitable: case processing, call centres, shift work.
The maths tips over with applications that demand a lot of memory or exclusive resources, with simultaneous peaks across all users, and with software whose licence model requires individual installations. The host count then rises so far that single-session is simpler and often no more expensive.
How do you tell that the problem is not the network but the profile container?
From how complaints are distributed across the day. Network problems show up as continuous sluggishness during the session — input lag, stuttering display. Profile problems cluster around sign-in and sign-out.
Concrete signs pointing at the container: long sign-in times that grow with length of use, settings lost after the session ends, lock conflicts when signing in to two hosts at once.
The distinction matters because expanding the network is expensive and does not fix a profile problem.
How important is the choice of transport protocol?
More important than often assumed, but not across the board. For office applications the established protocols barely differ in daily use. The choice becomes relevant with graphics load, video and conferencing, high latency, and peripherals such as scanners, signature pads or serial devices.
It is therefore sensible not to judge a protocol in general but to test it against the specific edge cases in your own application portfolio.
What belongs in the gold image — and what expressly does not?
Into the image goes what applies to everyone and rarely changes: operating system, base configuration, security agents, applications with a heavy start-up load.
Out of the image stays what changes often or affects only some groups. Every such application in the image forces a complete rebuild at each update — and thus a process that eventually is no longer sustained.
The rule of thumb: whatever changes more often than the image itself is built belongs beside it, not inside it.
Platforms differ not where you would expect
The core functions are largely comparable. The differences lie in operations, licensing and edge cases.
What really separates Azure Virtual Desktop and Windows 365?
AVD is a platform you size and run yourself: you decide host sizes, scaling, images and assignment. Billing follows consumption. That allows multi-session and fine optimisation — but requires operational competence.
Windows 365 delivers an assigned Cloud PC at a fixed price per user per month. Fewer levers, but predictable and without capacity planning.
The decision rarely follows the technology but the question of whether you want to build operational depth or need predictability. Running both is common and sensible.
When is an existing Citrix or Horizon environment a reason to stay?
When the environment covers requirements that would create extra work elsewhere: complex peripherals, granular policy control, established operating processes and trained staff.
A change does not pay for itself on licence costs alone. It pays when the existing environment is either no longer operationally viable or when requirements arise that it structurally cannot meet.
Comparable feature by feature in the DaaS Maps.
What does changing the delivery model cost — and what gets overlooked?
Regularly overlooked: repackaging the application portfolio, migrating user profiles, adapting monitoring and service desk processes, training the operations team, and the parallel phase during which both environments run.
These items often exceed the licence difference considerably. A comparison that sets only licence and infrastructure costs against each other therefore almost always produces too favourable a result.
Can desktop virtualisation be funded with Microsoft money?
Partly. Microsoft offers programmes for certain project phases that subsidise analysis, design or migration services. The usual prerequisites are a defined scope, a partner and a demonstrable target picture.
Which programmes come into question and what conditions attach to them: Microsoft Funding.
Regulation belongs in the architecture, not at the end
Compliance established after the fact is expensive. Considered early, it usually costs no more than a decision.
At what point in a project should compliance requirements be taken into account?
In the requirements phase, together with the functional requirements. Regulatory rules bear on the same decisions as functional ones — location, identity model, logging, encryption, retention.
If it is checked afterwards, those decisions have already been made. The correction then hits foundations rather than configuration.
What does data sovereignty mean beyond the storage location?
The storage location is the simplest level. Beyond it come questions about operating staff and their access, about control of keys, about the legal jurisdiction of the provider, and about your ability to act if a service is no longer available.
An environment can sit entirely within the EU and still carry dependencies that matter when it counts. Conversely, not every dependency is a risk — what matters is whether it was entered into knowingly.
How can several regulatory frameworks be met at once without duplicated effort?
Through a common control baseline. The widespread frameworks overlap substantially — access control, logging, encryption and contingency planning appear in nearly all of them, only under different names.
It therefore makes sense to define technical measures once and then map them onto the respective requirements — rather than running a separate implementation per framework.
What shifts by 2030
Not forecasts, but developments that already influence decisions today.
Is the virtual desktop disappearing?
Not foreseeably. More likely is a shift in its role: for longer, human-driven interaction a session remains sensible. For short, automated tasks, models without a persistent session are emerging alongside.
For planning that means less „replace“ than „complement“ — with the requirement to keep both worlds under one governance.
What does local AI acceleration in the device mean for the architecture?
It shifts the question of where data is processed. If a device computes locally, certain data never leaves it — which can ease the regulatory position. At the same time a new inequality appears between devices with and without acceleration.
For mixed estates that means features requiring local acceleration cannot be promised across the board. That belongs in the persona assignment, not in procurement alone.
How do you prepare governance for autonomous processes?
With foundations that hold regardless of the specific technology: classified data, policies as code rather than as documents, traceable logging, and clearly governed permissions for non-human identities.
This work pays off regardless of how quickly autonomous processes actually arrive — it improves today’s environment anyway.
Your question is not here?
If you are facing a specific decision and need an assessment, write to me. Vendor-neutral and without a sales conversation.
Send an email → Connect on LinkedIn