For some time now, I have been talking about what I labelled “The Data Problem“. While I have been talking about this for over three years, and even as recently as an article on BrianMadden.com last month, vendors have been coming to me to explain how their product solves the problem. This is a huge problem (big enough that I’m not going to try to explain it again in this blog post: see links in this post for that), and todays layering solutions only cover parts of the data problem. This problem comes to us thanks to the richness and history of the Microsoft Operating system and countless guidelines given to their legions of developers on how to write applications. We need more than bandages.
My friend Steve Greenberg over at ThinClient Computing refers to it as C.R.A.P., which stands for “Computer Residue of Applications and Personalization”. A great acronym, for sure.
Ever since I started talking about it, companies have been working on solutions. To be fair, they generally started before I began talking about it, but I was unaware of their efforts. And while I applaud their efforts, I haven’t viewed their solutions as being spot on (yet). In fact, just last month at BriForum I talked about this and said that probably only Microsoft can really address the issue.
Yesterday, Citrix aquired one of the companies working on layering, RingCube. In itself, this may not be such a significant event beyond that of awakening the market even further to layering. Appsense, UniDesk, MokaFive, and TriCerat should all be pleased. All great products, but this doesn’t change the fact that nobody has the right solution yet. These solutions do the most common reasonable steps, essentially capturing too much to be sure they have enough stuff.
So you say “sure Tim, complain complain, but what is the right solution”?
The right solution would be for Microsoft to fix the mess they created. But baring that, we need a layering solution that can understand the different kinds of crap and deal with it the right way. This means understanding application behavior to a much greater extent than they do today. This is why current layering solutions are not the right solution yet.
A great layering solution will understand the difference between things that need to be saved and things that should not. I don’t just mean temp files here, although those need to be identified. There is a ton of stuff written to the windows registry by applicatins that should not be saved too.
A great layering solution will understand when data is generated by a virtual application, where virtualized data might be as important as virtualizing the application binaries. That data should stay inside the virtual bubble IFF is would have stayed inside the virtual bubble without the layering. It might even be able to use information that the appvirt layer knows about the app to make even better decisions.
A great layering solution will also transform the data to make it portable. Think about how App-V makes all of the data references machine and user neutral. A great layering solution would make the data it captures neutral as well, allowing the user to roam to different machines.
A really great layering solution will also work correctly when a user logs on to more than one device at a time. We need better than “last write wins”, we had that with roaming profiles.
So there you go. Four steps to “Layering Done Right”. It’s just a simple matter of programing now. Should see one show up on my doorstep any day now. OK. Maybe not.
Photo Attribute: CCC Scott Roberts