SAP TCOROI Customers Final

TCO and ROI Analysis of SAP Landscapes using VMware TechnologyW H I T E P A P E R

TCO and ROI Analysis of SAP Landscapes using VMware Technology

W H I T E P A P E R / 2

Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Overview of the TCO/ROI Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

The Four TCO Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Direct and Indirect Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

TCO Calculation and Improvements for Virtualized SAP Systems . . . . . . . . . . . . . . . . . . 11

TCO Calculation for SAP Data Center Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 11

Requirements and Sizing for New and Reused Hardware . . . . . . . . . . . . . . . . . . . . . 11

Methodology for Calculation of Hardware Requirements . . . . . . . . . . . . . . . . . . . . . 12

Productivity Improvement with New Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

SAP Data Center Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

TCO Calculation for Data Center Server Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Calculation of Storage Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Storage Productivity Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

SAP Data Center Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

TCO Calculation for Data Center Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Methodology for the Calculation of Network Requirements . . . . . . . . . . . . . . . . . . 15

Productivity Improvement due to Network Virtualization . . . . . . . . . . . . . . . . . . . . . 15

Data Center Server Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Data Center Power and Cooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

TCO Calculation for Data Center Power and Cooling . . . . . . . . . . . . . . . . . . . . . . . . . 15

Calculation of Power and Cooling Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Productivity Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

SAP Data Center Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

TCO Calculation for Server and Software Provisioning . . . . . . . . . . . . . . . . . . . . . . . .17

Methodology for the Calculation of Provisioning Savings . . . . . . . . . . . . . . . . . . . . . .17

SAP Deployment Provisioning Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

SAP Data Center Server Administrative Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Resource requirements for newer SAP releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

TCO Calculation for SAP Administrative Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Methodology for the Calculation of SAP Administrative Costs . . . . . . . . . . . . . . . . 19

Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19



Reduced Business Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

TCO Calculation for Business Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Methodology for the Calculation of Business Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

SAP Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

TCO Calculation for SAP Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Methodology for the Calculation of SAP High Availability . . . . . . . . . . . . . . . . . . . . .21

Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

SAP and VMware Server Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

TCO Calculation for Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

SAP Installation and Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

SAP Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

SAP Downtime Minimized Upgrade Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

SAP Resource Minimized Upgrade Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Building Up an SAP Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

SAP Software and Hardware Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

SAP Support Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

SAP Kernel Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Industry-Standard (x86) Hardware Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Non-Industry Standard Hardware and Software Contracts . . . . . . . . . . . . . . . . . . . .24

SAP Enhancement Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

TCO Calculation for SAP Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

SAP Planned Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Methodology for the Calculation of SAP Planned Downtime . . . . . . . . . . . . . . . . . . .25

TCO Calculation for SAP Planned Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

VMware Infrastructure investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

VMware Infrastructure Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

VMware Infrastructure Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Training Class Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

VMware Virtualized SAP Environment Design and Planning . . . . . . . . . . . . . . . . . . . . . .28

Heterogeneous or Homogenous SAP Migration Costs . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Investment for SAP Physical to Virtual Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

System Copy Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

SAP Heterogeneous System Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

SAP Homogenous System Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30



Physical to Virtual Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

VMware Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Customer P2V SAP Migration Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Use Case Scenarios Before and After Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

SAP Solution Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Customer SAP Solution-Based Landscapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

SAP Landscapes Before Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

SAP Landscapes After Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Annual Hardware and Software Cost Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Annual A/C and Power Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Annual Cooling Costs for SAP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Deploying an SAP Solution with VMware Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Cost of Deploying a Solution Before Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Cost of Deploying a Solution After Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

High Availability and Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

SAP Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

SAP Message and Enqueue Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

HA and Clustering Before Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

HA and Clustering After Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Summary of SAP clustering and VMware high availability . . . . . . . . . . . . . . . . . . . . .45

SAP Front End Client Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Client Systems Before Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Capital Investment in VMware VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Client Systems After Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

SAP Upgrades and Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Upgrades and Patches Before Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Upgrades and Patches After Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

TCO Reduction: Three Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

TCO and ROI Summary for Customer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

TCO and ROI Summary for Customer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

TCO and ROI Summary for Customer 3 without VMware VDI . . . . . . . . . . . . . . . . . . . 55

TCO and ROI Summary for Customer 3 with VMware VDI . . . . . . . . . . . . . . . . . . . . . . . .57

Customer 1 TCO /ROI Summary with Planned Downtime Costs . . . . . . . . . . . . . . . . . .59

Customer 2 TCO /ROI Summary with Planned Downtime Costs . . . . . . . . . . . . . . . . . .61

Customer 3 TCO /ROI Summary with Planned Downtime Costs . . . . . . . . . . . . . . . . . 63

Customer 3 TCO /ROI Summary with Planned Downtime Costs and VMware VDI . 65

Virtualizing Large Enterprise Applications with VMware vSphere . . . . . . . . . . . . . . . . . . 67



Executive SummaryThis study examines how VMware software reduces total cost of ownership (TCO) for SAP landscapes. It focuses on three German reference customers, representing three different industry sectors with different numbers of concurrent SAP users.

SAP Customer Descriptions

CUSTOMER INDUSTRY SECTOR IMPLEMENTATION SCENARIO CONCURRENT SAP USERS

1 Automotive Heterogeneous SAP migration from a mainframe to x86

400

2 Pharmaceutical Heterogeneous SAP migration from a UNIX Cluster/Oracle to x86 hardware

200

3 Government Homogeneous SAP migration from X86 physical servers into virtual with VMware Converter

100

Source: VMware partner AddOn

These customers have virtualized their entire SAP infrastructure together with the associated databases. Some of the data was collected during the project phase using in-house questionnaires. All three customers run productive SAP systems on VMware Infrastructure 3. The projects have been finalized to the customers complete satisfaction. The detailed results for a three-year calculation before and after the SAP landscape virtualization have been combined and can be found in the appropriate chapters following.

The following tables summarize the TCO and return on investment (ROI) calculations for the three companies based on their successful migration from physical SAP environments to VMware infrastructure. All pre-defined customer objectives have been fully achieved.

The cost savings for SAP planned downtime is based on an estimate of $120,000 US per hour, which can vary in different use cases. The contribution to the TCO in this study is weighted at 30 percent. The planned downtime reduction is achieved with the use of VMware VMotion and the simplification of building clusters.

Please note that all monetary amounts in this document are expressed in $US.

TCO Savings with VMware Virtualization

CUSTOMERTOTAL COSTS WITHOUT VMWARE INFRASTRUCTURE*

TOTAL COSTS WITH VMWARE INFRASTRUCTURE

SAVINGS TCO IN %

Customer 1** $1,991,280 $372,321 $1,618,962 81

Customer 2 $772,131 $131,628 $640,503 83

Customer 3*** $252,765 $128,546 $124,219 49

Customer 3**** $399,165 $240,646 $158,519 40

* Reference prices based on customer information and quotes for pre-virtualization environment ** Value for simplified SAP Upgrade is included ***Value for VMware VDI is not included ****Value for VMware VDI is included



TCO savings with VMware Virtualization Including Costs of Planned Downtime *

CUSTOMER TOTAL COSTS WITHOUT VMWARE**TOTAL COSTS WITH VMWARE SAVINGS TCO IN %

Customer 1*** $ 5,447,283 $2,100,321 $3,346,962 61

Customer 2 $ 4,228,131 $1,859,628 $2,368,503 56

Customer 3**** $10,188,765 $5,312,546 $4,876,219 48

Customer 3***** $10,335,165 $5,424,646 $4,910,519 48

*Achieved through VMotion and simpler cluster build

**Reference prices based on customer information and quotes for pre-virtualization environment

*** Includes value for simplified SAP Upgrade

****Value for VMware VDI is not included

*****Value for VMware VDI is included

Customers 1 and 2 used UNIX and mainframe hardware before moving to virtualizing on industry-standard x86 systems.

Customer 3 used x86 systems before and after virtualization. For most medium-sized business customers this example fits best.

Break even for all three customers was between one and six months.

Customer Objectives for SAP Virtualization with VMware

CUSTOMER OBJECTIVES ACHIEVED

Customer 1 Reduction of hardware costs Reduction of hardware and

software maintenance costs

Yes

Customer 2 Reduction of hardware costs Reduction of hardware

maintenance costs Reduction of cluster costs

Yes

Customer 3 Reduction of cluster software and maintenance

Reduction of external consultant know-how requirements

Yes

Source: customers

Replacing expensive mainframe and UNIX systems with x86 and VMware virtualization technology reduces costs significantly1. Furthermore, customers achieve more flexibility and higher availability with all their SAP systems as well as simplified maintenance operations.

This study looks at the first three years after virtualization. Once the SAP solutions have been virtualized and encapsulated in virtual machines, further projects such as a technology refresh (migration to faster hardware and storage) become much easier. Moreover, external consultant costs can also be reduced.

1 All customers had shared storage infrastructure in place prior to virtualization. As a result, the virtualization projects did not introduce additional costs in that area.



IntroductionThis document provides a detailed overview of how three organizations use VMware virtualization technology to reduce TCO and increase ROI for their SAP solutions.

TCO is usually several times higher than merely the procurement costs. In addition to license costs for software, it is also necessary to consider hardware costs, maintenance fees, personnel costs for implementation and operation, and expenses for user training and licenses. The calculation of the total cost of ownership provides important information for planning and implementing projects and consolidating system landscapes, (defined as optimally combining components from different scenarios and integrating them on one physical server, as far as possible). Increasing cost pressures for companies make it necessary to merge systems, data, applications, and access to programs, and thereby achieve corresponding savings. There are various models for calculating TCO, including those devised by analyst firms Gartner Group and Alinean, each of which takes different costs into account.

The common goal of all TCO models is to split the total costs into blocks to identify the cost drivers within the system landscape. In this study, together with three customers with different user requirements from different industry sectors, we have analyzed TCO and ROI using the VMware/Alinean model. For SAP landscapes several adjustments were necessary. In addition, SAP aspects like clustering, deployment and patch scenarios enhance this model.

Several other TCO/ROI methodologies for VMware are available, but no single one covers the specific requirements and approaches for mission-critical Enterprise Resource Planning (ERP) applications such as SAP. Nearly all enterprise core business processes can be represented by this software.

SAP software is complex, with many dependencies related to customer needs. High availability, flexibility, scalability and reliability are key requirements for its users. Before SAP solutions can be used, many customizations are required. SAP is a multi-user environment, where 500 or more users can work simultaneously in the same system. Different operating systems and database platforms are supported by SAP, including UNIX, Windows, and Linux. (In conjunction with VMware, however, only Windows and Linux operating systems are supported.) These conditions make it necessary to adhere carefully to specific requirements when installing, supporting, maintaining and upgrading an SAP landscape.

To understand the benefits of running SAP solutions on VMware virtualization technology and the resulting calculation and measurement methods for the TCO/ROI study, this paper explains technical issues, procedures and best practices for running SAP solutions successfully in a virtualized environment. Following these procedures will result in customer cost savings.

To summarize:

This document describes a number of different areas where customers can save time and reduce costs by running SAP solutions on VMware virtualization platforms.

Another topic is the performance improvement observed after virtualization. For example, background jobs run 40 percent faster than they did on the older hardware.

This TCO/ROI study was validated together with our partner AddOn, which hosts the SAP Virtualization Competence Center in Europe. The study analyzes three different projects planned and implemented by this partner.

The intention of this paper is to help organizations quantify the current before VMware cost of ownership for SAP solutions-based landscapes. The study shows the after VMware scenario, quantifying the cost savings and the initial investments to set up and deploy the virtualized SAP data center.

The methodology uses proven financial techniques, industry research, VMware field and customer data and user-provided metrics to quantify the values. The TCO/ROI analysis formula subtracts the after VMware scenario from the before VMware scenario to document the change in TCO and other benefits from the VMware solution over a three-year period.

The ROI analysis formula compares the savings with the incremental investments as a percentage to illustrate the ratio of returns versus investment (ROI = Total Cumulative Savings / Total Cumulative Investments).



Overview of the TCO/ROI MethodologySAP recommends securing the productive SAP ERP system (PRD) with one or two additional systems in front called Development (DEV) and Quality Assurance (QAS).

Furthermore, all other SAP solutions such as SAP Enterprise Portals, SAP Exchange Infrastructure Systems and SAP Business Warehouse (Business Intelligence) should be handled in the same way. The collection of three independent systems for each SAP solution is called an SAP landscape.

The customers in this study, regardless of the number of users working concurrently, have followed this recommendation. As a result, these customers have to manage several servers with different requirements and high availability criteria.

For all three reference customers in this study, physical DEV and QAS systems were under-utilized in terms of CPU and memory consumption.

One way to reduce the total costs of servers is to improve asset utilization through workload consolidation. Over a 24-hour period, we have seen utilization of DEV and QAS systems at less than 20 percent of x86 and other hosts (UNIX, mainframe) computing capacity. One of the reference customers has a worldwide presence and, as a result, some of its systems have no idle periods. Nevertheless, the customer is not an exception to the rule: most of its physical systems are under-utilized.

Using these utilization values we can consolidate SAP DEV and QAS systems with a ratio of 4 or 5 to 1. This means that five SAP systems can be hosted on one well-sized VMware ESX host server. The number of virtual machines that can be hosted on one ESX host server is always dependent on the underlying physical hardware. The SAP PRD system is in all three customer cases a mission-critical enterprise solution. SAP defines some prerequisites for such systems:

The SAP release must be supported, together with the VMware software

The resources of SAP virtual machines should not be over-committed.

In this study, all calculation parameters for hardware and software vendors are anonymous. This allows a better comparison among the three analyzed project implementations, focusing on the VMware benefits and features for SAP Landscapes.

The Four TCO CategoriesFor our SAP / VMware study, we have chosen the Alinean/Gartner model with adapted contribution values for SAP implementations. This best reflects the Cost of Operation of an SAP solution. Costs are divided into four major categories. The following table shows the four cost categories and their contribution to the TCO.

COST CATEGORY CONTRIBUTION TO TCO SAP APPLICATION ACTIVITIES

Downtime 30% Planned and unplanned downtimeUsers affected

Operation 40% SAP maintenanceSupportDeploymentMaintenanceProcess and planningUpgradesEnergy consumption



COST CATEGORY CONTRIBUTION TO TCO SAP APPLICATION ACTIVITIES

Administration 10% Asset managementFirmware upgradesProcurementTraining (IS, end-user)

Hardware, software 20% Hardware, softwareAdditional management softwareSupplies

Cost categories and their contribution to TCO Source: Kagermann, Henning Prof .SAP Press book SAP-Solutions

DowntimeControlling and reducing the downtime of a dedicated SAP system is a critical success factor in an enterprise. External consultants work in DEV systems, while most of the SAP application users work in the productive SAP system. In the event of massive failure or disaster, hundreds of SAP users are unable to read and write business data from the ERP system. One of our reference customers operates in the automotive sector. He told us that in the event of an unavailable SAP system, supply trucks would not be able to deliver or charge parts. The whole logistics department would come to a standstill. There are many examples of the business need for high application availability; without it, the business loses money.

Downtime can be due to a user waiting for a service desk problem to be resolved, to planned maintenance, or to unplanned failures (e.g. network outage, database outage, application outage, etc.).

OperationDay-to-day operation of an SAP system requires a great deal of attention. The architecture of an SAP system consists of:

Operating system

Database

SAP software release

Additional SAP servers for the dialog instance

Each component must be integrated and monitored separately with system management software. SAP has an integrated Computer Center Management System (CCMS), but it only allows control and monitoring of an individual SAP system itself. Commonly, complex business processes are spanned over other application solutions as well. There is a need for additional system management software to take precedence and control over all business system members.

Operational elements comprise the technical staff resources including in-house staff, contractors, and outsourced management and support contracts. Included in this accounting are costs by operation subcategory (Technical Services, Planning and Process Management, Database Management and Administration, and Service Desk) and, for actual data collection, expense responsibility (Corporate IS, Business Unit IS).

To help in evaluating this cost we have obtained global values from IS management and have evaluated management time surveys.

AdministrationSometimes SAP administration interferes with SAP operation. However, we focused on asset management, firmware and hardware upgrades, procurement and training (for both IT staff and end-users).


W H I T E P A P E R / 1 0

Hardware and SoftwareSAP places very restricted requirements on hardware for different SAP solutions. For a productive use of SAP systems on virtualized hardware, SAP supports the virtualization solutions VMware ESX version 3.x. SAP exclusively supports 64-bit Windows as the operating system for virtual machines on AMD and Intel processors. On these operating system versions, all SAP applications (based on SAP NetWeaver Application Server ABAP and Java) that are supported on physical hardware are also supported on virtualized hardware.

Direct and Indirect CostsBesides the classification into categories, we have split the calculation of costs into

direct (budgeted) costs

indirect (unbudgeted) costs

Direct (budgeted) costs are the capital, fees, and labor costs spent by the corporate IT department and business unit IS groups for delivering information technology services and solutions to the organization and users. Direct costs capture actual costs for all direct expenses related to clients (mobile and desktop), servers, peripherals, and the network in the distributed computing environment.

Indirect (unbudgeted) costs measure the efficiency of IT in delivering expected services to end-users. If IT management and solutions are efficient, users are less likely to be burdened with self- and peer support as well as downtime. If IT management and solutions are inefficient, users typically must spend more time supporting themselves and each other (self- and peer support) and are affected by more downtime.

Indirect costs by definition cannot be measured directly and there is not always a direct causal relationship. But efficient IT spending can have a direct positive impact on end-user productivity. On the other hand, inefficient spending or cuts can cost an organization more because of lost productivity.

A very good example of indirect costs is energy costs. All three reference customers handle power for the SAP server as global costs.



TCO Calculation and Improvements for Virtualized SAP SystemsTCO Calculation for SAP Data Center Server HardwareSAP data center server workloads can be consolidated with virtualization. Customers generally achieve a consolidation ratio for SAP development, quality assurance, training, and demo systems of between 4:1 and 5:1, depending on hardware.

In mission-critical SAP environments, customers typically use a dedicated VMware ESX instance for the SAP production system, because SAP strongly advises against over-commitment of system resources for production environments.

Prices used in this study are based on systems with two-core and four-core sockets from Intel and AMD. After consolidation, unneeded system hardware can be reused or reallocated to other applications and future server purchases can be delayed or avoided.

The following table shows x86 hardware prices only:

Annual Costs of Certified Servers for SAP Systems*

CPU CAPACITY (SOCKET) ANNUAL SERVER COST

1 CPU $5,000

2 CPU $7,500

4 CPU $17,300

8 CPU $33,000

16 CPU $45,000

32 CPU $77,000

* Source: Internal customer information . Prices include chassis, CPUs, 32 GB RAM, and two local disks . Network and SAN are tallied separately .

Within this document, when we refer to reuse of an application server we mean reuse as a VMware ESX host, because most of the reusable SAP servers are certified for VMware ESX as well. This is an important factor in the TCO/ROI calculation and lowers the cost for purchasing ESX host systems. All three reference customers described here have purchased new multi-core server equipment for VMware ESX version 3.5.

To calculate servers for both the As Is and Projected environments, the consolidation savings are considered over the entire analysis period. We have examined the amortized server capital cost and the annual support and maintenance contract costs for the current installed base, as well as costs for the consolidated environment.

For the TCO data center hardware calculation we have used the formula:

Annual SAP hardware and software savings = Total servers * (cost per server) As Is Total servers with VMware ESX * (cost per server/useful life) Projected

Useful life in SAP hardware cycles = 3 years.

Requirements and Sizing for New and Reused HardwareReducing the number of physical servers definitely has a positive impact on the TCO calculation, but the virtualized SAP infrastructure must meet at least the same or, preferably, achieve even better performance values, availability, scalability, and reliability as the physical environment.

To meet these demands, all three customers in this study have gone through an SAP virtualization assessment.



This service is offered and delivered by VMware and AddOn Systemhaus, a VMware partner located in Walldorf, Germany. VMware and AddOn jointly host the SAP Virtualization Competence Center (http://www.vcc-sap.com). The assessment evaluated performance values of the existing physical SAP servers over a specific time period (in this case, between four and six weeks) to obtain information about the sizing of the VMware ESX hardware and the number of VMware ESX instances necessary to virtualize the existing SAP servers.

Typical daily business workload and sporadic peaks occur in this measurement window.

Methodology for Calculation of Hardware RequirementsVMware Capacity Planner is a tool used in the SAP Virtual Assessment. The tool discovers and catalogues relevant server information, and measures performance values over a defined time period. The measured data is stored locally or can be transferred to a VMware store called https://optimize.vmware.com.

Hardware discovery occurs after the tool is installed and properly configured. The following figure shows an example of a Capacity Planner report on discovered systems and includes information about the server chassis.

Figure 1b following shows an extract of an SAP server performance assessment:

Figure 1a: example of a Capacity Planner report on discovered systems and includes information about the server chassis .

Figure 1a: example of a Capacity Planner report on discovered systems and includes information about the server chassis .



After evaluating the data over a period of time, the number of VMware ESX instances is calculated.

SAP Assessments help to calculate the number and sizing of the VMware ESX host servers needed to provide robust and well-scaled SAP systems in a virtualized environment.

Productivity Improvement with New HardwareAll three customers have reported performance improvements with their virtualized SAP systems.

According to the SAP basis team of one reference customer, after successful migration of the productive SAP system with approx. 400 concurrent SAP users, they have seen a dramatic improvement in SAP system performance.

HARDWARE AV. RESPONSE TIME IN SAPDB REQUEST TIME IN SAP

DB DIRECT READ IN SAP AV. CPU-TIME

As Is 900 ms 500 ms 9.5 ms 177 ms

Projected (in a VM)

568 ms 326 ms 5.2 ms 10 ms

The most surprising effect is the runtime of a Material Requirements Planning (MRP) background job. Physical hardware calculates the job in 10,000 seconds; with the virtualized infrastructure it takes only 6,000 seconds.

Another customer has assigned more memory to the SAP system in the virtual machine, because legacy hardware did not have enough physical memory to increase the total amount. This has a positive impact on performance because of the settings of database and SAP buffers, e.g. the SAP Parameter abap/buffersize for the Advanced Business Application Programming (ABAP) programming buffer.

SAP Data Center StorageThere are several ways to connect VMware ESX hosts to shared storage. Shared storage is a prerequisite for using the VMware High Availability (HA) feature. The following access technologies can be used with VMware and SAP solutions.

TECHNOLOGY PROTOCOLS TRANSFERS INTERFACE PERFORMANCE

Fibre Channel FC/SCSI Block access of data/LUN

FC HBA High (due to dedicated network)

iSCSI IP/SCSI Block access of data/LUN

iSCSI, HBA, or NIC Medium (depends on integrity of LAN)

NAS IP/NFS File (no direct LUN access)

NIC and IP switches Medium (depends on integrity of LAN)

Source: VMware

All of the reference customers use Fibre Channel technology, because iSCSI and NAS currently have 10 Gbit/sec network hardware limitations (driver availability) and prerequisites (10 Gbit/sec switches). Nevertheless, using iSCSI or NAS can dramatically reduce costs for the network infrastructure. With NAS and iSCSI, no Fibre Channel assets are necessary.

TCO Calculation for Data Center Server StorageOne of the key cost factors in implementing a SAN architecture is the need for every server to be connected to a shared storage. This connection requires an investment in purchasing, deploying, and managing host bus adapters (HBA) to connect the servers to SAN fabrics. Each virtualized SAP system reduces the cost of implementing a SAN by reducing the number of SAN switches and HBAs needed.



All of the customers in this study already have a Fibre Channel SAN; therefore an investment in new storage technology was not necessary.

The following algorithms were used to calculate the storage TCO in this study:

Savings on HBA = ((Number of HBAs) * Price per HBA)/Life per Server) As Is (same) Projected

Savings SAN switches = ((Number of SAN Switches) * (Price per HBA) / (Life per Server) As Is (same)) Projected

Each server is calculated with 2 HBA for trespassing reasons.

SAN switches are calculated with 24 ports.

Calculation of Storage RequirementsWe used the inventory function of the Capacity Planner tool to analyze how many servers As Is had HBAs built in, since these HBAs were consequently attached to the SAN fabric as well.

As a result, we got a percentage As Is of servers attached to the SAN. In the projected environment we assume 100 percent of servers are attached to shared SAN. Attached to shared storage, these new servers become highly available because they can leverage the VMware HA feature.

As part of the VMware Virtualization Check, we obtained the I/O requirements for traffic between the SAN and the physical SAP machines. They are shown in Figure 1, in the Disk columns showing utilization in Transactions per second and MB per second. In addition, we checked and proved the results in the SAP systems with the help of SAP mechanisms (e.g. SAP Transaction ST04).

Typically, a Fibre Channel Disk in a SAN environment is able to deliver 180 I/O per second. Taking the storage RAID level into consideration, the number of disks needed in a SAN can be calculated.

Storage Productivity ImprovementIn the beginning of SAP migration project discussions, customers were very skeptical about gaining SAN improvements from SAP virtualization.

From a performance point of view they were right; there is no big difference between accessing data from a raw device (i.e. without using the VMware vStorage Virtual Machine File System) physically or virtually. Once we explained VMware Storage VMotion, however, customers saw the advantages immediately. This feature allows the movement of complete SAP system data (virtual OS, SAP and database files included) to other storage areas while the SAP system is up and running, and what is particularly exciting even to other SAN boxes, regardless of vendor and access type (iSCSI, NAS or Fibre Channel). Just imagine how difficult it is to migrate data from one SAN storage provider to another. The cost benefit of this capability is hard to calculate in a study such as this one, but many external consultant days can certainly be saved.

Another benefit for one of the reference customers was the ability to simplify his SAP offline backup strategy. Other features like data reduplication have not been analyzed. Specific storage tools from different vendors are being used by the customers, but this is outside the scope of this study.

SAP Data Center NetworkingAn efficient SAP system has to communicate over the network, with adequate response times, with hundreds of SAP front end applications. SAP systems are typical client-server systems: a query is sent from the client; the result set is calculated and sent back by the server.

To satisfy availability and Service Level Agreement (SLA) policies, typical physical SAP servers have redundant network team-enabled cards built in.

TCO Calculation for Data Center NetworkingThe number of physical network components, and thus the necessity of implementing different team-enabled drivers for different operating systems, is reduced with VMware virtualization technology. With fewer physical servers attached to the network, fewer switches, ports, NICs, and cables are required to provide server connectivity for the corporate network. One customer said: After virtualization, we completely filled one office room with useless network cables.



For this study we used the following equation to calculate savings on networking components:

Annual network savings = round UP (Number of servers * Number of NICs per server * Number of ports per NIC) / Number of ports per network switch) As Is (Same) Projected

Methodology for the Calculation of Network RequirementsThe total number of network cards is delivered by the discovery function of Capacity Planner in the Inventory section. We were able to see how many network cards in the SAP systems were built in, and with the aid of Capacity Planner, we could see the network traffic in MB/second.

Productivity Improvement due to Network VirtualizationThere are many NIC vendors in the market, each with different firmware, ports, and device drivers. With virtualization there is no need to pay particular attention to these details, because the network mechanism is part of the VMware tools.

Apart from cost reduction and administrative simplification, one of the biggest benefits of virtualization for SAP projects is the ability to change the virtual network card connection to other defined virtual switches on the fly. Customers can clone complete SAP virtual machines for fallback, backup reasons, for the creation of a test system, or for freezing errors for reproduction during an upgrade. Due to identical hostnames and IP-addresses, the cloned virtual machine is redirected to an internal switch with no physical connection to the enterprise LAN. This switch reduces the risk of generating problems and errors in enterprise networks.

It also saves time and costs for consultant services, since changing hostnames in SAP environments requires adjustments in operating system environment variables, share or mount points, SAP profiles, and SAP tables. An SAP system with ABAP and JAVA stacks is even more complex.

Data Center Server SpaceA reduction in the number of physical servers and SAN and network switches means reclaiming valuable data center space. Expansion of future data center facilities and power requirements can be avoided. Typically, special infrastructure (cooling racks and power systems, disaster resilience) is required for larger SAP systems due to redundant power supplies, multiple CPUs, and memory requirements.

As a result of discussions with the customers who took part in this study we concluded that, for this TCO analysis and all three reference customers, the countable monetary value of saving a few square meters is low. As a result we have decided to exclude server, storage, and network space calculations from this study. One customer did avoid having to perform a cooling efficiency upgrade of his air conditioning thanks to virtualization, but this is discussed in the next section.

Data Center Power and CoolingSAP systems are typically installed and integrated in the common customer data center. The largest SAP customer has implemented a redundant failover data center and replicates the storage data asynchronously to the failover site with SAN storage tools.

Power consumption in a data center can be divided into three categories:

Operating power for the computing infrastructure, including server hardware, network switches, SAN components

Network critical physical infrastructure (NCPI), such as transformers, uninterruptible power supplies (UPS), power wiring, fans, lighting

Cooling power for air conditioners, pumps, humidifiers

TCO Calculation for Data Center Power and CoolingVirtualization allows the number of physical servers to be reduced, along with related networking and data center infrastructure. As a result, power consumption for operation and cooling decreases.



Power saving is calculated by the differences in operating system power consumption and cooling power of hardware before (As Is) and after virtualization (Projected), as follows:

Annual Server Cooling Power per Server = Operating Power per Server * Cooling Load Factor * Airflow Redundancy / Airflow De-rating

To be fair, we have to acknowledge that, because of higher CPU utilization caused by higher consolidation ratios, a VMware ESX host system requires more cooling and energy than a physical server that is used less optimally.

In addition to power consumption, servers produce heat and require substantial cooling to keep running. Furthermore, the analyzed data centers have shown so-called hot spots, in which heat density is greater than in other areas. Data centers require additional airflow to account for inefficiencies related to humidification. Humidification is required to reduce damage resulting from a static discharge.

We used British Thermal Units (BTUs) for the calculation of the cooling device costs. One BTU is the amount of heat energy needed to raise the temperature of one pound of water by one degree F. This is the standard measurement for the amount of energy in fuel as well as the amount of output of any heat generating device.

3.41 million BTU = 1000 KW/h2

100 servers retired is equivalent to taking 122 cars off the streets per year. A typical car over an annual operating period produces nearly 12,000 pounds of CO2 emission or 600 gallons of fuel)3

The electricity average price per hour in Germany in 2008 = USD $0.28 per 1 KW/h.

The data center operating hours of the participating customers = 8736 (24/7/52) hours.

Calculation of Power and Cooling RequirementsThe operating power consumed by server hardware has been calculated by adding up the power ratings of each server in the data center. Because this number represents the maximum power used, it should be de-rated to achieve steady-state power consumption. In SAP environments we have seen an average running load factor of 50 percent and higher. This indicates that X86 servers consume between 50 - 70 percent of maximum rated power on average. For the TCO calculation we used BTUs available for the cooling environment and the average energy price per KWh in Germany in 2008 (see section 4.5.1). Together with the customers, we analyzed the operating manuals of the server and cooling units, in order to work out how many KW/h are used before and after virtualization.

The following table shows the power consumption of an X86 server:

SERVER WITH POWER WATT/H POWER / DAY IN KWATTPOWER / YEAR IN KWATT

COST / YEAR @ $0.28 KW/H

1 CPU 475 11.4 4161 $1,165

2 CPUs 550 13.2 4818 $1,349

4 CPUs 1150 27.6 10074 $2,820

8 CPUs 1600 38.4 14016 $3,924

16 CPUs 4400 105.6 38544 $10,792

32 CPUs 9200 220.8 80592 $22,565

Source: Power Consumption: Alinean 2007 and average electrical power price in Germany in 2008

2 http://www.physics.uci.edu/~silverma/units.html

3 Shulz, Garry, Storage Power and Cooling Issues Heat Up, May 21, 2007 http://www.enterprise storageforum.com.



Productivity ImprovementThe best improvement we saw was in a customer data center that was filled with physical hardware where the cooling system was operating at its limit. Decreasing the amount of physical hardware with virtualization saved the customer from having replace its cooling environment.

With regard to energy and power consumption, there are a number of social and economical aspects to be considered as well. Under the heading Green IT and carbon reduction, customers can use these savings as an instrument to show the companys contribution to the fight against global warming. For simplicity, we have not taken these criteria into consideration in our calculation model.

SAP Data Center ProvisioningWith virtualization, it is easier to acquire, set up and deploy SAP hardware and software to meet increasing demand. Typical customer SAP landscapes consist of development, quality assurance, and productive systems. One customer in this study enhanced the landscape with a training system and an SAP Solution Manager.

The hardware setup consists of server unpack, network and power cabling, rack installation, and disk setup. The SAP software deployment includes the installation of the operating system, database and the SAP software. In a physical environment, a high availability cluster-enabled software must be installed as well.

TCO Calculation for Server and Software ProvisioningProvisioning savings are measured as the working hours saved in not having to provision servers manually. The savings are calculated by multiplying the hours and the saved hourly wage of an SAP basis administrator.

For the installation of an SAP system we have calculated two full-time administrator days (16 hours) = Person hours per Provisioning Event. Included in the installation are the pre- and post- installation steps of an SAP Solution.

Annual data center SAP deployment provisioning savings = (Systems provisioned per year * Person hours per provisioning event * Average hourly labor rate for SAP basis staff) As Is (Same) Projected

+

Annual data center server provisioning savings = Server provisioning per year * Person hours per server * Person hours per provisioning event * Average hourly labor rate for SAP basis staff) As Is (Same) Projected * 0.5 (improved deployment time)

Person hours per provisioning event = 3 hours

Average hourly labor rate for basis staff = US$45

Methodology for the Calculation of Provisioning SavingsWith the aid of the SAP Virtualization Check we discovered the count of physical SAP systems, size of the SAP landscape, and consequently the number of VMware ESX host servers required to meet the performance and HA requirements for the virtualization project. With the aid of the HR department and in collaboration with the stakeholders, we created an average hourly wage for the SAP basis administrator for each customer. Besides the normal server installation, the SAP software deployment is considered and added to the TCO.

SAP Deployment Provisioning ImprovementVMware virtualization technology enables very fast deployment times to build up SAP landscapes. Depending on the systems involved, we can reduce the provisioning time for a three-system SAP landscape from six days to just under three days, for a 50 percent reduction in deployment time.

Initial SAP deployment savings = (Initial SAP Deployment) As Is (Same) Projected * 0.5 (improved deployment time with VMware template technique)



SAP Data Center Server Administrative CostsReducing the number of physical assets helps to lower administrative costs. Physical server administration includes changing the amount of physical memory and adding more CPUs (sockets) to asset inventory, and managing security, disaster and recovery planning, as well as compliance management, vendor and contract management, chargeback and financial budget management.

In terms of software, fewer monitoring tools are necessary, which also reduces administrative costs.

The following table lists additional physical resource requirements for newer SAP releases.

Resource requirements for newer SAP releases

SAP RELEASE ADDITIONAL CPU USAGEADDITIONAL MEMORY USAGE

ADDITIONAL DISK SPACE

SAP R/3 Enterprise (4.7) Baseline Baseline Baseline

SAP ECC 5.0* 10% 10% 5%

SAP ECC 6.0** 15% 20% 10%

Source: *SAP Note 778774 **SAP Note 901070

The reason for higher CPU and memory usage is that newer SAP releases need additional indexes, use larger table rows, support more database users or show different behavior of the cost-based optimizer of the databases.

Like every other software vendor, SAP follows a specific support and maintenance strategy. Some customers have to upgrade to a newer SAP release due to the extended maintenance costs.

7-2 maintenance strategy for new releases of the core applications* of SAP Business Suite: 7 years of mainstream maintenance, 2 years of extended maintenance. Long-term planning security and higher return on investmentnine years maintenance horizon

Additional time to deploy and benefit from innovation delivered via enhancement packages

Less additional cost for extended maintenance

Figure 2: SAP Maintenance Strategy



TCO Calculation for SAP Administrative CostsReducing the number of physical servers can reduce server administration labor costs, allowing reallocation of resources to more strategic uses.

Total server FTE (Full Time Equivalent) = Total physical servers / Physical servers per FTE

Total server administration labor costs savings = Total server FTEs required * Average annual burdened salary of SAP basis administrators) As Is (same) Projected

Methodology for the Calculation of SAP Administrative CostsWe pooled the information for the salary and external consultant support from the SAP basis team. The salary information was obtained directly from the employees. This kind of information is very critical, and no HR department was willing to give detailed information about the average annual salary. However, to verify what we learned from the employees we compared the information with an IDC|Alinean survey conducted in 2007.

ImprovementAs the SAP enterprise solution evolves to address more complex business problems, new versions of SAP software and current capabilities are introduced. VMware virtualization can provide capacity on demand for SAP functionality with minimal service interruption.

After the virtualization of physical SAP systems was completed, incentive pay for overtime of the SAP Basis Team was reduced by 20%. Subsequently, fewer people have been necessary to administrate the SAP Landscapes. External consulting services have been reduced.

All three customers benefit by encapsulating their SAP systems into a virtual machine. Figure 2 shows how long SAP estimates the lifetime for an SAP NetWeaver Version (6.40, 7.00), with the aid of mainstream maintenance. Typical hardware amortization, due to lifetime and service contracts with the vendor, is between three to four years. As a result, SAP customers need to redeploy the SAP release to a new piece of hardware once during its lifecycle. Due to operating system and database dependencies, these are complex projects. All three reference customers need support from different vendors and consultants (e.g. storage vendor, SAP consultants) for these hardware refresh cycles.

With virtualization, SAP systems can be cold migrated to any new VMware-certified system with no change to the core SAP application inside the virtual machine.

Reduced Business RiskIn case of a disaster, virtualization reduces risk because if provides hardware independence and built-in mechanisms to reduce the downtime of SAP systems. Traditional disaster recovery solutions require redundant productive hardware. An active-passive cluster for the database is also a mandatory failover mechanism to prevent downtime. Server configuration and complex multi-step processes in bare-metal environments are difficult and time consuming.

TCO Calculation for Business RiskThe following mathematical algorithm is used in this study.

Data center server disaster recovery savings = (Amount of disasters per year * Recovery time * Downtime cost per hour) As Is (Amount of disasters per year * Recovery time * 25 percent (Reduced recovery time with VMware) * Downtime cost per hour) Projected

The 25 percent reduction of recovery time is achieved with VMware Consolidated Backup in combination with third-party backup and recovery solutions.

Methodology for the Calculation of Business RiskIn our projects we have tried to investigate the downtime costs per hour. These costs include the labor for IT and the indirect impact of lost user productivity.

Unfortunately, opinions and calculations varied greatly within the companies; therefore we deferred to a study from IDC|Alinean published in 2007. IDC|Alinean costs for downtime for typical applications are shown in the next table.



Cost per Application Downtime/Hour

APPLICATION TYPE COST PER DOWNTIME HOUR BY APPLICATION

Collaboration and Messaging $60,000

ERP * $120,000

Infrastructure/Productivity Tools $42,000

Line of Business Applications $120,000

Retail / Point of Sale $400,000

Scientific / Technical $85,000

Supply Chain Management $120,000

Trading $600,000

* SAP solutions are ERP applications Source: IDC/Alinean

Alternative formula:

Downtime cost per hour = (Productivity impact to SAP end-user in %)* End-user burdened salary + costs for, say, production stop, delivery bottlenecks, contract penalty, loss of reputation

ImprovementsVMware virtualization works alongside SAP solutions to deliver enhanced infrastructure and high availability of applications for critical business functions. Using VMware infrastructure, customers can implement a unified disaster recovery (DR) platform that allows many production SAP virtual machine servers to be recovered in the event of a failure, without investing in an exact replica of the production hardware. VMware infrastructure capabilities such as VMware VMotion, VMware High Availability (HA) and VMware Consolidated Backup (VCB) deliver enhanced levels of availability to virtualized SAP environments.

SAP ClusteringTwo of the reference customers require an uptime of 24 hours 7 days a week, because they have worldwide subsidiaries across global time zones with different working hours. Virtualization helps to reduce both planned and unplanned downtime.

In a physical environment, SAP offers SAP cluster solutions in conjunction with database and storage vendors, which must be additionally implemented. This situation is described in one of the case studies below.

TCO Calculation for SAP ClusteringClustering implementation costs are higher than hardware and software costs. We have used the following formula:

Annual SAP high availability savings = ((Hourly labor rate for IT system administrator staff) * (Person hours to implement and test an SAP cluster) * Size of SAP solution + (Costs for additional cluster software) + (Volume of additional server costs)) As Is (Same) Projected.

The SAP customers told us that to implement an initial physical SAP Cluster you need approximately five work days. An additional eight hours in maintenance time is necessary for SAP support stack scenarios in comparison to a NON-cluster environment.



Methodology for the Calculation of SAP High AvailabilityWe worked with the customers to analyze the need for SAP high availability. Traditionally, each SAP productive system is a candidate for SAP high availability, as described earlier. With VMware virtualization, all SAP solutions including those in DEV and QAS can benefit from the VMware HA feature, at no additional cost.

Together with the customers, we analyzed the average baseline prices for the following products:

Microsoft Cluster

HP/Digital TruCluster

HP ServiceGuard

IBM HACMP

On average, the price for a two-node cluster in Unix environments is approximately $20,000 per year. A Microsoft Cluster is calculated at approximately $2000 per year.

The customers told us that the implementation of an initial SAP Cluster requires approximately five additional work days. An additional eight hours is necessary in SAP support stack scenarios in comparison to a NON-cluster environment.

ImprovementVMware HA provides cost-effective high availability for SAP applications running in virtual machines. In case of a physical server failure, SAP virtual machines can be automatically restarted on other servers within the pool that have spare capacity. VMware HA minimizes downtime and IT service disruption, while eliminating the need for dedicated stand-by hardware. It provides high availability across the entire virtualized IT environment, without the cost and complexity of failover solutions tied to either operating systems or specific applications. The VMware HA feature is part of the enterprise license and can be activated in five minutes for each kind of SAP solution.

The customers in this study report that single point of failure components like message server, enqueue service and database components run reliably and need no additional attention from cluster service monitor components. To monitor these SAP components, SAP CCMS features are used. VMware heart beat alarm settings prevent unresponsive SAP operating systems.

SAP and VMware Server Load BalancingSAP provides distributed transaction processing, automated load balancing, and replicated service framework offering high levels of scalability and resource optimization for the application environment. SAP environments also have a built-in logon group load-balancing mechanism. This mechanism can be combined with the VMware Distributed Resource Scheduler feature to assist with optimizing the infrastructure resources used by SAP and non-SAP applications.

TCO Calculation for Load BalancingThere are no real formulas to calculate a TCO value for load balancing. The load balancing mechanism in VMware can guarantee the performance values and thresholds defined in service level agreements.

ImprovementVMware infrastructure solutions support load balancing capabilities by addressing resource management across the entire data center infrastructure and across multiple distributed SAP application servers. VMware Distributed Resource Scheduler (DRS) dynamically allocates and balances computing capacity across a collection of hardware resources aggregated into logical resource pools. VMware DRS continuously monitors utilization across resource pools and intelligently allocates available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. When an SAP virtual machine experiences an increased load, VMware DRS automatically allocates additional resources by redistributing virtual machines across the physical servers. VMware DRS optimizes IT environments to align resources with business goals, while ensuring flexibility and efficient utilization of hardware resources.



SAP Installation and UpgradesSAP solutions can run in physical environments on different operating systems and database platforms. Only Windows and Linux (Red Hat, SUSE) operating systems are supported in a VMware virtual infrastructure. There are some pre-configuration steps on the operating system level that are required before an SAP installation takes place.

SAP InstallationThe installation steps in a virtualized environment are the same as in the physical world and can be performed in two days. With a virtualized environment, however, we have seen three benefits in SAP installation scenarios.

SAP software DVD media management can be simplified

Installation steps can be captured and recovered with the help of the VMware snapshot manager in VMware vCenter

Once an SAP system is installed, templates and clones can be made easily

In all three customer projects, the required SAP media DVDs were copied to a VMFS Disk and attached as a temporary installation drive. After installation, this drive can be reassigned to other virtual machines.

An SAP installation typically consists of four phases:

Installation of the operating system

Installation of the database

Installation of the SAP executable

Initial import and load of the database with tables, fields, and data

After each successful installation phase, a VMware snapshot was made to allow roll back to a know clean state in case of a serious error.

SAP upgrades consist of two phases:

Prepare

SAPup

In the SAPup phase there are two methods for importing the new release objects into the database. These methods are:

Downtime-minimized

Resource-minimized

The following is a brief explanation of both SAP upgrade methods.

SAP Downtime Minimized Upgrade MethodDue to the size and volume of SAP packages (SAP support packages, SAP add-on installation packages, and SAP add-on upgrades), import of the packages has a large impact on the duration of system downtime, when no end-user is able to work. To reduce the downtime when importing SAP support packages, the downtime-minimized import mode assists with importing the majority of the objects during production operation of the system. In this mode, the objects are imported into the database in an inactive state, in which they are largely invisible to the system. The system can continue to be used productively.

For this upgrade methodology, we strongly advise against the using VMware snapshots while end-users are working productively. Data can be lost in the case of a rollback to older snapshots.

SAP Resource Minimized Upgrade MethodIn resource-minimized environments, the system is down during SAP package import. The advantage of this method is that the database log files do not really increase, because no end-users produce additional data. This method is faster than downtime-minimized, but causes more downtime for the productive system.

With this method, VMware snapshots can prevent longrunning backup jobs performed by different departments and people.



Building Up an SAP LandscapeOnce an SAP system is installed in a virtual environment, VMware templates and the clone mechanism can be used to create an SAP landscape of two to five systems. SAP recommends the establishment of a three system landscape with development, quality assurance, and productive systems.

SAP Software and Hardware MaintenanceFrom time to time, SAP publishes changes and corrections to its solutions in support packages. These support packages are first applied to the development systems. After a successful test they are implemented in the downstream systems. Maintenance of the physical machines is also necessary, including such activities as doing a firmware upgrade of a network card, a Host Bus Adapter Controller, or the addition of more memory or CPU capacity.

SAP Support PackagesAn SAP system consists of different software layers, also called software components. All layers are regularly updated using support packages; that is, errors are corrected and new functions are provided.

The SAP system should always be kept at the current correction status to prevent errors in the standard release. In addition to the standard functions in an SAP system, additional functions are sometimes required for a particular industry solution (IS).

Each SAP support package has a stack number based on an SAP release number. If a customer has different SAP solutions and components, he has to deal with different SAP support package stacks.

In the table below the stack number 15 was released in the first quarter for SAP ERP 6.0. The next, number 16, is scheduled for August 2009.

Support packages and add-ons are installed in ABAP with an SAP transaction called SPAM and SAINT. For the Java stack a tool called JSPM (Java Support Package Manager) is used.

SAP Support Package Schedule for 2009 and SAP Solutions

We recommend instantly rolling back SAP virtual machines using snapshots during patch problem resolution.



SAP Kernel PatchesThe executable SAP programs are written in C and called SAP kernel. Each SAP release and SAP solution has its own subset and version of these executables. The programs must be patched from time to time, due to database, operating system, and release dependencies. Replacing these SAP programs causes SAP system downtime.

SAP kernel patching is a procedure in which the SAP programs are exchanged with current versions. Most of the up-to-date SAP release kernels are downward compatible. During the startup of the SAP system, these kernel programs are distributed to all attached SAP instances to make sure that every host or VM has the same patch version and functionality.

VMware patches can be tested concurrently on multiple configurations (different versions of OS, SAP, Web, etc.) that are hosted on the same physical system.

Industry-Standard (x86) Hardware MaintenanceNew computer equipment is usually sold with a warranty. The guarantee period in Germany is two years, but some vendors offer longer warranties. If the computer fails during the warranty period, the vendor should resolve any hardware problems at no additional cost. In addition, a customer can obtain an extended support and maintenance contract.

On average, we calculate using the following values for x86 hardware maintenance:

SERVER TYPE REACTION TIME (HOURS/DAYS/ YEAR) PRICE (USD)

2* Quad-Core 13/5/1 $450

4* Quad-Core 24/7/1 $840

Source: Customer contracts

Non-Industry Standard Hardware and Software ContractsTwo customers replaced their SAP systems running on non-x86 hosts with clustered environments with x86 technologies. The maintenance costs for the non-x86 hosts are significantly higher.

TYPE REACTION TIME (HOURS/DAYS/ YEAR) PRICE (USD)

Hardware 24/7/1 $46,000

Software - $20,700

We recommend dynamically reassigning SAP virtual machines with VMware VMotion to other systems while performing maintenance or changes on the current physical system, thus causing minimal disruption to end-users.

SAP Enhancement PackagesThe enhancement package for the SAP ERP application provides new or improved software functionality that can be implemented in a modular fashion. There is no need for a major upgrade. New features and technical improvements can be applied while the core software remains in place.

The enhancement packages include collections, or bundles, of enterprise services. Each bundle provides new services as well as documentation on how the services can assist with extending and reconfiguring processes or groups of related processes. Each bundle includes explanations of relevant processes, groups of processes, and roles, along with descriptions of business objects and tips on how to implement the new services.

TCO Calculation for SAP MaintenanceSAP maintenance is one of the major cost drivers for the reference customers. However, SAP patches, new SAP releases, are useful and necessary for reasons of new business functionality, security, and stability.



The calculation here is based on database sizes of nearly 500 GB.

SAP maintenance savings = ((SAP installation savings) As Is + (SAP upgrade savings) As is + (SAP patch savings)) As Is (Same) Projected * 0.75 improved by VMware

SAP installation savings (initial three-system landscape) = (2 work days * three systems * Hourly labor rate for IT system administrator staff per consultant) As Is (3 days for three systems * Hourly labor rate for IT system administrator staff or consultant)

SAP upgrade savings = ((5 work days * 1 DEV system + 3 days * 1 QAS system + 3 days * 1 PRD system) * Hourly labor rate for IT system administrator staff or consultant) As Is 0.8 *(same* Hourly labor rate for IT system administrator staff or consultant) Projected

SAP patch savings (complete support package stack) = (2 days * Hourly labor rate for IT system administrator staff) As Is 0.75 * (2 days * Hourly labor rate for IT system administrator staff) Projected

The SAP patch saving and the SAP upgrade factors of 0.75 and 0.8 are achieved by using VMware snapshot and clone technologies.

ImprovementThe new VMware clone and template technologies can save time and lower costs. Faster change management with fewer system resource requirements can be achieved using new test patches concurrently on multiple configurations (different versions of OS, SAP, Web etc.) that are hosted on the same physical system. With VMware snapshots, the backup times for milestones in SAP patch upgrade scenarios can be accelerated and resource utilization can be minimized.

SAP Planned DowntimePlanned downtime expenses are the annual losses in productivity due to planned unavailability of the SAP system. SAP planned downtime can be categorized as:

Hardware maintenance (adding more memory, adding more CPUs, firmware upgrades to the controller, and so on)

SAP software maintenance (adjusting SAP parameters such as memory, buffers, security settings, etc.)

Applying new support pack stacks

Offline backups

Methodology for the Calculation of SAP Planned DowntimeIn the SAP virtualization projects, we evaluated these criteria together with the customers end-users. We performed some end-user surveys and discussed the results with the IS management. For customers with 24/7 uptime, the reduction of planned downtime is equal to the downtime of the production system.



TCO Calculation for SAP Planned DowntimeThe SAP planned downtime depends on the company policies of the customer. The following values are taken from SAP customer surveys. A customer with 24/7 operation hours has the following prerequisites per year.

Annual SAP planned downtime for maintenance*

PLANNED DOWNTIME FOR MAINTENANCE

HOURS UNAVAILABLE

UNAVAILABLE PER YEAR IN % COST

Hardware** 4 0.05 $480,000

SAP Software per Central Instance***

16 0.18 $1,920,000

* At least two SAP patch stacks per year per eight hours each

** $120,000 for SAP ERP

***The contribution to TCO in the final calculation is 30 percent

In this study the calculation of SAP planned downtime is the same as for SAP unplanned downtime.

ImprovementWith VMware VMotion technology, the planned downtime for hardware maintenance becomes zero. While the SAP system is up and running, a hot migration to another VMware ESX host machine can be performed. Internal service level agreements can be fulfilled more satisfactorily with VMotion.

Offline backups can be completely replaced by VMware Consolidated Backup, with the aid of snapshot technology. VMware Consolidated Backup provides an easy-to-use, centralized facility for LAN-free backup of virtual machines. Consolidated Backup simplifies backup administration, reduces the load for VMware ESX host machines, and can reduce SAP downtime.



VMware Infrastructure investmentTo achieve expected TCO savings, there must be an investment in VMware virtualization solutions. Customers must take four areas into consideration:

VMware infrastructure licensing

VMware infrastructure training

VMware infrastructure design and planning

Heterogeneous or homogenous SAP migration costs

VMware Infrastructure LicensingDeploying a virtual infrastructure requires a onetime cost of purchasing VMware software licenses, as well as annual support und subscription costs. For an SAP solution as a mission-critical application, the VMware Infrastructure Enterprise Edition is required. The Enterprise edition includes ESX, VMFS, vCenter Management Server, Virtual SMP, VMotion, VMware HA, VMware DRS, and VMware Consolidated Backup.

The model derives the cost of software by dividing by two the total number of processors (socket) after virtualization. One Enterprise Edition server license for every two CPUs is required after consolidation.

Recurring fees vary, depending on the type of support and subscription program purchased. VMware provides Gold and Platinum level support contracts. Due to the need for 24 hours/7 days a week support for their SAP environments, two customers chose the Platinum Support model and pay 25 percent (21 percent) of the purchase price annually. We used the Enterprise Edition for the TCO calculation.

VMWARE VI EDITION DESCRIPTION VALUE SOURCE

VI Enterprise Edition License Cost

Unit price VI $5,750 VMware Commercial Price List*

VI Enterprise Edition License Units

Units to purchase Number of CPUs / 2 Calculated

VirtualCenter Management Server License Cost

Unit price VC $5,000 VMware Commercial Price List

Subscription Factor Percentage of unit price that yields annual fee

21% (Gold) 25% (Platinum)

VMware Commercial Price List

*Source: http://www.vmware.com/pdf/vi_pricing.pdf

TCO calculation:

Initial purchase = VI enterprise license cost * VI enterprise license units + VC management server license cost

VMware Infrastructure TrainingA training class is available for VMware virtualized SAP environments. This class can be found in the official SAP training catalog. For calculation purposes, the number of classes required is dependent on the number of administrators who require training. In addition, customers have attended the AD310 course classes for a better understanding how a virtualized SAP environment can be management efficiently.



Training Class Costs

CLASS TITLE COURSE COST*

AD310: Install and Configure VMware for SAP Administration (5 days)* $4,500

*Source: SAP Education Training Catalog http://www.sap.com/education

TCO calculation:

Initial VMware infrastructure trainings costs = AD310 * SAP Administrators * course cost

Initial costs for knowledge transfer

CUSTOMER NUMBER OF ADMINISTRATORS COST*

Customer 1 3 $13,500

Customer 2 2 $9,000

Customer 3 1 $4,500

*Source: Customer

VMware Virtualized SAP Environment Design and PlanningAn SAP / VMware migration requires dedicated planning and design of the virtualized VMware servers and SAN requirements, along with the adjustment of the SAP systems. Such a virtualization check, offered by multiple VMware SI partners, is used as the basis for the TCO calculation.

Cost of SAP Virtualization Check Offered by a VMware Partner

CONSULTING PACK AGE COST

SAP Virtualization Check (dependent on size of SAP landscape) $7,000

TCO calculation:

Initial virtualization check costs = Amount of SAP landscapes * Fee

Initial cost for SAP Virtualization Checks

CUSTOMER NUMBER OF VIRTUALIZATION CHECKS COST*

Customer 1 1 $7,000

Customer 2 1 $7,000

Customer 3 1 $7,000

Heterogeneous or Homogenous SAP Migration CostsTo facilitate the migration of physical SAP systems to a virtualized VMware environment, a certified SAP and



VMware migration consultant is needed. The time for the consultancy depends on the SAP database size. For databases smaller than 500 GB, twelve days are assumed (5-Dev, 3 QAS, 3 PRD, 1-STDBY).

Typical Costs per Day for a Certified SAP Migration Consultant in Germany

SERVICE COST PER DAY

Certified SAP and VMware Consultant Approx. $2,400

Source: VMware Partner

TCO calculation:

Initial Certified Consultant Costs = Number of days * Cost per day



Investment for SAP Physical to Virtual MigrationAn SAP system migrated to other platforms with different databases and/or operating systems is called a heterogeneous SAP system copy. If databases and operating systems remain the same, the migration is called a homogenous SAP system copy. The procedures and tools are supplied by SAP. In the case of heterogeneous SAP system copies, SAP strongly recommends the engagement of a certified SAP Migration Consultant. For homogenous SAP system copies, there is no specific SAP recommendation. The table following shows the decisions made by the three customers in this study on changing the operating system and the database for their physical to virtual (P2V) migration.

Customer Changes to Operating System and Database for Virtualization

CUSTOMER OPERATING SYSTEM CHANGEDATABASE CHANGE

SAP SYSTEM COPY PROCEDURE

Customer 1 X X Heterogeneous

Customer 2 X Heterogeneous

Customer 3 - - Homogenous

System Copy CategoriesSAP Heterogeneous System CopyA heterogeneous system copy is defined as one in which either the operating system or the database system or both are changed. A benefit of this kind of migration is the reorganization of the database and the combination of SAP Unicode features. In SAP terminology, the database is exported to the file system and imported into the target system.

SAP Homogenous System CopyA homogeneous system copy is defined as one in wh

Documents

SAP TCOROI Customers Final