Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Information Is Your Business
   Information Is Your Business Advanced Search
advertisement

RESOURCE PORTALS
Business Intelligence
Compliance
Corporate Performance Management
Data Integration
Data Quality
Data Warehousing Basics
ETL
Master Data Management
View all Portals

WEB SEMINARS
Scheduled Events

RESEARCH VAULT
White Paper Library
Research Papers

CAREERZONE

Advertisement

INFORMATION CENTER
DM Review Home
Newsletters
Current Magazine Issue
Magazine Archives
DM Review Extended Edition
Online Columnists
Ask the Experts
Industry News
Search DM Review

GENERAL RESOURCES
Tech Evaluation Center:
Evaluate IT solutions
Bookstore
Buyer's Guide
Glossary
Industry Events Calendar
Software Demo Lab
Vendor Listings

DM REVIEW
About Us
Press Releases
Awards
Advertising/Media Kit
Reprints
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Cross-Enterprise BI

  Article published in DM Direct Newsletter
February 9, 2007 Issue
 
  By Robert Blasum

Business intelligence (BI) is today tightly integrated into the performance management of many corporations. But corporate-wide BI is not enough for those companies that want to improve performance in a network of multiple enterprises. How to execute cross-enterprise reporting without compromising proprietary data remains one of the big challenges for the future of BI.

Currently, most companies rely on an enterprise data warehouse (EDW) to provide the data for their corporate-wide BI. An EDW is designed to represent a single source of truth within the enterprise. It provides business-critical information to the individual departments of an organization (such as finance, operations, customer service, etc.) and combines the data - and thus the knowledge - of each of these departments.

While such an EDW helps an individual organization to analyze its own data, a new trend is evolving: in order to keep their competitive edge, corporations share more and more of their data with each other. In environments where multiple enterprises work together, it is no longer sufficient for the respective partners to improve their own processes; the overall process of all partners needs to be improved in order to stay ahead of the competition.

The main drivers of this new development are supply chains. With goods being produced by a manufacturer, transported by a logistics provider and sold by a retailer, it is not good enough for each party to improve their own businesses. Instead, they need to improve the whole supply chain in order to maximize the gains that the business partners make together.

The challenge remains how to share operational or financial data among the partners of a business network in a way that enables cross-enterprise reporting. To make this cross-enterprise BI work, companies must be able to employ scorecards, dashboards and all other components of their BI-toolset across enterprises. For this, they need to:

  1. Get access to the detailed operational data of the involved business partners. To achieve the same in-depth analysis as with traditional BI tools, sharing aggregated summary reports is not enough. Instead, atomic operational data, provided by RFID transactions, for example, needs to be exchanged.
  2. Ensure that only disclosable information is shared among the partners. Each business partner must have full control over his or her own data.

At present, there seem to be three imaginable ways to achieve these targets.

Data Extracts

One possibility is to share data by providing data extracts to all respective partners. This is the most common strategy currently pursued by businesses with interest in cross-enterprise BI, e.g., some of the leading retailers enable their partners to see their inventory data online. One advantage of this method is that it is comparatively easy to develop - at least at first. Most businesses can agree on providing data extracts to other companies because they have full control over what they send out to their business partners.

Another advantage is that once a company receives the data extract from one of its partners, it can upload the data into its EDW and treat it in the same way as the company's own data. This means that all the BI tools and mechanisms developed in the past can be easily adapted to work on cross-enterprise data.

However, there are numerous problems with this approach. Data needs to be replicated and distributed among all partners. This automatically introduces latency, which might or might not be in an acceptable range. Furthermore, the exchanged and replicated data will be stored multiple times, namely in each of the partners' data warehouses (DW). If one looks at the overall, cross-enterprise network, this approach introduces redundancy that might render the network-related DW costs suboptimal when compared to business networks working with solutions that are not intrinsically relying on this form of data multiplication.

The real headache with this approach, however, stems from the synchronization of information among the partners of the business network. As each partner wants to remain the business owner of its own data, all data corrections or updates need to be propagated to all concerned partners. This data distribution needs to be fast enough so that potential customers do not get deviating or contradicting information from individual partners of the network. The single source of truth that many enterprises struggled to achieve during the recent years, does not exist in such an environment. Every enterprise has its individual version of the truth.

While it is theoretically possible to design the system to guarantee a consistent version of the truth, the situation becomes increasingly complicated with more network partners and derived data coming into play. In a true cross-enterprise BI environment, data will be shared with the other business partners, who derive further information, share this information once again and so on.

Imagine a minimal network of business partners A and B. The data from A receives an update. A will then provide the data update to B. But the information exchange does not stop here. B derived data based on the data from A. Therefore, with the new data from A, B has to recalculate its own derived data that is dependent on A's data and share the new derived data with the other partners in the network. In this example, the data is only shared with A. The new derived information from B might then in turn lead to a necessity for A to update its derived data and to share that with B again, and so on. With just two partners in the network, this is somewhat manageable, but with more partners coming into play, this scenario quickly becomes extremely complex.

SOA Clients

An alternative to the exchange of data extracts is for clients to provide data in a service-oriented architecture (SOA), possibly peer to peer, with a BI environment that implements cross-enterprise scorecards and dashboards. by directly addressing the respective internal BI environments of each individual enterprise via SOA has the main characteristic that data is not replicated but is stored solely in the EDW of the original enterprise. Instead of actively providing data, most data transmissions will be performed on request. That is, only when a user is requesting to see a specific key performance indicator (KPI) or specific details, is this information transferred from the EDW of the data owner to the cross-enterprise BI-tool.

This approach combines several advantages:

First of all, the data of the cross-enterprise scorecard can, if implemented in the right way, be extremely up to date. As soon as the data is incorporated into the shared environment of the EDW of a partner, the data becomes visible to the other partners.

Another aspect is that, overall, less data is transferred over the network. Not all detail data needs to be provided to the other partners in the network, because only the details that are requested will be transmitted.

In addition, the data remains under full control of the original data owner. Data is not replicated, but rather resides only in the EDW of the original data owner. If the owner decides to modify, correct or hide data, this can be easily and immediately achieved without further negotiations with the other partners. In that sense, the cross-enterprise BI environment represents a single source of truth.

In an SOA environment, data can be shared among the partners without every partner knowing every other partner. That is, a party in the network might decide to enable data access to another partner and all of its potential subcontractors. It would then be sufficient for the party to provide the other partner with access to the appropriate interfaces. The partner can then distribute this access to its subcontractors by himself; the original party has to make no further effort.

The main disadvantage with this approach is that it is not possible to combine cross-enterprise, mass data on detail level for automated calculations. In the technical language of SQL, one might say that with this architecture cross-enterprise data can only be efficiently combined using a union type of query. Join-type queries cannot be processed. This limits the type of questions that such a BI environment can answer.

Third-Party CEDW

The third option of how to achieve cross-enterprise BI would be to build, similarly to the creation of enterprise data warehouses, a cross-enterprise data warehouse (CEDW). This would have to be a data warehouse platform hosted by an independent third party enabling several corporations to store their data on a common platform. Encryption policies allow enterprises to store data in the CEDW with the guarantee that only the original data owner (and not even the third party that controls the DW) can read their data. In such a scenario, data can be shared among enterprises by allowing other parties to decrypt certain, declassified information elements.

Such an architecture has the advantage that data can be shared among the organizations extremely quickly - the data is sitting on the same platform. Moreover, all standard data processing (including joins) can be performed in the usual way. A third party hosting the data warehouse for multiple corporations eliminates the need for each individual enterprise to purchase their own hardware, to train their own resources and to be responsible for the data warehouse maintenance. This setup should have the potential to greatly reduce the overall DW-related IT costs in the business partners' network.

However, from the political perspective, this approach seems to be the least likely. Currently, most enterprises do not seem comfortable with the idea of hosting their strategic and their business-critical data with an independent third party, let alone together with other potential competitors.

What is more, companies would have to migrate their EDW solutions to a potential CEDW, which might prove a hard sell because many enterprises invested heavily to arrive at an EDW solution.

Finally, no vendor currently exists who could offer such third-party hosting with appropriate automatic data encryption.

...............................................................................

For more information on related topics visit the following related portals...
Business Intelligence (BI), DW Design, Methodology, Service-Oriented Architecture (SOA) and Storage.

Robert Blasum is CTO for BusinessCoDe in Germany. He may be reached at rblasum@business-code.de.



E-mail This Article E-Mail This Article
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
advertisement
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2007 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.