Commentary. SAP Products' Impact on Enterprise Architecture

Transcription

1 D. Prior Research Note 14 February 2003 Commentary SAP Products' Impact on Enterprise Architecture Gartner's enterprise architecture framework is a powerful planning tool. But customers deploying SAP business applications must know the constraints SAP products and technologies bring when applying the framework. Ideally, the term "doing business" means achieving real-time collaboration with customers, partners and suppliers. For most enterprises, a major step toward external collaboration is to obtain cooperation within their own organizations first which is easier said than done. An enterprise architecture strategy can promote collaboration by supporting flexible business processes (see "Enterprise Architecture Special Report: Overview," COM ). In the case of SAP, how should enterprises that depend on its business applications build a highly effective enterprise architecture? SAP is a leading packaged-business application provider, with products such as R/3, its highly successful, enterprise resource planning (ERP II) offering and its e-business application suite mysap. SAP's impressive customer base amounts to more than 19,000 (typically large) enterprises, of which 80 percent are R/3 customers and 20 percent are mysap. The mysap suite demands multiple applications, each with their own separate databases and integration. Clearly, mysap customers have a much higher critical dependence on SAP than R/3 customers do. Architectural Constraints Imposed by SAP Business Applications All enterprises depend on one or more IT vendors for each of their database, operating system and hardware infrastructure layers. Most SAP enterprises also use non-sap application vendors. SAP and these other application and infrastructure vendors each have their own open systems and proprietary IT standards. There is an increasing complexity and convergence of IT infrastructure technologies (such as application platform suites and smart enterprise suites). SAP enterprises urgently need to plan how their own enterprise architecture will incorporate the architectural constraints imposed by SAP and their strategic IT vendors. Such a plan must address a wide range of applications, from internally developed ones to packaged ones from SAP and other vendors. The Gartner Enterprise Architecture Framework Gartner has developed a powerful model for the definition and maintenance of enterprise architecture (see Figure 1 and "Defining Architecture for IT: A Framework of Frameworks," COM ). But it is Gartner 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 important for SAP customers, centered on R/3 or mysap suite, to appreciate how SAP products and technologies fit into the Gartner enterprise architecture framework. Figure 1 The New Enterprise Architecture Framework The Multienterprise Grid Enterprise Business Process Styles Patterns Bricks Source: Gartner Research Multienterprise Grid The multienterprise grid is an integration layer that defines an organization's data and processes that are exposed to external partners and customers. For true business collaboration, the multienterprise grid makes it easier for enterprises to exchange information. SAP's standard collaborative business processes are openly accessible, while SAP's semantic business data definitions are exposed through its Business Application Programming Interfaces (BAPI). SAP's heavily standards-based technology strategy is called SAP NetWeaver (formerly mysaptechnology). The cornerstone of this strategy is the SAP Web Application (WAS). This incorporates, WebFlow (using Wf) and several of the emerging Web services standards, all of which can be used to connect to the multienterprise grid. SAP's Exchange Infrastructure within SAP NetWeaver is intended to manage all internal and external integration, but, currently, it is too immature to use for non-sap integration. For such general integration, 14 February

3 enterprises should depend on leading enterprise application integration vendors and consider deploying Web services. SAP also offers its MarketSet product for building business-to-business (B2B) electronichubs, if needed, within the multienterprise grid. Business Process Styles SAP's business applications may be categorized into five different business process styles: High-volume, transaction processing for R/3 and R/3 Enterprise-type core applications. SAP has an enviable track record of high-volume, global ERP systems with the R/3 online transaction processing (OLTP) application. The mysap customer relationship management (CRM), mysap supplier relationship management (SRM) and mysap product life cycle management (PLM) all have the potential to fit the high-volume, OLTP style. Real-time operations SAP business applications rarely fit this style, although, potentially, the mysap CRM call center could. Analytical and business intelligence this includes mysap business intelligence applications, featuring the Business Information Warehouse (BW) component and the computationally intense mysap supply chain management (SCM) application, featuring the Advanced Planner and Optimizer (APO) component. Collaborative some, but not all of the mysap SRM, PLM and CRM applications feature highly collaborative business processes. Many more industry-specific processes are expected from SAP. SAP's new xapps generation of cross-applications fit the collaborative style. SAP's collaborative applications rely heavily on the Enterprise Portal and the very new Exchange Infrastructure technologies. Utility this includes financial and HR modules within R/3 and R/3 Enterprise. Patterns These represent actual technical design patterns. The fundamental design patterns, on which SAP originally rose to prominence with its R/3 product, are the three-tier architecture and thin-client computing. Release 4.6 of R/3 heralded a fatter client as a sacrifice to user friendliness, but SAP's new WebDynpro user interface technology seeks a return to the true thin-client model. WebDynpro will also try to solidify SAP's early attempts at the mobile computing design pattern. Rather than buy, SAP chose to build its own data warehouse design pattern. Bricks Technology bricks are base architectural elements. For platform-oriented bricks, SAP cleverly chose vendor independence for operating systems, servers and relational databases to maximize its addressable market. As enterprises start to map their enterprise architecture, they should keep to a minimum the different operating systems and database bricks deployed as mainstream infrastructure technologies. SAP has developed a wide range of its own technology components on which its applications are built (see Figure 2). Gartner expects that all existing baseline bricks will mature into retirement, containment or mainstream status. Figure 2 also lists all emerging SAP technologies. The classic SAP Basis (ABAP [Advanced Business Application Programming], C++) brick in the foundation layer has evolved into the SAP Web Application (ABAP, C++, Java) brick. For the computationally intensive supply-chain 14 February

4 optimization products, SAP built its own memory-based database technology (LiveCache) but for optimization algorithms it partnered with ILOG. Enterprises planning their enterprise architecture should: Focus on baseline and mainstream bricks wherever possible; limit investment in retirement bricks; and exercise caution when deploying emerging SAP brick technologies. Clearly, the number of bricks needed should be minimized to simplify architecture where possible and reduce the cost of maintaining diverse technical skills. Figure 2 The Future of SAP's Own Technology Bricks Type Baseline Retirement Containment Mainstream Emerging Foundation Layer Basis Component Basis WAS CRM Mobile CRM Mobile Mobile Engine Technology Technology Content/Cache Content/Cache SAP DB LiveCache SAP DB LiveCache User Integration (U2A) Application Integration (A2A) Enterprise Integration (B2B) SAP GUI SAP GUI Internet Transaction Internet Transaction WAS WAS Web Dynpro Internet Graphics Internet Graphics Index Management Index Management EP 5.0 EP 5.0 EP 6.0 RFC, BAPI, IDOC, RFC, BAPI, IDOC Exchange Infrastructure R/3 Plug-In R/3 Plug-In CRM Middleware CRM Middleware DCOM Connector DCOM Connector.NET Connector Java Connector Java Connector WAS Web Services Business Connector Business Connector Exchange Infrastructure MarketSet MarketSet WAS Web Services A2A B2B BAPI CRM DB DCOM Application-to-application Application Link Enabling Business-to-business Business Application Programming Interfaces Customer relationship management Database Distributed Common Object Protocol EP GUI IDOC RFC U2A WAS Enterprise Portal Graphical user interface Intermediate documents Remote function call User-to-application Web application server Extensible Markup Language Italics Denotes Windows Platform Only Source: Gartner Research Planning an Enterprise Architecture Blueprint for SAP Enterprises All SAP enterprises should clearly understand their corporate business strategy when planning their own enterprise architecture "blueprint." This is the individual set of specifications, standards, diagrams and guidelines to define and maintain their enterprise architecture. From this business startpoint certain critical SAP factors can then be considered: 14 February

5 SAP Instance Strategy A critical issue to consider is the number of instances for each SAP application that will be operated. Because of system landscapes, multi-instance strategy greatly increases blueprint and operational complexity, particularly for mysap suite enterprises. SAP-to-SAP Interfaces Enterprises have no control over how these are maintained; they are proprietary to SAP. However, SAP does expose the A2A and B2B bricks on which they build these interfaces within their interface repository ( SAP-to-Non-SAP Interfaces Enterprises do have control here, but need to manage them very carefully. It is important to rationalize and document all interface standards and to adopt the "enterprise nervous system" approach (see "How to Encourage Use of the Enterprise Nervous System," TG ). Operational Issues Any SAP enterprise's architecture blueprint must define how business disruption will be managed with respect to application high availability and business continuity strategies. Determining the full cost of business downtime enables the best data replication technology to be selected. Bottom Line: Through 2006, 80 percent of all SAP enterprises, with an enterprise architecture blueprint, will gain superior flexibility when implementing collaborative business processes (0.7 probability). The startpoint for planning such a blueprint is corporate business strategy. It is also vital to understand the future of all SAP technology bricks and to minimize the number of infrastructure technology bricks when building the blueprint. SAP instance strategy, interface standards and business disruption policies cannot be overlooked when formulating an enterprise architecture blueprint. 14 February