BUSINESS INTELLIGENCE IN SAP® ENVIRONMENTS:Understanding the value of complementary BI solutionsInforte - A Business & Dec...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions            ...
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Business Intelligence in SAP Environments: Understanding the value of complementary BI Solutions
Upcoming SlideShare
Loading in...5
×

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

1,950

Published on

A white paper sponsored by Business Objects prior to the SAP acquistion to make the business case for complementary third-party BI instead of \'one-stop-shop\' SAP solutions.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,950
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
70
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 1. BUSINESS INTELLIGENCE IN SAP® ENVIRONMENTS:Understanding the value of complementary BI solutionsInforte - A Business & Decision CompanyDavid Dixon
  2. 2. 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.................................................................................................................32Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  3. 3. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 11.1 WHITE PAPER OBJECTIVEThis white paper discusses how complementary Specialist Business Intelligence (BI) solutions can fit within a hybrid architecture strategy, whetheryour organization is an “SAP shop,” running the majority of their processes on SAP, or has “SAP in its shop,” with a heterogeneous enterpriseapplication environment that includes SAP solutions.Because of growing IT complexity and the higher stakes involved with enterprise solutions, decision makers increasingly rely on specialists andconstituents for support. When considering such support, decision makers must take into account both immediate, tactical, project-basedconcerns and longer-term strategic implications.Building consensus on support decisions not only distributes political risk and promotes inclusiveness, but also promotes objectivity and thetechnical accuracy of recommendations. But if consensus is split, as is often the case in BI environments consisting of SAP and non-SAPpractitioners, then consensus-building becomes a bottleneck. The explanations proposed in this document can serve as a communication tool tohelp 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 andSpecialist BI solution capabilities will also benefit from this white paper.1.2 EXECUTIVE SUMMARYA 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.1Ironically, however, when it comes time to evaluate BI solutions, organizations often divide themselves into product-aligned camps. They debateideological 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 withinSAP solutions as well as across vendors. Recent SAP acquisitions and tighter partnerships are opening up new hybrid options such as the recentSAP offer to acquire Business Objects.2 This paper shows that there is indeed value that complementary Specialist BI solutions add to customersthat run SAP solutions. The optimal solution isn’t an either/or choice, but rather one which incorporates both elements. Assumptions that SAP isa 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 inappropriatebecause of rapidly-changing industry dynamics. In the first place, SAP “one-stop-shop” architectures are falling short by sweeping unmetneeds under the carpet. In addition, “best-of-breed” solutions from Specialist BI providers now offer “one-stop-shop” BI in their own rightthat can complement rather than complicate SAP deployments. Using inaccurate labels can create impressions that lead decision-makingdown 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-alignedextreme. Achieving a more balanced and optimal state with hybrid architectures has less to do with buying into the the hype around thelatest buzzword technologies and more to do with focusing on established interfaces, maturing technologies and best practice techniquesthat are coming of age. But perhaps the tipping point is not so much technology-driven as knowledge- and experience-driven. After yearsof investment in studying SAP concepts, data and technology nuances, Specialist BI providers have developed proven solutions capableof 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. www.inforte.com
  4. 4. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 2Hybrid architectures are a reality that is not going away any time soon, no matter how big the SAP footprint. Rather than factionalize oruniversalize SAP architectures and programs, IT organizations should realize that the ever-growing scope and complexity of their enterprisearchitecture, 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 statearchitecture is to understand each product’s present-day strengths and weaknesses. Not all BI providers that have SAP solutions are createdequal, and it is important to consider criteria such as a solution providers’ experience working with SAP customers and the maturity of theirsolutions. (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 workaroundsthat unravel the spirit of SAP centralization. By taking an SAP BW “one-stop-shop” approach, organizations inadvertently create walls that canforce 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 leveragingcomplementary, Specialist BI solutions. Not only can Specialist BI tools reach larger audiences, but core constituents can also benefit frombroader and deeper BI capabilities. Otherwise, an ambitious SAP initiative may atrophy. The need for fast and flexible non-SAP data integrationand 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 ofownership (TCO) the prevalent financial driver, the application of BI inhabits a far more strategic plane. If properly applied, BI goes beyondsimple reporting, and can drive fundamental business decision-making at many levels throughout the organization. For this reason alone, it isimportant 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-productapproach must be weighed against the integration costs of a hybrid approach. TCO also comes into play when information consumers evolveinto their own producers and eliminate the middleman (i.e. BI developers). Business is changing faster than IT can support. As a result, backlogsare burgeoning and lengthy projects lose value. Faster time-to-value not only positively impacts business opportunity costs, but also resourceallocation and operational efficiencies.As automation shifts tasks into higher-brain-function knowledge work, empowering the knowledge worker with usable tools becomes anincreasingly important—if not the most important—driver in business value creation in the information revolution.1.3 DEFINITION OF TERMSBefore reading this document, you should be familiar with a number of acronyms, terms and concepts in order to avoid getting lost in words ormissing 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 thatyou can better appreciate “buzzword” nuances.Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  5. 5. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 3Note that other sources, some of which are cited below, also have comprehensive and slightly varying definitions for the same terms; you areencouraged 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 writerBill Inmon is largely credited with originating and popularizing. Inmon has a very specific definition for data warehousing, and has writtenmultiple 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 thingas BI, 2. Should not be confused with data marts, and 3. By definition is a separate system from transactional ones. SAP positions theEDW as an IT scenario that can be built with the functions of its SAP NetWeaver™ technology platform. This paper uses the term EDW torepresent the back-end part of BI that processes, manufactures and prepares data for the front–end, and consists of activities such asextraction, transformation and loading (known as “ETL”), data transfer scheduling, data modeling and data management (such as aggregatebuilds and indexing).Data Mart is a term that has numerous varying interpretations and nuances, a problem exacerbated by SAP’s own technical and specificuse 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 datathat sources its data either from the EDW or the underlying transactional systems, thereby by-passing the EDW. Data marts are usually theunderlying data structures for reporting, querying and analysis, while the EDW is more of a central data repository. As a result, data martsare 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) formsof 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” architecturereaps the benefits of fast implementation without the isolation tradeoff. The author anticipates that as SAP NetWeaver Master Data Managementgains adoption as a data repository this enterprise “bus” approach will gain popularity. However, in the meantime, EDW in the SAP worldusually 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 academiccontributions to relational database theory and design. This paper will not consider OLAP’s academic aspects, but rather its significanceas 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 majorityof third-party BI tools, access SAP BW data universally through SAP’s native and proprietary OLAP processor. SAP’s OLAP, or analyticalengine, is the heart of SAP BW data access no matter whether the data is flat or dimensional, and is the underlying interface to integratedplanning, 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. martsand 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 infrastructurecapabilities 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 capabilitiesunder 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. www.inforte.com
  6. 6. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 4Platform is an environment that is designed to support third parties (customers or other vendors) in developing their own applications. The platformitself 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-specificapplications. The SAP NetWeaver technical platform also enables composite applications where third-party vendors or customers can buildcustom business processes by integrating SAP applications with non-SAP applications. Such integrations occur via reusable enterprise servicesusing SAP NetWeaver not only as a technical platform, but also as a business process platform (BPP). SAP brands these composite applicationsas “xApps,” like SAP xApp™ Resource and Portfolio Management (SAP xRPM), which loads SAP and non-SAP projects for resource andportfolio 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 recognizingand holistically addressing the growing complexity of IT, as well as its corresponding difficulties in meeting business needs. It is a disciplinethat traces back twenty years to the thought leadership of John Zachman, but has now broadened to comprise many different competingmethodologies 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 planfor 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 ReportDesigner, 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 onlyworks 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 SAPNetWeaver BI 7.0 (formerly known as NetWeaver BI 2004s). Because SAP brand and release names have been subject to frequentchange, most customers still refer to SAP NetWeaver BI as SAP BW particularly in reference to the back-end such as the data warehouseor 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 earlyreferences to SAP CRM, SAP SCM and other enterprise applications used terms like “extended ERP” or “ERP II”, this paper will use “ERPreporting” as an umbrella term to encompass these enterprise applications as well. SAP ERP information systems like Logistics (LIS), HumanResources (HRIS) or Financials (FIS), as well as tools such as Report Painter and Query Painter, are examples of ERP reporting. SAP solutionmaps 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” (inthe SAP context), “pure play” or “best-of-breed” BI vendors that have comprehensive capabilities, both in terms of breadth and depth. Assome of these BI vendors have expanded their offering to become “one-stop-shops” in their own right and in the case of Business Objectsare in the process of being acquired, the Specialist BI term is being used in place of the traditional terms. Furthermore, a distinction mustbe 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 andanalysis tools such as Panorama or XLCubed, but other BI product categories such as ETL, vendors like Informatica or Ab Initio, or datawarehousing vendors such as Teradata and Kalido.Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  7. 7. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 52. “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 forin 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 henceintegrated (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 casefor employing Specialist BI tools to complement present-day SAP BW (i.e. SAP NetWeaver BI 7.0) capabilities. As IT investments in bothSAP BW and Specialist BI soltuions are growing, it makes pragmatic business sense to leverage both rather than push one out, even in anEA-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 toptwo roadblocks standing in the way of enterprise-wide adoption of BI.3 For an understanding of how the SAP NetWeaver technical platformunderlies usability and openness refer to Appendix 7.2.2.1 SAP USABILITY CONSIDERATIONSSupreme Court Justice Potter Stewart’s famous quote defining obscenity—“I know it when I see it”—applies equally well to usability. Forcustomers, usability is a product feature that is more cost-effective to consensus-score rather than empirically test and measure as part ofa 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 developmentand 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 intothe hands of the end-user, enabling autonomy. In fact, some BI products require zero report development, relying on “on-the-fly” andbookmarking capabilities.Usability goes beyond just graphical capabilities in the user interface. Appendix 7.3 provides a personal perspective that illustrates how SAP’scenter-of-design for report development was historically centered on developers. SAP applied software engineering principles to reportdevelopment so as to eliminate redundancies and promote reuse through a building-blocks approach. This design approach to separatedevelopment 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) designcontrol. 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 Withthe integration of SAP NetWeaver Visual Composer into SAP NetWeaver Composition Environment (SAP’s Java-based development platform) it ispossible that front-end tools from third-party vendors can be mashed up into a composite application. Specialist BI solutions already provide thiscapability, typically as part of dashboard designer tools. SAP may follow suit. Currently, it is not possible to mix and match SAP front-end tools likeSAP BEx Report Designer, SAP BEx Web Application Designer and SAP NetWeaver Visual Composer without programming or separating theminto portal iViews (SAP portlets). At some point, either Specialist BI or SAP BW dashboards will become ‘mash-boards’—a mixed-and-matchedcomposite of user interface components and web services. Some Specialist BI tools already directly support seamlessly integration with SAPNetWeaver 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. www.inforte.com
  8. 8. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 6Figure 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-castmolding—the output is predefined and standardized for mass consumption. Die-casts take more pre-defined design and planning, but once inplace 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 topick up, on-the-fly and WYSIWYG. Having both options for molding information gives organizations the power to support both centralized anddecentralized solutions in a controlled EA. Top-down developer-centric solutions can be balanced with bottom-up user-centric solutions, ratherthan 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 UsersIn conclusion, Specialist BI tools can still offer complementary capabilities to the latest release of SAP BW tools by providing users tools thatare self-service driven without undermining the strength and capabilities of SAP BW.2.2 SAP OPENNESS CONSIDERATIONSThe 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 financialconsolidation 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 fileformat 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 supportedexternal data interfaces with customizable structures and mapping rules. Even from the earliest days of SAP BW, flat file data loadingwas supported.These interfaces require files in a file structure that is accessible via the SAP application server. Later, SAP supported direct loading frommultiple external database systems; this was done by opening extra database connections on the application server in addition to thedefault. 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 thisCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  9. 9. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 7type 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 allmajor relational database management systems.But, technically speaking, connecting to an external data source and translating that data source into SAP semantics is much like placinga 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, thesedeals are more than just a replacement to the reseller agreement SAP had with Ascential before that company was bought by IBM. Thesedeals imply SAP recognizes the need for seamlessly integrated outside ETL capabilities to complement their own. Specialist BI suites offerETL capabilities but also can go beyond, from the OEM perspective, with enterprise information integration (EII) as well as data qualityand 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 byincorporating its ETL engine; no data has to be stored in SAP BW, but rather can point to SAP BW representations of extraction structures calledDataSources. 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 conversingin Chinese would be if several rustic dialects and non-native-speaker versions were on the other end of the phone rather than one clearStandard Mandarin voice.Simply standardizing and automating processes on SAP Solutions does noteradicate data defects or the need for data quality management. In fact, SAP Here again, Specialist BI can complement SAPNetWeaver MDM, designed for master data consolidation, cleansing, and capabilities, especially in the area of customerquality 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 dataintegration (CDI). Furthermore, Specialist BI suites can provide solutions for thoseSAP 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 SAPand non-SAP sourced data unless Specialist BI or Niche BI is leveraged. This gap exists both because of the level of programming effort neededin its native ETL engine, and also because of the availability of SAP’s pre-delivered information models. The SAP information models, calledBusiness Content, are predictably slanted towards SAP applications. SAP BW projects tend to be SAP-centric not because of a lack of SAP BWopenness, but because of the lack of automation and standardization of non-SAP scenarios. Although SAP BW does have some Business Contentfor external data sources, including Dun and Bradstreet and Oracle Financials, there is not enough pre-delivered content and native ETLcapabilities 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 connectorsfor 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 andanalysis on external market data or public government records for market research, competitive analysis, and forecasting or industrybenchmarking 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 BItool from an online store.Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  10. 10. 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 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 intoInfoProviders, in order to be available for SAP BEx. As discussed in Appendix 7.3, in SAP this information design is done with the DWWorkbench tool as a developer task. An alternative is to use SAP NetWeaver Visual Composer, which leverages the same underlyingarchitectural 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-servicereporting tool for business users. SAP NetWeaver Visual Composer has not yet demonstrated widespread adoption or acceptance by end-usercommunities commensurate to Specialist BI tools. Specialist BI tools have the benefit of an established history and rapport with businesscommunities (end-users and experts).Both Specialist BI products and SAP NetWeaver Visual Composer can connect heterogeneous data sets in their tools. What this effectively meansis that users can directly access outside data sources (or raw exports) and integrate them into their reports and analysis without having to waitfor 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 andNiche BI products, users have the ability to do their own information design and integration work. In contrast, SAP BW takes a structured andarchitected approach to BI that most IT organizations would commend for governance and control reasons. However, ad-hoc self-service analysisshould 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 thebuild in SAP BW. For non-SAP shops, this enables reporting on SAP data (whether in an SAP transactional system or in SAP BW) without loadingthe data into another environment. Furthermore, many SAP satellites need more immediate visibility to, and integrated reconciliation with, SAPdata 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 EAefforts on present-day realities; the IT industry is so volatile that prediction even one year out is difficult. EA should be focused on balancingstrategy 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 thoseassets 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-aligneddogma. 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. www.inforte.com
  11. 11. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 93. 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 debateand 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, enablingtechnologies and acquisitions. Furthermore, established BI providers have rapidly grown into a comprehensive suite of BI tools and applicationsthat 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 doyou 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 2007noted that 78% of respondents indicated that what they wanted from BI vendors was the “ability to integrate with existing applications,” puttingthat desire at the top of the survey wish list.5The ability to customize and extend vendor solutions further obscures the “make” versus “buy” dichotomy, embodied in the difference between buildingsolutions out of “best-of-breed” versus buying a “one-stop-shop” solution, respectively. The power of “out-of-the-box” capabilities in an application suitecan be combined with the development and self-service capabilities of a platform or tool. This enables organizations to build malleable designs andarchitecture 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 investmentsalready made in enterprise BI solutions, putting these investments together instead of throwing some away makes good sense. The increase inacquisitions, 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 traditionaldichotomy has been an architectural debate that is vendor aligned and, as a result, polarizes approaches. The traditional dichotomy suggeststhat one vendor group precludes the use of the other instead of considering both. The perception is that organizations must force-fit either SAPBW 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 thatholistically assess depth-versus-breadth capabilities and open-versus-proprietary features. “To SAP or not to SAP” is no longer a clear-cutquestion, and indeed, is now a bit myopic. Instead, a bigger-picture question is how to blend different BI product capabilities in order tomaximize the enterprise value of information assets when SAP is in the mix.3.1 “ONE-STOP-SHOP” MISNOMERA decision to standardize on SAP BW for all reporting, query and analysis might be flawed without consideration of all user requirements, presentand future. Very often an organization will wait for transactional systems to be standardized before rolling out BI. Consequently, the organization isCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  12. 12. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 10quite immature with respect to BI, and thus its understanding of how user requirements may develop is very limited. It makes sense to investigatewhat 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 theirmandates, 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 asa spreadsheet), too interim (like a retiring legacy system), or too unwieldy (like syndicated data) to be brought into the SAP BW solution. Inaddition, there may be BI demand from satellite consumers that want to bring SAP access into their local solution, but that demand gets eitherignored 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 EAand the move to become an SAP shop. It is not uncommon behavior in large-footprint SAP BW implementations to find users routinely exportingdetailed 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 withoutthe benefits of centralized truth, support and visibility.Rather than letting hidden costs proliferate, SAP shops should considerexpanding their architectural vision to address unmet outside needs by SAP shops should consider expanding theirleveraging Specialist BI tools. Approaches for doing so will be discussed later architectural vision to address unmet outsidein 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 BIcapabilities. Otherwise, an ambitious SAP EDW initiative may atrophy into anSAP 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 publishingand 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 (andperhaps still is). When SAP ERP first hit the market, there were few software implementations quite like it in magnitude. It was so monolithic andcovered 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 shiftedwith the advent of other monolithic enterprise applications such as SAP CRM and SAP SRM. EA-aware advocates realized ERP investments were likepoured 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 andMicrosoft 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” willeventually be unattainable. EA disciplines around managing and controlling hybrid architectures are a growing, not shrinking, need.Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  13. 13. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 113.2 “BEST-OF-BREED” MISNOMERSpecialist BI Suites that were traditionally dubbed as “best-of-breed” are increasingly harder to distinguish from “one-stop-shop” brandedenterprise 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 anddepth of functionality and features in contrast to the flexibility and openness of the architecture on which it is built (i.e. business applicationversus 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 abest-of-hybrid solution. In other words, Niche BI vendors with proprietary and closed architectures are increasingly hard to justify asorganizations move towards enterprise solutions. Isolated “best-of-breed” solutions can persist in fragmented and departmentalizedorganizations, but as those walls come down, so will those products because of the EA headaches they produce. Many times, there are moreopen 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 INTEGRATIONSpecialist 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-basedcentral access point. Reporting and analysis output is simply published through an iView. Not only can SAP and Specialist BI iViews be arrangedtogether on the same portal, but SAP drag-and-relate and portal-eventing technology also enables data integration and interactivity betweeniViews. 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 forspecialist features such as postal validation and duplicate matching for maintenance by business partners such as customers and vendors. Nomatter the size of your SAP footprint and whether you are using SAP NetWeaver MDM, Specialist BI data quality management capabilities canoffer 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 ITstrategy 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 SAPCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  14. 14. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 12Additionally, each data access approach has two options:• Access data from SAP BW• Access data from the SAP transactional systemsIf you are a large SAP shop, you may keep data in SAP as your source of truthrather than have it extracted. As not all reporting needs are typically addressed Specialist BI tools add the most value by beingby SAP BW (such as real-time reporting due to customization or performance able to merge SAP BW and SAP transactionalimpacts), Specialist BI tools add the most value by being able to merge SAP BW data as well as serve as a consistent tooland 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 alsosaves change management costs, especially when underlying systems are goingthrough 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. Thedirect 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. Akey architectural decision to make is whether to extract from the SAP BW or from the SAP transactional systems. Theoretically, it makes moresense to extract from the SAP transactional systems, but pragmatically most organizations use SAP BW as a proxy to the transactional systemsin order to leverage all the pre-delivered Business Content extractors. However, the latter option has a licensing impact. (The impacts of eacharchitectural approach are discussed in more detail later.) For ERP real-time reporting needs, the data access approach needs to directly readsome type of interface instead of replicating data via extraction. Whether you consider your environment an SAP or non-SAP shop, the dataaccess approach for ERP reporting should be handled the same.4.1 DATA QUALITY MANAGEMENT IN SAPEven if a business had only a single instance of SAP ERP, owning no other applications outside of it, data defects can still proliferate. Data entryis 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 masterdata maintenance. For example, both finance and sales share the customer master, which may be updated at different times for different reasonsthat 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 aredefined, 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 largerenvironments may have multiple instances of SAP as well as other vendor packages, all on different versions and configurations. Suchheterogeneous 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 scenarioand the need for data quality control rigor mounts. Poor quality in customer data alone costs corporate America $611 billion a year.7Although data quality management solutions typically support data profiling, mass cleansing and quality monitoring capabilities on largeexported data sets, best practices in data quality are the same as in manufacturing: scrap and rework costs more in the long run than addressingproblems at their source. The basic manufacturing-based quality concepts and tenets are the same: preventing problems upstream savesinspection and repair downstream.Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  15. 15. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 13SAP NetWeaver MDM has validations and matching strategies to correct errors and eliminate duplicates, but as yet this is not where most SAPenvironments 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 mostcases, master data maintenance is still distributed. As a result, these systems still need a central way to validate and quality-control data enteredinto those distributed systems.For checking documents posted into the ERP-based financial modules, SAP has validation and substitution rules that can be applied via Booleanlogic or custom-programmed enhancements. But these business rules are system-defined (i.e. are local), as are other application-specific checksand 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 auniversal basis, a capability which SAP calls Business Address Services (BAS). Almost anything in SAP that references an address isintegrated with BAS. A limited number of Specialist BI and Niche BI products with CDI capabilities offer direct SAP integration throughthe following two BAS BADIs in question:• Postal Validation (Online and in Batch)• Duplicate Check, Error Tolerant Search InterfaceBefore SAP-based applications, some early data quality applications centered on names and addresses stored in mainframes for marketingcampaign mailings. These applications realized significant savings by cross-referencing postal information that government agencies madeavailable such as NCOALink (National Change Of Address). Postal standardization of names and addresses has probably more obviousreference for a single source of truth, and it can be applied in other countries as well. Business Objects (formerly First Logic) provides globalpostal 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 (GlobalTrade Item Number) for products. Some industries also maintain data pools for product master data, such as 1SYNC for global datasynchronization (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-duplicationand error-tolerant searches as well. For example, Business Objects (formerly First Logic) performs fuzzy or phonetic logic search thatprompts data entry clerks with alternate matches if duplicates or errors are found even if entered data is ambiguous. The same logic canbe 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 postalWhether you choose to leverage SAP BW or not, your SAP solution stands to validation, duplicate check and error tolerantbenefit from postal validation, duplicate check and error tolerant search that search that complementary solutions cancomplementary solutions can provide using government agency databases. provide using government agency databases.4.2 INTERFACE-BASED ACCESS APPROACHESIf 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 thedata and performance strain these activities have on your SAP transactional systems.Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  16. 16. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 14From a data management perspective, SAP BW generally has better capabilities than the information systems found in the SAP transactionalsystems 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 andsophisticated mechanisms), trickle feeds (called real-time data acquisition or RDA) and federated data access (Remote Cubes). Remote Cubesactually 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 totransactional 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 SAPBEx queries, as Open Analysis Interfaces. From an overall modeling perspective, if Specialist BI tools are being used to push down informationdesign (data unions and joins), query design (information subsets, OLAP definitions and calculations) and presentation design (formatting andlayout) then the question of how to design a BEx query for external access becomes a strategic design decision. Using Specialist BI tools as asimple presentation design tool on top of query design limits the value proposition of the solution. On the other hand, uncontrolled accesspotentially undermines your SAP BW system instead of augmenting it. Appendix 7.4 reviews some best practice query design principles to makethe most of the hybrid design.4.2.1 OPEN ANALYSIS INTERFACES DATA ACCESSAs noted earlier, almost all direct access to SAP BW data passes through the OLAP processor based off of SAP BEx queries. The Open AnalysisInterfaces are designed to allow complementary BI solutions direct access to the OLAP engine. These interfaces are based on a long-establishedand 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 benoted, 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 insome BI products support for the interface. The current situation has improved significantly from the early adopters’ experiences, as solutionproviders that committed to SAP BW integration have ironed out the issues and closed the gaps. Nevertheless, not all solution providersare created equal in this respect. Established solution providers that have iterated multiple generations of certified SAP offerings and that haveCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  17. 17. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 15a long working histories with SAP customers are in a much better position tofully capitalize on Open Analysis Interfaces than vendors new to SAP. Established solution providers that have iterated multiple generations of certified SAP offeringsSpecialist BI firms with an established history of integration with SAP BW and that have a long working histories with SAPwill have worked out the kinks, while those vendors new to SAP will have customers are in a much better position to fullyto lay out the development dollars and commitment to work through these capitalize on Open Analysis Interfaces thanoften-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 avendor selection will quickly create a short list.4.2.2. OPERATIONS-BASED DATA ACCESSSAP BW was first originally designed for analytics on historical and summarized data rather than detailed operational data. As a result, thebuild of the environment was more architected and OLAP-driven than reporting-driven. To deliver enterprise reporting, SAP partnered withCrystal Decisions (now Business Objects) to deliver form-based formatted reporting capabilities for SAP BW. Joint development integratedCrystal Reports directly into the SAP BW metadata repository and against the native OLAP processor (for better performance and flatteningoperations instead of an Open Analysis Interface). Later, SAP recently introduced the SAP BEx Report Designer for formatted reporting in thelatest version. However, SAP BEx Report Designer only works against SAP BW data versus SAP Business Suite data, while Crystal Reports notonly 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 andaccelerators (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 andhow 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 APPROACHESIf 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 SAPBusiness 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 dataarchitectures, 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 mayCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  18. 18. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 16find SAP has a steep learning curve. Data modelers may be challenged to quickly understand SAP Business Suites sheer volume of tables andin-depth data logic. It may also take users some time to understand the SAP BW system’s data repository, and the graphical renderingconventions 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 BWlandscapes 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 asan EDW is growing as SAP BW multi-terabyte testimonies increase. IBM recently issued a rigorous proof-of-concept study that endorsed SAPBW 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 wellbeyond 100 terabytes. For those sizes, there are no references or empirical evidence that SAP BW can effectively scale. But for hybrid federateddata 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 EDWtransactional history be federated?These paradigms and shades of gray can spur philosophical BI debates that create cultural barriers around technological differences. The goodnews is that Specialist BI suites can stitch together the results from both environments. The bad news is that many organizations are not preparedfor that from a cultural perspective.4.3.1 SAP BUSINESS SUITE DATA ACCESSBefore deciding on where to extract data from SAP Solutions, due diligence should be performed to determine what is involved with extractionfrom the various sources, what SAP BW capabilities are provided to facilitate extraction and what percentage of extracted data is non-SAPsourced. 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 andinformation models) in these bundles can also be leveraged to bridge SAP into larger-scale data warehouses as well. The content thatSpecialist BI suites offer usually covers all of the core modules in SAP ERP. The value proposition is a savings in implementation time byleveraging a ready-to-run template. The added advantage in using a Specialist BI suites is that the products will have similar templates forother business suite vendors that SAP Business Content will not cover. In addition, Specialist BI suite leverage their integrated capabilities, suchas a data lineage from queries or report output, back to the raw SAP source that does not have an equivalent in SAP Business Content. Havingpre-delivered content at your disposal is important in order to eliminate data complexities, but even SAP Business Content cannot cover allscenarios 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. www.inforte.com
  19. 19. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 17Extracting data from SAP transactional systems faces some of the same challenges as reporting directly from those systems (i.e. knowing whereto go for the data and how to transform it into something meaningful) with the additional technical challenges of streaming the data and handlingdelta change capture (i.e. the incremental difference from the last data pull). Both are important for data load performance. Each ETL solutionprovider (or Specialist BI suite with ETL capabilities), as well as SAP BW, has a mechanism for handling data streams; handling delta changecapture 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 extractiondevelopers that need to understand how SAP BW extraction works for incremental data pulls in order to optimize the performance of theirown development work.For implementations whose requirements can be met by a Specialist BI quick start offering, the details covered in Appendix 7.8 are probablymore than you need to know. However, the larger and more specialized (i.e. non-core modules) the SAP footprint, the more likely that thesedetails will be relevant to an architect and extraction developer, and also make SAP BW Business Content more attractive.4.3.2 SAP BW DATA ACCESSMost of the value of Business Content lies in the pre-delivered extractors and metadata (atomic data elements or fields called InfoObjects). Thedownstream information models (such as InfoProviders and queries) serve more as templates for reference and reconciliation. Most customersend 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 Contentextractors 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 extractorscompelling enough to warrant customizing them in order to feed third-party ETL tools. These isolated approaches have yet to meet withwidespread 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 OpenHub Services to distribute data from SAP BW. Open Hub Services export data from SAP BW InfoProviders to file or table which third-party toolscan 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 universalsource of truth in a separate environment, SAP has EII or federation capabilities. Master data can point to DataSources directly or ABAP codethat reads an outside data source instead of a native SAP BW-generated ABAP table. Similarly, transaction data can be loaded into a RemoteCube via a DataSource or ABAP code instead of an SAP BW-generated extended star schema.5. EVALUATING RETURN ON INVESTMENTWhen evaluating the cost of building new capabilities with either a hybrid approach or a single product approach, the following generalformulas compare the two alternatives (making the sweeping assumption that the benefits can be realized by both approaches within the sametimeframe 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 withanother application and integrate it?Copyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  20. 20. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 18The cost of implementing a product capability is comprised of tangible expenses such as hardware, software and labor, and intangibleexpenses, such as business opportunity costs and burned-out resources. Time-to-value is perhaps the largest hidden cost, though difficult tomeasure and interrelated with the expected business benefits. Labor is probably the most expensive tangible cost, especially in SAP BWimplementations, 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 arereplaced 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 Basicfor workbook-based formatting gaps. Because of the SAP knowledge required for all three types of developments, the labor costs and time tofulfill 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 cansustain a requirement, then the only real cost to consider (over and above standard product-related skills) is the hybrid skills necessary fororchestrating the design and implementation. Because Specialist BI tools typically are designed for less-skilled developers and informationworkers, the availability of labor for standard product skills should be easier to secure than the hybrid skills necessary to pull it together. Similarto EA, the customer should develop and own these cross-product skills in their BI competency center rather than looking to market in order toreduce 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 theSAP 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 allthe complicated business logic and data design must be done regardless, and can just as easily be encapsulated in a RFC-enabled functionmodule and passed to a Specialist BI tool in a hybrid approach. After the function module, the incremental cost of integration is low as theSpecialist BI can already readily connect to RFC data; all that remains is some metadata mapping, layout development and formatting. If acustom ABAP report has requirements for numerous custom layout and formatting options that makes a better case to pass the work to anempowered 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 mayconsist of leveraging a Specialist BI suite to extract directly from SAP into their environment. If one of their pre-packaged offerings meets therequirements, then the costs are usually fixed and rapid to implement. However, broader-scoped implementations are likely to run into significantenhancement 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 Contentextractors and Open Hub Services. In this case, the cost of integration would be low, since relatively less labor is required to prepare Business Contentand 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 makeson-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 aCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com
  21. 21. WHITE PAPER - Business Intelligence in SAP Environments: Understanding the value of complementary BI solutions 19result, backlogs of projects pile up and even worse, projects that run too long become obsolete or lose value. Time-to-value is not only importantto 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 businessbenefits is much more difficult to quantify or estimate than costs, especially if it is a question of usability or the value of more accessibleinformation. 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 aspecified context of use.”9Ironically, the difficulty in measuring such intangible value is one of the strongest underlying business drivers for BI. The growingimportance of knowledge workers in value creation activities is a generally-acknowledged trend but hard to empirically measure andengage. Yet there are visible trends and anecdotes for shift in work that is commanding higher-brain-function activities. Perhaps one of themore convincing scientific studies that demonstrates the shift from routine and manual tasks to non-routine cognitive tasks (analytic andinteractive) is depicted in Figure 2 below.10Figure 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 interactiveNon-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), drivingworkers toward non-routine tasks to handle exceptions. Celebrated management guru Peter Drucker noted that amid the information revolution, workersCopyright © 2008 Inforte Corp. All Rights Reserved. www.inforte.com

×