CIO Update: The Impact of SAP Products on Enterprise Architecture

Transcription

1 IGG D. Prior Article 26 February 2003 CIO Update: The Impact of SAP Products on Enterprise Architecture Gartner s enterprise architecture framework is a powerful planning tool. When applying the framework, however, enterprises deploying SAP business applications must know the constraints that SAP products and technologies bring. Gartner s enterprise architecture framework is a powerful planning tool. When applying the framework, however, enterprises deploying SAP business applications must know the constraints that SAP products and technologies bring. Real-Time Collaboration 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. In the case of SAP, how should enterprises that depend on its business applications build a highly effective enterprise architecture? SAP s R/3 and mysap Products 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 enterprises (typically large), of which 80 percent are R/3 customers and 20 percent are mysap customers. 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 the 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 Gartner Entire contents 2003 Gartner, Inc. 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 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 4). But it is important for SAP customers, centered on R/3 or the mysap suite, to appreciate how SAP products and technologies fit into the Gartner enterprise architecture framework. Figure 4 The New Enterprise Architecture Framework The Multienterprise G rid Enterprise Business Process Styles Patterns Bricks Source: Gartner Research Multienterprise Grid

3 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 that strategy is the SAP Web Application (WAS). It incorporates XML, WebFlow (using WfXML) and several 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. Currently, however, it is too immature to use for non-sap integration. For such general integration, enterprises should depend on leading enterprise application integration vendors and consider deploying Web services. SAP also offers its MarketSet product for building businessto-business (B2B) electronic-hubs, 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 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

4 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 5). Gartner expects all existing baseline bricks to mature into retirement, containment or mainstream status. Figure 5 also lists all emerging SAP technologies. The classic SAP Basis brick (Advanced Business Application Programming, or ABAP, C++) in the foundation layer has evolved into the SAP Web Application brick (ABAP, C++, Java). For the computationally intensive supply-chain optimization products, SAP built its own memory-based database technology (LiveCache) but for optimization algorithms it partnered with ILOG. Figure 5 The Future of SAP s Own Technology Bricks Type Base line Retirement Containment Ma ins tream Emerging Foundation Layer Basis Component Basis WAS CRM Mo bile CRM Mobile Mo bile Engine Te chnology Technology Content/Cache Content/Cache SAP DB SAP DB Liv ecache Liv ecache User Integration (U2A) Application Integration (A2A) Enterprise Integration (B2B) Source: Gartner Research SAP GUI SAP GUI Internet Transaction Internet Transaction WAS WAS Web Dynpro Internet Graphics Internet Graphics Index Ma nag emen t Inde x Manag ement EP 5.0 EP 5.0 EP 6.0 RFC, BAPI, IDOC, RFC, BAPI, IDOC ALE ALE R/3 Plug-In R/3 Plug-In CRM Middleware CRM Middleware Exchange Infrastructure DCOM Connector DCOM Connector.NET Connector Java Connector Java Connector WAS Web Services Business Connector Business Connector Exchange XML XML Infrastructure Market Set MarketSet WAS Web Services A2A Application-to-ap plication EP Enterprise Portal Italics ALE Application Link Ena bling GUI Graphical user interface D en otes Windows B2B Business-to-business IDOC Intermediate documents Platform Only BAPI Business Applicat ion Programming Interfaces RFC Remote function call CRM Customer relationship management U2A User-to-application DB Databa se WAS Web a pplication server DCOM Distributed Common Object Protocol XML Extensible Markup Language Enterprises planning their enterprise architecture should do the following:

5 Focus on baseline and mainstream bricks wherever possible. Limit investment in retirement bricks. 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. 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. That is the individual set of specifications, standards, diagrams and guidelines to define and maintain their enterprise architecture. From this business starting point certain critical SAP factors can then be considered: 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 such interfaces 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 must manage them very carefully. It is important to rationalize and document all interface standards and to adopt the enterprise nervous system approach. 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 starting point for planning such a blueprint is corporate business strategy. It is vital to understand the future of all SAP technology bricks and to minimize the number of infrastructure technology bricks when building the blueprint.

6 SAP instance strategy, interface standards and business disruption policies cannot be overlooked when formulating an enterprise architecture blueprint. Written by Edward Younker, Research Products Analytical source: Derek Prior, Gartner Research For related Inside Gartner articles, see: Management Update: How to Implement a Successful ERP II Project, 25 September 2002 At Random, SAP Shows Thought Leadership on Supplier Relationships, 13 February 2002