Business Intelligence in SAP Environments

Document Sample
Business Intelligence in SAP Environments Powered By Docstoc
Understanding the value of complementary BI solutions

Inforte - A Business & Decision Company
David Dixon
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions

                                                                  TABLE OF CONTENTS

            1.        UNDERSTANDING THE VALUE OF COMPLEMENTARY BI SOLUTIONS .....................................1
                      1.1 White Paper Objective ..............................................................................................................1
                      1.2 Executive Summary ...................................................................................................................1
                      1.3 Definition of Terms ....................................................................................................................2

            2.        “WHY NOT SAP?” .....................................................................................................................5
                      2.1 SAP Usability Considerations .....................................................................................................5
                      2.2 SAP Openness Considerations ...................................................................................................7

            3.        WHY CONSIDER HYBRIDS? .......................................................................................................9
                      3.1 “One-Stop-Shop” Misnomer .......................................................................................................9
                      3.2 “Best-of-Breed” Misnomer.........................................................................................................11

            4.        APPROACHES FOR SAP INTEGRATION ...................................................................................11
                      4.1 Data Quality Management in SAP ............................................................................................12
                      4.2 Interface-Based Access Approaches ..........................................................................................13
                      4.2.1 Open Analysis Interfaces Data Access....................................................................................14
                      4.2.2 Operations-Based Data Access ..............................................................................................15
                      4.3 Extraction-Based Data Access Approaches.................................................................................15
                      4.3.1 SAP Business Suite Data Access.............................................................................................16
                      4.3.2 SAP BW Data Access...........................................................................................................17

            5.        EVALUATING RETURN ON INVESTMENT .................................................................................17

            6.        CONCLUSION............................................................................................................................20

            7         APPENDICES..............................................................................................................................21
                      7.1 Specialist BI Selection Criteria ..................................................................................................21
                      7.2 SAP Platform Considerations ....................................................................................................21
                      7.3 SAP Front-End History..............................................................................................................22
                      7.4 Query Design for Open Analysis Interfaces ...............................................................................24
                      7.5 Open Analysis Interfaces .........................................................................................................25
                      7.6 ABAP™-Based Data Access .......................................................................................................27
                      7.7 SAP BW Metadata .................................................................................................................28
                      7.8 SAP Delta Change Capture for Extraction ..................................................................................30
                      7.9 Open Hub Services.................................................................................................................32

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                                                     
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                 1

This white paper discusses how complementary Specialist Business Intelligence (BI) solutions can fit within a hybrid architecture strategy, whether
your organization is an “SAP shop,” running the majority of their processes on SAP, or has “SAP in its shop,” with a heterogeneous enterprise
application environment that includes SAP solutions.

Because of growing IT complexity and the higher stakes involved with enterprise solutions, decision makers increasingly rely on specialists and
constituents for support. When considering such support, decision makers must take into account both immediate, tactical, project-based
concerns and longer-term strategic implications.

Building consensus on support decisions not only distributes political risk and promotes inclusiveness, but also promotes objectivity and the
technical accuracy of recommendations. But if consensus is split, as is often the case in BI environments consisting of SAP and non-SAP
practitioners, then consensus-building becomes a bottleneck. The explanations proposed in this document can serve as a communication tool to
help expedite the arbitration of differences.

Project teams that face tight timelines to perform high-impact BI evaluations or assessments that need to incorporate how to position SAP and
Specialist BI solution capabilities will also benefit from this white paper.

A 2007 Information Week survey found that decision makers ranked “BI vendors that can integrate with existing operational applications”
at the top of their strategic-planning wish lists.1

Ironically, however, when it comes time to evaluate BI solutions, organizations often divide themselves into product-aligned camps. They debate
ideological differences that preclude the other camp, when in fact Specialist BI solutions can complement SAP irrespective of footprint size.

SAP shops typically put into place governance rules that categorically ask “Why not use SAP?” failing to understand the hybrid options within
SAP solutions as well as across vendors. Recent SAP acquisitions and tighter partnerships are opening up new hybrid options such as the recent
SAP offer to acquire Business Objects.2 This paper shows that there is indeed value that complementary Specialist BI solutions add to customers
that run SAP solutions. The optimal solution isn’t an either/or choice, but rather one which incorporates both elements. Assumptions that SAP is
a good enough “one-stop-shop”—or on the other hand, that SAP complicates “best-of-breed” BI environments—are no longer relevant.

One serious perceptual problem involves the misuse of oversimplified labels. Both “one-stop-shop” and “best-of-breed” are inappropriate
because of rapidly-changing industry dynamics. In the first place, SAP “one-stop-shop” architectures are falling short by sweeping unmet
needs under the carpet. In addition, “best-of-breed” solutions from Specialist BI providers now offer “one-stop-shop” BI in their own right
that can complement rather than complicate SAP deployments. Using inaccurate labels can create impressions that lead decision-making
down the wrong path. Strategically leveraging the respective strengths of all solution providers make “best-of-both-worlds” or “best-of-
hybrid” capabilities possible.

To be clear, “best-of-both-worlds” does not mean BI nirvana, but rather an environment that is better than having to pick a vendor-aligned
extreme. Achieving a more balanced and optimal state with hybrid architectures has less to do with buying into the the hype around the
latest buzzword technologies and more to do with focusing on established interfaces, maturing technologies and best practice techniques
that are coming of age. But perhaps the tipping point is not so much technology-driven as knowledge- and experience-driven. After years
of investment in studying SAP concepts, data and technology nuances, Specialist BI providers have developed proven solutions capable
of leveraging preexisting investments in SAP transactional systems. The stabilization of SAP integration touch points, as well as pre-
delivered best practices, promises to turn hybrid BI architectures from a legacy landscape problem into a strategic infrastructure asset.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                      
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                 2

Hybrid architectures are a reality that is not going away any time soon, no matter how big the SAP footprint. Rather than factionalize or
universalize SAP architectures and programs, IT organizations should realize that the ever-growing scope and complexity of their enterprise
architecture, as well as the need to yield better business value, necessitates a multi-product and customization strategy.

The questions you should weigh are:

• What “best-of-hybrid” approach gives the most capability and flexibility?

• Which “best-of-hybrid” approach keeps options open and minimizes lock-in risks?

Addressing these questions can be done in a more pragmatic and incremental way through iterative transitions, rather than attempting a multi-
year, “Big Bang” approach whose business benefits will invariably decline as the world changes. The key to defining the optimal transition state
architecture is to understand each product’s present-day strengths and weaknesses. Not all BI providers that have SAP solutions are created
equal, and it is important to consider criteria such as a solution providers’ experience working with SAP customers and the maturity of their
solutions. (See Appendix 7.1 for a detailed list).

SAP data-centric organizations that presume “SAP-speak” is the lingua franca of BI risk alienating others, who in turn often craft workarounds
that unravel the spirit of SAP centralization. By taking an SAP BW “one-stop-shop” approach, organizations inadvertently create walls that can
force isolated groups to choose preferred “best-of-breed” tools without the benefits of a single version of truth, shared support and transparency.

Rather than letting hidden costs mushroom, SAP shops should consider expanding their architectural vision to address unmet needs by leveraging
complementary, Specialist BI solutions. Not only can Specialist BI tools reach larger audiences, but core constituents can also benefit from
broader and deeper BI capabilities. Otherwise, an ambitious SAP initiative may atrophy. The need for fast and flexible non-SAP data integration
and end-user time-to-value should not be underestimated.

Whereas the decision to standardize on a single ERP vendor is often made with a view toward gaining efficiencies, making total cost of
ownership (TCO) the prevalent financial driver, the application of BI inhabits a far more strategic plane. If properly applied, BI goes beyond
simple reporting, and can drive fundamental business decision-making at many levels throughout the organization. For this reason alone, it is
important to understand what the business is trying to accomplish when choosing amongst solution providers. While TCO may be king for ERP,
ROI is the applicable approach for BI.

Even so, many organizations still need to consider TCO. When evaluating the various approaches, the enhancement costs of a single-product
approach must be weighed against the integration costs of a hybrid approach. TCO also comes into play when information consumers evolve
into their own producers and eliminate the middleman (i.e. BI developers). Business is changing faster than IT can support. As a result, backlogs
are burgeoning and lengthy projects lose value. Faster time-to-value not only positively impacts business opportunity costs, but also resource
allocation and operational efficiencies.

As automation shifts tasks into higher-brain-function knowledge work, empowering the knowledge worker with usable tools becomes an
increasingly important—if not the most important—driver in business value creation in the information revolution.

Before reading this document, you should be familiar with a number of acronyms, terms and concepts in order to avoid getting lost in words or
missing important connotations. This section outlines the vocabulary used in this white paper.

The objective of this section is to capture the distinctions between terms influenced by SAP but reconciled with the rest of the industry so that
you can better appreciate “buzzword” nuances.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                      
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              3

Note that other sources, some of which are cited below, also have comprehensive and slightly varying definitions for the same terms; you are
encouraged to reference them for further background.

Data Warehouse, also more broadly referred to as Enterprise Data Warehouse (EDW), is a term and architectural approach that writer
Bill Inmon is largely credited with originating and popularizing. Inmon has a very specific definition for data warehousing, and has written
multiple books on the subject. For the sake of this white paper, the important nuance to grasp is that an EDW is: 1. Not the same thing
as BI, 2. Should not be confused with data marts, and 3. By definition is a separate system from transactional ones. SAP positions the
EDW as an IT scenario that can be built with the functions of its SAP NetWeaver™ technology platform. This paper uses the term EDW to
represent the back-end part of BI that processes, manufactures and prepares data for the front–end, and consists of activities such as
extraction, transformation and loading (known as “ETL”), data transfer scheduling, data modeling and data management (such as aggregate
builds and indexing).

Data Mart is a term that has numerous varying interpretations and nuances, a problem exacerbated by SAP’s own technical and specific
use of the term—that is, for transferring SAP BW data to another SAP system. This paper uses this term to either represent a subset of data
that sources its data either from the EDW or the underlying transactional systems, thereby by-passing the EDW. Data marts are usually the
underlying data structures for reporting, querying and analysis, while the EDW is more of a central data repository. As a result, data marts
are generally faster and simpler to implement but are done so in isolation.

Furthermore, they are typically (but not necessarily) dimensional in nature in order to better support OLAP (online analytical processing) forms
of analysis. SAP dimensional data structures are called InfoCubes, and in this case SAP refers to Ralph Kimball’s body of work for data design.
Beyond contributions to dimensional data design, Kimball proposes an alternate approach to EDW architecture. Kimball’s “bus” architecture
reaps the benefits of fast implementation without the isolation tradeoff. The author anticipates that as SAP NetWeaver Master Data Management
gains adoption as a data repository this enterprise “bus” approach will gain popularity. However, in the meantime, EDW in the SAP world
usually means taking the Inmon approach, and Kimball’s main contribution is reflected in InfoCubes.

OLAP is an acronym for Online Analytical Processing, and was coined in 1993 by E.F. Codd, popularly known for his academic
contributions to relational database theory and design. This paper will not consider OLAP’s academic aspects, but rather its significance
as it relates to SAP BW. Namely, all the SAP front-end BI tools known as the SAP Business Explorer (SAP BEx) Suite, as well as the majority
of third-party BI tools, access SAP BW data universally through SAP’s native and proprietary OLAP processor. SAP’s OLAP, or analytical
engine, is the heart of SAP BW data access no matter whether the data is flat or dimensional, and is the underlying interface to integrated
planning, data mining and the SAP NetWeaver Visual Composer (explained in Appendix 7.3 in more detail).

Business Intelligence (BI) refers to the front-end layer (e.g. OLAP and presentation tools) that sits on top of the data layer (i.e. marts
and warehouse), and is also used as an all-encompassing umbrella term. So as not to confuse the two usages, the front-end “out-of-the-
box” application capabilities will be more specifically referred to as part of a “BI Suite,” while the overall development infrastructure
capabilities will be referred to as part of a “BI Platform.”

Suite refers to a family of applications or tools, connoting integration across the family of software and functionality that is pre-delivered
“off-the-shelf” or “out-of-the-box” rather than requiring custom programming. A suite represents the full breadth of software capabilities
under the same brand. SAP ERP, SAP Customer Relationship Management (SAP CRM) and SAP Supply Chain Management (SAP SCM)
are examples of SAP Business Suite applications. This paper will on occasion refer to the SAP Business Suite as “SAP transactional systems”
in order to distinguish between its online transaction processing (OLTP) and OLAP capabilities.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                   
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                       4

Platform is an environment that is designed to support third parties (customers or other vendors) in developing their own applications. The platform
itself may consist of applications, frameworks, reusable services, interfaces, tools and an integrated development environment (IDE). Some of the better-
known platform examples are .NET from Microsoft and WebSphere from IBM. SAP NetWeaver is SAP’s technical platform.

SAP NetWeaver is the underlying application development infrastructure for SAP’s own SAP Business Suite applications and industry-specific
applications. The SAP NetWeaver technical platform also enables composite applications where third-party vendors or customers can build
custom business processes by integrating SAP applications with non-SAP applications. Such integrations occur via reusable enterprise services
using SAP NetWeaver not only as a technical platform, but also as a business process platform (BPP). SAP brands these composite applications
as “xApps,” like SAP xApp™ Resource and Portfolio Management (SAP xRPM), which loads SAP and non-SAP projects for resource and
portfolio management. (Appendix 7.2 gives a historical background to SAP NetWeaver and the implications it has on SAP BW).

EA is an acronym for Enterprise Architecture. EA represents a rapidly evolving and expanding discipline that has its roots in recognizing
and holistically addressing the growing complexity of IT, as well as its corresponding difficulties in meeting business needs. It is a discipline
that traces back twenty years to the thought leadership of John Zachman, but has now broadened to comprise many different competing
methodologies and frameworks. EA has enjoyed significant private sector adoption and legally-mandated adoption in the public sector.
For the sake of this white paper, the use of the term “EA” is meant to suggest that SAP cannot represent a holistic architecture and plan
for the entire enterprise, as EA represents a much larger concept.

SAP BEx is SAP’s branded BI suite. The SAP BEx consists of a grouping of BI tools such as SAP BEx Query Designer, SAP BEx Report
Designer, SAP BEx Web Application Designer, SAP BEx Analyzer and SAP BEx Broadcaster. Using these tools, dashboards, reports and ad-
hoc analysis can be developed on the web or in Excel without custom code. The SAP BEx also includes the OLAP processor and only
works with SAP BW.

SAP BW stands for SAP Business Information Warehouse, and is SAP’s branded BI platform that includes SAP BEx. The term “SAP BW”
was dropped by SAP after SAP BW release 3.5 (also known as SAP NetWeaver BI 2004). The subsequent release was named SAP
NetWeaver BI 7.0 (formerly known as NetWeaver BI 2004s). Because SAP brand and release names have been subject to frequent
change, most customers still refer to SAP NetWeaver BI as SAP BW particularly in reference to the back-end such as the data warehouse
or data models. As a result, this paper will continue to use this term for readability.

ERP Reporting will be used in this paper to represent the reporting and analysis capabilities of SAP Business Suite applications. As early
references to SAP CRM, SAP SCM and other enterprise applications used terms like “extended ERP” or “ERP II”, this paper will use “ERP
reporting” as an umbrella term to encompass these enterprise applications as well. SAP ERP information systems like Logistics (LIS), Human
Resources (HRIS) or Financials (FIS), as well as tools such as Report Painter and Query Painter, are examples of ERP reporting. SAP solution
maps refer to ERP reporting as part of their “Analytics” capabilities.

Specialist BI is a term used in this paper to refer to SAP third-party BI vendor suites sometimes traditionally referred to as “non-SAP” (in
the SAP context), “pure play” or “best-of-breed” BI vendors that have comprehensive capabilities, both in terms of breadth and depth. As
some of these BI vendors have expanded their offering to become “one-stop-shops” in their own right and in the case of Business Objects
are in the process of being acquired, the Specialist BI term is being used in place of the traditional terms. Furthermore, a distinction must
be made between Specialist BI vendors like Business Objects, Cognos or SAS and Niche BI vendors, as described below.

Niche BI refers to vendors that work within a specific product category in BI. The category not only includes Niche BI reporting and
analysis tools such as Panorama or XLCubed, but other BI product categories such as ETL, vendors like Informatica or Ab Initio, or data
warehousing vendors such as Teradata and Kalido.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                           
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                     5

No matter the size of the SAP footprint, organizations are increasingly asking, “Why not SAP?” especially in areas that are already paid for
in their license agreement, such as SAP BW. The business case for SAP BW is that it is part of the SAP NetWeaver technical platform and hence
integrated (or integrateable) with the rest of SAP’s Solutions.

What follows is some historical context around the evolution of SAP BW to separate myth from fact. In addition, this paper will make the case
for employing Specialist BI tools to complement present-day SAP BW (i.e. SAP NetWeaver BI 7.0) capabilities. As IT investments in both
SAP BW and Specialist BI soltuions are growing, it makes pragmatic business sense to leverage both rather than push one out, even in an
EA-disciplined organization.

First, this paper will discuss SAP front-end usability, followed by a consideration of back-end openness from a BI and ERP reporting perspective.
The Information Week survey noted earlier indicated that integration and compatibility problems, followed by ease-of-use issues, are the top
two roadblocks standing in the way of enterprise-wide adoption of BI.3 For an understanding of how the SAP NetWeaver technical platform
underlies usability and openness refer to Appendix 7.2.

Supreme Court Justice Potter Stewart’s famous quote defining obscenity—“I know it when I see it”—applies equally well to usability. For
customers, usability is a product feature that is more cost-effective to consensus-score rather than empirically test and measure as part of
a scientific work study. This white paper will not go into depth describing usability features, but rather delve into center-of-design concepts.
As it relates to SAP tools, a distinction is made between developer usability and end-user usability. Historically, SAP report development
and usage were clearly divided into two roles: the developer and the user. As an ultimate result, production design became developer-
centric and centralized to avoid expensive rework. In contrast, Specialist BI typically blurred the distinction by putting development into
the hands of the end-user, enabling autonomy. In fact, some BI products require zero report development, relying on “on-the-fly” and
bookmarking capabilities.

Usability goes beyond just graphical capabilities in the user interface. Appendix 7.3 provides a personal perspective that illustrates how SAP’s
center-of-design for report development was historically centered on developers. SAP applied software engineering principles to report
development so as to eliminate redundancies and promote reuse through a building-blocks approach. This design approach to separate
development into logical and separated units of work carried through to SAP BW. In contrast, Specialist BI historically centered on end–users,
empowering them to build reports and analysis from scratch with a high degree of visual what-you-see-is-what-you-get (WYSIWYG) design
control. More details are provided in Appendix 7.3.

                                                                  But the centers-of-design for both users and developers are converging as the tools
                                                                  for each become more sophisticated and easier to use. The potential to build hybrid
     The potential to build hybrid solutions by
                                                                  solutions by “mashing up” SAP with Specialist BI capabilities is around the corner.
     “mashing up” SAP with Specialist BI capabilities
                                                                  Presently, SAP pilot projects are testing next-generation SAP NetWeaver APIs, called
     is around the corner.
                                                                  BI Consumer Services, that not only enable universal data access but support access
                                                                  to functions such as exception alerts, list rankings and document attachments.4 With
the integration of SAP NetWeaver Visual Composer into SAP NetWeaver Composition Environment (SAP’s Java-based development platform) it is
possible that front-end tools from third-party vendors can be mashed up into a composite application. Specialist BI solutions already provide this
capability, typically as part of dashboard designer tools. SAP may follow suit. Currently, it is not possible to mix and match SAP front-end tools like
SAP BEx Report Designer, SAP BEx Web Application Designer and SAP NetWeaver Visual Composer without programming or separating them
into portal iViews (SAP portlets). At some point, either Specialist BI or SAP BW dashboards will become ‘mash-boards’—a mixed-and-matched
composite of user interface components and web services. Some Specialist BI tools already directly support seamlessly integration with SAP
NetWeaver Portal via iViews, and can interact across iViews and auto-generate reports into easy-to-use web services.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                         
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                    6

Figure 1 depicts the complementary capabilities of SAP BW versus Specialist BI tools. The power of SAP BW is that it can be used like die-cast
molding—the output is predefined and standardized for mass consumption. Die-casts take more pre-defined design and planning, but once in
place are reusable over and over. The power of Specialist BI tools is that it can be used like molding by hand, which is more flexible, easier to
pick up, on-the-fly and WYSIWYG. Having both options for molding information gives organizations the power to support both centralized and
decentralized solutions in a controlled EA. Top-down developer-centric solutions can be balanced with bottom-up user-centric solutions, rather
than stir conflict in the middle.

Figure 1 - Developer versus User Spectrum

                                                                                             SPECIALIST BI



                     Technology Platform for                                                          Application Self-Service
                     Programmer Developers                                                                 for Business Users

In conclusion, Specialist BI tools can still offer complementary capabilities to the latest release of SAP BW tools by providing users tools that
are self-service driven without undermining the strength and capabilities of SAP BW.

The author’s first customer assignment at SAP was to write an interface to load data from a flat file that would eventually roll up into the financial
consolidation ledger. The program was not that flexible; the file was fixed length and had to be in a specific file format.

About a year later, SAP came out with a financial consolidations-based tool called “flexible upload”—“flexible” in that the structure and file
format were configurable—that retired the development.

There is now many standard and stable APIs available in SAP. In particular, profitability analysis (CO-PA) and LIS have long supported
external data interfaces with customizable structures and mapping rules. Even from the earliest days of SAP BW, flat file data loading
was supported.

These interfaces require files in a file structure that is accessible via the SAP application server. Later, SAP supported direct loading from
multiple external database systems; this was done by opening extra database connections on the application server in addition to the
default. The constraint in this case was that the database system had to be one of the limited set that SAP itself runs on. SAP called this

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                         
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              7

type of SAP BW data source DB Connect. Then, when the SAP application server supported a Java stack, SAP introduced Universal Data
(UD) Connect, designed to connect directly to anything Java can. Java Database Connectivity (JDBC) alone has over 220 drivers for all
major relational database management systems.

But, technically speaking, connecting to an external data source and translating that data source into SAP semantics is much like placing
a call to China and then speaking Chinese. SAP’s recent acquisition activities for Specialist BI and OEM agreement with Niche BI
(Informatica) will help SAP customers build those translations without having to program them in ABAP. From a licensing perspective, these
deals are more than just a replacement to the reseller agreement SAP had with Ascential before that company was bought by IBM. These
deals imply SAP recognizes the need for seamlessly integrated outside ETL capabilities to complement their own. Specialist BI suites offer
ETL capabilities but also can go beyond, from the OEM perspective, with enterprise information integration (EII) as well as data quality
and cleansing capabilities.

EII, also known as data federation, is the equivalent of ETL, minus the data replication. In fact, SAP BW has data federation capabilities by
incorporating its ETL engine; no data has to be stored in SAP BW, but rather can point to SAP BW representations of extraction structures called
DataSources. Of course, there are performance implications with querying structures that ETL the data on-the-fly each time it is referenced.
Specialist BI suites and Niche BI vendors like MetaMatrix have tools that are more established in this domain for more robust needs.

Data quality and cleansing is a prerequisite to effective data transformation, whether it be ETL or EII. Imagine how much harder conversing
in Chinese would be if several rustic dialects and non-native-speaker versions were on the other end of the phone rather than one clear
Standard Mandarin voice.

Simply standardizing and automating processes on SAP Solutions does not
eradicate data defects or the need for data quality management. In fact, SAP
                                                                                          Here again, Specialist BI can complement SAP
NetWeaver MDM, designed for master data consolidation, cleansing, and
                                                                                          capabilities, especially in the area of customer
quality control, would not exist if that were the case. Here again, Specialist BI
                                                                                          data integration (CDI).
can complement SAP capabilities, especially in the area of customer data
integration (CDI). Furthermore, Specialist BI suites can provide solutions for those
SAP customers that have not yet taken the architectural plunge in to SAP NetWeaver MDM, but still need data quality and cleansing capabilities.

Although SAP BW has opened its architecture from external connectivity perspective, there still remains a significant value gap between SAP
and non-SAP sourced data unless Specialist BI or Niche BI is leveraged. This gap exists both because of the level of programming effort needed
in its native ETL engine, and also because of the availability of SAP’s pre-delivered information models. The SAP information models, called
Business Content, are predictably slanted towards SAP applications. SAP BW projects tend to be SAP-centric not because of a lack of SAP BW
openness, but because of the lack of automation and standardization of non-SAP scenarios. Although SAP BW does have some Business Content
for external data sources, including Dun and Bradstreet and Oracle Financials, there is not enough pre-delivered content and native ETL
capabilities to make the same business case for accelerated implementations on non-SAP data as there is for SAP data.

Due to their “Switzerland neutrality” in BI, Specialist BI and Niche BI vendors can bring much more pre-delivered content and connectors
for diverse enterprise applications external to SAP such as, Oracle and pre-Oracle applications (i.e. JD Edwards, Siebel,
Hyperion, Peoplesoft, et al) as well as SAP itself. Furthermore, on-demand BI has pushed the envelope. Pre-packaged reporting and
analysis on external market data or public government records for market research, competitive analysis, and forecasting or industry
benchmarking are now available as subscription-based services. Diverse sources such as eBay market data, Bureau of Labor Statistics,
Bureau of Economic Analysis, Dun & Bradstreet, Hoovers, and Thomson Financial can be readily accessed and used in a web-based BI
tool from an online store.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                   
                   WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                    8

                                                                  While SAP does have partnerships with syndicated data sources and does
                                                                  stand to gain by supporting other enterprise applications, it does not seem
     Due to their “Switzerland neutrality” in BI,
                                                                  SAP will be expending much effort delivering Business Content for these
     Specialist BI and Niche BI vendors can bring much
                                                                  sources, and vice versa. Specialist BI and Niche BI vendors, on the other
     more pre-delivered content and connectors for
                                                                  hand, have a much more vested interest. For organizations with a small SAP
     diverse enterprise applications external to SAP
                                                                  footprint, the multi-vendor pre-delivered content that Specialist BI and Niche
     such as, Oracle and pre-Oracle
                                                                  BI vendors bring may be more relevant. Specialist BI and Niche BI vendors do
     applications (i.e. JD Edwards, Siebel, Hyperion,
                                                                  not cover all business applications or external sources, and those they do
     Peoplesoft, et al) as well as SAP itself.
                                                                  cover are done at varying degrees, especially in regards to SAP data, so
                                                                  customers must account for this in their evaluation.

In SAP BW, all new data sources must flow through its ETL engine for integration, and subsequently must be information-modeled into
InfoProviders, in order to be available for SAP BEx. As discussed in Appendix 7.3, in SAP this information design is done with the DW
Workbench tool as a developer task. An alternative is to use SAP NetWeaver Visual Composer, which leverages the same underlying
architectural components as UD Connect to connect to any SAP and non-SAP system, as well as ABAP via RFC and web services.

SAP NetWeaver Visual Composer is touted as a business process expert tool. However, it is not yet a candidate for deployment as a self-service
reporting tool for business users. SAP NetWeaver Visual Composer has not yet demonstrated widespread adoption or acceptance by end-user
communities commensurate to Specialist BI tools. Specialist BI tools have the benefit of an established history and rapport with business
communities (end-users and experts).

Both Specialist BI products and SAP NetWeaver Visual Composer can connect heterogeneous data sets in their tools. What this effectively means
is that users can directly access outside data sources (or raw exports) and integrate them into their reports and analysis without having to wait
for IT specialists to build the information model for them.

However, as explained in Appendix 7.3, SAP NetWeaver Visual Composer is not as strong an information-modeling tool. In Specialist BI and
Niche BI products, users have the ability to do their own information design and integration work. In contrast, SAP BW takes a structured and
architected approach to BI that most IT organizations would commend for governance and control reasons. However, ad-hoc self-service analysis
should not be discounted, since inexorable business demands and specialized needs are creating mounting IT backlogs.

Specialist BI tools provide a quick alternative solution to access outside data sources without the need for a data warehouse or even data mart
(SAP or non-SAP). For SAP shops, this enables the bridging of data gaps caused by data sources deemed too trivial or difficult to cost-justify the
build in SAP BW. For non-SAP shops, this enables reporting on SAP data (whether in an SAP transactional system or in SAP BW) without loading
the data into another environment. Furthermore, many SAP satellites need more immediate visibility to, and integrated reconciliation with, SAP
data before they can effectively replace or stabilize interfaces that may break down after SAP retires legacy systems.

From an EA and roadmap perspective, although SAP BW may deliver more flexible ad-hoc data integration options, it is better to focus EA
efforts on present-day realities; the IT industry is so volatile that prediction even one year out is difficult. EA should be focused on balancing
strategy and stability through continuous transition-state architectures rather than attempting a multi-year leap from the “as-is” current state to the
“to-be” end state. As many environments already have both SAP and Specialist BI suites in their portfolio, it is a matter of rationalizing those
assets but then also finding ways to create synergies with those stabilized investments.

The main challenge is not technological, but political and organizational, as IT and even business fiefdoms will clash around vendor-aligned
dogma. Ironically, organizations pushed BI vendors hard to interoperate with each other, and now that SAP integration has reached maturity,
it is the organizations themselves that are more closed than the technologies.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                         
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                         9

The world of IT has its share of industry-specific dichotomies and trade-offs. But over time, innovations and improvements born of industry debate
and market needs give rise to new alternatives that do not necessarily require compromise. Both SAP and Specialist BI suites are now touting
“best-of-both-worlds” solutions with lower overall TCO by leveraging maturing interfaces, the benefits of better architectural design, enabling
technologies and acquisitions. Furthermore, established BI providers have rapidly grown into a comprehensive suite of BI tools and applications
that are as much “one-stop-shop” as they are “best-of-breed” in BI.

The promise of “best-of-both-worlds” offerings is taking the place of “best-of-
breed” versus “one-stop-shop” trade-offs. The premise of this white paper is that                The premise of this white paper is that you do
you do not have to pick vendor sides and then wait for your vendor to deliver                    not have to pick vendor sides and then wait
“best-of-both-worlds” capabilities. Instead, you can start to pragmatically “spread              for your vendor to deliver “best-of-both-
your bets” with a composite approach capitalizing on well-established interfaces                 worlds” capabilities.
or extraction techniques.

In fact, BI vendor interoperability is exactly what the majority of the market has been clamoring for. An Information Week survey in March 2007
noted that 78% of respondents indicated that what they wanted from BI vendors was the “ability to integrate with existing applications,” putting
that desire at the top of the survey wish list.5

The ability to customize and extend vendor solutions further obscures the “make” versus “buy” dichotomy, embodied in the difference between building
solutions out of “best-of-breed” versus buying a “one-stop-shop” solution, respectively. The power of “out-of-the-box” capabilities in an application suite
can be combined with the development and self-service capabilities of a platform or tool. This enables organizations to build malleable designs and
architecture on an enterprise scale that is unique to their needs as well as enable “prosumer” (consumer as producer) activities.6

                                                                   As vendors make acquisitions, embrace openness and create separate licensing
                                                                   agreements, hybrid architectures have more potential for synergy than
     As vendors adopt open standards and existing
                                                                   cannibalism. For enterprise architects, the new challenge is to determine the
     interfaces mature, hybrid landscapes can
                                                                   optimal hybrid architecture. Hybrid architectures historically have posed
     become more of a strategy than a legacy.
                                                                   problems, since proprietary architectures lock out other vendors, creating de
                                                                   facto isolation. As vendors adopt open standards and existing interfaces mature,
hybrid landscapes can become more of a strategy than a legacy. Considering the large data volumes and heavy infrastructure investments
already made in enterprise BI solutions, putting these investments together instead of throwing some away makes good sense. The increase in
acquisitions, partnerships, semi-packaged applications and composite solutions are testaments to the value of the hybrid approach.

Perhaps a different set of dichotomies in lieu of the traditional “best-of-breed” versus “one-stop-shop” debate is necessary. The traditional
dichotomy has been an architectural debate that is vendor aligned and, as a result, polarizes approaches. The traditional dichotomy suggests
that one vendor group precludes the use of the other instead of considering both. The perception is that organizations must force-fit either SAP
BW or a competing BI product rather than finding the right balance.

Given the recent trends in BI, perhaps alternate dichotomies are necessary to assess overall best-of-hybrid architectural approaches that
holistically assess depth-versus-breadth capabilities and open-versus-proprietary features. “To SAP or not to SAP” is no longer a clear-cut
question, and indeed, is now a bit myopic. Instead, a bigger-picture question is how to blend different BI product capabilities in order to
maximize the enterprise value of information assets when SAP is in the mix.

A decision to standardize on SAP BW for all reporting, query and analysis might be flawed without consideration of all user requirements, present
and future. Very often an organization will wait for transactional systems to be standardized before rolling out BI. Consequently, the organization is

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                             
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                   10

quite immature with respect to BI, and thus its understanding of how user requirements may develop is very limited. It makes sense to investigate
what analysis organizations similar to your own perform, how long it took for them to get there, and what technology they finally selected.

Many large-footprint SAP BW implementations could benefit from enhancing their solutions with Specialist BI capabilities, but given their
mandates, budget and program scope simply do not look beyond the SAP walls.

Even in wall-to-wall SAP implementations, typically there is still BI demand for some non-SAP data sources that are deemed too small (such as
a spreadsheet), too interim (like a retiring legacy system), or too unwieldy (like syndicated data) to be brought into the SAP BW solution. In
addition, there may be BI demand from satellite consumers that want to bring SAP access into their local solution, but that demand gets either
ignored or addressed with a one-size-fits-all data dump.

In many of these “exception” cases, under-served or ignored groups find local or un-standardized workarounds that undermine the spirit of EA
and the move to become an SAP shop. It is not uncommon behavior in large-footprint SAP BW implementations to find users routinely exporting
detailed data from reports that were supposed to serve users’ needs in and of themselves. By taking a “one-stop-shop” approach with SAP BW,
organizations may inadvertently create an SAP fiefdom that is surrounded by satellites with the autonomy to choose their own BI tools but without
the benefits of centralized truth, support and visibility.

Rather than letting hidden costs proliferate, SAP shops should consider
expanding their architectural vision to address unmet outside needs by
                                                                                              SAP shops should consider expanding their
leveraging Specialist BI tools. Approaches for doing so will be discussed later
                                                                                              architectural vision to address unmet outside
in this document. Not only can Specialist BI tools reach larger audiences, but
                                                                                              needs by leveraging Specialist BI tools.
core constituents can also benefit from broadened and deepened BI
capabilities. Otherwise, an ambitious SAP EDW initiative may atrophy into an
SAP data mart. The need for fast and flexible non-SAP data integration should not be underestimated.

Besides providing easier access to non-SAP data, Specialist BI solutions can also potentially better fulfill implementation-specific requirements,
such as more dynamic or functional semi-additive measures, pixel-based formatting, specialized interactive visualization, advanced publishing
and distribution options or self-service usability, while at the same time integrating with SAP outputs in SAP NetWeaver Portal or on the web.

In broader EA terms, no one vendor can cover all enterprise needs. In the early days of SAP, this notion was lost on some SAP shops (and
perhaps still is). When SAP ERP first hit the market, there were few software implementations quite like it in magnitude. It was so monolithic and
covered so much business scope that organizations assumed they had gotten their EA in one vendor box.

But as customer IT investments continued to grow and landscapes became more complex, the belief that SAP ERP was an all-encompassing island shifted
with the advent of other monolithic enterprise applications such as SAP CRM and SAP SRM. EA-aware advocates realized ERP investments were like
poured concrete, and SAP eventually responded with what evolved into the SAP NetWeaver BPP to address interoperability and flexibility concerns.

                                                                 Multi-vendor landscapes and hybrid architectures are a present and future reality. As
                                                                 a result, customers must realize that they own their EA; not the vendors. Rather than
     IT organizations should realize that the ever-
                                                                 factionalize or universalize SAP architectures and programs, IT organizations should
     growing scope and complexity of their EA and
                                                                 realize that the ever-growing scope and complexity of their EA and the need for
     the need for business autonomy necessitate a
                                                                 business autonomy necessitate a multi-product and customization strategy. Even SAP
     multi-product and customization strategy.
                                                                 has implicitly recognized and acknowledged the need for hybrid solutions by
                                                                 fostering a healthy partner ecosystem around its core solutions. The SAP and
Microsoft joint venture product called Duet is one such manifestation and further blurs the vendor lines to promote hybrid architectures. Furthermore,
mergers and acquisitions as well as trends towards business networks and cross-enterprise collaboration virtually guarantee that “one-stop-shops” will
eventually be unattainable. EA disciplines around managing and controlling hybrid architectures are a growing, not shrinking, need.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                        
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                11

Specialist BI Suites that were traditionally dubbed as “best-of-breed” are increasingly harder to distinguish from “one-stop-shop” branded
enterprise application vendors, at least from a BI perspective. For example, Specialist BI offerings in Enterprise Performance Management (EPM)
are as comprehensive and integrated, if not more so, than SAP solution offerings in that category.

As a result, alternate methods to differentiate and complement solution providers are needed. Two criteria for comparison are the breadth and
depth of functionality and features in contrast to the flexibility and openness of the architecture on which it is built (i.e. business application
versus infrastructure platform).

Many former “best-of-breed” functions and features have since been commoditized and hence, no longer qualify as “best-of-breed.” “Slice-and-
dice,” ranking lists, exception alerts and web-based reporting and analysis are now non-differentiating functions. In contrast, having a single,
integrated and consistent BI front-end for all BI needs is now a differentiator for Specialist BI providers to address.

Furthermore, Niche BI vendors with true “best-of-breed” capabilities are not viable over the long-term unless they can interoperate as part of a
best-of-hybrid solution. In other words, Niche BI vendors with proprietary and closed architectures are increasingly hard to justify as
organizations move towards enterprise solutions. Isolated “best-of-breed” solutions can persist in fragmented and departmentalized
organizations, but as those walls come down, so will those products because of the EA headaches they produce. Many times, there are more
open and competing alternatives that are better cost-justified. For Niche BI vendors to add long-term value to their short-term business value,
they need to invest in interoperability in order to function in best-of-hybrid environments.

Specialist BI providers have three fundamental ways to achieve hybrid information integration with SAP:

• Presentation output integration via a Portal.

• Data quality integration via master data maintenance.

• Data access and information design integration.

Both SAP and Specialist BI providers have the ability to integrate into SAP NetWeaver Portal via iViews to achieve integration to a web-based
central access point. Reporting and analysis output is simply published through an iView. Not only can SAP and Specialist BI iViews be arranged
together on the same portal, but SAP drag-and-relate and portal-eventing technology also enables data integration and interactivity between
iViews. Standard portal capabilities enable roles-based composite applications that leverage both SAP and Specialist BI output.

At the other end of the information value chain, Specialist BI data quality capabilities can directly embed into SAP transactional systems for
specialist features such as postal validation and duplicate matching for maintenance by business partners such as customers and vendors. No
matter the size of your SAP footprint and whether you are using SAP NetWeaver MDM, Specialist BI data quality management capabilities can
offer functions and features that native SAP capabilities cannot.

Perhaps the most controversial BI integration topic involves SAP data access because there are two different approaches with significant IT
strategy and architectural implications. The two basic ways to access and integrate SAP data in question are:

• Reporting on the data directly from SAP via an interface

• Extracting the data out of SAP

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                      
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                 12

Additionally, each data access approach has two options:

• Access data from SAP BW

• Access data from the SAP transactional systems

If you are a large SAP shop, you may keep data in SAP as your source of truth
rather than have it extracted. As not all reporting needs are typically addressed
                                                                                             Specialist BI tools add the most value by being
by SAP BW (such as real-time reporting due to customization or performance
                                                                                             able to merge SAP BW and SAP transactional
impacts), Specialist BI tools add the most value by being able to merge SAP BW
                                                                                             data as well as serve as a consistent tool
and SAP transactional data as well as serve as a consistent tool across both.
                                                                                             across both.
Having a consistent tool not only lowers TCO as an enterprise standard, but also
saves change management costs, especially when underlying systems are going
through upgrades or migrations on different release schedules. All back-end change volatility and complexity can then be shielded from the user.
Alternatively, Specialist BI tools may be more appropriate for certain user groups that deem the SAP BW user interface less than optimal. The
direct access methods have few technical variations, while the positioning of front-end tools has far greater variability.

If you have SAP in your shop, then you are likely to have your “source of truth” in another system, and may want to extract data from SAP. A
key architectural decision to make is whether to extract from the SAP BW or from the SAP transactional systems. Theoretically, it makes more
sense to extract from the SAP transactional systems, but pragmatically most organizations use SAP BW as a proxy to the transactional systems
in order to leverage all the pre-delivered Business Content extractors. However, the latter option has a licensing impact. (The impacts of each
architectural approach are discussed in more detail later.) For ERP real-time reporting needs, the data access approach needs to directly read
some type of interface instead of replicating data via extraction. Whether you consider your environment an SAP or non-SAP shop, the data
access approach for ERP reporting should be handled the same.

Even if a business had only a single instance of SAP ERP, owning no other applications outside of it, data defects can still proliferate. Data entry
is prone to human errors, and is perhaps the most common source of bad data in the form of non-conforming conventions, typographical errors,
duplicates, obsolete entries and missing details. The likelihood of process breakdowns is high due to the cross-departmental nature of ERP master
data maintenance. For example, both finance and sales share the customer master, which may be updated at different times for different reasons
that can in turn lead to duplication. Material master records are even more enterprise-crosscutting; with finance, sales, procurement,
manufacturing and materials management all possessing their own views of these records. Even if well-regimented master data workflows are
defined, status and tracking is not a failsafe against data entry errors.

In reality, most environments have more than one SAP ERP system running, along with many other applications sharing similar master data.
Even an enterprise CRM system has a separate customer database than an ERP, irrespective if both are SAP. Furthermore, many larger
environments may have multiple instances of SAP as well as other vendor packages, all on different versions and configurations. Such
heterogeneous environments create additional data consistency issues due to differences in formats, structures and versions of truth.

Add spider-web interfaces and massive data conversions (where sometimes validations are turned off for performance reasons) to the scenario
and the need for data quality control rigor mounts. Poor quality in customer data alone costs corporate America $611 billion a year.7

Although data quality management solutions typically support data profiling, mass cleansing and quality monitoring capabilities on large
exported data sets, best practices in data quality are the same as in manufacturing: scrap and rework costs more in the long run than addressing
problems at their source. The basic manufacturing-based quality concepts and tenets are the same: preventing problems upstream saves
inspection and repair downstream.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                       
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                  13

SAP NetWeaver MDM has validations and matching strategies to correct errors and eliminate duplicates, but as yet this is not where most SAP
environments first enter their master data. In many SAP environments, master data maintenance is still done in a local SAP ERP system. At best,
a master client designed for central maintenance distributes updates to other SAP clients via Application Link Enabling (ALE). However, in most
cases, master data maintenance is still distributed. As a result, these systems still need a central way to validate and quality-control data entered
into those distributed systems.

For checking documents posted into the ERP-based financial modules, SAP has validation and substitution rules that can be applied via Boolean
logic or custom-programmed enhancements. But these business rules are system-defined (i.e. are local), as are other application-specific checks
and validations SAP delivers in the form of Business Add-Ins (BADIs).

In contrast, however, there exist two notable BADIs designed for a well-integrated set of functions for managing address data on a
universal basis, a capability which SAP calls Business Address Services (BAS). Almost anything in SAP that references an address is
integrated with BAS. A limited number of Specialist BI and Niche BI products with CDI capabilities offer direct SAP integration through
the following two BAS BADIs in question:

• Postal Validation (Online and in Batch)

• Duplicate Check, Error Tolerant Search Interface

Before SAP-based applications, some early data quality applications centered on names and addresses stored in mainframes for marketing
campaign mailings. These applications realized significant savings by cross-referencing postal information that government agencies made
available such as NCOALink (National Change Of Address). Postal standardization of names and addresses has probably more obvious
reference for a single source of truth, and it can be applied in other countries as well. Business Objects (formerly First Logic) provides global
postal validation coverage to over 190 different countries.

There are other standards for other master data such as UPC (Universal Product Code), EAN (European Article Number) and GTIN (Global
Trade Item Number) for products. Some industries also maintain data pools for product master data, such as 1SYNC for global data
synchronization (GDS) in retail using globally referenceable GTIN. SAP NetWeaver MDM provides direct support for GDS and 1SYNC.

Having access to up-to-date postal data not only supports validation (catching address changes, omissions or errors) but de-duplication
and error-tolerant searches as well. For example, Business Objects (formerly First Logic) performs fuzzy or phonetic logic search that
prompts data entry clerks with alternate matches if duplicates or errors are found even if entered data is ambiguous. The same logic can
be used for error-tolerant search.

This direct integration with SAP master data maintenance enables bad data                    Whether you chose to leverage SAP BW or not,
prevention at the source so that no further scrubbing is necessary after extraction.         your SAP solution stands to benefit from postal
Whether you choose to leverage SAP BW or not, your SAP solution stands to                    validation, duplicate check and error tolerant
benefit from postal validation, duplicate check and error tolerant search that               search that complementary solutions can
complementary solutions can provide using government agency databases.                       provide using government agency databases.

If you are an SAP shop, SAP BW may be the best candidate for housing all the data for your reporting and analysis needs as it relieves the
data and performance strain these activities have on your SAP transactional systems.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                       
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions               14

From a data management perspective, SAP BW generally has better capabilities than the information systems found in the SAP transactional
systems for data design and integration. Some examples:

• Data realignments in ERP modules such as CO-PA were either system intensive or unavailable. In SAP BW, data design concepts such as time-
  dependent master data (i.e. changes tracked outside of the transactions) and navigational attributes (i.e. joining master data with transaction
  data in reports) reduce the impact of changes in reporting structures. In addition, these data design concepts provide more functionality for
  historical versus any-point-in-time versions of truth.

• There are limited options to improve reporting performance in SAP Business Suite applications. Pre-calculation, query cache, database
  partitioning, logical partitioning and aggregates are all SAP BW standard functions not generally available in the SAP Business Suite.
  More notably, in-memory indexing technology, called BI Accelerator and powered by partner hardware appliances, offers improved
  performance on SAP BW.

• Keeping transactional history in SAP BW longer is easier with near-line storage capabilities through partnerships like SAND technologies.

• SAP BW has ETL capabilities, whereas SAP transactional systems do not. However, in some cases the configuration-based data integration
  and validation capabilities in ERP modules such as CO-PA and the new general ledger are stronger. However, these modules are designed
  for local SAP data, while the ETL capabilities of SAP BW can be more generally applied across SAP and non-SAP data.

In addition, SAP BW has several techniques for fresher data: delta-change captures (Business Content pre-delivers application-specific and
sophisticated mechanisms), trickle feeds (called real-time data acquisition or RDA) and federated data access (Remote Cubes). Remote Cubes
actually diminish the SAP BW value propositions for offloading data and performance and, as a result, should be restricted to uses such as tie-
back reconciliation.

From reporting, query and analysis perspectives, SAP BW allows you to leverage Business Content, BI analysis authorizations and drill-back to
transactional systems as well as its native OLAP capabilities.

The standard way SAP BW handles all data requests is to pass them through the SAP proprietary OLAP processor, whether it is SAP or third-
party. Put differently, SAP BW data access is SAP BEx query-centric. SAP refers to the set of APIs that access their OLAP processor through SAP
BEx queries, as Open Analysis Interfaces. From an overall modeling perspective, if Specialist BI tools are being used to push down information
design (data unions and joins), query design (information subsets, OLAP definitions and calculations) and presentation design (formatting and
layout) then the question of how to design a BEx query for external access becomes a strategic design decision. Using Specialist BI tools as a
simple presentation design tool on top of query design limits the value proposition of the solution. On the other hand, uncontrolled access
potentially undermines your SAP BW system instead of augmenting it. Appendix 7.4 reviews some best practice query design principles to make
the most of the hybrid design.

As noted earlier, almost all direct access to SAP BW data passes through the OLAP processor based off of SAP BEx queries. The Open Analysis
Interfaces are designed to allow complementary BI solutions direct access to the OLAP engine. These interfaces are based on a long-established
and proven Microsoft standard on which many BI companies and products are built. SAP provides practically full coverage of the standard,
and yet some customers remain skeptical of what Specialist BI or Niche BI providers can yield from Open Analysis Interfaces—not, it must be
noted, without reason (specific details are covered at length in Appendix 7.5).

However, the first Open Analysis Interface has been around almost as long as the Microsoft standard and has reached full maturity in
some BI products support for the interface. The current situation has improved significantly from the early adopters’ experiences, as solution
providers that committed to SAP BW integration have ironed out the issues and closed the gaps. Nevertheless, not all solution providers
are created equal in this respect. Established solution providers that have iterated multiple generations of certified SAP offerings and that have

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                     
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              15

a long working histories with SAP customers are in a much better position to
fully capitalize on Open Analysis Interfaces than vendors new to SAP.
                                                                                       Established solution providers that have iterated
                                                                                       multiple generations of certified SAP offerings
Specialist BI firms with an established history of integration with SAP BW
                                                                                       and that have a long working histories with SAP
will have worked out the kinks, while those vendors new to SAP will have
                                                                                       customers are in a much better position to fully
to lay out the development dollars and commitment to work through these
                                                                                       capitalize on Open Analysis Interfaces than
often-obscure issues. For SAP shops wanting to keep the data in SAP BW,
                                                                                       vendors new to SAP.
establishing integration with SAP BW as one of the first criteria in a
vendor selection will quickly create a short list.

SAP BW was first originally designed for analytics on historical and summarized data rather than detailed operational data. As a result, the
build of the environment was more architected and OLAP-driven than reporting-driven. To deliver enterprise reporting, SAP partnered with
Crystal Decisions (now Business Objects) to deliver form-based formatted reporting capabilities for SAP BW. Joint development integrated
Crystal Reports directly into the SAP BW metadata repository and against the native OLAP processor (for better performance and flattening
operations instead of an Open Analysis Interface). Later, SAP recently introduced the SAP BEx Report Designer for formatted reporting in the
latest version. However, SAP BEx Report Designer only works against SAP BW data versus SAP Business Suite data, while Crystal Reports not
only works against both but can integrate non-SAP data as well.

In fact, Crystal Decisions was a popular enterprise reporting tool against SAP ERP data well before the partnership deal for SAP BW integration.
Crystal Reports shows its maturity and stabilization after seven generations with SAP integration, pixel-based visual control, expert modes and
accelerators (such as wizards and templates) that in the eyes of users raise the bar high for other enterprise reporting tools.

In order for Specialist BI or Niche BI products to read SAP Business Suite data, they must interoperate with ABAP via an RFC connection.
However, establishing the technical connection to SAP environments is only the tip of the iceberg. Understanding where to go for the data and
how to access it is a far more challenging endeavor that only vendors that have an established history can credibly deliver.

Appendix 7.6 covers these technical and semantic complexities with ABAP-based data access in more detail.

If SAP solutions are in your shop, then you are probably faced with one of the following two perspectives:

• You cannot invest in SAP BW for strategy or budget reasons.

• You have invested in SAP BW, but now must figure out how to position it vis-à-vis your other BI solutions.

In either case, the fundamental question is, what is the best way to extract data from SAP Solutions? More specifically, do you pull from the SAP
Business Suite directly or use SAP BW, either as a pass-through or part of a federated data warehouse?

Those enterprises that are looking for SAP BW alternatives, either because of budget constraints or their level of investment in non-SAP BW data
architectures, can skip to the next section on data extraction considerations.

Those enterprises that are looking to incorporate SAP BW into their existing landscape must understand that the SAP BW metadata management,
design practices and tools are fundamentally different than traditional BI. In such environments, traditional BI architects and data modelers may

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                     
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                 16

find SAP has a steep learning curve. Data modelers may be challenged to quickly understand SAP Business Suite's sheer volume of tables and
in-depth data logic. It may also take users some time to understand the SAP BW system’s data repository, and the graphical rendering
conventions and the tools.

Appendix 7.7 goes into more detail about the paradigm differences in order to explain why attempts to incorporate SAP BW into non-SAP BW
landscapes are often met with ideological resistance. It is inherently rooted in how the EDW is modeled and how BI metadata is managed.

In addition, perhaps one of the most hotly-contested capabilities of SAP BW is its scalability for very large data warehouses. SAP credibility as
an EDW is growing as SAP BW multi-terabyte testimonies increase. IBM recently issued a rigorous proof-of-concept study that endorsed SAP
BW as a solution for managing 20 terabytes or greater.8 Additionally, for large volumes, some of the same Niche BI vendors that provide non-
SAP near-line storage capabilities can be leveraged for SAP BW environments.

However, for some environments with retail-based financial transactions, point-of-sale records or RFID tracking, the sizing needs will push well
beyond 100 terabytes. For those sizes, there are no references or empirical evidence that SAP BW can effectively scale. But for hybrid federated
data warehousing strategies, does SAP need to? If SAP BW is just used for SAP data, is 20 terabytes enough? In most cases, the answer is
“yes,” which then drives the question of how central sources of truth are ensured and how to best architect SAP BW. Is SAP BW a simple pass-
through proxy for SAP transactions? Should the environment also handle multi-layered staging and incorporate a reporting layer? Should EDW
transactional history be federated?

These paradigms and shades of gray can spur philosophical BI debates that create cultural barriers around technological differences. The good
news is that Specialist BI suites can stitch together the results from both environments. The bad news is that many organizations are not prepared
for that from a cultural perspective.

Before deciding on where to extract data from SAP Solutions, due diligence should be performed to determine what is involved with extraction
from the various sources, what SAP BW capabilities are provided to facilitate extraction and what percentage of extracted data is non-SAP
sourced. In the end, there are only two best-practice options for getting data out of SAP:

• From the SAP Business Suite applications directly.

• From data loaded into SAP BW.

This section will focus on the first method. The next section will focus on the second.

Some large Specialist BI suites provide SAP quick-start offerings (i.e. pre-packaged and even fixed-price content that includes consulting)
that are positioned as low-cost data mart alternatives to implementing SAP BW. Of course, the content (i.e. pre-defined mappings and
information models) in these bundles can also be leveraged to bridge SAP into larger-scale data warehouses as well. The content that
Specialist BI suites offer usually covers all of the core modules in SAP ERP. The value proposition is a savings in implementation time by
leveraging a ready-to-run template. The added advantage in using a Specialist BI suites is that the products will have similar templates for
other business suite vendors that SAP Business Content will not cover. In addition, Specialist BI suite leverage their integrated capabilities, such
as a data lineage from queries or report output, back to the raw SAP source that does not have an equivalent in SAP Business Content. Having
pre-delivered content at your disposal is important in order to eliminate data complexities, but even SAP Business Content cannot cover all
scenarios and requirements. As a result, in some cases the data challenges cannot be avoided, and therefore must be addressed.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                       
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              17

Extracting data from SAP transactional systems faces some of the same challenges as reporting directly from those systems (i.e. knowing where
to go for the data and how to transform it into something meaningful) with the additional technical challenges of streaming the data and handling
delta change capture (i.e. the incremental difference from the last data pull). Both are important for data load performance. Each ETL solution
provider (or Specialist BI suite with ETL capabilities), as well as SAP BW, has a mechanism for handling data streams; handling delta change
capture is much more data source-driven and hence, SAP-centric topic.

The details behind SAP BW delta change capture techniques for extraction are covered in Appendix 7.8. It is intended for extraction
developers that need to understand how SAP BW extraction works for incremental data pulls in order to optimize the performance of their
own development work.

For implementations whose requirements can be met by a Specialist BI quick start offering, the details covered in Appendix 7.8 are probably
more than you need to know. However, the larger and more specialized (i.e. non-core modules) the SAP footprint, the more likely that these
details will be relevant to an architect and extraction developer, and also make SAP BW Business Content more attractive.

Most of the value of Business Content lies in the pre-delivered extractors and metadata (atomic data elements or fields called InfoObjects). The
downstream information models (such as InfoProviders and queries) serve more as templates for reference and reconciliation. Most customers
end up building their own downstream information models from scratch while leveraging the existing InfoObjects and extractors.

As explained in Appendix 7.8, all of the SAP extractors leverage a core interface called the BI service API, which gives Business Content
extractors privileged access to the delta queue. In turn, the delta queue has widespread coverage that helps support faster refreshes of data.
Any external access to the BI service API is not SAP-supported. Nevertheless, some organizations found the Business Content extractors
compelling enough to warrant customizing them in order to feed third-party ETL tools. These isolated approaches have yet to meet with
widespread success, and are, of course, discouraged by SAP.

Instead, most organizations turn to SAP BW and Business Content to get data out of SAP transactional systems and use the SAP-supported Open
Hub Services to distribute data from SAP BW. Open Hub Services export data from SAP BW InfoProviders to file or table which third-party tools
can then read from. Appendix 7.9 explains in more detail.

For SAP BW inbound considerations, where there are requests to pull data out of a legacy EDW in order to integrate the data with SAP data,
there are alternatives to consider beyond data replication. For those environments concerned about data duplication and establishing a universal
source of truth in a separate environment, SAP has EII or federation capabilities. Master data can point to DataSources directly or ABAP code
that reads an outside data source instead of a native SAP BW-generated ABAP table. Similarly, transaction data can be loaded into a Remote
Cube via a DataSource or ABAP code instead of an SAP BW-generated extended star schema.

When evaluating the cost of building new capabilities with either a hybrid approach or a single product approach, the following general
formulas compare the two alternatives (making the sweeping assumption that the benefits can be realized by both approaches within the same
timeframe for comparability purposes):

• Single Product Approach = Cost of Implementing Product Capability + Enhancement Costs + Operating Costs.

• Hybrid Approach = Cost of Implementing Multiple Products’ Capabilities + Cost of Integrating Products + Operating Costs.

In other words, is it cheaper to extend a single product design by filling the gaps with enhancements, or is it cheaper to cover the gaps with
another application and integrate it?

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                    
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                      18

The cost of implementing a product capability is comprised of tangible expenses such as hardware, software and labor, and intangible
expenses, such as business opportunity costs and burned-out resources. Time-to-value is perhaps the largest hidden cost, though difficult to
measure and interrelated with the expected business benefits. Labor is probably the most expensive tangible cost, especially in SAP BW
implementations, and gets much more expensive if customization is necessary. Similarly, with Specialist BI suites offering on-demand (i.e.
software-as-a-service or SaaS) alternatives, this is also the case on a much smaller scale and controlled basis; hardware and software costs are
replaced by ongoing subscription fees as part of operating costs, and labor is shifted to prosumers.

The enhancement cost in SAP BW usually means ABAP for gaps in OLAP capabilities, JavaScript for web-based formatting gaps, or Visual Basic
for workbook-based formatting gaps. Because of the SAP knowledge required for all three types of developments, the labor costs and time to
fulfill requests can be extensive.

                                                                  In contrast, many times there is an alternative solution that can directly address a
                                                                  gap, but the limitation has been the cost of integrating with SAP BW. However,
     Specialist BI suites that provide robust Open                this cost has been effectively absorbed by SAP-committed solution providers, like
     Analysis Interface integration also provide broad            Specialist BI suites, who provide comprehensive MDX and SAP support.
     and deep BI capabilities that can address most               Furthermore, Specialist BI suites that provide robust Open Analysis Interface
     gaps without going to another Specialist BI firm.            integration also provide broad and deep BI capabilities that can address most
                                                                  gaps without going to another Specialist BI firm. In essence, when comprehensive
                                                                  Open Analysis Integration is covered and SAP BEx query performance can
sustain a requirement, then the only real cost to consider (over and above standard product-related skills) is the hybrid skills necessary for
orchestrating the design and implementation. Because Specialist BI tools typically are designed for less-skilled developers and information
workers, the availability of labor for standard product skills should be easier to secure than the hybrid skills necessary to pull it together. Similar
to EA, the customer should develop and own these cross-product skills in their BI competency center rather than looking to market in order to
reduce TCO, as few consultancies have these truly hybrid skills.

For ERP reporting not covered by BI solutions, the cost comparison for the single product approach is the cost of either developing in one of the
SAP native reporting tools (such as SAP Query or Report Painter) or a custom ABAP report. If the reporting needs to be done in ABAP, then all
the complicated business logic and data design must be done regardless, and can just as easily be encapsulated in a RFC-enabled function
module and passed to a Specialist BI tool in a hybrid approach. After the function module, the incremental cost of integration is low as the
Specialist BI can already readily connect to RFC data; all that remains is some metadata mapping, layout development and formatting. If a
custom ABAP report has requirements for numerous custom layout and formatting options that makes a better case to pass the work to an
empowered user in a Specialist BI tool.

When SAP transactional applications need to be brought into a non-SAP BW environment, then the single-product approach in this case may
consist of leveraging a Specialist BI suite to extract directly from SAP into their environment. If one of their pre-packaged offerings meets the
requirements, then the costs are usually fixed and rapid to implement. However, broader-scoped implementations are likely to run into significant
enhancement costs if Business Content extractors need to be reverse-engineered and duplicated.

In contrast, the hybrid approach would be the cost of implementing both SAP BW and Specialist BI capabilities leveraging the Business Content
extractors and Open Hub Services. In this case, the cost of integration would be low, since relatively less labor is required to prepare Business Content
and Open Hub Services. The only potential integration cost is if the third-party scheduler does not already support the new Open Hub Service APIs.
In earlier releases, the Open Hub Services model is similar, except InfoProviders need to be loaded as well, and similar APIs would need to be custom-
developed. Note that the non-trivial semantic integration costs are shared by both extraction options, and therefore are left out in this comparison.

TCO is also directly impacted when information consumers evolve into prosumers and disintermediate BI developers, a proposition that makes
on-demand BI quite promising. A well-known quandary in the IT industry is that business is changing at a pace faster than IT can match. As a

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                           
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                                             19

result, backlogs of projects pile up and even worse, projects that run too long become obsolete or lose value. Time-to-value is not only important
to minimize business opportunity costs, but also for effective resource allocation and operational efficiencies.

Of course, return on investment analysis is more than just evaluating TCO; it also includes estimating business benefits. Evaluating business
benefits is much more difficult to quantify or estimate than costs, especially if it is a question of usability or the value of more accessible
information. The International Organization for Standardization (ISO) defines usability as:

“The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a
specified context of use.”9

Ironically, the difficulty in measuring such intangible value is one of the strongest underlying business drivers for BI. The growing
importance of knowledge workers in value creation activities is a generally-acknowledged trend but hard to empirically measure and
engage. Yet there are visible trends and anecdotes for shift in work that is commanding higher-brain-function activities. Perhaps one of the
more convincing scientific studies that demonstrates the shift from routine and manual tasks to non-routine cognitive tasks (analytic and
interactive) is depicted in Figure 2 below.10

Figure 2 - Skill Content of Technological Change (Autor, Levy and Murane)11
                               Mean Task Input in Percentiles of 1960 Task Distribution













                                                                                               1960             1970           1980                1990   2000

                                                                                                      Nonroutine analytic      Routine manual
                                                                                                      Routine cognitive        Nonroutine manual
                                                                                                      Nonroutine interactive

Non-routine analytic, interactive and manual tasks represent non-repetitive quantitative and reasoning skills, communication and coordination skills,
and ‘hands-on’ or dexterity-related skills, respectively. Routine cognitive and manual tasks are repetitive ‘thinking’ and ‘doing’ tasks, respectively.

Ever-expanding enterprise applications are continuously automating routine manual and even routine cognitive tasks (through operational BI), driving
workers toward non-routine tasks to handle exceptions. Celebrated management guru Peter Drucker noted that amid the information revolution, workers

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                                                    
                   WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                           20

are divided into service workers (performing routine cognitive tasks) and higher value-adding knowledge workers (performing non-routine analytic and
non-routine interactive tasks). For non-routine work, software cannot easily replace people, as in manual or routine work, but rather must support and
enable them “to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” as in the ISO definition for usability.

In this information revolution context, empowering the knowledge worker is perhaps the most important driver for business value creation.

Hybrid architecture strategy forces the need for interoperable solutions. By achieving more open EA, IT environments will become more flexible
and agile in responding to business needs. By leveraging solutions that enable the IT specialist as well as empower the business user,
organizations can then orchestrate their work in a more balanced and collaborative way for maximum business gain.

Two fundamental ways Specialist BI and Niche BI can complement SAP capabilities are in the areas of end-user usability and data integration
(especially non-SAP data and data quality management).

For those customers who are looking for complementary capabilities to their SAP BW and SAP ERP Reporting, it is important to remember that
not all solution providers know how to effectively bolt-on or bolt-in to SAP, even if they are SAP NetWeaver-certified. There are differing levels
of breadth and depth in complementing and integrating with SAP that can make or break hybrid architectures. Only Specialist BI or Niche BI
providers with a detailed understanding of, long demonstrated history with, and high degree of investment commitment in SAP can effectively
make hybrid solutions work. The integration touch points and considerations covered include:

• Data quality management – The best solutions address root causes of defects at the source: during manual data entry.

• SAP BW enterprise reporting, query and analysis – The level of SAP BEx support beyond SAP NetWeaver certification should be aggressively evaluated.

• ERP reporting – Deep knowledge of application-specific data access and technical complexities is essential. The ability to merge SAP BW
  data with ERP Reporting is also an important Specialist BI value-add capability.

• SAP extractions – The same data complexity considerations as ERP Reporting but with additional factors related to Business Content evaluation.

• Open Hub Services – Instead of direct SAP extractions, leveraging Business Content and SAP BW as a proxy to the SAP transactional systems.

All these SAP data access techniques are maturing and are enabling the feasibility of hybrid architectures. Specialist BI and Niche BI solution
providers that integrate with SAP create best-of-both-worlds value propositions that improve the value of their own solutions as well as SAP.

David Dixon is a Vice President at Inforte, a Business & Decision Company, and co-author of the book “Mastering the SAP Business Information
Warehouse.” He joined Inforte in March 2004 via the acquisition of COMPENDIT, an SAP BI consulting firm. David was a founding team
member of COMPENDIT. Prior to that, he was a Platinum Consultant with SAP. David has worked with SAP’s SEM development team on
numerous occasions in support of Business Consolidations and Business Planning and Simulation, and has also continuously collaborated with
the SAP NetWeaver RIG Americas. He started his career in 1995 as a Financials and Controlling (FI/CO) consultant with SAP, specializing in
all of the SAP reporting and analysis applications and tools. David has extensive project experience in implementing complicated global
solutions for Fortune 100 companies and has presented at various SAP and BI forums such as SAP TechEd, TDWI and ASUG.

Inforte, a Business & Decision Company, helps its clients acquire, develop and retain profitable customers with a unique combination of strategy, Business
Intelligence, and CRM consulting services. Our approach enables clients to improve their understanding of customer behavior; successfully apply this insight to
customer interactions; and continually analyze and fine-tune their strategies and tactics. Founded in 1993, Inforte is headquartered in Chicago with offices in
North America, Germany, India and the United Kingdom. For more information, call 800.340.0200 or visit

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                                 
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                     21


The table below can be used as a guideline to evaluate different Specialist BI providers as a BI solution for your SAP environment or as a
standard for all enterprise information (SAP and non-SAP).

  Criteria for Judgment                   Rationale

  Number of SAP customers                 Experienced with numerous customers and different customer deployments.

  SAP partnership history                 Any unique integration co-developed with SAP.

  Breadth and depth of SAP                Solution providers should provide complete solutions that cover information management (data integration,
  complementary capabilities              data quality, data federation, data marts etc) through BI tools and performance management
                                          applications (planning, budgeting, consolidation, profitability analysis, compliance etc.) giving the
                                          customer the option to standardize on the BI Specialist suite.

  Maturity of SAP solution                Multiple iterations and generations of a solution improve robustness of offering.

  Size of organization                    Alleviates vendor viability concerns.

  SAP integration touch points            Number of “Powered By SAP NetWeaver” certified designations. How solution leverages the SAP
                                          NetWeaver technical platform such as integration with SAP security model and ABAP.

  SAP data warehouse and                  Native drivers that provide the ability to create reports directly off SAP BW SAP transitional systems
  transactional reporting capabilities    like SAP ERP.

  Pre-delivered content and               Third-party equivalent to SAP Business Content that helps accelerate projects with pre-packaged
  templates for SAP Solutions             developments that address SAP-specific complexities or template offerings for SAP-specific scenarios.

7.2 SAP PLATFORM CONSIDERATIONS                                                   Aside from cultural and competitive reasons, the fundamental
The bane of SAP’s existence has been usability and openness.                      technological legacy that constrained openness and usability has
Although SAP has come a long way on both fronts, it still has yet to              strong roots related to a four-letter acronym: ABAP. ABAP stands
definitively shed its reputation in BI. Perhaps the recent SAP move to            for Advanced Business Application Programming and started as
acquire Business Objects will help wipe this stigma clean.                        a   report   generation    programming       language     for    SAP’s
                                                                                  mainframe-based solution known as SAP R/2.® ABAP then
Understanding where and why SAP struggles, and its historical context,            evolved into a full- blown IDE when SAP migrated SAP R/2 to a
lends insight to how and when to complement its capabilities with other           client-server based solution called SAP R/3.®
solutions or approaches. With a fast-growing and evolving partner
ecosystem on the SAP NetWeaver technical platform, understanding                  ABAP is an SAP-proprietary programming language, so since
how third-party solutions complement SAP is increasingly important.               inception it has not been portable to any environment other than SAP.
Whereas some third parties such as Specialist BI firms found a distinct           Ironically, this made ABAP even more “open” than most other
niche in the early SAP market providing more open and graphical                   applications, since all of SAP’s source code is exposed to anyone that
tools, that differentiating gap is becoming less obvious.                         knows how to read ABAP; it just wasn’t as technically interoperable as

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                           
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions               22

it is today. This enabled programmers to dive into the ABAP IDE in        technology and entitled it NetWeaver Business Client (NWBC).
order to enhance and even modify—against recommendations—SAP              SAP has also partnered with Microsoft to create a joint-
applications. But getting SAP to talk to outside languages required an    development offering called Duet, which integrates SAP into
SAP proprietary library and files to be installed that varied by          Microsoft Office. In addition, SAP has partnered with Adobe to
platform, if supported, as well as other technology restrictions.         create yet another user interface alternative called Adobe
                                                                          Interactive Forms. Furthermore, SAP NetWeaver Mobile is a whole
ABAP started as a fourth-generation language (4GL) that was first         platform offering around developing mobile device applications.
developed in an era where many vendors were looking for ways to
abstract and improve on COBOL (considered 3GL). Even today, an            SAP is decoupling the user interface from the ABAP-driven back-
estimated three-fourths of all computer transactions are still in         end, thereby opening the business case for third-party front-end
COBOL, with an even greater footprint for financial transactions.         tools wider than even before. New value in SAP can be created by
For business applications, COBOL has substantial credibility and          giving it a new face but relying on its application logic backbone
history, and correspondingly, so does ABAP.                               through enterprise services.

When the author first started coding ABAP in SAP R/3 (about three         But usability is not just about the chosen programming language,
years after SAP R/3 was officially launched in 1992), he found the        nor is openness just about technical interoperability or portability;
similarities to COBOL striking, as did others who dubbed it               both are just low-level constraints or enablers. Intuitive design in the
“German COBOL.” Just as COBOL has evolved to become more                  front end and semantic integration in the back end are much higher-
object-oriented and interoperable, so has ABAP; but to give ABAP          level and higher-impact factors.
credit, perhaps it is even more advanced than COBOL. However,
just as very few developers would position COBOL for high-end
graphical user interface (GUI) developments, ABAP has suffered a          7.3 SAP FRONT-END HISTORY
similar fate. Although SAP has ABAP-based graphical capabilities          The author made an early career out of being an SAP financial
much stronger than anything that evolved for character-based              reporting specialist due to the level of mastery needed to efficiently
COBOL, SAP has long recognized that it needed an alternative              develop SAP R/3-based reports. The early application-specific (like
technology to build GUIs.                                                 the Legal Consolidations Report Writer) and generic report writers
                                                                          (such as Report Writer and ABAP Query) shared a similar design
Well before the launch of the SAP NetWeaver offering, SAP had             paradigm: development was logic and form-driven rather than
plans to incorporate Java into its platform in order to exploit the       visual and layout-driven. Similar to the rest of SAP R/3, report
market-leveling qualities of Java. As early as December 1998, SAP         development was transaction-driven and consisted of form-based,
revealed to the market its intention to move towards Java in order        screen-by-screen sequential steps.
to address usability and openness issues. Almost a decade later, a
Java stack embedded in SAP’s application server platform is an            Since report development was highly conceptual and configuration-
active reality with support for the latest release (Java Platform         driven, this high-level step-by-step description of the SAP Report
Enterprise Edition 5).                                                    Writer conveys the gist of “developer-centric design.” The work was
                                                                          broken down into logical units:
With Java-based capabilities, SAP has developed rich Internet
applications (RIA) such as its SAP NetWeaver Visual Composer tool         • You first start with the report creation transaction where a form-
that can be modeled and deployed from the Web for building                  based input screen prompts for a library name (which represents
dashboards or analytical applications. SAP is also well poised to           the reporting structure) and the report name, which effectively
take advantage of the latest Web 2.0 innovations and leverage               makes the assignment.
partners with Java-based strengths such as their fully embedded
                                                                          • In the next form-based screen you are prompted for header-level
Adobe Macromedia Flex capabilities (via OEM).
                                                                            details such as report text and authorization group assignment
                                                                            (obviously nothing a user would do).
In addition to browser-based user interfaces enabled by its Java
stack, SAP has redesigned its desktop client leveraging Microsoft

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                    
                    WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              23

• On the next screen, you define row sections by entering texts,            approach (namely, abstraction and reuse), but this approach
  and then control their formatting by configuring indicators for           normally confounds typical users that expect a more direct method.
  options like zero handling, indentations, alignment justification,        More explicitly, SAP BW logically separates information design
  page breaks and borders.                                                  (data unions and joins), query design (information subsets, OLAP
                                                                            definitions and calculations) and presentation design (formatting
• Then within each row section (in another drill-down screen) you
                                                                            and layout) from each other.
  enter row blocks, which are either a reference to hierarchies,
  formulas or metrics. Again, on each row you control formatting
                                                                            The SAP BW information design is done by a back-end tool called
  options by setting configuration switches. In either row section or
                                                                            the Data Warehouse (DW) Workbench. Data unions (to combine
  row block there are also “business intelligence” settings such as
                                                                            data sets) and joins (to link data sets) are done by structures SAP
  subtotaling logic, sorting, thresholds and traffic light colors.
                                                                            calls Multi-Providers and InfoSets, respectively. These structures
• Then column blocks are defined on another screen, and are are,            (generically referred to as InfoProviders) are centrally defined and
  once again, either references to hierarchies, formulas or metrics         created by developer specialists.
  belonging to the library with associated configuration switches
  for formatting.                                                           In contrast, the query design is developed with a front-end tool
                                                                            called the SAP BEx Query Designer. SAP BEx Query Designer is
• Then on another screen, the general data selection criteria are
                                                                            conceptually similar to the Report Writer in terms of how it logically
  defined which act as filters or variables to the report.
                                                                            separates the components of a query. However, instead of flipping
• A final optional screen can be configured with printing options           through form-based screens, the general data selection (called
  such as headers, footers, title page and last page.                       filters), rows and columns are all presented in a layout logically
                                                                            separated into separate tabs or panes. Furthermore, the standalone
Up until this point, the developer must conceptualize what the              tool is in a much more user-friendly .NET-based environment. The
output looks like until the report is actually generated and executed.      equivalent of the library (i.e. the InfoProvider) is also displayed and
What ensued for novice report writers was an iterative trial-and-           its data elements can be dragged and dropped into the different
error process until the output looked correct.                              panes to subset the data and parameterized to control the output.

It was not long before Report Writer was displaced by Report                Although a conceptual tabular rendering is displayed during
Painter, which was layout-driven and mostly defined on one screen.          development, the SAP BEx Query Designer does not have an actual
However, it was still an abstraction for the actual output, although        picture or preview of what the output will look like until the query is
more visual. ABAP query development (presently known as InfoSet             executed. The “look-and-feel” of the output also depends on the default
query) has become even more graphical with a query painter                  template or pattern, which applies styling, formatting and functions
option and the ability to define table joins as in MS Access.               available that are separately defined (another reusable abstraction).
However, these tools are still ABAP-based, and most practitioners
will agree that the SAP’s BEx front-end is far more advanced in             In addition, there are optional standalone presentation design tools
usability for both the developers and user perspective. In fact, there      (such as the SAP BEx Web Application Designer for web
have been ERP implementations where users threatened to stop go-            applications and SAP BEx Analyzer for MS Excel workbooks) that
live unless given alternatives to the native SAP ERP reporting. This        use graphical layout-based designer tools, where presentation
difference in capabilities drives SAP Business Suite implementations        items can be dragged and dropped (like buttons, tabular data
to SAP BW, which is perhaps a strategic outcome desired by SAP.             grids, graphs, charts, and so forth). Each of these items is
This difference also gives a business cause to employ a Specialist          represented by an icon and a true picture of the output filled with
BI tool without the need for a data warehouse or even a data mart.          data is not seen until actual time of execution (e.g. the layout gives
                                                                            you a general idea of where a radio button group or tabular grid
The design paradigm of logically separating design into different           might drop into a cockpit, but you don’t see the number of radio
stages has carried through to the SAP BW to some extent. There are          button values that will display or the row and column structure until
developer advantages to taking a methodical “building blocks”               the cockpit is filled with data at runtime).

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                     
                   WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                24

Many of the OLAP and formatting functions and features that can               activities, but both are done via the SAP NetWeaver Portal instead
be predefined at design-time in the SAP BEx Query Designer are also           of separate environments or standalone tools.
available to the user at runtime besides just drag-and-drop slicing-and-
dicing. This led to a stand-alone tool called SAP BEx Web Analyzer.           In contrast, established Specialist BI tools typically do not separate
The SAP BEx Web Analyzer tool has many of the same runtime                    information design, query design and presentation design into
capabilities as its developer-centric counterparts (i.e. SAP BEx Query        standalone tools or reusable development objects. Instead, Specialist
Designer and to a lesser degree the SAP BEx Web Application                   BI tools combine them all together in one report development or ad
Designer); the difference is that it does not logically separate design       hoc analysis experience in order to give end-users quicker time to
time from runtime (i.e. they are the one and the same). “Development”         value. Furthermore, the distinction between design time and runtime
or the navigation state is saved as a bookmark for reuse or reference.        are blurred through true WYSIWYG capabilities. Users or less-skilled
Furthermore, no pre-defined queries are necessary, as this can be             developers are empowered to do a lot more on their own through a
done ad-hoc via the web as well (following similar logical                    high degree of graphical control and visualization, thereby
development steps as in SAP BEx Query Designer).                              disintermediating the developer specialists. Such autonomy and self-
                                                                              service capabilities do raise governance and reusability issues that
However, the SAP BEx Web Analyzer was just introduced in the most             should be addressed by holistic EA strategy (i.e. without the SAP
current release of SAP BW, and is still far from reaching parity with the     blinders) and organizational design.
SAP BEx design-time tools. Similarly, SAP NetWeaver’s Visual
Composer has not yet replaced the SAP BEx Suite in reporting
capabilities, nor is it yet clear that it will do so. Furthermore, back-end   7.4 QUERY DESIGN FOR
InfoProviders still need to be defined for all sources of SAP BW data,        OPEN ANALYSIS INTERFACES
whether SAP NetWeaver Visual Composer, SAP BEx Web Analyzer,                  Design separate and controlled SAP BEx queries specifically for
the SAP BEx Suite or a Specialist BI tool is used.                            Specialist BI or Niche BI access that are separate from BEx queries
                                                                              used for SAP BW reporting, query and analysis.
As the name suggests, SAP NetWeaver Visual Composer is a
graphical and visual design tool for developing SAP NetWeaver                 There should be no more than one external access query per data
Portal content. It is a relatively new, rapidly evolving product that         structure in SAP BW (i.e. InfoCubes or Multi-Providers for
is clearly born of Java, suffering none of the graphical and                  dimensional structures and DataStore objects or master data for
openness challenges of ABAP world but with the advantage of                   relational structures). The SAP BEx query then becomes the proxy
being able to interoperate with ABAP through remote function                  for the data structure. Whether you allow access to the EDW layer
calls (RFC). As a result, however, it requires the use of SAP                 is a case-by-case strategic design decision. But generally, basing
NetWeaver Portal and is not available as a standalone tool for                these queries off of integrated data marts (InfoCubes or Multi-
desktop integrations or offline capabilities.                                 Providers) proves better for performance and saves the reporting
                                                                              and analysis users design work on which they can build.
SAP NetWeaver Visual Composer is a much broader tool for
reporting or even dashboard deployments, and has been                         The queries should have all the detailed fields needed for reporting
integrated into the recent and more holistic SAP NetWeaver                    and analysis defined in the free characteristics with optional
Composition Environment platform for Java-based developments.                 variables (which makes them available but does not immediately
SAP NetWeaver Visual Composer is engineered for model-driven                  pull all data, and also makes them all filterable).
developments that are perhaps more process design-centric (i.e.
flow diagramming) than information–design-centric (i.e. entity-               Global metrics, calculations or columns should be defined as
relationship diagramming). For example, it lacks information                  restricted key figures, calculated key figures or structures,
design capabilities such as inner and left-outer joins, as well as            respectively (these are defined in the query but makes them part of
native OLAP capabilities, such as support for drilldowns and                  information design for Specialist BI queries). Local metrics,
hierarchies. Nonetheless, SAP NetWeaver Visual Composer does                  calculations or columns can be pushed down to Specialist BI tool
have a graphical layout tab that gives a better visual clue of output         users. These local definitions should be reviewed and governed to
then the SAP BEx designer tools. SAP NetWeaver Visual Composer                identify designs that are better pulled back into the global design
also makes the sharp distinction between design-time and run-time             for reuse and standardization.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                       
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions          25

In order to enable a SAP BEx query for external data access, it must be released by flagging an indicator for OLE DB for OLAP (ODBO)
in the query properties. ODBO is a widely supported Microsoft standard that extends its Object Linking and Embedding Database (OLE
DB) specification to OLAP. As ODBO is a Microsoft standard using the COM (Component Object Model) platform, it requires some
Microsoft files to be installed on the client system. Alternatively, the same interface (called the OLAP BAPI) can be called via an SAP
connection, but in this case SAP files need to be installed on the client in order to establish the RFC connection. In order to avoid these
client files and be desktop independent, there is a newer third option called XML for Analysis (XMLA), which leverages the web standards
XML (Extensible Markup Language), HTTP (Hypertext Transfer Protocol) and SOAP (Simple Object Access Protocol). Just to review the
standards: XML is to encode documents with tags to give it structure, HTTP is the communications protocol for passing information through
the web and SOAP is a protocol for exchanging XML-based messages.

SAP refers to all three APIs as their Open Analysis Interfaces, and they all work off of the same ODBO-released queries. All Open Analysis
Interfaces use the industry-adopted OLAP language created by Microsoft called MDX (Multidimensional Expressions). MDX was first
introduced as part of the ODBO specification in 1997 and stabilized by 1999 (latest version update of ODBO). Think of MDX as the
query language to multi-dimensional data in the same way that SQL (structured query language) is the query language to relational data.
A version of Table 1 can be found on SAP help but is summarized here for quick reference on the comparisons.

Table 1 - Comparison of the SAP BW Open Analysis Interfaces

                                    OLE DB for OLAP (ODBO)                OLAP BAPI                           XML/A

 Communication layer                COM (Component Object Model)          RFC (Remote Function Call)          XML using SOAP over HTTP

 Prerequisites for the client       Driver installed on client system     Only one library needs to           None
                                    (registration of ODBO Components      be installed and registered.
                                    consisting of a few of DLLs)          Access library available from
                                                                          all SAP platforms

 Query language                     MDX                                   MDX                                 MDX

 Platforms                          Windows                               SAP platforms                       Platform independent

 Availability                       As of SAP BW 1.2B                     As of SAP BW 2.0A                   As of SAP BW 3.0A

 Unicode Capability                 Fully Unicode-enabled                 The caller specifies the            Fully Unicode-enabled, by
                                                                          required Code Page when             default UTF-8 (Unicode
                                                                          establishing the RFC connection.    Transformation Format,
                                                                                                              8 bit display).

What all these acronyms mean is that all third-party BI tools have a standard way of accessing SAP BW data through the SAP OLAP processor.
However, only the SAP BEx Suite works directly against the native OLAP processor using ABAP as the language to access SAP BW data. In
order to translate to MDX (for Open Analysis Interfaces), SAP developed an MDX processor on top of the native OLAP processor and contracted

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                               
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              26

Simba Technologies to develop the ODBO provider in parallel. The work completed in 1998 as part of SAP BW 1.2B. Since then, the OLAP
BAPI and XMLA were released to round out the Open Analysis Interfaces as part of SAP BW 2.0A and SAP BW 3.0A, respectively. The
architecture of Open Analysis Interfaces reproduced from SAP help documentation is illustrated in Figure 3.

Figure 3 - Architecture of SAP BW Open Analysis Interfaces

                                                                 Web Browser                        Rich Client

                                       Web Service                                                    COM

                                                                                                 OLE DB for OLAP

                                            HTTP SOAP                                                   RFC
                       BI SERVER

                                            XML for Analysis                                OLAP BAPIs

                                       SAP BEx                   MDX Processor

                                                                                                        Meta Data
                                                                 OLAP Processor

                                                                     DataStore                   Master Data

After ODBO was first introduced close to a decade ago, Specialist           be done via Multi-Providers in SAP BW). In addition, SAP slightly
BI suites and MDX-focused Niche BI firms have either closed or              extended MDX so that it could support its SAP BEx variables.
narrowed the gap from rocky starts.
                                                                            In contrast, Specialist BI provider support for Open Analysis
Fortunately, MDX is a proven standard with a lot of industry                Interfaces has varied greatly and is at different levels of maturity.
adoption even though it is Microsoft standard (with healthy                 For SAP shops considering adding a specialty BI tool to the
expansion to the web-based XMLA from ODBO roots). Practitioners             complement SAP BW, this level of integration with open analysis
will swear by it, and there are vendors other than Microsoft that           interfaces one of the most important solution criteria to evaluate.
have built their products and company around it.
                                                                            Simba Technologies indirectly tested all of the Open Analysis
As SAP contracted support for its ODBO provider from Simba, Open            Interfaces against each other and the native SAP OLAP processor
Analysis Interfaces had always provided close to full coverage for          by selecting a number of Specialist BI tools and SAP BEx Analyzer
MDX (at least currently, there only a few minor exceptions such as          to run four series of tests on SAP demo content.12 What Simba was
some metadata search and the ability to combine MDX cubes that can          found was that for the same data and similar outputs the

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                    
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions         27

performance times greatly varied depending on the solution                  novice vendors may fail to account for by treating both
provider tool. The tests analyzed three potential factors:                  structures the same way.

                                                                          • Handling all the different types of SAP BEx variable inputs and
• The type of Open Analysis Interface that was being called.
                                                                            incorporating them into queries—a uniquely SAP concept.
• The efficiency of the MDX statement that was being generated by           Each variable is assigned one of five variable types
  the application.                                                          (characteristic value, hierarchy, hierarchy node, text and
                                                                            formula) and one of five processing types (manual or default
• The efficiency of the application after it received the data.             entry, replacement path, customer exit, SAP exit or
                                                                            authorization exit) that drive a diverse set of behaviors.
What Simba’s tests and conclusions highlight is that even if a
                                                                          • When third parties use the interface to replicate data for local
solution provider is certified in one of the MDX-based interfaces           OLAP analysis, not only is data duplicated but also SAP BW
doesn’t mean there is parity with other certified solutions from an         OLAP definitions may be lost. For example, SAP-defined
SAP integration perspective.                                                exception aggregation (or semi-additive) behaviors are lost
                                                                            when the connection is dropped.
Furthermore, what the tests did not cover is how comprehensive
                                                                          • SAP-relevant query output considerations such as currencies,
or rudimentary a solution provider support is for MDX from a
                                                                            unit of measures and hierarchy-awareness.
functionality perspective. There is a difference between
mandated MDX for the Microsoft specification and optional MDX             • The use of SAP BW time-dependent master data, hierarchies
that can have an impact on performance.                                     and hierarchy structures including capabilities to set the
                                                                            correct reference date (commonly used for reorganizations
                                                                            and financial restatements).
However, the level of MDX sophistication is trivial in comparison
to other factors impacting SAP BW integration. Deliberate
engineering around SAP-specific concepts, conventions and
                                                                          7.6 ABAP-BASED DATA ACCESS
metadata is the far greater challenge. The fact that SAP adopted
                                                                          Early SAP users discovered that it was better to read from the
a Microsoft standard for querying its data does not abstract
                                                                          SAP application server layer than its database layer because of
away SAP complexity; in fact the situation is quite the opposite.
                                                                          SAP’s three-tiered client-server architecture. The SAP application
Vendors integrating with SAP BW via open analysis interfaces
                                                                          server has logical objects and data that the database does not,
must be intimately aware of how SAP BEx works besides simply
                                                                          and is only accessible via ABAP. For example, the application
understanding how to call the interface.
                                                                          server has its own buffering and locking that stores data before
                                                                          it commits to the database. Furthermore, how data is stored in
Some common problems that novice third-party vendor integrations          the database may be very different than how it is represented in
encounter with Open Analysis Interfaces stem from failing to take into    ABAP, and in turn how it is presented to the user. Significant
account the full range of SAP BEx capabilities. Common problem            data transformation can occur as information passes through the
areas with Open Analysis Interfaces include (but are not limited to)      three-tiered architecture.
how complementary tools handle the following scenarios:
                                                                          For example, in the early days of SAP R/3 the application had
• Metadata translation and synchronization of SAP BW and the              more tables than the database systems it supported could
  local third party BI environment. SAP maps SAP BEx queries to           manage. So SAP created what it called pooled tables, which
  the MDX schema which in turn maps to third party metadata               grouped several logical tables into one physical database table
  conventions; the translation of which is not always natural             using a particular convention that saves data as strings. Pooled
  causing potential confusion.                                            tables (which are one-to-many ABAP to database tables) appear
• In particular, the use of both row and column structures in SAP         the same as transparent tables (which are one-to-one ABAP to
  BEx Queries may create a confusing mapping to the                       database tables) in the ABAP dictionary. The SAP financial line
  dimensions and facts of third party metadata; a scenario that           items table is an example of a pooled table.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                               
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions           28

But the data transformation journey does not stop at the ABAP             SAP expertise will have explicit support for reading against
data dictionary layer; there can be further application-specific          transparent tables, HR Infotypes, classic InfoSets (which can also
conventions applied to ABAP dictionary tables to make the data            cover logical databases) and BAPIs, as well as example template
intelligible. Similar to pooled tables, SAP has another table type,       scenarios. Anything else needs to be coded as custom RFCs that
called cluster tables, that allows for complex data objects in            can replace customary ABAP report programs. Some solution
ABAP memory to be persistently stored without flattening                  provider also provide integration to well-known RFC-enabled APIs
operations.     However, these structures have a separate                 for SAP currency translations and unit-of-measure conversions.
convention and data structure that requires special application-
specific logic and ABAP syntax to read (using IMPORT instead of           Interestingly, these same RFC-based data access techniques can
SELECT command statements). The HR payroll databases are                  be used to read SAP BW data without the need to go through the
examples of cluster tables.                                               SAP-endorsed open analysis interfaces. The SAP Data Manager
                                                                          (called by both the OLAP processor and the DW Workbench
SAP also has a concept it calls logical databases, which                  transaction to display InfoProvider data) can be directly invoked
represents a hierarchy of reporting structures that are populated         via an API. This API is not RFC-enabled, so a “wrapper” API
with values via ABAP programming. The structures in the                   needs to be programmed in order to make it generally available.
hierarchy may or may not represent actual tables. Logical                 SAP has documented this API as the Data Mart interface.
databases are popular for reporting because they encapsulate              Similarly, master data has a documented API that is already RFC-
complicated data models into a standard object for reuse.                 enabled. For DataStore objects in particular, there is an SAP-
However, ABAP reports that use logical databases have to follow           endorsed BAPI that some products already explicitly support,
a specific programming structure and convention.                          which reads the flat structure that is commonly used as an EDW
                                                                          or staging layer in best practice SAP BW environments.
An easier use of logical databases is to use them in InfoSets
defined by the SAP Query reporting tool (similar in concept but
not to be confused with SAP BW InfoSets—the ERP reporting                 7.7 SAP BW METADATA
structures are sometimes referred to as “classic InfoSets” to             What follows is a comparison of SAP BW to traditional BI
distinguish the difference). Furthermore, SAP query can be used           concepts. It is intended for those organizations that have
to list report against transparent tables and graphically defined         implemented SAP BW and are struggling with making it fit with
join logic defined in classic InfoSets. Similarly, Report Painter         the rest of their BI landscape. The basic premise is that paradigm
reports can be defined against simple transparent table                   differences between SAP BW and traditional BI can cause
structures via LIS, or against Report-Writer specific logical tables      change management clashes that need to be reconciled before
that are filled via specialized application-specific programs. In         the technological differences can be sorted out. Strategic
some cases, this logic is also encapsulated and abstracted via a          questions also must be raised as to which paradigm needs to be
BAPI that performs functions such as reading the complex data             embraced, extended or extinguished.
structures of the Controlling (CO) module for management
accounting.                                                               The way logical data models are designed and developed in
                                                                          SAP BW is typically different than in traditional EDW or data
All of these SAP-specific considerations make it impractical for any      mart environments. Figure 3 below compares how SAP BW
Specialist BI tool to report directly out of the SAP database.            modeling works vis-à-vis a traditional approach with EA and
Furthermore, when shopping for a Specialist BI provider to do SAP         data modeling tools, and compares them to the Object
ERP reporting, the product should not only account for the SAP-           Management      Group     (OMG)     consortium’s    Model-Driven
specific technical complications but have pre-delivered content in        Architecture (MDA) specification standard.
order to accelerate development. Established solution providerwith

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                
                                WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                        29

Figure 4 - SAP BW modeling concepts

                                 Base Level:                    Modeling in a technology-
                                                              independent UML profile allows
                          UML Platform-Independent                                                             Enterprise Architecture Models and Tools
                                                                 a precise representation of
                         Model of Business Functionality
                                                                   business process/rules.
                                 and Behavior

                                                               Executed by MDA tool which

                                                             follows OMG-standard mapping.
                                   Automated                  Recruiting PSM may need some                 MetaData Interface                   XMI Import/Export
                                 Transformation                  hand adjustments based on
                                                                   infrastructure decisions.

                            Intermediate Level:              Modeled in a technology-specific
                          UML Platform-Specific Model(s)      UML profile. Represents every
                                                              aspect of a coded application,            Logical Data Models             SAP BW Metadata Repository
                             on reflected platforms
                              generated from PIM                   but still as a model.

                                                                    Executed by MDA tool.
                                   Automated                       Many tools on the market                    Translator                        DW Workbench
                                 Transformation                   execute this step very well.

                                                              Generated code and auxiliary
                                  Top Level:
                                                                files ready for completion,
                           Implementation(s) generated                                                 Physical Data Models                 SAP ABAP Repository
                                                               linking with legacy or other
                                   from PSMs                       code and deployment.

                                                                                                               DDL Script                           DB Connect

                                                                                                              DBMS                                  DBMS

First, separate standalone metadata design tools are not employed                                one level. In other words, InfoCubes are structures that join master
to build logical and physical data models in SAP BW; everything is                               data with transaction data directly. Users “configure” DataStore
developed and administered in the DW Workbench at the logical                                    objects similarly by graphically dragging and dropping InfoObjects
layer only. Second, the build of the logical models are more                                     into either a key field grouping (one that defines the primary key) or
abstract                 and    configuration-driven       than    data-diagrammed.              data field grouping. After saving and activating a standard DataStore
Information design is not done by logical entity-relationship                                    object the system generates a group of three tables (one for updating,
diagramming (ERD), but rather by defining SAP BW data objects                                    one for activating and a change log for tracking before and after
that have an underlying implicit ERD built in.                                                   images). These physical tables are generated in the ABAP dictionary,
                                                                                                 which would normally map to physical data models in a standalone
More explicitly, SAP BW has two fundamental data objects to choose                               metadata management tool. Whereas the SAP application server then
from for storing transactional data: dimensional structures called                               automatically activates and adjust the database, the metadata
InfoCubes and flat structures called DataStore objects. Users                                    management tool would generate a Data Definition Language (DDL)
“configure” InfoCubes by graphically dragging and dropping fields                                script that executes SQL to physically create or modify tables in the
(called InfoObjects) into dimensional groupings or a fact grouping.                              database system.
After saving and activation, the SAP BW system then automatically
generates what SAP calls an extended star schema. For BI                                         The SAP BW system generates its “best practice” schemas that
practitioners, that is a star schema that is snow-flaked or normalized                           cannot be altered (i.e. further normalized or de-normalized) at the

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                                             
                    WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                   30

physical    data    model     layer    without    serious     modification      attributes of a vendor on a purchase order modeled as master data).
repercussions. This logical layer can be read by any third-party                Transitive attributes need to be redundantly brought into the extended
metadata tool that accepts XML Metadata Interchange (XMI)                       star schema as navigational attributes for reporting purposes.
imports, which is an abstraction layer higher than data modelers
immersed in the relational world are used to playing in. It is a                In addition, data engineers may find the SAP BW metadata
Unified Modeling Language (UML) standard set by the OMG                         repository inflexible for a number of reasons. First, it is not a
consortium for sharing models across platforms. SAP BW also has                 standalone repository, but rather tightly coupled with SAP BW.
an XMI import option so these models can be externally developed                Second, definition history or versioning is not stored anywhere;
and imported, a practice which has yet to become commonplace.                   there is only business content, modified and active versions as well
                                                                                as transaction event logs. Third, multiple InfoObjects cannot be sub-
Perhaps because SAP applications were born out a configuration-                 typed or super-typed (i.e. applying inheritance principles) but rather
driven, three-tier, client-server model, SAP BW development                     created as completely separate InfoObjects (creating significant
abstracts the database details that most traditional EDW or data                master data redundancy) or with reference to each other (with
mart developers live and breathe. This thereby creates a change                 updates restricted to only the parent).
management impact that begs the strategic question of whether this
level of control is more effectively wielded by a system (SAP BW)               Lastly, non-SAP BW practitioners may find SAP BW data lineage
or experts (traditional BI data modelers).                                      capabilities lacking. One of the criticisms of Business Content
                                                                                extractors is that although it abstracts a lot of complexity, it is also
Furthermore, EDW purists may find a rigidity and lack of data                   a data lineage “black box.” The argument it that as long as
designer control in order to address what might be perceived as                 Business Content can be used out-of-the-box then it is acceptable,
gaps in the SAP BW delivered schemas. For example, DataStore                    but once additional fields need to be added, mapped and sourced,
objects are not designed to capture all historical changes, but are             as well as reconciled back to underlying source tables, then data
designed to overwrite latest changes. Some SAP BW customers that                lineage documentation is needed. Furthermore, once the data is
perceived this design as an EDW requirement gap addressed it by                 loaded in SAP BW there is no data lineage capability that can take
adding a timestamp (or something similar) to the key of a DataStore             a data element in a report and trace it all the way back to the
object, or saving off the change log details. Both approaches have              extraction source, as can be found in some Specialist BI suites.
a customized ABAP programming impact that may have been
avoided by simply adopting the SAP BW convention or leveraging
an existing legacy EDW that supports this capability. Another                   7.8 SAP DELTA CHANGE CAPTURE
possibility is that this customization was effective in order to be             FOR EXTRACTION
used in federated warehouses but also comply with EDW                           Capturing changes on all records can be a complicated affair that even
standards. Regardless, EDW corporate philosophy is an important                 SAP Business Content has missed (but then corrected) in the past. Since
discussion point when incorporating SAP BW.                                     transactional data is normalized (or split) in many different tables, any
                                                                                normalization (or bringing together) of those tables can create data
As another EDW example, because InfoCube extended star schemas                  realignment scenarios where one table change requires a refresh of all
cannot be flexibly defined (i.e. further normalized or linked to any            tables. For example, financial documents are generally comprised of
table), scenarios are created where transactional data is also                  two tables: a header table and a line item details table. Both tables are
redundantly stored as master data in order to achieve better flexibility        extracted together as a financial document transaction by SAP Business
(e.g. standard change run realignments) and performance (i.e. BI                Content. Each table has text fields associated with them that can be
Accelerator and aggregates only support InfoCubes). As a specific               changed after a document is posted. If either the header text or the line
example, some environments have modeled purchase orders as master               item text is changed, the whole document must be re-extracted. In more
data in order to better handle volatile changes in the orders rather than       complicated extractors, or even BI data models where multiple sources
historically saving it as dimensional attributes with an InfoCube. But this     of data are integrated (typically the case when marrying logistics with
approach creates new challenges, such as performance and the                    financials), there can be more complicated technical scenarios such as
handling of ‘attributes of attributes’ (what SAP calls transitive attributes)   data volatility, absence of an event trigger and update timing
which fall outside the extended star schema (such as a geographical             differences (such as batch scheduling).

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                           
                  WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions              31

SAP BW has two fundamental ways for identifying delta changes:            changes. For example, if a document is changed several times in
timestamps (or datestamps) or delta queues.                               the same day (datestamp stays the same) or several times since the
                                                                          last extraction (datestamp updated), the timestamp approach will
The timestamp approach is the most popular and straightforward            miss those changes even if the time of change is also recorded,
approach when it is available. The mechanism is similar to a full         unless new records are generated. Because the delta queue is
load extraction, but is restricted to a date range of the most recent     event-driven, all the change events should be registered. One
transactions. Some SAP extractors also add what is referred to as         advantage the timestamp approach has is the ability to repeat date
a “safety delta,” where the date range is expanded to capture time-       range extractions. The SAP delta queue does have a repeat mode
overlapping records for each delta pull in order to ensure records        where data from the last extraction is still kept as a fail-safe.
are not missed. For frequent updates, this might happen if there is       Although the delta queue is engineered to support multiple target
a memory backlog that has not yet been committed to database or           systems, third parties do not typically integrate with this mechanism,
if a transaction is asynchronous (i.e. passed off to another work         as it is part of the SAP proprietary BI service API (the interface used
process and queued for update). The downstream overlaps then              by all SAP Business Content extractors).
can be resolved by comparing the last load with current load and
reconciling the difference. In SAP BW, this is essentially done with      Conceptually, another type of delta queue approach is to track
DataStore objects and their change log and activation functions;          changes in a separate log and then read the log during
third-party ETL products typically handle this approach as well.          extraction in order to propagate changes. In SAP, ALE change
                                                                          pointer technology takes this approach. ALE is SAP middleware
The delta queue approach is more sophisticated with technical             technology to integrate SAP systems with other systems (SAP or
variations. Conceptually, delta queues are separate storage areas         non-SAP including SAP BW). ALE uses the standard SAP format
that are written to after an event change (record creation, change        for electronic data interchange, called IDocs (Intermediate
or deletion) and emptied after extraction. This eliminates the need       Document), to pass messages and data across networks. ALE
for any safety delta and downstream reconciliation of redundancy.         change pointers were used to identify the master data changes
It is more of a fail-safe mechanism that can conserve space by            that needed to be replicated in a distributed SAP landscape. The
storing pointers to the real data. SAP BW has a generic delta queue       BI service API leverages this infrastructure for some of its master
as a shared service for many extractors. The same delta queue is          data extractors for delta change tracking. ALE change pointers
also used in SAP BW in order to accept pushed records from SAP            track the keys of all changed data records in a separate table
Exchange Infrastructure (XI) or third-party Enterprise Application        and are designed only to deliver the latest version of an entire
Integration (EAI) product. The SAP delta queue actually tracks, in a      data record versus field level changes.
compressed format, “before” and “after” images of all changed
data records, allowing identification and tracking of every single        Third-party ETL products typically support ALE change pointers as
field value change accessible and administered via a check tool.          well. They also support Idocs, which should not be confused with
The way transactional systems update the delta queue can vary             ALE change pointers. To read from ALE change pointer tables,
from application-specific logic to general frameworks. One popular        developers do not necessarily need to use IDocs or ALE, which
framework is what SAP calls business transaction events (BTE),            are downstream mechanisms to store the changes in a message
which are heavily used by the SAP Advanced Planner Optimizer              structure and to communicate to the other systems, respectively.
(APO) product but also leveraged for SAP BW extractions. BTEs are         Similarly, developers do not need ALE change pointers to create
interfaces in the logic for document posting that can be hooked into      IDocs. A case in point is the SAP BW extractors that read the
by outside applications like SAP APO, SAP BW or even third                delta queue in order to generate IDocs to pass to SAP BW via
parties. Another framework for LIS extractions asynchronously             ALE. IDocs are the standard structures used to pass SAP
updates the delta queue directly via a special periodic batch job.        information over networks to other systems. They are typically
                                                                          purged from the system as part of operations, but can be
One advantage the delta queue approach has over the timestamp             leveraged by ETL vendors as another delta change capture
approach is that the delta queue tracks all changes between               mechanism.
extractions, while the timestamp approach only grabs the latest

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                   
                       WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions                                             32

7.9 OPEN HUB SERVICES                                                                            has only two downsides in comparison to extracting directly from
In the latest release of SAP BW, SAP supports the direct loading of                              the SAP transactional system (besides not leveraging the rest of SAP
a component called Open Hub Destination from any SAP BW Data                                     BW or having another environment to maintain):
Source without having to go through an InfoCube or DataStore
object (whereas in previous releases it did). Both an Open Hub                                   • Outbound SAP BW data has a licensing impact (in fact any data
Destination and Data Source have persistent objects associated                                     exported from SAP BW has a licensing impact, Open Hub
with them. An Open Hub Destination can be either a file or table                                   Service or not).
while a Data Source has what is called a Persistent Staging Area                                 • Data has to be persistently stored at least twice before reaching
(PSA); both can be emptied when loading is completed. As a result,                                 its target: the PSA and the Open Hub Destination file or table in
a fairly direct path can be made to load an outside system through                                 the BW application server.
SAP BW via the Open Hub Service such as a delta update.
Furthermore, the current release supports a series of Open Hub                                   Although the additional persistent objects in SAP BW might
Service APIs for notifications, status updates, metadata search and                              increase latency, they gain access to SAP capabilities like delta
Open Hub Service data extraction (instead of reading the file or                                 loading and RDA trickle feeds that speed it up which may net
table directly) so that the process can be effectively managed and                               positive over a custom direct access approach.
monitored by a third-party scheduling tool.
                                                                                                 For organizations where there is already a significant SAP
From a customer perspective, using Open Hub Services as a direct                                 environment already, then data is already in SAP BW and only the
pass-through mechanism to access SAP Business Content extractors                                 Open Hub Service needs to be configured to pull data out.

     According to Information Week: “When evaluating a vendor, nearly 80% of respondents are interested in the company's ability to integrate its offerings with existing applications
     and provide service and support.” Weier, Mary Hayes and Lisa Smith. “Many Companies Plan To Increase BI Spending.” Information Week, 19 March 2007., Path: Many Companies Plan To Increase BI Spending.

     The majority of this content was prepared prior to the announcement that SAP has tendered an offer to acquire Business Objects. This white paper should provide significant and
     pertinent context to the potential synergies this deal creates.

     Information Week reports that 51% and 48% of those surveyed cited integration and compatibility problems and ease-of-use issues as enterprise BI deterrents, respectively. Weier,
     Information Week.

     Wood, Brian. “Where Will Enterprise SOA Matter Most In Your Organization?” SAP White Paper,

     Weier, Information Week.

     Futurist Alvin Toffler coined the term “prosumer,” a combination of “producer” and “consumer,” in his book The Third Wave.

     According to a TDWI estimate based on reported cost savings by survey respondents after data quality implementations extrapolated by Dun and Bradstreet counts of businesses by
     employee size. Cost savings were realized in the way of excessive spending such as unneeded postage, printing and staff overhead. Eckerson, Wayne W. “Data Warehousing
     Special Report: Data Quality and the bottom line.” Application Development Trends, 1 May 2002., Path: “Data Warehousing Special Report.

     Davis, Carol. “Extreme Business Warehousing: Experiences With Netweaver BI at 20 Terabytes.” IBM Case Study, Document WP101012. http://www-

     ISO 9241-11 (1998) Guidance on Usability

     Autor, David H., Frank Levy, and Richard J. Murnane. “The Skill Content of Recent Technological Change: An Empirical Exploration.” Quarterly Journal of Economics, 118(4),
     November 2003.

     A median value of 70% means that 50% of the task type is needed when only 30% was needed in 1960 (vertical axis normalized around the 50th percentile median measure).

     Rajan, Amyn, George Chow and Darryl Eckstein. “ODBO, BAPI and XMLA: It’s All MDX To Me.” Simba Technologies White Paper.

Copyright © 2008 Inforte Corp. All Rights Reserved.                                                                                                     
500 N. Dearborn Street, Suite 1200
Chicago, IL 60610