Building Office Business ApplicationsA new breed of business applications built on the 2007 Microsoft Office system

This document supports a preliminary release of a software product that may be changed substantially prior to its final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.© 2006 Microsoft Corporation. All rights reserved.

Building Office Business Applications June 2006

Microsoft, MS-DOS, Windows, Windows NT, Windows Server, ActiveX, Excel, FrontPage, InfoPath, IntelliSense, JScript, OneNote, Outlook, PivotChart, PivotTable, PowerPoint, SharePoint, ShapeSheet, Visual Basic, Visual C++, Visual C#, Visual Studio, Visual Web Developer, Visio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.All other trademarks are property of their respective owners.

© 2006 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.

To comment on this paper or request more documentation on these developer features, contact us at O12Devdx@microsoft.com. We look forward to hearing from you.

Building Office Business ApplicationsA new breed of business applications built on the 2007 Microsoft Office systemJaved SikanderMicrosoft Corporation June 2006 Summary: This white paper introduces Office Business Applications (OBA), a new breed of easily customizable solutions that address real-world business problems through the 2007 Microsoft® Office system. OBA delivers people-centric, collaborative solutions to the enterprise through familiar Microsoft Office servers, clients and tools. This document discusses today’s business environment and identifies a “Results Gap” that contributes to reduced productivity and shows that OBA is 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 OBA. 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 final product names, such as the next release of Microsoft Office products, currently code-named Microsoft Office "12” and feature names, included in quotation marks throughout this paper, are not yet released or finalized. The application names used in this article refer to the next versions of the products, unless otherwise specified.

ContentsToday’s Environment 1

The Results Gap 1

Enabling the Last Mile of Productivity 1

Challenges on the Last Mile 2

Office Business Applications 3Easy To Use 3

Role-Based 4

Collaborative 4

Configurable 5

Contextual 5

The 2007 Microsoft Office system 6Open XML File Formats 6

Extensible UI 7

Client/Server Integration 7

Strong Server Platform 7

Excel Services 7

InfoPath Forms Services 8

Search 8

Content Management 8

Business Intelligence 9

Workflow 9

Business Data Catalog 9

Based Upon Windows Infrastructure 9

LOBi for Office SharePoint Server extends the Microsoft Office system 10Office Business Application Example: Collaborative Planning 13Conclusion 16Call to Action 17

Page 4

Today’s Environment

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 IT departments to drive business performance through continuous process innovations and rapid technology adoption.

The Results Gap

Companies rely heavily on information technology (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). Yet, many organizations have not realized the expected value from these investments. There is a clear gap between the efficiency and productivity increases 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 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, 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 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 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 the level of productivity people experience with these powerful tools in the business world to the enterprise application 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, thereby 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 include a hard-coded reporting engine for role-specific reports. Since these key capabilities (Collaboration, Analytics, Portals, etc.) 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 to make sound business decisions. They frequently use manual processes that involve data reentry to address this need. 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 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.

Office Business Applications 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

Easy To Use

Information workers need to access business data to make decisions and take actions. However, LOB systems are usually accessible to only a relatively few individuals who have painstakingly developed their understanding and have learned how to reach the information they need. Information workers today have no choice but to have these few experts export useful business data from LOB systems into familiar tools like Microsoft® Office Excel® and share that in a disconnected fashion. OBA bridges this gap by seamlessly bringing business data into information workers’ familiar interfaces. This enables them to analyze the information by using powerful tools 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 to maintain data consistency across the enterprise.

Easy to useRole-basedCollaborativeConfigurableContextual

Human Resources

Product Design

FinancialsSales and Operations

Customer Relations

2007 Office system

LOB Applications, Data Warehouses, trading partner systems etc

Role-Based

OBA 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, pull data from various data sources manually, 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 they need, the systems they use, and the decisions 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.

Collaborative

Much of the activity that is needed to achieve a business task happens outside of today’s enterprise systems. For example, a procurement manager who is finalizing sourcing contracts spends 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 then finalize the procurement. Most of this activity happens outside 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, OBA 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

Configurable

OBA 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 they like, and 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.

Contextual

OBA focus on business interactions, analytics and actions to 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 like data access and interactions, workflows, analysis and reporting, but they do leverage these capabilities from the underlying Office Business Platform. This decoupling allows for the applications to leverage the power of the Office system for base capabilities and to provide agile and highly customizable business capabilities.

Office Business Applications A new breed of business solutions built on 2007 Office system

2007 Office SharePoint Server

2007 Office system Clients

Tools

U

sers, Designe

rs, Professi

onal Develo

persContent ManagementCommunication and

CollaborationBusiness Intelligence

Search

Workflow and Process

Business Data Connectivity

Website and Security Framework

Open XML file format Extensible UI

Duet ISV Office Applications

MS Dynamics Applications

SI Office Applications

Customer IT Applications

Office Business Applications

Microsoft Office system

LOB Applications, Data Warehouses, trading partner systems, etc.

The 2007 Microsoft Office System

The Office Business Application Platform forms a basis for designing and developing OBA. It provides a complete, integrated infrastructure for OBA design, development, deployment and maintenance.

Figure 3: Office system Architecture for Office Business Applications

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. These applications now save by default 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 OBA now that the underlying documents are consumable by server-side processes.

Extensible UI

Not only has the Office client user interface (UI) been redesigned for a more effective user experience, it has been opened up to developers as well. Custom solutions can be integrated both into 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 facilitates integration of legacy enterprise application data with information worker content.

Client/Server Integration

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 either edited 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 & 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, such as enterprise content management, business intelligence, integrated Excel Services and InfoPath Forms Services as well as greatly enhanced search capabilities.

Excel Services

With the release of Excel Services, a user-created spreadsheet can be hosted on a SharePoint Server and exposed to clients and applications either through a Web-rendered Web part 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 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 in the traditional InfoPath rich client or in the new Microsoft® Visual Studio® editor for complete control over form functionality as well as look and feel.

Search

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 provides new keyword syntax to support keyword searches.

Content Management

Microsoft Content Management Server 2002 (MCMS) 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 Web sites without having to write custom code.

Additionally, new policy driven document and records management features enables 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.

Business Intelligence

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.

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, by using either 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 Line of Business systems to applications 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 Upon Windows Infrastructure

Office SharePoint Server 2007 is built upon a strong foundation provided by the Windows Server® System. Windows SharePoint Services provides the basic functionality upon which SharePoint Server is based, such as 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.

LOBi for Office SharePoint Server extends the Microsoft Office SystemThe 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 like 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 Office system without BDC

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 line-of-business 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 to have this data exposed in Web parts and Search.

Figure 5: Office system custom components with BDC

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 to consume data directly from the BDC.

Even with the BDC, there is a good amount of work for enterprise developer 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 line-of-business entities surface within the context of an Office application, they will potentially need to be kept synchronized with the back-end line of business 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 line of business 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 line of business application

Allow line of business 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 (such as product, account, and 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

OBEs, with their corresponding Office Business Parts, will significantly reduce the amount of effort needed 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, Office Business Entities can be surfaced directly in the client application without losing their corresponding entity definitions, 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 such as 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, giving them a consistent view of the LOBi defined business entities across the entire Office system.

Office Business Application Example: Collaborative PlanningA 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 use Excel Services to maintain it. This way, they can have a single definitive version of the data, and the plan can be shared from the server to other persons in the organization very easily.

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:

1. Build Application Parts: Create an Excel file that contains the Sales and Merchandise numbers by using the metadata. Partition the numbers into different Worksheets based upon the type–for example, a Sales Plan sheet for the sales targets or a Merchandise Plan sheet for the merchandise numbers.

2. Create 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 will not have access to any of the formulae being used in the document.

3. 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 only see those files they are interested in. Since the file is being hosted within Excel Services, all users receive the same copy of the file.

4. Design 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 which has been modified, the user who last modified the file, or the library where the file resides. The workflow could also perform more complex functions like creating a SharePoint task for a set of users or sending an e-mail message to the users 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.

5. Build 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 such that, whenever any changes are made to the file and saved, the workflow runs.

6. 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 (BDC) 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—a Purchase Order can contain line items, for example. Since the metadata is in XML, it does not require users to be aware of any programming language to make changes.

Figure 7: Design-time steps to implement collaborative planning example

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 backend systems sends an alert to the merchandizing manager on the merchandizing manager portal.

Figure 8: Data flow with collaborative planning example

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.

ConclusionOne 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 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. Organizations have had significant amounts of money to automate their back offices over the past few decades. 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 extend the information assets to the people who need them. Not only do they provide access to information, 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 Line of Business data and logic to the people who are responsible for running the business in the context of their familiar Office applications. OBA will drive home a higher ROI for the legacy applications by enabling broader access, and 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 OBA as a way for IT to deliver much more value. In many ways, OBA will become the mechanism IT will use to deliver the last mile of value and productivity to its customers and to capitalize on all its existing IT investments.

Call to ActionThe 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, such as 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. Additionally, register with Microsoft to be notified when more information on LOBi for Office SharePoint Server becomes available.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering this document or the subject matter included in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2006 Microsoft Corporation. All rights reserved.