Office is a platform. When we combine the programmability of Office Clients (Word, Excel, PowerPoint, and Access) with the programmability of SharePoint to enable deep integration of data from Line-of-Business enterprise applications, we enable building an entirely new category of application. This blog post presents my thoughts and reflections on Office Business Applications.
This blog is inactive.New blog: EricWhite.com/blogBlog TOCAcknowledgements: I’ve taken this information from a variety of sources, including Steve Fox, who is one of the experts in what an OBA is (and isn’t). Thanks, Steve!
Here’s the situation:
We can divide the activities of information workers into two categories:
1) Interaction with back-end enterprise level applications. These are the applications that run large corporations. These applications include customer resource management (CRM), enterprise resource planning (ERP), and back-office accounting systems. These systems tend to be transaction oriented and highly structured.
2) Ad-hoc, flexible, innovative, and collaborative processes that are necessary to do the work of the business that brings in revenue - write requests for proposals, put together design/engineer projects, and close deals. Typically, these activities are accomplished in the Microsoft Office clients. We use Outlook to manage email. We write documents in Word. You get the picture.
Information workers spend most of their time in ad-hoc, collaborative processes. Then, more or less frequently, based on the type of their work, people then log into their back-end system(s) and add/update information. In the case of a sales person interacting with a Customer Relationship Management (CRM) system, this interaction may be several times (or several dozen times) a day. A recruiter in HR may need to update her back-end system a few times per day.
But in either case, the disjointed nature of these two types of work lead to inefficiencies, cut and paste integration, and potential for errors. If the back-end systems are not integrated with the productivity applications, we can’t even begin to take advantage of new scenarios that integration provides. Given that people spend much of their day using their tools of collaboration (the Office Clients and SharePoint), our goal should to bring their data to them, instead of forcing them to go to their data. We want to avoid making them interrupt their flow of work, leave their productivity applications, and interact with back-end systems in an isolated way.
Office Business Applications are a vision of a new way for information workers to do what they do on a day to day basis. The gist of an OBA is that information workers primarily work in Office, so to the extent that we surface Line of Business data and make it easy to interact with that data from within Office, we make our employees more productive, and reduce their workload.
So what does this mean in real terms?
It means that a good OBA makes use of the task pane and ribbon in the client applications to bring data to the fore. The task pane can include information from LOB applications, SharePoint, web services, or just about any other source of data that an information worker can use during ad-hoc collaborative processes. And this pane doesn’t just present information side-by-side to your Word document or Excel spreadsheet. A good OBA integrates documents/spreadsheets and LOB data. Click a button on the task pane or ribbon and generate a letter. Retrieve information from documents and populate SharePoint lists.
If, when you design your Open XML documents, you separate semantic information from presentation information (using custom XML), you enable that semantic information to play nicely with SharePoint and the LOB application. Imagine a scenario where you design a smart document that includes bound content controls – a job application, say. You send this to whoever wants one. Then, when that document is filled out and returned, you can click a button or select a menu item in SharePoint to pull that semantic information into a SharePoint list.
And of course, the task pane is integrated with the ribbon (the Fluent UI). You implement a powerful interface using the ribbon to enable the scenarios that your users need.
Ideally, you construct the task pane using WPF, and make a visually pleasing and more efficient user interface.
The deep integration of the Office client applications (Word, Excel, PowerPoint, and Access) with SharePoint means that it becomes frictionless to share information throughout your company. You save to document libraries, and your information is immediately available to those you have given permission. The versioning and other ECM capabilities of SharePoint provide a level of management and control that you don’t get when each user works in the silo of their desktop computer.
And, of course, you can use SharePoint to enable collaboration that makes your organization operate smoothly. Employees use blogs, wikis, and discussion threads. And you integrate these activities organically around the flow and process of back-end systems while at the same time making this collaboration searchable and accessible.
Integration of Line of Business data within SharePoint is crucial too. By setting up the Business Data Catalog (BDC), you enable your users to use LOB data in concert with lists and document libraries in SharePoint. Search can find data in the LOB system as well as data stored in lists and document libraries. With the proper design, SharePoint lists and document libraries integrate naturally into the flow of data in the back-end enterprise systems.
As we said, a good OBA surfaces information from the back-end system in the Office client applications, and enables intelligent use of that data to make it easy for users to integrate that data in their ad-hoc, creative processes. You can use the BDC, Windows Communication Foundation, web services, .NET connector, a Biztalk adapter, or other mechanisms to bring LOB data into the Office client applications and SharePoint.
But whichever approach you take, the key point here is that a good OBA integrates the data previously imprisoned in back-end systems, and brings it to the user when they need it.
Now that we’ve defined with an Office Business Application is, we can talk about what a truly excellent OBA is.
Open XML enables new scenarios for dealing with documents in an OBA.
Open XML defines a number of ways to separate semantic information from display information. For instance, custom XML parts used in combination with content controls allow server applications to retrieve that semantic information and take intelligent action based on that data.
The tools for working with Open XML are server-side friendly tools, such as the Open XML SDK, and XML programming libraries such as LINQ to XML and XmlDocument. These tools are used on servers day-in and day-out. We can use these tools to ‘light up’ documents from within SharePoint. Documents are no longer black boxes accessible to the lonely few applications that know how to crack open a binary document. Imagine a scenario where the user can go navigate to a document library and then browse and preview documents without launching the Office clients.
Document generation may be the most compelling use of Open XML from within SharePoint. We can write small bits of code that take data from the BDC and SharePoint lists, and create new documents, again without involving the Office Clients.
Developers who use Silverlight from within SharePoint have the capacity to revolutionize their user’s interactions. User interfaces can be dynamic, powerful, intuitive, and pleasing to view.
We can use Silverlight to enable new user experiences. I recently saw a demo where latitude and longitude information was used to position markers on a map rendered in Silverlight. Surfacing geographical information in a visual way is always powerful.
Graphing and charting in Silverlight raise the level of fit and finish for your application.