IT-Conductor Blog

SAP Performance Best Practices for Implementation, Upgrade & Migration

Posted by Linh Nguyen on Jun 25, 2015 2:25:00 PM


See our recent SAP Performance Testing as a Service announcement

INTRODUCTION:

Optimizing SAP performance of the newly implemented, upgraded or migrated SAP environment should be one of the top priorities of an application or technology refresh project besides gaining some new functionality or business benefits.  However, our experience shows that most customers either short-cut these efforts or they are done as an after-thought.  Even when it is baked into the plan, often there are controversies about how to best approach performance testing, monitoring and optimization as part of an overall performance assurance methodology.  The results frequently reflect post-golive issues which hinder availability, end-user experience, that cause management and operation teams much headache.

In this post we will cover some essential items and best practices to consider when planning performance assurance around the life cycle management of an SAP environment.  We'll also point out some useful tools you can use to implement these tips, where appropriate.

On the go? Download FREE PDF !

ITC_SAPPerformanceBestPractices

SAP Basis System Health Check A limited time free offer valued over $2000 USD


To avoid performance shortfalls and end-user disappointment, we're summarizing the best practices in a complete performance assurance plan:

Phase 1: Sizing & Architecture Design

Phase 2: Business Service Level Agreement

Phase 3: Plan, Build, Deploy, Test

Phase 4: Monitor, Optimize

Phase 5: Baseline and Continuous Service Level Management


 

Phase 1: Sizing & Architecture Design

Sizing: and the design of the architecture that follows is the first important phase of any project.  A step in the wrong direction will likely derail the project.  The topic sounds technical right? Actually, sizing involves as much of the business as the IT team.  According to SAP, sizing involves 'Translating business requirements into hardware requirements - in an iterative process.'  Gartner in its June 2014 article (Follow Three Best Practices to Optimize SAP Business Suite Application Performance) recommended to 'Perform annual capacity planning for each SAP Business Suite application to ensure sufficient hardware headroom through its life cycle'.

SAP sizing involves collection of business metrics such as users, business transaction document volume and line items which equates to SAPS (SAP Application Performance Standard) which is a hardware-independent measurement unit representing a throughput processing requirement.  Certified Hardware partners who provide computing resources to SAP customers often measure the throughput of their platforms using standard Sales & Distribution (SD) benchmark where 100 SAP = 2000 fully processed order line items per hour (or 6000 dialog steps - also known as interactive GUI screen changes).  For more information, see www.sap.com/benchmark

There are 2 main approaches and tools associated, other approaches are combinations or deeper dives on the variations.  Sizing needs to take into account whether it's a new implementation, upgrade or migration as obviously an upgrade or migration may have better numbers from an existing production environment (e.g. SAP EarlyWatch report, or some monitoring report):

  • SAP Quick Sizer is a questionnaire-based tool which does a pretty good job estimating common business scenarios (such as ECC, BW, CRM, etc.).  Visit http://service.sap.com/quicksizing for further details
  • T-shirt sizing is an approach using 3-4 rough sizes under the assumption that some numbers are better than none when it comes to estimating processing requirements.  It can be useful for budget planning phase when numbers may not be clear, assumptions can be made and validation can occur later.  For more information visit http://www.slideshare.net/princedoddi/sizing-sap-system

Architecture Design: Once the sizing information has been generated as standard SAPS, the customer can submit those to their platform vendor (which may now also include cloud providers).  The vendor architect will map those requirements to CPU, Memory, Disk Size, I/O throughput, and Network load.  Based on those requirements, platform specific hardware or virtualized infrastructure options are proposed.

Tips:

  • Customers to shop several partners for options, assess pros and cons, and if possible perform a proof-of-concept (PoC) on those options.  In earlier SAP days, POC can be costly with leased hardware and services which may get credited by the vendor towards a purchase (if made).  Nowadays, with cloud PaaS (Platform as a Service) and IaaS (Infrastructure as a Service), it's definitely less costly to trial before your buy.
  • Sizing is part art, part science so make it iterative and review often as earlier assumptions become fact or validated as part of PoC or testing.  Requirements also may change over time so just expect them and iterate accordingly.  Of course, the more complex the business scenarios, the more iterations may be needed to address various application needs.

Phase 2: Business Service Level Agreement

Business Service Level Agreement (SLA) are ways of measuring the quality of service that IT provides to the business units or end-user groups of the application.  Sometimes they may be referred to internally in IT as Operational Level Agreement (OLA), which governs how the IT environment should operate to provide shared services to end-users.  Before building, testing and delivering any service, IT organization should establish templates and metrics for which the Business can agree with as the baseline for service quality.  These items will become KPI (Key Performance Indicator) which are measured, reported for compliance on a periodic basis.

Common SLA metrics may include:

  • Availability (Planned and Unplanned)
  • Average Dialog Response Times (System wide)
  • Application Response Times (Specific transactions or group of transactions)
  • Batch Processing Run Times
  • Incident Response Times (Incident detection to resolution for specific event types such as job, transaction, interface failures)

Tips:

  • IT and Business (or Line of Business - LOB) should agree during this phase to mock-up dashboards which would measure, report, notify and pre-assemble remediation processes to deal with SLA violations, including service desk queues and team assignments to deal with availability and performance issues or incidents.
  • Poor Performance = Poor Availability

Phase 3: Plan, Build, Deploy and Test

ITC_SAPPerformance-LifeCycle

Plan: the work and work the plan!  Now that there are clear sizing, architecture and SLA established, it's time to map out the tasks required to accomplish the delivery of a functional and efficient application environment.  Depending on the size of the project, executive sponsorship must exist to create a project plan that includes availability and performance related tasks in every step.  

Build: documentation must reflect the reference architecture chosen to support the availability and performance requirements determined in the previous two phases Sizing & Architecture, as well as SLA.  Often, either a time gap and/or team gap occur such that the build is done by a different team later and does not look anything like the original design

Deploy: isn't it the same as Build? It can be if you're building only one system, often it's not the case with SAP.  Unless your environment is a single-system landscape, many customers will build development, QA, test/staging, DR and Production.  Sometimes a Production environment is built initially as a learning exercise for early testing, but deployed again with various optimization or automation, especially in virtualized settings or software-defined datacenter such as VMware.

Test: validates the build and deployment to ensure it performs as expected in the areas of availability and performance.  The more testing with objectives the better the operational readiness the team and environment.

Tips:

  • Regardless of organization size, a performance taskforce (either dedicated or virtual) should be established to focus on the performance aspects of everything from architecture decisions, configuration, build, testing and go-live
  • Proper testing may sometimes reveal more than just configuration defect but also vendor platform or software defects (aka bugs).  This is part of the burn-in process needed to stress new environment
  • Test automation tools will greatly accelerate both functional validation and performance load test so that iterative testing can be done.  SAP provides for Business Suite the eCATT tool which with trained resources can record and replay transaction testing scenarios, while other vendor tools like HP LoadRunner and Worksoft Certify provide more powerful integrated test automation.  IT-Conductor can integrate tests built by these tools into automated test scenarios that can be scheduled to run and analyzed

Phase 4: Monitor & Optimize

Monitor: Gartner also listed the top 3 best practices as 'Implement proactive performance monitoring and trending for each SAP Business Suite
application and its infrastructure' in its June 2014 article.  Whatever SAP monitoring tools you choose, whether native vendor tools such as SAP Solution Manager, CCMS, or 3rd-party tools, consider the 10-Ways to Automate towards Smart Application Management

Optimize: can be at the infrastructure level (OS, DB, Storage, Network), application configuration, and custom code.  Apply specific tuning recommendations from each vendor for the technology deployed.  Poorly optimized code can be mistaken as performance issues at the infrastructure level, so application code analysis along with SQL analysis are typically the next level of optimization once monitoring has identified them as top consumers.  Code inspectors can be used to identify poorly formed code which may appear fine when run against small volume but grinds against large volume of data.

Tips:

  • Code review for performance is a critical part of application life cycle management.  Use System trace, ABAP trace, SQL trace, Root-cause analysis tools to pin-point the deficient resource hogs
  • Tuning should only be done if performance can be measured before and after to gauge the effectiveness of any optimization
  • Use synthetic transaction monitoring to simulate transactions end-to-end on a proactive basis to check their status and response times as well as detect when deviation occur from performance baselines for those transactions

 

Phase 5: Baseline and Continuous Service Level Management

Baseline: involves the performance measurement at key times to capture what to expect under certain workload, such as load tests, benchmarks and other cycles like daily, weekly, monthly, quarterly, annually.  Pre-golive tests and measurements should provide estimates of what to expect after going productive on the new environment.  After go-live, the actual production workload at those cycles like month-end or some key peak workload times should be captured for comparisons and analysis.

Continuous SLM: Performance is dynamic and constantly changing based on business usage patterns and data volume over time, so continuous vigilance in monitoring, analysis and optimizing is required to ensure capacity and configuration continues to meet demands.

Tips:

  • GoingLive Check and EarlyWatch are some SAP services customers often leverage, but they can lack the dynamic tools for deeper dive and can be reactive, even though they are supposed to be proactive.  Look for proactive tools that monitor and manage exceptions as they occur with baseline capabilities for comparisons, as well as dynamic SLA dashboards based on flexible definitions of KPI
  • Service Impact Management monitoring tool is important to relate whether infrastructure or application issues actually have impacts on overall SLA so that appropriate priorities can be assigned to managing those exceptions.  Otherwise, there would be too many unprioritized items fighting for the performance team's resources.

 


SUMMARY:

SAP Performance management is a complex subject that spans many teams, technology and processes within the organization, but there are clear best practices with which to guide organizations of all shapes and sizes on ways to manage it as a life-cycle rather than a one-time occurrence.  Whether implementing SAP for the first time, upgrading/patching or migrating to new platforms, the effort spent will pay back many folds in operational efficiencies that ensure better user experience as well as business availability

Looking for an integrated solution to help with many of the SAP Performance management needs?  Try IT-Conductor, engineered as a cloud-based SAP Performance management platform.  We also offer SAP Performance consulting via our partner solution at OZSOFT

ITC_TwitterLeadGenerationCard-4x1



 

Linh Nguyen

Written by Linh Nguyen

Linh was born in democratic Vietnam, escaped from the communist after the war as a boat-people refugee to Malaysia, subsequently immigrated to Australia where he attended high-school and completed dual-degrees in Computer Science & Computer Engineering in just 5 years. He started SAP career in Melbourne, then came to the US in the mid-1990s as a SAP technical consultant. He built a software and consulting company in Silicon Valley in 1996 named OZSoft and has been an entrepreneur with a passion to automate IT processes. In 2014, he started IT-Conductor, Inc. as CEO and co-founder along with David Stavisski, with the goal to help IT organizations to Stop Guessing and Start Managing by automating IT operations using a cloud-based platform IT-Conductor.

Topics: HANA Availability & Performance Monitoring, SAP Transaction Performance, Application performance management, Performance monitor, SAP Performance Service Level Management, SAP Performance

FREE IT-Conductor Trial to Monitor SAP

Posts by Topic

see all

Recent Posts

Subscribe to Email Updates