When I speak with vendors and customers about their remote work efforts, the conversations invariably turn to applications and the types of applications that need to be deployed.
Understanding this is critical to any end-user computing (EUC) strategy since the types of apps directly affect the endpoints and back-end systems required, as well as the application delivery mechanisms and management requirements.
It's safe to say that most apps being written today are not being written for Microsoft Windows, with developers instead favoring browser or mobile apps. It often seems, however, that this point is being exaggerated to mean that nobody is using Windows apps these days and that we no longer need Windows endpoints. Not so fast!
It's true that there are multiple options for endpoints these days and if you don't depend on Windows apps -- or, more accurately, if you only use browser apps -- you're basically free to choose from any one of them. But that all changes when a Windows app is introduced. Here's why:
Windows apps require Windows to run.
Nearly all Windows apps are made to be used with a keyboard and mouse.
Windows apps have a long tail and tend to be deployed and supported for many years.
Many Windows apps are custom-made, equipment-specific or developed in-house.
For these reasons and more, when Windows apps are in the equation, the endpoint becomes the center of attention. Can a Chromebook work for an average enterprise employee? Sure! What if a user needs to run a Windows app that their company developed in-house? Not so much. Even the most comprehensive non-Windows EUC strategy can be upended when factoring in the Windows apps needed to keep things moving. All it takes is one app that can't be redeveloped.
How to approach supporting Windows apps across all devices and platforms
First, it's important to note that the presence of a Windows app does not mean that you're locked into Windows endpoints. Typically, you have three choices to deal with Windows apps:
Deploy Windows-based endpoints.
Migrate the apps away from Windows.
Apply some kind of desktop virtualization, such as VDI or desktop as a service (DaaS), to remotely deliver the app interface to any endpoint device.
Since you probably would have migrated the app by now if you could, let's focus on the other options.
Deploying Windows endpoints is the easy option. For the most part, it's business as usual and it's functionally the most flexible option. We're all familiar with Windows-based endpoints and what goes into managing and maintaining them, and we know that they can run just about any of the apps required by end users. This is true for Windows or browser-based apps, so it's no surprise that recent research from TechTarget's Enterprise Strategy Group found that the endpoint devices that organizations most commonly deploy are PCs running Microsoft Windows.
But what if you've decided to eschew Windows endpoints in favor of something else? Or what if you support all types of endpoints but still need to deliver Windows apps? That's where desktop virtualization comes in, and it's why technologies such as VDI, DaaS and even app publishing are not going away any time soon.
By running Windows in a centralized location -- data center or cloud -- and remotely delivering the app UI or the full desktop to the user, organizations free up users to use whichever device they prefer. And since users can access those apps or desktops from a browser, organizations can effectively deliver legacy Windows apps in the same way their other, more modern, apps are deployed. If you squint, it's almost like you've converted your Windows app to a browser app.
Desktop virtualization is going to be around for a long time
It's easy to think that desktop virtualization might be a stopgap measure, and that eventually all things will go be delivered in the browser. There are two truths that answer this notion:
You're not wrong: The browser is the destination for just about everything, eventually.
You're still wrong: It will take so long to deliver everything in the browser that desktop virtualization will hardly be a stopgap measure.
The presence of even a minimal set of Windows apps means that your organization will have to deal with them for the foreseeable future. For most organizations, this means that a future where every app is browser-based and users don't need Windows at all is out of reach.
There are far more combination use cases than there are either-or use cases.
We're in this position because migrating away from Windows apps is a technically challenging, time-consuming endeavor that has effects on IT, end users and organizations in general. To migrate an app away from Windows, organizations must ensure that the new platform will address all these challenges relatively quickly. We saw platforms such as Salesforce, Concur, Tableau and others have great success because they quickly replaced off-the-shelf platforms that all organizations needed. But the same isn't true for custom apps that were developed in-house for specialized purposes. Similarly, commercial apps that are more functional than their browser counterparts -- like Microsoft Office -- will face challenges with migration.
Frankly, it comes down to this: If you could have migrated your apps to the browser or to SaaS, you would have done it by now. Windows apps are here to stay, regardless of how modern your current projects or future plans are. The decision that needs to be made isn't whether to use Windows, but rather how you will use it.
Where do we go from here?
Any endpoint device strategy must consider the prevalence of Windows apps and the effect that they have on the organization. There are very few situations where an organization can simply decide that they don't need Windows in any of its forms anymore. However, that doesn't mean they can't take advantage of things like modern management, enterprise browsers and non-Windows endpoints.
Technology vendors can help customers succeed by understanding the overall customer experience, even if it extends beyond their swim lane. In some areas, this could mean partnering instead of competing.
For example, Google has partnered with Cameyo to ensure its Chrome OS customers have access to Windows apps despite not running Windows on their endpoints. Others, such as the emerging enterprise browser vendors Island and Talon, and any other innovative vendors, would be wise to partner with desktop virtualization vendors. This way, they can focus on delivering a best-of-both-worlds product rather than trying to compete. There are far more combination use cases than there are either-or use cases.
Gabe Knuth is the senior end-user computing analyst for TechTarget's Enterprise Strategy Group. He writes publicly for TechTarget in addition to his analyst work. If you'd like to reach out, see his profile on LinkedIn or send an email to [email protected].
