Michael Kiselman is a Technical Product Manager for the new Information Bridge Framework (IBF) at Microsoft. Introduced at the recent TechEdge Conference in San Diego, IBF provides a framework for connecting disparate sources of enterprise information from back-end systems like ERP and CRM to Office 2003 Professional applications via web services and WinForms. The benefits can be compelling.
Microsoft paints a picture of office workers in sales, customer service, and support having instant access to information about a customer in the familiar environments of Outlook and Word. The elimination of proprietary client software used to access each of these back-end systems reduces licensing, support, and training costs. And the reduction in "context switching" from one application to another to gather, transfer, and manipulate information also provides big potential savings and productivity gains.
I posed a number of questions to Michael about the vision for IBF and how it may impact the way knowledge work is done.
Marc Orchant: IBF seems like a tremendous idea but it feels like it's going to take some time before it really has an impact. Can you address the core requirements, both from an infrastructure and a developer perspective, that are needed to take advantage of IBF in an enterprise setting? Does this "scale down" to SMBs?
Michael Kiselman: IBF requires Office 2003 with .NET Framework 1.1 on the client, Windows Server 2003 with SQL Server 2000 SP3a on the server and VS.NET 2003 for the Metadata Designer development tool. As you see, requirements are not complex and definitely could be afforded by SMBs.
MO: As a follow-up, some of the early documents I've read take a very cautionary tone in talking to developers about how they might use IBF. Charles Maxon (another OfficeZealot), for example, has an introductory article about IBF at MSDN that raises potential red flags for developers. In essence, it says "this is not the pool you're accustomed to swimming in - take another look before you dive in". Does IBF create a new class of developer/consultants like the old Notes Developer community?
MK: IBF definitely has a learning curve, however, you leverage your existing skills in .NET development (WS and WinForms) and gain a tremendous flexibility and extensibility of the Office solutions you are developing. Do we create a new class of developers? We hope not - one of the main benefits of IBF based solution development is an ability to separate back end WS development from the declarative solution development itself. We are hearing from our customers that one of the barriers for development of solutions today is inability by today's Office developer to understand the back end application and all the associated intricacies of access to it. With IBF you overcome that by leveraging skills of people knowing the back end well.
MO: Can you give me a sense of how long it might take to develop a working implementation of the sort of solution being used as an archetype in the IBF documentation Microsoft is making available? Is this a project measured in days, weeks, or months to develop?
MK: We actually observed an interesting trend - when a developer comes to learn IBF - it takes about 1.5-2 weeks to come up to speed and create first solution. The second one takes him/her 3 days and the next only a few hours. Of course, these numbers would depend tremendously on the complexity of the solution.
MO: Does the long-term vision at Microsoft for IBF include a model where service companies (think
utilities, phone companies, cable providers, Amazon, etc.) might offer their customers the ability to self-manage
their accounts by using IBF to provide an appropriate level of permissions to make changes in the core data about
themselves. For example, say I move. It'd be cool to go into my Amazon account, etc. and make the address change
myself and know that it was done properly. Seems to me that, if this is possible, it's a win for everyone. I'm
certain my account info is correct and Amazon saves money because I did the work for them.
MK: This is a great vision for IBF as long as these customers need access and
action to these service provider systems while they are in Word, Excel or Outlook.
MO: How do you see IBF and SharePoint integrating? That seems like a big potential win but the
vision for that is pretty sketchy in the materials I've been able to find so far.
MK: Today, IBF can easily incorporate SharePoint as a source application, as a matter
of fact, we will release a sample solution providing developers metadata to do just that in out Resource Kit.
The other way around is trickier. We are working with the SharePoint team on defining the roadmap,
which will allow IBF to deliver and render Information and actions in IE or other SharePoint UIs.
MO: Is IBF the technology that will really breathes life into InfoPath? They seem made for each
other. If there's a way to allow me, as an end user knowledge worker, to "snap together" a smart form using pre-built
IBF "parts", that's pretty compelling.
MK: Absolutely, in IBF 1.1, which is slated to be released at the end of the 2004, we are adding support for InfoPath - you will be able to access the same information and action via IBF while filling out a form in InfoPath.
I also asked Chris Kunicki of OfficeZealot.com as an independent consultant who specializes in Enterprise use of Microsoft Office what he thought of IBF? Here is what he said:
From early on we knew that enterprises and ISVs would be excited in what they saw with IBF. However, our original estimates were way off. The interest for IBF has been nothing short of phenomenal.
Why so popular? We think IBF serves as a common intersection point for a number of high impact technologies that companies are investing in: Web services for exposing corporate data resources, .NET for rapid application development and Microsoft Office 2003 as the place where people live and work all day. By themselves each of these technologies bring their own value to the table, but when you fuse them all together you really begin to see a return on investment in the order of multitudes larger than if they individually have to stand on their own.
One common question asked is how large does an organization need to be to make the investment in IBF. Clearly many enterprises and software vendors are already adopting IBF. However adoption of IBF won't be limited to just large organizations. We have already seen interest from small businesses. For example, small legal firms, independent community banks, and healthcare firms that provides in house care services. I have yet to see an executive sponsor watch a demonstration of IBF that doesn't express interest in how they might use it.
Why adopt IBF? The great thing about IBF is that it's not a solution by itself, but typically will compliment and extend existing systems. This means that you don't need to start building a new application from scratch. Most developers will analyze existing systems and plug IBF into them. IBF is just another way to extend the reach of existing systems to more users in the enterprise and to increase the ROI in those systems.
A key concept to understand about IBF is that it functions as glue that binds various data resources with components that let users take meaningful action on that data. As an organization begins to catalog internal data resources and develop actionable components on top of them they begin to build a reusable library of IBF components (similar to the SharePoint Web Part concept) that can be reused in connecting to multiple applications. I imagine in a year or so some companies may have literally a 100 reusable components that can be mixed and matched to create custom IBF solutions for users. Then their investment in IBF pays off even further.
OfficeZealot.com has an IBF Zone for those looking for additional information and resources.
