Building Office Business Applications: A New Breed of Business Applications Built on the 2007 Microsoft Office System
Microsoft Office "12"
Summary: This white paper introduces Office Business Applications (OBAs), a new breed of easily customizable solutions that address real-world business problems through the 2007 Microsoft Office system. (12 printed pages)
Office Business Applications
The 2007 Microsoft Office System
LOBi for Office SharePoint Server Extends the Microsoft Office System
Office Business Application Example: Collaborative Planning
Call to Action
This white paper introduces Office Business Applications (OBAs), a new breed of easily customizable solutions that address real-world business problems through the 2007 Microsoft Office system. OBAs deliver people-centric, collaborative solutions to the enterprise through familiar Microsoft Office servers, clients, and tools. This document discusses today's business environment, identifies a "results gap" that contributes to reduced productivity, and shows that OBAs are an effective new approach that enables enterprises to achieve the "last mile of productivity." You will see that several key components of the 2007 Microsoft Office system can be used to develop Office Business Applications and that, when Line of Business Integration (LOBi) for Microsoft Office SharePoint Server is released, it will further simplify the development of OBAs. Finally, if you would like to develop a collaboration-planning scenario using the 2007 Office system, just follow the steps outlined in this paper.
Note The product names and feature names included in quotation marks throughout this paper—such as the next release of Microsoft Office products, currently code-named Microsoft Office "12"—are not yet released or finalized. The application names used in this article refer to the next versions of the products, unless otherwise specified.
The worldwide business landscape is becoming increasingly challenging. Globalization has removed traditional trade barriers, opened new markets, and infused businesses with new talent and creativity. Companies have easier access to new customers and partners around the world. However, this increased reach has also made business more complex. Companies have to connect with tiers of business partners globally, orchestrate the flow of goods and services, and respond to customers at Internet speeds. Increasing variability, competitive pressures, and higher market volatility are forcing organizations to forecast more accurately and adapt more quickly to changing business conditions.
Under these challenging conditions, stakeholders expect companies to compete effectively, and to grow revenues and profits. Companies, in turn, are asking their Information Technology (IT) departments to drive business performance through continuous process innovations and rapid technology adoption.
The Results Gap
Companies rely heavily on IT to help address these challenges, as evidenced by the huge investment in large financial management systems and solutions for enterprise resource planning (ERP), customer relationship management (CRM), and supply chain management (SCM). Nevertheless, many organizations have not realized the expected value from these investments. There is a clear gap between the efficiency and productivity increases that corporate leaders expected to see, and the actual return on investment (ROI) that they have experienced.
This "results gap" is caused by a fundamental inconsistency between how business systems work and how people work. The systems are based on transactional processes that are necessary in order to accomplish specific tasks—for example, creating a Purchase Order. What they have not effectively captured are the ad hoc, local people-driven processes that invariably arise. The result is that decision makers take a "feed the machine" view to their corporate business applications, but rely more heavily on the people-to-people collaboration for making decisions and taking actions.
Enabling the Last Mile of Productivity
Software has become pervasive in every organization. Automation of back office business processes has been occurring for several decades, and huge investments have been made in these enterprise applications. Software has also driven a revolution in how people work. Spreadsheets, word processing, e-mail, and browsers have profoundly changed the way people interact with information. These tools are the baseline work environment today for hundreds of millions of people, and they have had a tremendous impact on personal productivity. And this revolution is not complete—we predict many more substantial innovations in personal productivity software.
Information workers have powerful tools that help them garner insights, make decisions, take action, and collaborate, but they're largely limited to local or personal information. By contrast, very few systems are designed for the people who use them. We believe that the results gap exists fundamentally because of this discrepancy. How do we tap the vast quantities of data that flow through our transactional systems and allow our people to use that information in a way that can magnify their impact on the business's performance? How can we bring to the enterprise application world the level of productivity that people experience with these powerful tools in the business world? We call these challenges "enabling the last mile of productivity."
Challenges on the Last Mile
Application vendors, services providers, and IT environments have attempted to fill the results gap and enable the last mile of productivity. However, these efforts have fallen short for a number of reasons:
- Inward-facing design—Application vendors have taken a one-off approach, building independent and non-interoperable solutions. They have tried to address needs by designing and developing "cool" user interfaces, but have not fundamentally captured the people interactions and context, and therefore they have not made much positive impact on the overall end-user experience. Applications that are built independently rarely allow decision makers to collaborate in the process and take appropriate actions. Companies have spent billions of dollars trying to integrate these systems.
- Lack of agility—In an environment in which businesses evolve so rapidly, applications need to adapt to the changes. However, long implementation cycles frequently render the applications obsolete for business users by the time IT departments can deploy updated versions.
- Fragmented offerings—Application vendors tend to hard-code core platform capabilities into solutions. For example, many vendors build workflow capabilities into solutions that have rudimentary analytics hard-coded into the user interface, or they include a hard-coded reporting engine for role-specific reports. Since these key capabilities (collaboration, analytics, portals, and so on) and the applications themselves belong to different levels within the IT infrastructure, these attempts at hard-coded integration fall short.
- User interface integration—Workers need to correlate information from multiple systems in order to make sound business decisions. To address this need, they frequently use manual processes that involve data reentry. There is a new breed of applications called composite applications that try to provide a solution, but only from a user interface integration perspective. User interface aggregation of tasks and screens from multiple applications solves one significant problem: it eliminates the need to jump between applications for business analysis. For instance, with an integrated user interface, a planner no longer needs to look at demand and supply in two separate systems in order to make inventory decisions. This solves a significant problem, but it is not enough. Unless individuals can take actions based on the analysis, this aggregation is of limited value. Information workers need to be able to drive actions collaboratively, while making use of the business context.
To fill the results gap and enable the last mile of productivity, we need a new breed of business applications that are agile and adaptive. These applications are fundamentally different in many ways from the traditional monolithic enterprise programs.
Figure 1. Office Business Applications (Click on the image for a larger picture)
Easy to Use
Information workers need to access business data in order to make decisions and take actions. However, Line of Business (LOB) systems are usually accessible only to relatively few individuals who have painstakingly developed their understanding and learned how to reach the information that they need. Information workers today have no choice but to have these few experts export useful business data from LOB systems into familiar tools such as Microsoft Office Excel, and then share that in a disconnected fashion. Office Business Applications (OBAs) bridge this gap by seamlessly bringing business data into information workers' familiar interfaces. This enables them to analyze the information by using powerful tools that they already know how to use, thereby facilitating more rapid decision making and quicker action. OBAs also push appropriate data back to the LOB systems, in order to maintain data consistency across the enterprise.
OBAs formalize people-centric processes, and tie them back to system-centric processes. They let workers perform a particular task end-to-end, without having to shift context, manually pull data from various data sources, or perform "out of loop" analyses with disparate applications. OBAs provide a role-based interface to information access, analysis, and decision making. Every role in an enterprise has specific tasks to perform. The data that they need, the systems that they use, and the decisions that they make are unique to their roles—a worker on the plant floor needs to carry out a job order, a supervisor needs to be able to assign those jobs, and a planner needs to be able to schedule the jobs and resources. They may all need to access bill of materials (BOM), resource calendars, and material availability data; but individuals need to do so within their own role-based "windows" into the enterprise.
Much of the activity that is needed in order to achieve a business task happens outside of today's enterprise systems. For example, procurement managers who are finalizing sourcing contracts spend a lot of time researching the price, pulling data from various marketplaces into spreadsheets, and analyzing customer demographics. Then, they interact with their preferred suppliers, share forecasts, commit to order splits and pull rates, and finalize the procurement. Most of this activity happens outside of enterprise systems. Only after they have successfully finalized the details do they go to their ERP or purchasing systems, and generate a sourcing contract. By contrast, OBAs are inherently collaborative. The OBA platform allows developers to capture all aspects of a business process within familiar Microsoft Office interfaces. In the present example, the procurement manager can collaborate and make decisions directly from within familiar applications.
Figure 2. Evolution of business applications (Click on the image for a larger picture)
OBAs are self-service, adaptive, and highly customizable by IT developers and end users. Because the collaboration and business rules are not hard-coded into the application, end users have considerable ability to configure the applications to their own needs. Power users can arrange their portals the way that they like, and they can set business rules for certain tasks by using tools that they are already familiar with—usually without writing a single line of code. As business needs change, IT developers can rebuild the components and modify the applications relatively easily and with less code.
OBAs focus on business interactions, analytics, and actions that allow the users to make decisions and take actions in the context of the business problem(s) at hand. These applications do not "re-invent the wheel" for functions such as data access and interactions, workflows, analysis, and reporting, but they do leverage these capabilities from the underlying Office Business Application Platform. This decoupling allows the applications to leverage the power of the Office system for base capabilities, and to provide agile and highly customizable business capabilities.
The Office Business Application Platform forms a basis for designing and developing OBAs. It provides a complete, integrated infrastructure for OBA design, development, deployment, and maintenance.
Figure 3. Office system architecture for Office Business Applications (Click on the image for a larger picture)
Open XML File Formats
Adoption of the Open XML file format across Microsoft Word, Excel, and PowerPoint facilitates rich server-side document manipulation scenarios, and enables developers to include custom data payloads on the client directly within the document. By default, these applications now save in this open file format, the specification of which has been published to OpenXMLDeveloper.org. Furthermore, Microsoft has already released upgrades that enable down-level clients to read the new file formats. By storing the document as XML, Microsoft is facilitating server-side document creation and manipulation, without needing to instantiate the client applications on the server. Server advances, such as document property promotion, workflow, and search are among the many new capabilities that are available to OBAs now that the underlying documents are consumable by server-side processes.
Extensible User Interface
Not only has the Office client user interface (UI) been redesigned for a more effective user experience, but it has been opened up to developers as well. Custom solutions can be integrated into both the ribbon and the new application-level task pane within the client. Organizations and software vendors can seamlessly integrate their solutions within the normal UI framework that users are expecting. This encourages adoption of new solutions, and it facilitates integration of legacy enterprise application data with information worker content.
With the 2007 Microsoft Office system, the line between client and server applications is blurring. Both Excel and Microsoft Office InfoPath can now publish files to server-side services that enable users to interact with spreadsheets and forms by using only a browser. Furthermore, all Office Client documents can now expose their properties to the SharePoint lists in which they are hosted. These properties can be edited either on the client or within the SharePoint list.
Strong Server Platform
Microsoft Windows SharePoint Services provides baseline platform-level functionalities such as integrated workflow support, blogs and wikis, Really Simple Syndication (RSS), and native support for ASP.NET 2.0. Microsoft Office SharePoint Server 2007 extends this functionality, presenting a unified suite of enterprise-scale applications that satisfies diverse business-critical needs—for example, enterprise content management, business intelligence, integrated Excel Services and InfoPath Forms Services, and greatly enhanced search capabilities.
With the release of Excel Services, a user-created spreadsheet can be hosted on a SharePoint Server, and it can then be exposed to clients and applications either through a Web-rendered Web part that is hosted in a SharePoint site, or through an Excel Services Web service query. This enables users to define and host complex calculations for an application within an Excel spreadsheet. In essence, users who have deep knowledge of a business function, but no application programming experience, can contribute directly to the application logic, simply by using the tool that they are most comfortable with—Microsoft Excel.
InfoPath Forms Services
InfoPath Forms Services is a scalable, security enhanced, standards-based form solution that organizations can use to extend the reach of a forms-driven business process to anyone, through a Web browser. Forms can be designed either in the traditional InfoPath rich client or in the new Microsoft Visual Studio editor, for complete control over form functionality, as well as its look and feel.
Enterprise Search in Office SharePoint Server 2007 is a SharePoint Server 2007 shared service that provides extensive and extensible content gathering, indexing, and querying. This service supports full-text searching that uses Structured Query Language (SQL-based) query syntax, and it provides new keyword syntax to support keyword searches.
Microsoft Content Management Server (MCMS) 2002 functionality is now part of SharePoint Server 2007. With this functionality, users can take advantage of comprehensive Web content management features that are available directly from the SharePoint Server platform. Master pages that can define the look and feel of an entire site, as well as page layouts and logos that allow for consistent looking pages, also add standardization and consistency to Web applications and content.
This single content management and collaborative system provided by SharePoint Server 2007 eliminates the need for the separate solutions previously offered by SharePoint Portal Server and MCMS. In SharePoint Server 2007, users can quickly and easily create dynamic, customized, content-centric websites, without having to write custom code.
In addition, new policy-driven document and records management features enable developers to define and deploy policy definitions that map to specific content types across their organizations. Once categorized, content is more easily located and manipulated on a programmatic basis.
Microsoft Office SharePoint Server 2007 expands beyond the traditional portal and dashboard to provide users with interactive business intelligence portals that allow for substantial data manipulation and analysis. Users can create dashboards from multiple data sources, without writing code. Key performance indicators (KPIs) can be defined from Excel Services, SharePoint lists, Analysis Server cubes, and a variety of other sources. Because this data is hosted with SharePoint, it can be an active participant in other SharePoint Services, such as Search or Workflow.
With the integration of Windows Workflow Foundation into Office SharePoint Server 2007, Microsoft has made significant inroads in making the 2007 Microsoft Office system capable of explicitly supporting information worker–centric business processes. Furthermore, either by using custom "out of the box" workflows, or by using SharePoint Designer to create code-free custom workflows, power users can start defining their organizational level workflows. However, with extended support for the Windows Workflow Foundation development model in Visual Studio, enterprise-level developers can design organization-wide workflows that are surfaced at the highest level of Office SharePoint Server. These workflows will contextually drive an organization's business process at any level.
Business Data Catalog
With the new Business Data Catalog (BDC) feature of Office SharePoint Server 2007, organizations can expose read-only data from LOB systems to applications that are running within the portal. Data exposed through the BDC will be available to Web Parts, custom applications, InfoPath Forms Services, and Search. By coupling BDC data with InfoPath Forms Services and search, organizations can build searchable server-side applications that allow users to interact with previously difficult-to-access siloed data within the context of the organization's portal.
Based on Windows Infrastructure
Office SharePoint Server 2007 is built on a strong foundation provided by the Windows Server System. Windows SharePoint Services provides the basic functionality upon which SharePoint Server is based—for example, document libraries, lists, and team sites. Microsoft Internet Information Server (IIS) sits behind SharePoint Services and makes it possible for both applications to take advantage of .NET Framework 2.0 and ASP.NET features, including Web Parts and master pages.
The current development story for Office is strong. With the Open XML file formats, developers can begin to achieve a separation between data and documents. The new application-level task panes allow organizations to surface their own custom logic and processes within the context of Word, PowerPoint, Excel, and Outlook. Information workers can now work with their business processes in the context of their business documents, directly within any Office document.
Even without data integration technologies such as the BDC, organizations can integrate individual Office system applications with enterprise systems. For example, add-ins can be written for almost all Office clients, and Web Parts or custom search providers can be built on SharePoint Server. The challenge is that each add-in or server-side component is responsible for handling its communications with the back-end system. Caching, online/offline detection, and all communication protocols must be dealt with from within each solution.
Figure 4. Custom Code components for an Office system without BDC (Click on the image for a larger picture)
Note that each entity within the solution requires its own custom code in order to connect to back-end systems.
With the Business Data Catalog, some of the burden is removed from developers by exposing LOB data at the portal level. Except for configuring a BDC metadata file for each legacy system to be exposed through the BDC, developers do not need to write a single line of code in order to have this data exposed in Web Parts and Search.
Figure 5. Office system custom components with BDC (Click on the image for a larger picture)
Note that the server-side story has become much more compelling. Once the BDC is configured, Web Parts and Search can automatically consume read-only LOB data. Custom logic must still be used to write data back to legacy systems. Office system clients still need custom code in order to consume data directly from the BDC.
Even with the BDC, there is a good amount of work for enterprise developers, in terms of writing the logic and processes to connect a client-side Office Business Application to the various LOB applications within the organization. Generally, developers will design a Service-Oriented Architecture (SOA) as a middle tier, to translate the more simplistic task-oriented functionality of the LOB applications to the entity-oriented business processes that take place in an information worker's context. Furthermore, after these LOB entities surface within the context of an Office application, they will potentially need to be kept synchronized with the back-end LOB systems. Currently, there are few tools to help developers do these very complex tasks.
Line of Business Interoperability (LOBi) for Office SharePoint Server is a framework designed specifically to integrate an organization's LOB applications with the Microsoft Office system. The LOBi framework will provide mechanisms to allow developers to do the following much more easily:
- Surface LOB content in rich client Office applications
- Drive a consistent LOB-based UI across Office clients
- Provide transactional write-back capabilities from the client to the underlying LOB application
- Allow LOB data and processes to be taken off-line
- Provide context between structured LOB applications and unstructured people-driven processes
To support the development of OBA Services, LOBi facilitates the creation and management of Office Business Entities (OBE). OBEs are the heart of the LOBi framework. They map to both the LOB applications that contain the data and the task-oriented processes that define an entity (for example, a product, account, or customer), and to the client and server aspects of the Microsoft Office system. OBEs will allow developers to create an Office persona for business entities, overcoming the limitations that are imposed by the transactional "systems of record" nature of business applications.
OBEs can be coupled with reusable UI components—Office Business Parts—that will travel across the Office platform with the OBE. Office Business Parts will surface in Office client task panes and special LOBi Web Parts in Office SharePoint Server. Furthermore, the OBA Services client runtime provides a declarative programming model that allows the user experience to be driven by standard Office context events (such as item open), with the experience tailored by parameters such as role and locale.
Figure 6. Office system components with LOBi (Click on the image for a larger picture)
OBEs, with their corresponding Office Business Parts, will significantly reduce the amount of effort needed in order to connect the various client layers of an Office Business Application to a legacy enterprise application. The UI and logic defined in the Office Business Part can be surfaced in any Office client application that supports an application-wide task pane. Furthermore, OBEs can be surfaced directly in the client application, without losing their corresponding entity definitions, thus enabling the integration of strongly typed data and logic within the Office application's surface.
In some respects, LOBi for Office SharePoint Server is similar to the Business Data Catalog, in that both systems are surfacing LOB data within the context of at least one aspect of the Microsoft Office system. Whereas the BDC is primarily focused on surfacing read-only data within SharePoint Server, LOBi provides a framework for developers to surface custom UI and content across both SharePoint Server and the Microsoft Office client applications—for example, Word, Excel, PowerPoint, and Outlook. As part of its server integration strategy, LOBi allows developers to optionally surface their LOBi business entities in the BDC, thus giving them a consistent view of the LOBi-defined business entities across the entire Office system.
A common collaborative planning task within an enterprise is the reconciliation of numbers between Sales and Merchandizing. By using the 2007 Microsoft Office system, a Sales Director and a Merchandise Planner can complete this process more efficiently. They both can use a single underlying Excel document to store the data, and they can use Excel Services to maintain it. In this way, they can have a single definitive version of the data, and the plan can be shared very easily from the server to other persons in the organization.
The document can be stored in a document library in SharePoint. A workflow can be associated with this document library, with custom business logic that is executed whenever the spreadsheet is saved. For example, the workflow could run validation rules on the spreadsheet; apply approval policies to the data; cleanse, validate, or filter the data; or update back-end systems.
You can take the following steps to implement this collaborative planning process with the 2007 Microsoft Office system:
- Build application parts—Use the metadata to create an Excel file that contains the Sales and Merchandise numbers. Partition the numbers into different worksheets, based on the type—for example, a Sales Plan sheet for the sales targets, or a Merchandise Plan sheet for the merchandise numbers.
- Create a team portal—Create a SharePoint portal, and publish the file to Excel Services within the portal. The document will reside within a document library. Excel Services allows multi-level permissions to be applied to the file. For example, users may be allowed to view the file contents in a browser, but they will be unable to open the file in the Excel client. Or, users will be able to see only the numbers in the Excel client, but they will not have access to any of the formulae being used in the document.
- Build custom GUIs—Create personalized sites for the Sales Director & Merchandise Planner within the portal, and provide links to the Excel file on each of the sites. These users will see only those files that they are interested in. Since the file is being hosted within Excel Services, all users receive the same copy of the file.
- Design a workflow—Use .NET Framework 3.0 & Visual Studio 2005 to develop a workflow that takes the contents of the Excel file and saves it to a database. Use the OpenXml libraries (under System.IO.Packaging) that are available in .NET Framework 3.0 to get the Excel data. Because the workflow will be hosted in SharePoint Server, it has access at runtime to the attributes of the file. These include, for example, the stream for the file that has been modified, the user who last modified the file, and the library where the file resides. The workflow could also perform more complex functions, such as creating a SharePoint task for a set of users, or sending users an e-mail message with the details of the task. Alternatively, to support communication across partners, the workflow could also send the data externally to a trading partner. As a final step, create a strong-named assembly containing the workflow, and install it in the local .NET Global Assembly Cache.
- Build an input mechanism—Create an association form using InfoPath. This form will be used to accept user data when the workflow is associated with the document library. Create an initiation form if required. The initiation form could be used to accept user data when the workflow begins. Install the workflow in the SharePoint portal as a feature, and associate it with the document library that contains the Excel file. Configure the workflow in such a way that, whenever any changes are made to the file and saved, the workflow runs.
- Create analytics—At the back end, create a data warehouse that is based on the schema that matches the Excel spreadsheet metadata. Using SQL Server Integration Services, copy data from the database to the data warehouse in a scheduled or on-demand manner. Create an SQL Server Analysis Services cube by using the warehouse. Create a pivot chart in an Excel file, and link it to the cube. Publish the Excel file to Excel Services. Finally, use the Excel Web Renderer Web Part to display the chart to users of the portal. Alternatively, use Business Data Catalog metadata to declare an entity for each row in the database. Use BDC Web Parts to display lists of the entities and enable users to search the database. You can also use the specification to create a parent-child relationship between entities—for example, a Purchase Order can contain line items. Since the metadata is in XML, it does not require users to be aware of any programming language in order to make changes.
Figure 7. Design-time steps to implement the collaborative planning example (Click on the image for a larger picture)
Now that the solution is ready for the users, the Sales Director can use the Sales portal and make any necessary changes to the forecast numbers. As soon as the document is saved, the workflow that updates the back-end systems sends an alert to the Merchandizing Manager on the Merchandizing Manager portal.
Figure 8. Data flow with collaborative planning example (Click on the image for a larger picture)
A reference architecture and sample code for this and other supply chain scenarios will be published soon on the Microsoft Architecture Resource Center. Please stay tuned.
One of the challenges IT faces today is demonstrating the business value of what it does. There is no doubt that IT is integral to an organization's success. In fact, most modern businesses cannot run without all the systems at its disposal. The question of business value, however, goes deeper than simply how efficiently the business is run. Business value is also determined by how IT helps drive the business forward, and how it directly contributes to performance. Be it revenue growth, profit growth, market share growth, or some other metric, organizations are striving for growth in the face of more demanding customers, increasing competition, globalization, new regulatory mandates, and the ever-advancing pace of technology.
There are a lot of business applications in today's environment that run the business. They process invoices, update customer records, track inventory, and do many other things. Over the past few decades, organizations have had significant amounts of money to automate their back offices. They now have systems that are excellent at automating transactions. Few, however, are designed to help the people that really run the business.
There is a huge opportunity to bridge back office systems with the people who can use the information and processes in these legacy enterprise applications, but within the context of their routine work processes. We call this new breed of applications Office Business Applications. These applications bridge the last mile to productivity, and they extend the information assets to the people who need them. Not only do they provide access to information, but they also give workers familiar and powerful tools to act on that information. Connecting the vast mountains of business data in our back office systems with these tools will enable people to access information and act in new ways—and to do it in ways that fundamentally impact and enhance business performance.
By building on the 2007 Microsoft Office system, organizations can deliver LOB data and logic to the people who are responsible for running the business, in the context of their familiar Office applications. OBAs will drive home a higher ROI for the legacy applications by enabling broader access, and they will make process automation a reality to the organizations and people who use them—for just a fraction of what it would cost to deploy these legacy applications more broadly.
We are extremely excited about Office Business Applications. We see OBAs as a way for IT to deliver much more value. In many ways, OBAs will become the mechanism that IT will use to deliver the last mile of value and productivity to its customers, and to capitalize on all its existing IT investments.
The Microsoft Office system has shown consistent progress toward a more customizable application platform where developers and ISVs can create collaboration-oriented solutions that exist within an information worker's native environment. Organizations should invest in developing Office Business Applications on the 2007 Microsoft Office system. Solution providers should develop collaborative, easy-to-use, and highly customizable Office Business Applications by using the 2007 Microsoft Office system. IT departments should start leveraging the client capabilities in the 2007 release—for example, the OpenXML file format and the extensible UI (ribbon and application-level task pane) —to provide in-context application capabilities to users in their familiar Office client experience. In addition, register with Microsoft to be notified when more information about LOBi for Office SharePoint Server becomes available.