Microsoft Office as a Rich Client For Enterprise Applications

One of the great things about Ted Neward is the joy he takes in skillfully explaining that the Emperor has no clothes. And it seems that he most often finds himself in that position when he is trying to explain to the Java community how much value they are leaving on the table when they automatically exclude Microsoft technologies while defining solution architectures. Last week Ted wrote a short blog post pointing to a piece written up by Bruce Wilson about using Microsoft Office as a (really powerful) rich client. After introducing Wilson's article Ted gets right to the point:

The interesting thing is, most of the ideas he talks about here could just as easily be implemented on top of a Java back-end, or a Ruby back-end, as a .NET back-end. Office is a tool that many end-users "get" right away (whether you agree with Microsoft's user interface metaphors or not, or even like the fact that Office is one of the most widely-installed software packages on the planet), and it has a lot of support infrastructure built in.

It's fair to say that the single most important quality in a rich client platform (or any client platform) is ubiquity. And while MS Office is still not as ubiquitous as the browser, the context both of these authors are talking about is application development to support enterprise automation. The focus here is an internal application that will never be used outside the context of that organization. And in most enterprises, MS Office truly is ubiquitous.

The Wilson piece starts out at a pretty high level, but as the article progresses there are some interesting perspectives. Here is a paragraph from his post that did a good job in making a case for Office applications:

At my company we pride ourselves on our ability to improve “user experience.” In essence, this means customizing the parts of software that users touch to make software fit users better. In recent years we’ve been seeing increasing interest in developing systems that make more of the back-end accessible to more users, in particular making information that traditionally has only been accessible to database specialists accessible to business users. We also continue to see, surprisingly often, manual re-entry of information, even in very large companies. The solution in both scenarios often involves SOA (web services), OBAs and related Microsoft technologies.

User experience focus is sorely lacking in most internally developed enterprise applications. Making a web application with a natural and effective user experience can be done, but it is also expensive, and it usually doesn't make business sense to spend that money because "good enough" will get the job done. The perspective of bringing solutions to the set of tools the users already know and leveraging that context to provide that intuitive user experience for a much lower cost just makes sense.

For a solution that makes so much sense there is relatively low uptake in the enterprise. InfoQ asked Ted about this to get his thoughts:
Q: "Ted, you have been talking about this topic for years, and yet we still seem to be in the idea introduction phase for this concept in the broader community, and it seems we are in the same place we all were a few years ago with XForms before most of us gave up on it forever. XForms was obvious, it was WAY better than HTML forms, and it was going to happen - had to happen. There were O'Reilly books written about it. Then we stood around looking at each other saying "why isn't this happening?" This combination of a services backend and an Office front end is also really powerful, and yet uptake still seems marginal at best. By now you must be asking 'Why isn't this obvious to people?'"

I think it *is* obvious to people… specifically, the people that have been developing Office Business Apps for the better part of a decade now. :-)

If you go to TechEd IT, you find a lot of these folks there, they’re just not traditional developers as we think about developers in the “enterprise” or “CompSci” sense. They’re what Microsoft calls “Information Workers”, people who are only moderately (if that) technical but very business-savvy, and use Office to solve their problems in various ways. (These are the same folks from whom we get all those Access databases that we end up “scaling up” into Oracle and SQL Server backed web front-end enterprise systems.) Sometimes these are the folks to whom we turn when we need to figure out the business rules for an application or system.

Quite frankly, I think the Office-as-a-rich-client idea has one thing the XForms stuff didn’t, and that’s installed market share. Office is NOT going away any time soon (name for me a successor that has even a tenth of Office’s market share), and so long as Office remains a playa, so will the idea of Office as a rich client. The thing I want to do is bring it out of the “that’s not REAL programming” mindset that so many developers have when looking at Office.

If you want a *real* interesting prediction, I suggest that Office will outlive SOA… just as it outlived “objects” and “client-server” before it… which is something the traditional developer does NOT want to hear.

If your curiosity is piqued, you can watch an interview Ted did with InfoQ that covered some of these concepts.