Microsoft's architectural update for productivity

They call it Connected Computing, but I think it should be called .Client/Server

Microsoft at the PDC '05 here in Los Angeles this week is giving a view of the future of corporate worker productivity and it's ... client/server computing. Well, more precisely, it's loosely coupled client/server, with multiple back-send applications and XML data sources. It's called Connected Computing, and it's a mash-up of loosely coupled compositing of business applications using Microsoft Office as the clients, Visual Studio Tools for Office as the builder, and Windows Communications Foundation (Indigo) as the messaging layer. Naturally, you'll have to upgrade everything on your clients and servers after Nov. 7 to be able to bank on the vast worker productivity boost.

They call it Connected Computing, but I think it should be called .Client/Server. There isn't much "NET" in there. In fact, if an internal Microsoft productivity project, code-named Elixir, is any indication, Microsoft thinks it's time to dump the browser and intranet portals paradigm. Kiss the last 10 years goodbye -- it's back to 1994.

Microsoft on Monday described Elixir in depth to a group of jet-lagged international press and analysts, and not even an hour-long power outage could dim the gleam in the eyes of those Microsoft strategists who saw the appeal of taking all of your CRM data with you in your email client. Yep, Microsoft Outlook transcends the browser and portal to -- for several hundred of Microsoft's sales force right now -- use Outlook folders to synchronize and replicate to the back-end CRM applications.

I'm not making this up. Seems that, like a lot of folks tasked with feeding the CRM beast with data, the Microsoft sales staff didn't always enter the customer interaction notes in a timely and comprehensive fashion through their browsers when connected to the CRM application or portal. They, even when highly incentivized with monetary inducements, often waited until the last day of the month to cut and paste all their calendar entries into the CRM fields. This, by the way, for better or worse, is standard operating procedure across corporations everywhere.

So the Microsoft architects went to work. They knew what their connected systems were capable of, and they knew that Microsoft Office is where these workers are most adapt. They figured they would get them to add in all the customer interactions data when they were "living" in their email and calendar application. To the apparent initial resistance of the Microsoft IT department (sensibly), they wired the CRM data to -- using XML Web services -- the Outlook folders. And they also produced the CRM application interface within Outlook.

So, in project Elixir, all the customer data feeds from the CRM application on the server to Outlook on all the client PCs so that the salespeople can input their CRM updates and notes where ever they are -- connected or not. The offline capability plus the fact they are using an application interface they are familiar with, Outlook, leads to the productivity boost. Microsoft says they are seeing 10% more "face time" with customers as a result. They did not break out the costs associated with this breakneck advance.

But what I see, for a modest productivity increase, is complex and retro. There is also a lot of sensitive data piled up on the local hard drives, a lot of data transferring around the network at connection times, and a lot of architectural complexity to connect up the multiple apps and data to the email folders. What they are seeing architecturally is Lotus Notes in 1994, but without the benefit of the entire system architected securely from the get-go for such activity.

I guess Office is key to Microsoft's future, but I'm not sure this return to client/server using Web services technologies makes a lot of cost-benefit analysis sense. Enterprises have swung back to centralized servers with thin clients for a lot of applications and portals for good and long-term reasons. Microsoft seems to be betting that the server-side architectural pendulum will swing back in its favor, based pretty much on the benefits of offline data access to a rich client interface that can access a variety of server and data sources. I'm not so sure.