Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions

BUSINESS INTELLIGENCE IN SAP® ENVIRONMENTS:
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. www.inforte.com

WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 1

1.1 WHITE PAPER OBJECTIVE
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.

1.2 EXECUTIVE SUMMARY
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.



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.

1.3 DEFINITION OF TERMS
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.



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.



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.



2. “WHY NOT SAP?”
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.

2.1 SAP USABILITY CONSIDERATIONS
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.



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

SAP

IBM

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.

2.2 SAP OPENNESS CONSIDERATIONS
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



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 Salesforce.com, 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.



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 Salesforce.com, 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.



3. WHY CONSIDER HYBRIDS?
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.

3.1 “ONE-STOP-SHOP” MISNOMER
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



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.



3.2 “BEST-OF-BREED” MISNOMER
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.

4. APPROACHES FOR SAP INTEGRATION
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



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.

4.1 DATA QUALITY MANAGEMENT IN SAP
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.



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.

4.2 INTERFACE-BASED ACCESS APPROACHES
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.



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.

4.2.1 OPEN ANALYSIS INTERFACES DATA ACCESS
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



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.

4.2.2. OPERATIONS-BASED DATA ACCESS
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.

4.3 EXTRACTION-BASED DATA ACCESS APPROACHES
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



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.

4.3.1 SAP BUSINESS SUITE DATA ACCESS
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.



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.

4.3.2 SAP BW DATA ACCESS
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.

5. EVALUATING RETURN ON INVESTMENT
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?



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



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

62

60

58

56

54

52

50

48

46

44

42

40

38
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



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.

6. CONCLUSION
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.

ABOUT THE AUTHOR
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.

ABOUT INFORTE
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 www.inforte.com


Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions

Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions

Similaire à Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions (20)

Dernier

Dernier (20)

Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions