Reference Application Pack for Supply Chain Management

Atanu Banerjee
Microsoft Corporation

October 2006

Applies to:
   2007 Microsoft Office System
   Microsoft BizTalk Server 2006
   Microsoft SharePoint Portal Server 2003

Summary: The 2007 Microsoft Office system provides a set of servers, clients, and tools to make it easier for enterprises and software vendors to build and deploy Office Business Applications to connect current line-of-business systems with the people who use them through the familiar Microsoft Office user interface. (20 printed pages)

Contents

Introduction
Bridging the Productivity Gap
Anatomy of an Office Business Application
Building an Office Business Application for Supply Chain Management
Building the OBA Reference Application Pack for Supply Chain Management
Enabling Team Collaboration
Conclusion

Introduction

Enterprises have invested billions of dollars in large, complex, line-of-business (LOB) systems to automate routine, transactional business processes, such as inventory management, invoice processing, payroll, and customer relationship management (CRM). While traditional LOB systems work well for automation of structured processes, these processes represent only a small percentage of what businesses and their employees actually do. From the small business to the global enterprise, business practice involves one-off, unstructured, collaborative interaction and exception-handling that occurs outside of LOB systems and the structured processes they automate. This causes a disconnect between the structured and unstructured worlds of process and practice—which, in turn, creates barriers to decision-making and business insight.

What does this mean for businesses? They need a way to connect the structured, transactional world of LOB applications with the unstructured, collaborative world of people handling exceptions, making decisions, cultivating ideas, and winning customers. They need to be able to extract more from their current investments into back-end applications and systems, in a way that enables new cross-functional business processes.

The 2007 Microsoft Office system will provide a set of servers, clients, and tools to make it easier for enterprises and software vendors to build and deploy a new class of business applications called Office Business Applications (OBAs). OBAs connect current LOB systems with the people that use them through the familiar user interface of Microsoft Office. OBAs enable businesses to extend the Microsoft Office clients and the SharePoint Portal into business processes running in applications such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply Chain Management (SCM). Therefore, OBAs make it possible to create new value from current IT investments into business applications, by combining them in innovative ways.

Microsoft is committed to providing technical resources and guidance on how to build OBAs that provide meaningful business value. As part of that, this document provides details on how to build an OBA. To provide the business context, the OBA described in this paper was developed as a Reference Application Pack for Supply Chain Management, and covers scenarios for collaboration between the different levels of a multi-tier supply chain.

Bridging the Productivity Gap

Globalization, specialization, and outsourcing require people to work in more collaborative ways. This trend requires a matching change in the tools that information workers use to gain insight, collaborate, make decisions, and take action. Today, most business applications today are effective at automating transactions, but do not enable rich collaborations across functional boundaries. This usually leads information workers to use personal productivity tools to perform the complex interactions required to conduct business. However, this leads to a loss in productivity, as users are forced to cross from one set of tools to another. It is this gap between business applications and collaborative interactions through productivity tools that we call "the productivity gap." What information workers need is a way to bridge this gap in a way that is seamless, synchronized, and secure.

Not only is the productivity gap frustrating for employees, but it also has other critical consequences for the enterprise. Consider the following quote from "The Knowledge Worker Investment Paradox", a Gartner, Inc., research note by Regina Casonato and Kathy Harris (July 17, 2002):

In most enterprises, an employee will get 50 percent to 75 percent of their relevant information directly from other people.

More than 80 percent of the enterprise's digitized resources are not accessible to the enterprise as a whole, because they reside in individual hard drives and personal files.

The individual owns the key resource of the knowledge economy—tacit and explicit knowledge—and most of that knowledge is lost when they decide to leave the enterprise.

Ideally, it would be easy to stitch together different business applications and also enable collaboration for information workers, but in a way that complex interactions between people can plug into structured business processes. Unfortunately, though, this has not been easy to do, as today's business applications are usually monolithic and difficult to modularize. There has been a lot of discussion in the industry around composite applications that surface business data and functionality out of back-end business systems into the familiar world of personal productivity tools. The idea is that these kinds of business solutions will be able to capture and support real-world processes, as opposed to structured, transactional, idealized processes.

This certainly is a laudable goal, and there have been a number of industry efforts in this direction. However, there really has not yet been an effective way to enable composition in a way that is contextual, collaborative, easy to use, role-based, and configurable. This paper will show that OBAs are a means to that end, given the ubiquity of Microsoft Office in the business world, and the familiarity of information workers with the easy-to-use interfaces of the Microsoft Office client applications. Customers have already begun to respond to the need for this class of applications by building business solutions on Microsoft Office 2003 and Microsoft SharePoint Portal Server 2003. Given the unique capabilities that are coming in the 2007 Microsoft Office system, this will only get easier to do.

Anatomy of an Office Business Application

Enterprise architectures are usually decomposed into three tiers: presentation, application (or business logic), and data. However, this segmentation disregards the implicit interactions between information workers that are essential to get any business process complete. Therefore, it is critical to add a fourth tier to this, the productivity tier, as shown in Figure 1.

Figure 1. Application architecture tiers in the real world

While at first glance there appears to be a lot of overlap between the productivity tier and the application tier, the two are in fact quite different. Some of the differences in these two tiers are enumerated in Table 1.

Table 1. Differences between the productivity tier and the application tier

Traditional discussions around the architecture of business applications tend to focus on the application tier as being the connection between people and data. Typically, however, the application tier contains structured business logic; and this holds for discussions around Service Oriented Architectures (SOAs), Enterprise Service Buses (ESBs), Service Component Architectures (SCAs), or most other architectural perspectives in the industry today, including first-generation discussions around composite applications. However, building an OBA requires a mindset that not only is the productivity tier a critical element of the stack, but also it is where the most business value to enterprises can be found. To expand on the comparison between OBAs and SOA, both of them target flexibility and modularization. However, SOA provides flexibility at just one tier: that of the structured business logic in the middle tier. OBAs target flexibility at all four tiers: presentation, productivity, application, and data. So, OBAs provide business value to the end users, in a way that goes far beyond what can be achieved with just service orientation. That said, an OBA is a great way to surface information out of a SOA, and having LOB applications exposed as services makes it easier to build support for cross-functional processes into an OBA.

Figure 2 illustrates that an OBA is a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities.

Figure 2. High-level architecture of a composite application

What are the software assets that enable composition? In the past, an enterprise's software assets were usually a set of independent business applications that were monolithic and poorly integrated with each other. However, to get the business benefits of composition, an enterprise must treat its software assets in a more granular manner, and each of the tiers in Figure 1 will provide a set of assets. So, assets can be divided into presentation assets, productivity assets, application assets, and data assets. For example, a Web service might be an application asset, an OLAP cube might be a data asset, and a particular data-entry screen might be a presentation asset.

Now, having an inventory of software assets by itself does not enable the ability to assemble composition applications. This requires a platform with capabilities for composition—that is, a platform that provides the ability to deploy assets separately from each other, and in combination with each other. In other words, these assets must be components, and the platform must provide containers. Because a composite application requires composition in each of the four tiers listed in Figure 1, for each tier the platform needs to provide containers with foundational capabilities, and components that can be deployed into those containers. So, building composite applications requires a solutions architect to:

• Choose a composition stack. Pick one or more containers from each tier, and a set of components types that are deployable into those containers.
• Choose components. Define the repository of assets that must be built from this set of component types, based on business needs.
• Specify the composite application. Define the ways in which those assets will be wired together, to provide a particular cross-functional process.

How OBAs Provide Support for Composition

The 2007 Microsoft Office system is such a platform for building composite applications. The high-level capabilities of this platform are shown in Figure 3.

Figure 3. Capabilities provided by the 2007 Microsoft Office system to serve as an application platform

To understand the potential for composition better, it is useful to decompose the high-level capabilities from Figure 3 and map some of them to the presentation, productivity, application, and data tiers. Because the 2007 Microsoft Office system comes with a very broad range of functionalities, this could result in a very long list. So, Figure 4 shows this decomposition, but only for some of those specific capabilities that were used in the OBA Reference Application Pack for Supply Chain Management.

Figure 4. Capabilities of the 2007 Microsoft Office system application platform, mapped back to the presentation, productivity, application, and data tiers

Composition in the Presentation Tier

The first channel for users to interface with the system is through Microsoft Office documents, which can now more easily surface information and functionality from LOB applications. This is done through custom XML blocks in the Open XML document formats, and by surrounding this data with custom task panes that can present users with data and actions in the context of their current activity.

The second channel for users is through a browser that connects to the SharePoint Portal Server. A portal is composed from sites, a site is composed from pages, and pages are composed from Web parts. So, the platform provides rich composition at the presentation tier, and a Web part is the most basic building block of the portal. SharePoint Portal Server comes with a rich set of Web parts out-of-the-box—for example, to surface Office Excel spreadsheets and charts, and to view lists and tables—but solution providers can also provide their own custom Web parts for application-specific functionality. Information workers can customize the pages that they own, by adding and removing Web parts.

A special kind of page is a dashboard, which is a page that has been assembled from Web parts and provided to users as a template built around a specific business function. So, for example, a business might have standard dashboards for sales, marketing, inventory management, or any other business function. In addition to creating templates for dashboards, you can also create templates for complete sites, for deployment across multiple organizations or customers. So, you can actually deploy a site or a collection of sites as part of an OBA solution. In addition to standard sites, users also get personalized "My Sites" for customization, which they build out by selecting the Web parts made available to them, or they could just pull in links to standard dashboards that are appropriate for their role.

Composition in the Productivity Tier

Information is processed and collaborated upon using a number of services provided by the 2007 Microsoft Office system. For example, storage for in-process documents is available through forms libraries (for InfoPath forms) and document libraries (for other types of documents). Information workers can add libraries themselves, and specify the document templates to be used by those libraries. If Excel spreadsheets are to be stored in document libraries, these libraries can be registered with Excel Services, so that the spreadsheets stored within them can also be consumed using thin, browser views of charts and tables.

The 2007 Microsoft Office system also supports Workflow Foundation. This allows the deployment of workflows into the server that have been developed using Workflow Foundation tools. Users can then choose to associate particular document and form libraries with workflows, and specify the conditions under which these workflows are triggered (for example, a document in a given library might have been modified or created). These workflows could provide business process (document routing) or document lifecycle management (document approval and expiration).

Finally, the productivity tier also comes with a lightweight way to create and publish reports. Information workers can choose to supply metrics for these reports in four ways:

• SharePoint lists (for example, connected to a data store by way of the Business Data Catalog)
• A spreadsheet that has been published by way of Excel Services
• Manual entry
• By selecting from an OLAP cube built in Microsoft SQL Server 2005 Analysis Services

Having chosen the metrics, the information worker must choose an appropriate Web part to display the report (for example, an Office Excel or Business Scorecard Manager Web part); select an appropriate set of filters to parameterize the report; and then select (or create) a dashboard to host the Web part.

Composition in the Application Tier

The 2007 Microsoft Office system can be plugged seamlessly into a services-oriented architecture. If the enterprise has a services backbone already under development, these interfaces can be consumed from the 2007 Microsoft Office system. This can be done in a couple of ways. The first is by invoking Web service interfaces in activities that have been built into workflows deployed into the productivity tier. The second is through the Business Data Catalog (BDC), which is described in the next section.

Another way to build applications directly into the 2007 Microsoft Office system is to use Excel Services. This is a server-side Office Excel calculation engine that is built into SharePoint Server. It provides browser access to live, interactive spreadsheets that are deployed on the server, and also Web service access to server-side Office Excel calculations. Most enterprises will have information workers who are subject-matter experts in a particular domain, as well as experts in developing Office Excel spreadsheets. With Excel Services, these people now have the ability to provide server-side application logic in a way that is familiar to them.

Composition in the Data Tier

The 2007 Microsoft Office system also comes with a Business Data Catalog (BDC). This acts as a metadata repository for descriptions of business-data entities and their attributes, and for mappings of these entities back to data stores within the enterprise. While the BDC cannot be used to create an entity that maps across multiple data stores, it is possible to define relationships that link entities—for example, parent-child relationships. So, the BDC can be used to create lightweight linkages between data entities across the enterprise—almost like an enterprise thesaurus. Actions that can be taken on an entity can also be defined within the BDC, and these become available by way of a drop-down menu on a SharePoint list. These actions can then be tied back to a URL that might correspond either to a Web service or a document such as an InfoPath form, as these can be hosted on the server. The BDC would make sure that the correct context is passed along to this URL, and if this link corresponds to a Microsoft Office document with an appropriate code-behind, that document can be pre-populated from the context that gets passed in from the BDC. Information workers can then use the portal to create tables and lists that surface BDC data and actions.

Based on this, Table 2 provides a list of potential enterprise software assets that are deployable as components into the platform, as a basis for composition. This is a fractal model in some sense, and so there might be composition within these assets, too. For example, software assets might include Web services, but those services are likely to contain workflows, activities, business rules, and authorizations (claims) of their own.

Table 2. List of application assets for composition

Building an Office Business Application for Supply Chain Management

To help businesses and solution providers build composite applications on the 2007 Microsoft Office system, Microsoft provides a reference solution and a reference implementation of an OBA for Supply Chain Management. This OBA comes with scenarios for collaboration between different levels of a multi-tier supply chain, starting with a retailer and extending back through a manufacturer to a tier-1 supplier. This supply chain is illustrated in Figure 5.

Figure 5. Supply chain used for scenarios in the Reference Application Pack (Click on the image for a larger picture)

This reference solution shows how to leverage the capabilities of the platform, to build a repository of assets that allow composition at multiple levels: presentation tier, productivity tier, application tier, and data tier. The reference solution shows how to wire together individual assets, to bring together structured and unstructured business processes. The scenarios chosen illustrate collaboration between trading partners, for both planning and operational needs. To accelerate solution development and enable interoperability with other business solutions, this reference application also shows how to leverage existing industry-standard schemas, including RosettaNet, for collaboration to build up the repository of assets, as well as how to leverage other enterprise assets, such as an SOA backbone.

Description of Application Pack Scenarios

Close collaboration with customers, suppliers, and partners has become essential for companies to be successful in the marketplace. The importance of this was highlighted in a comment made by Robert Handfield in Optimize (December 2002): "…the future won't be about companies competing against each other, but about supply chains competing against other supply chains." Typically, companies collaborate with their suppliers, so that procurement transactions can be automated and timely information can be shared without too much manual intervention.

The goal is to make the supplier collaboration process agile, adaptable, and aligned, as pointed out by Professor Hau Lee in "The Triple-A Supply Chain," from the Harvard Business Review (October 2004). This will help reduce costs and inefficiencies, while ensuring a high level of service from suppliers. To achieve this, the right information must be shared at the right time, which means that the information flows shown in Figure 5 are just as important as the material flows. The OBA Reference Application Pack for SCM enables these information flows.

This kind of application is mission-critical. Business processes must be aligned across trading partners, for operational efficiencies. However, if the business processes between the partners are too tightly coupled, the overall system will not be adaptable, and will lack the flexibility to respond to changes in the business. Finally, the supply chain needs to be agile, to be able to respond quickly to changing market conditions. The business applications that enable the information flows must provide agility, adaptability, and alignment—just like the physical supply chain does for material flows. If this is not the case, the organization might experience a variety of different problems, such as excess costs and lead times, reduced margins, and excess or inadequate inventory. In the extreme case, failures in supply-chain management systems can lead to the types of catastrophic business losses that have happened in a number of well-publicized cases over the past few years.

An overview of trading-partner collaboration is shown in Figure 6. This shows the documents that are exchanged between trading partners, and the business processes that make use of these documents. Some of these documents and workflows are operational (such as for purchase orders, invoices, and goods receipts), while others are more long-term (such as demand forecasts and supply commitments). Still others are very strategic (such as agreements on hub placement, and for contracts and service level agreements). While Figure 6 shows the mechanics of how supply-chain collaboration occurs, it would be a mistake to think of this as a purely transactional process. Documents are frequently exchanged a number of times until both sides agree, and building consensus might require several iterations. When exceptions occur (and they will), it might be necessary to escalate documents outside of traditional routing lanes. All of this requires complex interactions on the part of information workers—a lot more complex than routine transactions, such as order entry.

Figure 6. Functional overview of supplier collaboration (Click on the image for a larger picture)

For the purposes of this Reference Application Pack, the OBA provides support for two kinds of documents—purchase orders and demand forecasts—although it would be relatively straightforward to duplicate this for the other kinds of documents and processes in Figure 6.

While discussing collaboration scenarios, it should be noted that collaboration is always between people and never between organizations. Therefore, Figure 5 will be an incomplete description of the scenario, without considering the different roles involved in this scenario. This is shown in Figure 7.

Figure 7. Different roles to be considered in the scenario

Analyzing the Business Needs for This OBA

It needs to be understood that there will be an OBA developed for each trading partner in the supply chain, as there is no omniscient arbitrator who owns the end-to-end business process. Instead, there is a composite application to be built and deployed for each organization. For purposes of this discussion, these will be referred to as the retailer OBA and the manufacturer OBA.

Now, the traditional way to start discussing collaboration scenarios, such as the one shown in Figure 6, is to start discussing message schemas and wire protocols. However, for an OBA, instead of starting at the edge of the enterprise, it is better to analyze business needs starting with the information workers, and then moving out towards the edge.

First of all, the signals in Figure 6 can be represented by actual documents that are processed by information workers. For example, a purchase-order request is just a form that has been filled out by the inventory analyst in the retail organization and that needs confirmation from the product planner in the manufacturing organization. Until the purchase order has been confirmed, the request is "in-process" and awaiting resolution.

On the other hand, a strategic forecast is multidimensional data, such as demand signals projected over the dimensions product, location, and time. While the scope of this data can be quite large, the scope of data that an information worker will process at any given moment is much smaller (for example, the set of products and locations that the production planner is responsible for, for a particular planning horizon), and this can be represented in a spreadsheet.

It might appear at first that a purchase order or a strategic forecast represents structured data and can be processed in a structured business process, just as in a traditional transactional application. However, this is frequently not the case. Often, these documents are exchanged between information workers over a number of different iterations, as changes keep being made to the document on both sides. Therefore, the composite applications must accommodate collaborative flows of documents potentially multiple times, and potentially between multiple people in both organizations.

A good way to ensure this is to provide:

• Information workers with applications that are people-friendly and not system-friendly. This means that the applications should be document-centric, instead of transaction-centric.
• Storage locations to hold in-process documents. Note that separate locations must be established within both the retailer and the manufacturer organizations.
• A way for multiple stakeholders to have access to these documents, and for the document to be published only when it is complete.
• A way to apply approval processes, if necessary, to manage the flow of these documents until they are completed. Typically, the flow of documents will be local to a particular team or department, until publication criteria are met.

As soon as the composite application meets these requirements, there needs to be a way to transfer these documents from an information worker's workspace to a counterpart's workspace in the trading-partner organization. One way to do this might be to e-mail the document, but this suffers from a number of weaknesses:

• The message within the document is not secure, and not guaranteed to be delivered.
• There are no service-level agreements around e-mail, or response to e-mail.
• It establishes a point-to-point connection that is inflexible. It precludes system processing of the message prior to it being sent out—for example, for cleansing, transformation, or to apply corporate policies. It makes it harder to change endpoints, if needed (such as if the supplier changes).

However despite this, sending documents by e-mail in this manner has two great strengths:

• It is easy to do. The information worker does not have to master any new tool.
• It does not require the system on the other end to be ready and listening for a message. In other words, it is asynchronous.

Therefore, the OBA for SCM must provide a way to connect information workers across organizational boundaries that does not suffer the weaknesses of e-mail, but still provides an easy-to-use transport mechanism that is asynchronous.

The next business need that must be satisfied by this solution is the ability to tie back into LOB systems. Although information workers are able to collaborate around documents, and a storage location for in-process documents is being provided, the system of record for supply-chain data will be either a business application (such as an ERP system) or a database. Therefore, the collaborative solution being provided through this OBA must be able to update these back-end systems whenever any in-process document is changed—and this must be seamless to the user.

The final requirement on this solution is providing decision support to information workers in the context of these collaborative workflows. Business users must be able to make decisions (for example, whether to accept a purchase order or a strategic forecast from a trading partner); also, at the moment of making that decision, they must be able to check other data (such as whether inventory is available to satisfy a request).

Building the OBA Reference Application Pack for Supply Chain Management

To satisfy the business needs for the OBA, the following development processes should be adopted.

Build a Process Pack

Build a process pack by following each of these steps in order.

Enable team collaboration around semi-structured documents and practices:

1. Build client applications around Microsoft Office documents.
2. Build SharePoint sites to host in-process documents.

Connect to structured LOB applications and business processes:

1. Wire together sites and applications using workflow.
2. Connect to applications using a services backbone.
3. Add data connections for cross-functional processes.
4. Connect business processes to systems at "the edge."

Enable business insight:

1. Add decision support through analysis services.
2. Add metrics, reports, and dashboards.

Package process pack for distribution:

• Export metadata.

Deploy process pack to production systems:

1. Import metadata.
2. Configure connections to data and application tiers.

Enabling Team Collaboration

One of the requirements on the solution was to provide information workers with applications that are people-friendly, and not system-friendly. This means that the applications should be document-centric, instead of transaction-centric.

Build Client Applications Around Microsoft Office Documents

A fairly straightforward way to achieve this is to build the front-end applications in the Microsoft Office client. For example, this can be done with:

• InfoPath forms.
  • Purchase-order requests and confirmations
• Office Excel spreadsheets.
  • Forecasts and response to forecasts
• Office Outlook.
  • Receive notifications of exception conditions
  • Support for purchase-order management using a custom task pane

For each kind of document, there must be a way to extract the contents of the document as structured data for further processing. Therefore, the document must serve as a container for this structured data, but in a way that it can be easily manipulated and extended with other data that might be unstructured. One way to do this is to bind XML schemas for each of the different message types to the document that contains it. There are industry standards that provide schemas for each of the different message types that are exchanged; for this OBA, schemas from the RosettaNet standards body were used.

For an InfoPath form, binding the document to the schema is trivial, as the design tool supports this out-of-the-box. For Office Excel, there is a variety of different ways of achieving this based on the underlying Open XML representation of the spreadsheet—for example, as a custom XML block, or through an XSLT transform from Open XML to the RosettaNet schema and back.

To build support for PO management within Office Outlook, it is necessary to create an Office Outlook add-in project in VSTO, creating a custom ribbon and a custom task pane. In the OBA for SCM, the custom task pane hosts a browser control that pulls data from a SharePoint Web part for PO management—which, in turn, is connected to the back-end data source using the BDC.

Build SharePoint Sites to Host In-Process Documents

SharePoint sites must be set up at the department level to enable team collaboration. These sites will have document libraries and form libraries to store in-process documents. Clicking on a form will cause it to be opened as a thin view within the browser. Clicking on a spreadsheet will allow authorized users to edit it, whereas others can see a thin view of charts and named ranges within the browser, through Excel Services. It is also possible for information workers to extend a site by selecting from a collection of Web parts, and for solution providers to deliver custom Web parts for users to extend their solution.

Figure 8. Departmental portals for team collaboration, with folders for shared documents and tasks

Connect to Structured LOB Applications and Business Processes

As shown in Figure 9, business-process models coordinate activities both within a team and across departments.

Figure 9. Business-process models coordinating activities within a team, as well as across departments

Wire Together Sites and Applications Using Workflow

In-process documents are being stored in document libraries in SharePoint. Individual workflows have also been deployed to SharePoint, and then associated with each document library; these get invoked whenever a document is created, or edited and saved back. For example, a workflow could run validation rules on the spreadsheet; apply approval policies and actions to the data; cleanse, validate, or filter the data contained within; or update back-end systems.

In the OBA for SCM, the workflows running in SharePoint extract information from forms and spreadsheets as XML data, and then process this data by updating LOB systems (for example, a database by way of Web services), before submitting data to the next role in the process.

Although not shown in the OBA, in-process documents undergo a lifecycle of their own, from authoring and collaboration through management and publication to archiving or destruction. Whenever a document reaches one of these stages, a new workflow can be set to be triggered, such as an expiration workflow when a document expires to manage the archiving process.

Note in Figure 9 that business process workflows can be located centrally in the data center, or close to the information user in departmental servers. For example, long-running workflows running centrally might be running on Microsoft BizTalk Server, to enable the flow of documents and messages between departments. For the Reference Application Pack, however, these central workflows were implemented as WF state machines running as Web services for the sake of simplicity, employing an event-driven architecture.

Connect to Line-of-Business Applications

Service orientation is one of the ways to expose current business applications into an OBA, in order to extract more value, by extending and evolving existing systems.

Figure 10. Connecting the OBA to a services backbone

In that sense, SOA promotes modularization in the application tier—which is a basic requirement for composition, and which is why OBAs and SOA are complementary solutions. This allows the assembly of new cross-functional business applications that extend beyond the boundaries of what the current applications were designed to do.

A point to note is that while SOA is a good way to connect line-of-business (LOB) applications into an OBA by way of modular interfaces, it is not the only way. It is easy to plug calls to Web services from business-process orchestrations and workflows, but a services backbone can also be exposed using other integration technologies, such as custom adapters.

In the OBA for SCM, very basic implementations for a couple of Web services for order promising and demand management have been provided. The interfaces for these services use data contracts based on XML schemas taken from the RosettaNet industry standard.

Add Data Connections for Cross-Functional Processes

The BDC runs within a SharePoint server as a shared service. It can read data from multiple types of data sources—databases, analysis services cubes, and Web services—and then surface this back into the portal through SharePoint tables and lists.

The BDC does not directly support write-back. However, you can specify actions that can be taken on a data entity. For each action, you can provide a URL to invoke, as well as a set of attributes from the entity to pass in as context. The URL might be a Web service, or a link to a document with code-behind written using VSTO.

In the OBA for SCM, the BDC is used to surface lists of supplier orders. Clicking on any particular order brings up the line items for that order using a separate SharePoint list, because a linkage has been defined in the BDC between the header and the line items that belong to it. An action has been added at the line-item level, and clicking on this action will pass-in certain context into an InfoPath form, to bring up the line-item details. This form has code-behind to pre-populate fields in the document based on the context being passed in. It is clear that some reasonably powerful set of composite applications can be built using a combination of BDC, SharePoint lists, and workflow, as shown in Figure 11.

Figure 11. Adding data connections for cross-functional processes

Connect Business Processes to Systems at "the Edge"

As mentioned previously, the OBA needs to provide a way to transfer documents from one information-worker's workspace to that of a counterpart in the trading-partner organization. This needs to be done in a way that is secure, reliable, asynchronous, and transparent to information workers.

Figure 12. Connecting the OBA to systems at "the edge" (Click on the image for a larger picture)

One way to do this is shown in Figure 12. Message brokers have been set up at the edge of the organization to send and receive messages and documents from trading partners. Messages from different trading partners can potentially be received in multiple message formats and delivered over multiple channels, such as Web services, EDI, e-mail, RosettaNet, and so on. Furthermore, messages can be exchanged in a variety of different patterns—one-way, asynchronous two-way, or synchronous two-way messaging. These message brokers must handle each combination of these message-interchange patterns and message formats.

After the message is received by the message broker, it is processed, and a transformed message is persisted to a message queue. At this point, an acknowledgment message can be returned to the sender—which is an acknowledgement of receipt, instead of a response to the inbound request from the trading partner. This enables loose-coupling between the message sender and the message receiver, and promotes adaptability in the architecture, as well as capability for load-balancing. Note also that the message persisted in the message queue will be in the single canonical format that is required for downstream services; it need not be in the same format as the message originally received by the broker.

Documents must be routed from their message queues to the appropriate person who will be handling that document. Before the document reaches its intended recipient, it might have to be preprocessed to get to a form that the end user can use to make a quick decision. For example, a purchase-order request from the retailer will be fed into an order-promising service to auto-generate confirmations, with promise dates and quantities pre-populated based on available inventory/ATP. These confirmations will be used to generate XML documents corresponding to an InfoPath form that contains the PO Confirmation, and it is this generated document that will be placed into the SharePoint forms library for the information worker to review. After the information worker has reviewed the proposed confirmation and made any changes, the form is submitted. This kicks off the workflow for the return trip, which updates LOB systems (database through Web services interface) and then posts the message into the queue for outbound messages. This message then has to be delivered to the trading partner as a response to the original request. This task must be handled by the message broker again, as outbound messages must be converted from canonical formats into the formats used by each of the different trading partners.

The message brokers also provide a second function. Business rules can be applied to the incoming and outgoing messages, to ensure validity of the message and enforce any corporate policies. For example, if an incoming message from a trading partner is incomplete, there is no point in surfacing this into a document that goes before an information worker. The message broker should send back a response indicating that the message could not be processed. Applying business rules at this stage allows the enterprise to create a central repository of policies to be enforced at the edge, instead of having this done across a multitude of LOB systems.

There are multiple ways to implement the message brokers at the edge, but the best way to do this would be to use BizTalk Server. In the Reference Application Pack, however, these message brokers were implemented using WF workflows running within Web services. The queues that decouple internal and external processes have been implemented using Microsoft SQL Service Broker 2005. Using BizTalk Server would be more scalable and would allow the use of standard-based accelerators and adapters, such as the RosettaNet accelerator. BizTalk Server also would provide support for Business Activity Monitoring and Trading Partner Management.

Enable Business Insight

The OBA must provide decision support to information workers in the context of the workflows in which they are participating. Business users must be able to make decisions (for example, whether to accept a purchase order or a strategic forecast from a trading partner); and, at the moment of making that decision, they must be able to check other data (for example, whether inventory is available to satisfy a request).

The OBA for SCM provides data for decision support through a set of SQL Analysis Services OLAP cubes for tasks such as order fulfillment, production schedule, and inventory plans. These cubes are built off of a set of star schema tables (dimension tables plus fact tables) that get populated from the SQL database by a set of Integration Services packages. Then, this data for decision support gets surfaced through various channels, including Office Excel spreadsheets and Web parts, a Business Scorecard Manager (BSM) report, and SharePoint lists.

Conclusion

The 2007 Microsoft Office system provides a powerful set of capabilities to build composite applications. Composition is enabled at the presentation, productivity, application, and data tiers. This enables cross-functional solutions that offer a composite user interface that exposes business functions and capabilities across a heterogeneous set of back-end IT assets. These solutions also provide collaborative business capabilities that fill the white space between traditional business applications and personal productivity tools.

These kinds of composite solutions are called Office Business Applications (OBAs). The purpose of this document was to provide details on how to build an OBA; and, to provide business context, the OBA described here was developed as a Reference Application Pack for Supply Chain Management, which is available for download on this page. This reference application covered a variety of collaboration scenarios between the different levels of a multi-tier supply chain.