Day 3 @ TechEd - IBF Architecture Overview

The Information Bridge Framework helps connect Microsoft Office to enterprise resources. How is this done? IBF is made up of two components, one for the server and one for the client. The server component called the Information Bridge Metadata Service gives you a central place to store information about the resources available with in an enterprise and the types of things that can be done with that information in Office. IBF calls this information Metadata. As it name might imply, the Metadata is not the data people actually work with but it defines where the data Office users need is located, how to access it and what do with it.

The client component communicates with the Information Bridge Metadata Service to retrieve the Metadata that applies to the Office user. This Metadata is then cached on the client to reduce unneeded connections to the server. From there, as the user works in Office IBF kicks in by reacting to the type of data the Office user is working with and then providing them with relevant information and actions based on the context of their work.

I realize that my description may sound nebulous; however, I?m trying to be careful not to lock you into any quick conclusions about what IBF can do. The truth is that most enterprise resource can be wired up to IBF and exposed to Office through its programmatic interfaces. That is one of the things you learn quickly about IBF is that its architecture is very flexible.

In the future I?ll come back to each of these components and get more specific about what is possible and various scenarios that might be useful in your organization.

Check out the IBF Zone on OfficeZealot.com for an interview with Alex Marchicelli, Program Manager on the IBF team for a Architecture Overview of IBF.