Choosing VDI, Streaming, TS, or SBC: Focus on the application use cases

Most people reading this understand the concept of "application delivery." They get that it's more than server-based computing or application streaming.

Most people reading this understand the concept of "application delivery." They get that it's more than server-based computing or application streaming. They know that IT is about providing applications to users, and that today there's a plethora of different technologies for delivering these apps.

Ten years ago it was easy. We only had two options: Citrix (the new way), and traditional installs (the old way). But in 2007 we have application streaming, virtualization, and isolation; VDI- and Terminal Server-based server-based computing; local installations, local streaming, remote desktops, remote isolation, OS streaming, OS isolation.... the list goes on.

I travel extensively. The one question I'm asked again and again is, "With all of these different methods of deploying apps, how do we figure out what we should use in our environment?" (The second most frequent question I get is, "what's real and what's not today?" But that's a topic for another day. ;)

The topic of trying to figure out which technologies should be used for which apps came up in the training class I taught last week in Paris. The attendees and I brainstormed about this for awhile, and we ultimately created a series of questions and a simple flowchart that we think can frame the conversation.

Before we look at that, I want to point out a few things:

First, this flowchart and these questions are not all-inclusive, and they're not dogma. Ultimately you need to do what's right for your environment, and you need to mold the solution so that it works for you. Our goal was a create an organized way to think about these issues.

Second, we built this for Windows applications. Web apps have their own complexities, but their complexities are different. (Ironically, as more and more web apps use specific versions of the .NET framework, Java, ActiveX controls, and other plug-ins, a lot of people today are treating web apps as Internet Explorer packages that are no different than any other Windows apps.)

Third, this framework assumes that you're focusing on application "use cases." For each application, the properties of a specific user (or group), a client device, and a client device make up the "use case." You might have to work through this excercise a few times for each application to catch all of the use cases. (Sales reps in the field with company-issused laptops is one use case. Client support reps in the office with a desktop PC is another use case. Business support staff connecting from their home computers over the Internet is a third use case.)

Finally, there are more technically-detailed (yet slightly different) views of this data out there. Ruben Spruijt created a very technical flowchart for BriForum 2007 Chicago that walks through all the various technical application delivery options. I've also seen (although I can't find at the moment) a giant table from Citrix that lists application delivery methods on one axis and the various properties (use offline, use with non-Windows clients, etc.) along the other axis.

That said, let's take a look at the flowchart we created last week. Detailed explanations of each decision point follow.

 Application Decision Flowchart 

1. Application execution location

The first question to answer is where this application needs to execute: locally on the client device or remotely in the datacenter? (In other words, will you "remote" the application?) The following questions can help you make this decision for the particular use case that you're evaluating:

  • Do users need to access the app from non-Windows clients?
  • Will the application ever need to used from a client device with no network connection?
  • Are there high back-end data requirements? (Does the application need access to back-end data to be used? How much data?)
  • Do users need to start the application quickly from new devices?
  • Does the application need to access data that's stored locally on the client device?
  • Does the application need to integrate with other apps? Where are those other apps?
  • Does the nature of the application lend itself to being "remotable?" (i.e. are there high graphics requirements, multimedia, etc.)
  • Do you need to ensure that data stays off the client device?

2. Multi-user or single-user execution environment

If you decide that the application will be remoted, then you need to decide what backend architecture you'll use. Can the application run on a multi-user system like Terminal Server? Or will it need to be isolated onto a single user instance of Windows? (Windows XP or Vista. Blade or virtual machine. Will OS isolation like Virtuozzo work?)

  • Is the application terminal server compatible?
  • Does it require admin rights or anything like that?
  • Does it require some kind of physical key or dongle to run?
  • Does the user need access to "the system?" (Admin rights, full control of Windows, the ability to reboot or install drivers, etc.)

3. App installation

Once you decide where the application will run, you'll last need to decide whether you'll virualize and/or isolate the application. This applies regardless of whether the application will be remoted.

  • Is it even technically possible to virtualize / isolate / stream the app? (This will depend on what app virtualization product you're using.)
  • Do you need dynamic application installs?
  • Do you have a stateless user environment or stateless desktop?
  • Does everyone need the app, or just some users?
  • How hard is the app to manage? Is it worth virtualizing?
  • How many other apps will run locally in the context of this app?
  • Do you need the raw application performance?

That sums up the basic questions you need to answer. Remember that you'll need to work through this for each use case for each application.

You'll have to be somewhat flexible with your results. For example, if you decide to build a large VDI environment, but a few of your app use cases ideally call for terminal server-based application remoting, you might decide to just use the VDI infrastructure for those few apps instead of building a dedicated terminal server environment just for a few apps.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Brian...great article.  I think is a great way to think logically about the way these technologies are implemented.  Thanks
I think more companies have to start thinking this way. Too many buy an application virtualization or terminal server and expect to get all their applications into one solution. I like to nickname it the square peg round hole syndrome. Application management is more complex than this for every med - large company I've done work in.
Thanks for the flowchart.It's much smaller than Rubin's. I wanted to know how is an application Terminal Services compatible? Is there a document that Microsoft has which they have yested and certfied? I have heard of Citrix Ready app certified and just assumed that you are talking about that same list of apps
Nice article Brian!

This is really the "step back mentality" that companies should be adopting and are lacking at the moment.

Everybody is adopting VMWare/virtualization as being the wholy solution to all our problems but as Kevin K already stated it doesn't fit every case.

This article does help me a lot to make me and my customers aware of how diverse an app delivery scenario can be!

My goal while creating this flowchart some time ago was to give the readers a detailed overview of the decisions which can be made when you deliver Windows applications. I really hope that both Brian's article and my flowchart makes sense for the audience. When you have remarks about my flowchart, feel free to send me an email. I think every consultant needs to understand these steps when they are consulting in the application and desktop delivery space.


Hi Brian,

I always read your articles and all the comments from the community very carefully. But it´s now really time to ask you guys if you ever thought about the the costs for the licenses, implementation and operations of such solutions (e.g. in huge customer environments)?  Desktop Virtualisation e.g. sounds technically very cool! Perhaps I´m wrong to comment this here - however...

Have anybody ever calculated the costs of all neccesary parts (hardware, licenses, implementation costs) and the operational cost over a period of 3 years? Hey, regarding desktop virtualizsation you need a powerfull server hardware, a hypervisor, an OS Streaming/Deployment tool, an App Streaming/Deployment, a remote secure connectivty protocol (RDP/ICA) and a client deviced. Building it once is not a big thing. But running it with high SLA requirements, DR, change/release management (ITIL), regulatory compliance requirements and last not least - with the lowest operational costs - is that possible? Each longer I think about - each more I´m concerned.

In technical test environments it´s really cool to play arround with such technologies. But if it comes to an commercial/business level in the executive decision board and the guys there ask for ROI, TCO, SLA, legal compliance - the technical cool stúff will be rated from another foucs - the business focus!

Within visionapp with have a lot of experience on: technology vs. economics. Since we also offer hosted application solutions (SaaS), we try to delivery the most attractive prices for such solutions. But: each more (cool) technology with costs we put in, each more expensive our offers become (and each less we sell, because customers are price sensitive). So the lesson we learned (from the cost side): keep it small and simple, but secure with a high performance!

My experience is: each more technology parts you add on the stack, each more complexity and costs you will receive. And this rule is indpendent on the fact, that you offer hosted apps as a service or run them in your own environment.

Would be happy to share my thoughts with you guys! Any economical experience available of combining Presentation+App+OS+hardware virtualisation?

My opinion: dedicated approaches (with one or two virtualization technologies in combination) make sense - but all together - isn´t that a little too much (also regarding a high performance and a managable complexity).

Thanks for your feedback

PS: I also like Ruben´s flowchart. But show that to a business person and he will ask you: "Costs and Complexity - sure that both seriously under control?"

Microsoft provides the  free Application Compatibility Toolkit to determine if your applications are compatible, and you can often alter them to make them compatible.  Rick Mack has done excellent presentations on Application Compatibility at previous BriForum Conferences.


There have been may whitepapers on the TCO/ROI of SBC environments.  Thare are even a few decent ones on the economics of virtualization but I've yet to see one on the economics of TS vs VM (let me know if you know of any).  Perhaps that's because they are really just different flavours of the same thing.  As Brian has said (forgive me if I over simplify or misrepresent), one is virutalizing a multi-user OS and the other virtualizes multiple singlle user OSes.

I think that the flow chart helps to identify the solution that will best fit  the custoemr needs for the majority of application delivery requirements and then it's a question of how to deal with the exceptions.

Secondly, I think the flowchart helps to minimize the complexity that as you correctly state is directly related to overall TCO.