This is popular advice: don’t wait until you have to change, do it while you can choose how and when. I believe it’s time to apply that to the front end architecture for XenApp and XenDesktop.

Has It Been 10 Years Already?

Well, nearly ten. Ten years since Web Interface was conceived, nearly ten since it was launched as NFuse 1.0 in March 2000. Back then it was pretty basic: a few Java objects handling communication with MetaFrame 1.8 using an XML protocol, and offering a simple template language for constructing web pages and ICA files dynamically. Oh, and some example web pages to illustrate how they could be used. Sort of an early Lego MindStorms, but without the Lego …or the robotics …or – okay, okay, not really Lego MindStorms at all: it was just a construction kit.
Seeing as perhaps it didn’t have quite the same level of fun as Lego Mindstorms, I guess it’s not surprising that people started to ask, politely, if there could be a working example with, let’s say, a standard login page and list of apps you could launch. Point taken: NFuse 1.5 shipped in March 2001 as the first turnkey release.

So it started; the idea of accessing apps and desktops via the web caught on. It made sense, but it needed a little more: a way to give users the ICA client would be useful. A way to tell if they had an old version and should upgrade would be good. How about supporting stronger authentication for the Internet, like one time passwords – you can? Great! Credit for a lot of rapid innovation goes to a group of people, pretty much all in customer facing roles, who seized the opportunity to forge ahead. Jay Tomlin is still revered for Project Columbia; a rich collection of features rivalling what Web Interface offers today. It was still 2001.

How Old is 10 in Web Years?

Web Interface has changed a lot since then, even if it isn’t always obvious. Web security became a big deal, thanks to hundreds of penetration tests and audits. The demise of Microsoft’s Java VM resulted in a switch to J# and ASP.NET (WI3). The Java objects eventually gave way to a completely new SDK (WI4). A major UI redesign (WI5) finally swapped tables for stylesheets – and white for black (sorry about that). Versions for SharePoint, WebSphere and other portals appeared along the way, along with more features than I can remember. Over the years Web Interface became essential, used by nearly 90% of XenApp customers and 100% of XenDesktop customers. For 50% of customers, it is the only access method.

That’s all deeply fascinating, I hear you say, but what’s my point – is ten a magic number?

Well, perhaps it is. You see, I believe it’s time for a change – no, more than a change, a regeneration. A Doctor Who moment of sorts. The feedback I get is that Web Interface is serving customers well, and yet increasingly I hear how you want more. People are moving well beyond simple app and desktop access via the web; your environments are more complex, there are more access scenarios, more types of devices, greater diversity of users – indeed, greater diversity of most things – and now user expectations are going through the roof as the digital generation goes to work. As architect, I see how much Web Interface is being stretched trying to satisfy more and more requirements, and I see the cracks getting wider.

We all want to take things to a higher level. My message is that we need a new foundation to do that. After all, how old is ten in web years?

Enter Delivery Web Services, Dazzle, Receiver, Merchandising Server, and more. Delivery Web Services is the new bedrock designed to support native clients and web apps alike. Receiver and Dazzle signify a componentized approach to clients, as well as an invigorated focus on user experience and design. Merchandising Server is the start of a tool set for holistic delivery of IT services (whether in-house or out-sourced) to disparate end points.

My focus is on the web services, client components, and other infrastructure behind the scenes in this picture; that’s primarily what I’ll be blogging about in the coming months.

How Fast Does the Future Get Here?

A new foundation is all well and good, but it raises some thorny questions. How do we minimize disruption and confusion as 200,000 customers migrate to a new platform, and how long will it take? The only way I can see to do it is scenario by scenario, with a clear roadmap of the steps along the way. Even that will be a challenge because 200,000 customers cover a lot of scenarios, no matter how you group them, and the adage applies to us as much as to Microsoft that everyone uses a different 20% of the product.

Often, with a new platform, there are some signficant changes in approach, and a rethinking of assumptions. That is certainly true here, and I and others will be blogging about these over the coming months, to test whether our assumptions are valid and if our design choices will hold up. Our aim is to be open about what we are planning to do and why, so you can point out where we are getting it wrong. I think it is clear by now that you can change what we do, but I also believe you’ll like where we’re heading.

So don’t panic! It’s clear that Web Interface is going to be in use for years to come, and I’m sure we’ll be supporting it for a long time (though hopefully not another 10 years!). I expect it will be updated to cope with updates to the OS, browsers, clients etc; probably a few more features will sneak in too. But increasingly our development focus will be (I would argue, needs to be) on building out capabilities in the Delivery Web Services bedrock, extending Dazzle to more scenarios, and building a web version of Dazzle+Receiver – maybe even more than one.  That’s the beauty of the new platform: we can afford to build more UIs, each a better fit for its intended use, rather than always packing yet more features into the sardine tin that is Web Interface.  But beauty aside, I believe, quite simply, that now is a good time to build a new foundation, while we can still discuss the details and adjust the roadmap. I hope you will understand, and guide us on the best way to proceed.

Andrew Innes
Citrix Architect for Web Interface, Dazzle, Delivery Web Services, and assorted clients