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.

It's nice to see someone on the Java side of the fence talk about the benefits of MS Office. I've seen *lots* of Java dev teams build expensive, over-engineered, buggy, feature-poor webapps trying to get something done that could have very easily been done by simply grokking the data into Excel.

At my last job, I built a document editing application that used MS Word 2007. The app had a web interface to Documentum (a CMS) with a small applet that managed document transfers to and from the client.

When a user clicked on a document, it opened in Word. They could edit it, then go back to the web interface and commit their changes. This would tell the (invisible) applet to upload the changed files transparently. This avoided needing a file input form field to do uploads every time an editor made changes. As far as the users were concerned, they were editing files over the web with MS Word. :)

Since the document was Office XML, we could then parse the changes and validate the document before saving it back to the CMS. New documents could be created from Word templates as well. It was actually a pretty slick system and felt very user-friendly to the editorial staff.

I believe that this discussion brings not just the barrier that exist today between java apps and office. Its about interoperability between languages and different development frameworks. For years the decision about a language was considered a "catholic marriage" i.e. when you choose a language you actually choose a whole set of tools and methodologies that comes with it. Leveraging tools that are available from one language to another is close to impossible

Does it have to be that way?

Ted brought to my attention an interesting analogy - when we develop a web application we already use multiple langagues, we use HTML, XML, CSS, JASON and of course Java. What that means is that we already proven the languages can live side by side togather and interoperability doesn't have to be that difficult.

We (GigaSpaces) had faced many cases in which the demand for integrating excel and our Java backend. For that purpose we created a Portable Binary Serialization format (PBS) and once we solved that part the rest was easy. Now we were able to easily plug excel and other office application to our java middleware. This enables you to write/read and get notification to/from Java and Excel using VBScript API that uses our interoperability layer. Now the nice thing is that its generic and everyone can use it to bridge between office and the Java world.

A good reference that shows excel/Java interoperability is provided here.The same thing can work with any office environment as they all support VBScript.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.