A bridge for Microsoft-land

Microsoft recently announced the release of the beta version of the somewhat grandiosely-named Microsoft Office Information Bridge Framework. Microsoft has been creating extensible and programmable products for years now, but lately I detect a new interest on the part of the Redmondites in actually hooking all this stuff together. IBF is designed to help developers quickly and easily hook together Microsoft Office, parts of the Windows Server System, and .NET code to form solutions for the knowledge worker.

There is a great deal of information already available in the Office Developer Center, and I'm still coming to grips with it all. But the basic idea here is that Office 2003 has enough power and XML hooks to tie into corporate data sources with just a few glue components, which are supplied by the IBF. You'll need to be running Windows 2003 Server and SQL Server 2000 to provide the infrastructure, Office 2003 for the client, and Web Services (presumably developed with Visual Studio .NET) to tie everything together. To the extent that they can get anyone to buy into this stuff, this is obviously a marketing dream for Microsoft. An organization that wants to be using the IBF pretty much has to be on the latest and greatest versions of everything.

The basic idea is pretty simple. IBF is a way for information workers who currently waste time looking things up and cutting and pasting to remain within an Office document and have information brought to them. From the worker's point of view, it's all done with Smart Tags and task panes. For example, you might be reading a memo about inventory levels for various parts in your Chicago warehouse, and discover that the inventory of widgets is very low. "Widget" would get a Smart Tag with choices like "show order history", "visit manufacturer Web site", and whatever else seems pertinent. Asking for the order history would fill a task pane, perhaps with a grid of inventory changes. From there, you could proceed to place the order for more inventory - all without ever leaving Word where you were working in the first place.

For the developer, all this involves defining the entities in the business, figuring out where the data is stored, building a metadata store that Office can draw on, and providing Web services to get data, store updates, and perform actions. IBF glues it all together so that it works flexibly even in situations that you didn't anticipate. The whole ends up being very information-centric.

Overall, the IBF looks to me like it's the Office analog of some of the things that the Patterns & Practices Group has been doing for the purely developer space. In the last few versions there's been a bit of an imbalance between the developers within Microsoft who build Office, and those outside of Microsoft who use it. They've been putting in new functionality and interfaces faster than we consume them. By going beyond the traditional demo applications to provide actual, usable code and prescriptive guidance, Microsoft is making a sound investment in continuing to make Office a premier tool.

About the Author

Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.


Upcoming Events


Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.