Two Value Releases per Year - SAPfm.sap.com/data/UPLOAD/files/Two Value Releases per... · Two Value Releases per Year How IT Can Deliver Releases with Tangible Business Value

Two Value Releases per Year

How IT Can Deliver Releases with Tangible Business Value Every Six Months

TWO VALUE RELEASES PER YEAR

2

TABLE OF CONTENTS

0 LEGAL DISCLAIMER ....................................................................................................................... 4

1 IMPROVE VALUE CHAIN AND REDUCE SG&A COSTS IN FAST CYCLES ................................ 5 1.1 New business models require innovation and speed in IT ......................................................... 5 1.2 IT & SAP - the Business Contribution and Value Center ............................................................. 5

2 REQUIREMENTS AND RELEASE MANAGEMENT COMBINED WITH SAP UPDATES .............. 7 2.1 Managing Requirements from Business Users ............................................................................ 7 2.1.1 Gathering Big Ideas: Project Portfolio Management ......................................................................... 7 2.1.2 Gathering Small Ideas: Requests for Change ................................................................................... 8 2.2 Release Management ...................................................................................................................... 9 2.2.1 Overview and Benefits of Release Management .............................................................................. 9 2.2.2 Release Categories ......................................................................................................................... 10 2.2.3 Change Categories and Priorities .................................................................................................... 13 2.2.4 Combining Customer Major Release with SAP Innovation ............................................................. 14 2.2.5 Quality Gates for Minor and Major Releases ................................................................................... 15 2.2.6 Release Calendar (per year) ........................................................................................................... 15 2.3 Implementation of Requirements governed by Change Request Management and cProjects 15 2.4 Roles in Requirements and Release Management .................................................................... 16

3 MANAGE DUAL TRACK LANDSCAPE FOR MULTI-PROJECT SUPPORT ............................... 18 3.1 Implement a Dual Track Transport Landscape with 6 systems ................................................ 18 3.2 Dual Track Cutover Process ......................................................................................................... 20 3.3 Retrofit in a Dual Track Transport Landscape............................................................................ 21 3.3.1 Semi-Automated Synchronization of Dual Landscape with Retrofit ................................................ 21 3.3.2 When, and how often, to retrofit ...................................................................................................... 22 3.3.3 Prerequisites for Retrofit in SAP Solution Manager ........................................................................ 23

4 LEAN CUSTOM CODE – AVOID, IMPROVE, MINIMIZE .............................................................. 24 4.1 Custom Code Management Summary ......................................................................................... 24 4.1.1 The ‘green’ City Model – Lean Measurement .................................................................................. 24 4.1.2 Custom Code Management - Governance Process and Optimization............................................ 25 4.1.3 Custom Code Lifecycle Management - Transparency & Control .................................................... 27 4.1.3.1 Get transparency about custom code .............................................................................................. 27 4.1.3.2 Process and Architecture ................................................................................................................. 27 4.2 Avoid Modifications and get closer to SAP ................................................................................ 28 4.2.1 Gap management by Innovation Control Center ............................................................................. 28 4.2.1.1 How the Innovation Control Center works ....................................................................................... 28 4.2.1.2 Blueprint Analyzer ............................................................................................................................ 28 4.2.2 Monitoring and evaluating existing modifications ............................................................................ 29 4.2.3 Get Closer to SAP ........................................................................................................................... 29 4.2.4 Replace clones ................................................................................................................................ 30 4.2.4.1 Distinguishing SAP Original Objects from Clones ........................................................................... 30 4.2.4.2 Identifying the Usage Area of Clones .............................................................................................. 31 4.2.4.3 Cross system custom code versioning ............................................................................................ 31 4.2.4.4 Time for Improvement ...................................................................................................................... 32 4.3 Improve custom code quality ....................................................................................................... 32 4.3.1 Custom Code Quality Improvement with SAP ABAP Test cockpit/Code inspector ........................ 32 4.4 Minimize Modifications ................................................................................................................. 33 4.4.1 Usage and Procedure Logging ........................................................................................................ 33 4.4.2 Obsolescence of customer objects .................................................................................................. 33 4.4.3 Deleting objects with CDMC ............................................................................................................ 34

5 ONLY ADJUST AND TEST WHAT MATTERS .............................................................................. 36 5.1 Identify change impact on custom developments ..................................................................... 36 5.2 Reduce development scope to used objects.............................................................................. 36


3

5.3 Reduced test effort through Test Scope Optimization .............................................................. 37 5.3.1 Preparing BPCA .............................................................................................................................. 37 5.3.2 Standard Change Impact Analysis using BPCA .............................................................................. 38 5.3.3 BPCA Test Scope Optimization for large SAP change events ........................................................ 43 5.3.4 Quantitative Example ....................................................................................................................... 46 5.3.5 Value Proposition ............................................................................................................................. 48 5.4 Increase Test Efficiency by Test Automation ............................................................................. 48 5.4.1 Test Option 1 ................................................................................................................................... 49 5.4.2 Test Data handling in SAP Test Option 1 ........................................................................................ 51 5.4.3 Test Option 2 ................................................................................................................................... 53 5.4.4 Test data handling in Test Option 2 ................................................................................................. 56 5.5 Outlook: EhP Scope and Effort Estimator .................................................................................. 58

6 PERFORM UPDATES WITH NEAR ZERO DOWNTIME ............................................................... 62 6.1 Typical Pattern of Planned Downtime ......................................................................................... 62 6.2 Frequency versus Effort and Business Downtime .................................................................... 62 6.3 Managing Planned Downtime ....................................................................................................... 64 6.4 Minimize Planned Downtime ........................................................................................................ 67 6.4.1 Recommendations for ABAP-based systems .................................................................................. 67 6.4.2 Recommendations for Dual-stack-based Systems ......................................................................... 69 6.4.3 Recommendations for Databases ................................................................................................... 69 6.4.3.1 Any DB ............................................................................................................................................. 69 6.4.3.2 SAP HANA database ....................................................................................................................... 70 6.5 Outlook: Zero Downtime ............................................................................................................... 71


4

0 LEGAL DISCLAIMER

This script is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this presentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent.


5

1 IMPROVE VALUE CHAIN AND REDUCE SG&A COSTS IN FAST CYCLES

1.1 New business models require innovation and speed in IT Talking to many of our customers globally, there is enormous pressure on being able to implement new business models. Innovation and speed are required to compete with cloud providers like Amazon.com, for example, but up-front investments are hard to obtain and justify. Outcomes have to be predictable. Very often IT, and even the existing software solutions (SAP and non-SAP), are perceived as inhibitors of required business innovations. This is often due to the extent of modifications, but may also be caused by a lack of the skills and resources required to adapt and change existing solutions. Changing this perception requires a solid strategy and a new way of working together. It requires a platform which enables, not prohibits, business transformation. With the SAP Business Suite on HANA and the SAP Mobile Platform, SAP provides the building blocks of such a platform. Moreover, the SAP building blocks fit together and are managed and supported as one end to end business solution by SAP orchestration. SAP solutions are efficient to run, and they are built to scale. Last but not least, with the SAP mobile platform, every consumer and partner is always connected. In this way, SAP provides the capabilities to run SAP solutions without interruption. Many SAP MaxAttention customers run their SAP solutions as a single global instance, supporting their business operations all over the world. 1.2 IT & SAP - the Business Contribution and Value Center The speed of change of business models and the entry of strong new competitors into the market, require that change and transformation for more competitiveness be driven from the bottom of the pyramid. IT and SAP have to become a Business Contribution and Value Center, to actively and timely support the bottom of the pyramid. To achieve this, and become part of the LOB innovation requirements and cycles, requires a new business relationship. A business relationship on the one side based on a KPI framework to measure the performance and quality of existing end to end business processes. Finally, in a joint taskforce, IT and LOB run the 6 sigma improvement cycles. All of this can only work if the improvements which require software solution changes can be made productive in frequent cycles. A value release every 6 months is required. If innovations and improvements are not feasible in the existing framework of installed business solutions and processes, they have to be designed properly. Their feasibility and viability has to be analyzed. Finally, and most importantly, the desirability must be understood and the services/products designed appropriately. The SAP Business Suite on HANA, combined with the SAP Mobile Platform, are the enabling technologies and platforms to support the innovation required at the bottom of the pyramid. In combination with the business network cloud solutions of Ariba, and the cloud services of Success Factors, value can be delivered extremely fast. The SAP Business Suite is the business data foundation for most large enterprises today, especially for SAP MaxAttention customers. In many discussions with SAP MaxAttention customers they claimed that having all this data is important, but we do not do enough with it. The proper analytical functions could not be implemented on the transactional systems. The CPU and memory capacity was not available, and the transactional systems had too much impact on performance. This resulted in:

many data copies, and many batch jobs to load and aggregate data

a lot of manual and delayed work for accruals, profitability analysis, planning and analytics

Now, with SAP HANA, the reasons which made this necessary, no longer apply. There are no data loading programs and no aggregates anymore. All costs are allocated when they occur. All planning is done when required. We can provide much smarter IT solutions overall. The IT landscape becomes much simpler. Business process operation becomes much simpler, since work which needs doing today is now real time. SG&A costs (Selling, General and Administrative Expenses) are therefore reduced dramatically, and we establish one central data pool - one single source of truth. On top of that, data from suppliers and customers can be integrated to implement an improved value chain, end to end, from suppliers to customers. To manage risk, SAP also provides flexible deployment options. We provide a technology (the SLT platform) which replicates data from the transactional data foundation to an enterprise data warehouse (SAP Business Warehouse on HANA), or to an in-memory database (SAP


6

HANA). This allows fast time to market with accelerators or data warehouse functions. Sometimes it is also better to integrate non-company data on data warehouse level than on transactional system level. The SAP Mobile Platform now allows us to establish, on the SAP Business Suite, a user experience on mobile devices, tablets for example. To an end user, this looks like a cloud solution. With SAP Gateway, this new user experience is developed customer-specifically, without disruption and modifications of the SAP solution as the SAP Business Suite is cloud-enabled by the SAP Mobile Platform. To address these needs, rapid prototyping of new business models and capabilities is required. This is delivered in the framework of Build SAP Like a Factory. Based on building blocks delivered by SAP (Rapid Deployment Solutions, RDS) and industry/market best practices, the new business solution is integrated into the existing solution landscape. All integration issues and perceived gaps are managed in the Innovation Control Center. All gaps are resolved or closed quickly. To bring all these components together, SAP provides a new Build SAP and Run SAP Like a Factory methodology, with the following objectives:

1. A new value release with tangible and measurable benefits for each LOB, every 6 months

2. An upgrade to the latest release and technology, with (Near-)Zero Downtime, every 6 months Typical questions from customers are:

How do I manage the gathering of requirements of big and small ideas from business users, and translate them into major releases, minor releases and standard changes? How do I integrate SAP updates into this release strategy?

Are the designed software change processes and transport landscape effective? Do they support the release/maintenance strategy? Are they in line with industry best practices? How can the processes be improved for higher quality or higher agility for changes?

Can the number of non-productive systems be reduced, without impacting the quality of service? What is the “right” number of supporting systems? What is the best practice for developing multiple projects in parallel?

How can I predict, for a given SAP shipment (e.g. EhP), what custom code will stop working, and which regression tests will be required? Once scoped, how can I execute the adjustment and regression tests efficiently?

How can I deploy all these changes with minimum downtime for business users? In answer to these questions, this document lines out how to design and improve the software change management processes and the transport landscape, and how SAP Solution Manager can better automate tasks and control the process.

The target audiences for this document are IT architects, who ask the questions about software change management above. It is structured in five chapters:

1. Manage Requirements and Releases Collect big and small ideas (business requirements) and manage their implementation in major releases combined with SAP updates, minor releases and standard or urgent changes

2. Manage Dual Track Landscape Synchronize highly automated synchronization of dual development landscapes to support parallel deployments (releases) with minimum efforts and risks.

3. Lean custom code Avoid, improve and reduce custom code enhancements, and modifications, to minimize effort for software maintenance and customer release projects.

4. Only Adjust and Test What Matters Reduce project effort by focusing development and test on business-relevant changes and by automating tests.


7

5. Near-Zero Downtime updates Ensure minimal business disruption by maintenance and customer release deployments, with the latest SAP near-zero downtime methods and technologies.

2 REQUIREMENTS AND RELEASE MANAGEMENT COMBINED WITH SAP UPDATES

2.1 Managing Requirements from Business Users 2.1.1 Gathering Big Ideas: Project Portfolio Management

Portfolio management, or multi-project management, takes care of high-level project management tasks like planning, controlling, resourcing, and reporting of multiple development projects.

The target of strategic multi-project management is to identify business and IT requirements for new development projects, prioritize them with the business, according to business cases, and with IT according to business benefits, and manage their risks.

Once a program or project is approved, it is handed over to the project management organization for detailed planning and execution.

As well as changes implemented in development projects, updates and housekeeping activities are necessary for production support. Operations, which are usually managed by ITIL processes, provide bug fixes, continuous improvements or standard changes, regularly.

Project developments and production support might “fight” for the same resources, such as systems or people. Such conflicts between production support and project work cannot be resolved in isolation. We need the complete picture which takes into account risks, such as:

Project delays because key resources are blocked to solve problems which are critical for production

If the same object is processed multiple times within a timeframe, there is a risk of blocking it, and also a risk of object version mismatches (transport sequence violations) and object downgrades. Additional measures are needed to govern multiple transport requests of the same object. Testing such changes can also become more complex, or even irrelevant (e.g. testing a scenario which will not be imported into production).

To overcome such conflicts, we recommend integrated portfolio management and IT service management processes, which can harmonize the incident and change management processes based on company criteria.

These processes provide an assessment based on unified criteria and weighting, synchronize operational requirements and project management regularly, and define holistic processes for planning, development and deployment. During the process, strict release management eases the coordination of requests.


8

You can use IT Portfolio and Project Management (ITPPM) on SAP Solution Manager to manage the project portfolio process.

SAP's portfolio management capabilities give high-level visibility over the entire project portfolio, portfolio analytics, capacities, budgets, and resources.

Portfolio management provides a comprehensive and up-to-date view of the entire portfolio of IT projects, to present the full extent of project risks and opportunities. It allows you to overcome delays that can occur as information is collected from disparate sources. Portfolio management gathers diverse data into dashboards, which are the starting point for portfolio analyses.

Portfolio management integrates information from existing project management, human resources, and financial systems, to provide an overview of the project portfolio and resource availability, and it provides easy drilldown to details.

The overall structure of a portfolio is reflected in the hierarchy of investment buckets. This allows you a flexible categorization of portfolios. Portfolio management supports multi-level portfolio hierarchies. Portfolios can have several investment bucket hierarchies, which can for example represent product lines, organizations or regional structures. Once you have set up the investment bucket hierarchy, you can add items to the individual investment buckets, plan the budgets and resources, and make assignments accordingly.

You use financial and capacity planning to store and plan financial and capacity data for your project, and to maintain actual cost data. You can maintain financial and capacity planning data for an investment bucket, a scope item, or an initiative. You can also enter negative values for financial and capacity planning. After you have saved your entries, the system calculates the values according to your customizing settings.

Portfolio items represent objects (project proposals, concepts, for instance) that should be analyzed within a portfolio. You can compare portfolio items or initiatives in a scoring model, based on quantitative key performance indicators. This enables decision makers to make informed decisions about portfolio items or initiatives. You can implement different scoring models to aggregate data. The quantitative scores of a scoring model are obtained either from portfolio item or initiative attributes, or the results of questionnaires. You can use qualitative responses to questionnaires to derive numerical scores for risk, strategic fit, feasibility, and other types of soft data of portfolio items or initiatives. The business value of portfolio items is documented and is the basis for checking value realization in the LoB, once the project goes live and the enhanced IT solution is used productively. As SAP Solution Manager connects to all productive systems in the landscape, the improvements realized can be measured and compared against the expected business case and the business requirements that define the scope of projects.

2.1.2 Gathering Small Ideas: Requests for Change

Requests for change can occur daily, from various sources, e.g. a problem to be solved because of an incident (break fix), a minor enhancement to an existing business process, or a change to an existing project. In SAP Solution Manager IT Service Management, a request for change can be created to trigger the approval and initiation of the change process. A request for change may include following information:

Short description of the request for change Parties involved:

o Reporter

o Change manager


9

o Chand advisory board

o Service team

o Service agent

Impact on the business

o Urgency

o Priority

o Categorization of the request for change (business process or service effected)

Notes

Change description

Solution description

Description of workaround

Queries to the reporter

Answers from the reporter

In this phase, all information required to make a subsequent decision about what needs to be changed and what is the impact, is collected. Depending on the impact, a category and priority are assigned to the change, to be able to obtain approval. Thus, small ideas are usually delivered in minor releases or in standard changes, in which transport to production is not bundled. Break fix support is managed in urgent changes, which are transported to production on request. 2.2 Release Management 2.2.1 Overview and Benefits of Release Management

Release management is the process of planning, building, testing, and deploying software and configuration. It ensures that a consistent and cyclic re-occurring methodology of deployment is used, and, reduces the likelihood of errors in production, using formal checks and procedures. A release is the set of software, configuration, processes and documentation required to implement one or more approved changes. A release is a single cohesive entity for development, testing, distributing, deployment and support.

The key objective of release management is to protect the live productive environment while enabling business-as-usual corrections and enhancements to be deployed in a controlled manner. Releases include:

Major and minor business enhancements

SAP Maintenance: Support Packages, Enhancement Packages

Problem resolution development

Emergency fixes

Figure 1 outlines the principles of release management, release planning and a release calendar. In a release with multiple projects, as illustrated in Figure 1, all projects must be aligned when the release enters or exits a quality gate or major milestone.

The uppermost arrow depicts a timeline for which there will be three major releases. Four independent projects are shown in blue. The business owners, requirements analysis, change category and prioritization and the software change management (SWCM) organization will determine in which release a project is deployed. In this example, projects 2, 3 and 4 will be deployed in major release 2. These three projects must be aligned, and commit to ‘Synchronized Transition to Testing’ at the same time, and be aligned when the release enters or exits a quality gate or major milestone (e.g. end of development, testing cycles, and Go-Live).

For larger projects, which need to deliver functionality quickly and at different times, the scope of the project may need to be split by functions, and managed in multiple releases, such as for project 4.


10

Figure 1: Releases and Synchronized Testing of Projects

Incident-related changes are often implemented by customers individually, even if the deployment is not urgent. Releases should be used for all change types. It is best practice to differentiate between standard changes, emergency changes, minor and major releases, to accommodate the different requirements of production support and project development.

There are clear benefits of managing all changes in releases:

A repeatable and reliable software release process

A commitment to and visibility for the business of what goes live, and when

The stability of the production system is increased because the frequency of transports to production is reduced, and solid testing of the release components, as one cohesive work package, is ensured.

Quality gates can be defined as check points to sign off deliverables.

The overall costs for testing can be reduced by using common regression and integration testing for several projects/changes, as one cohesive work package.

Risk of inconsistencies is reduced, as forgotten transports or sequence violations are minimized

Administration efforts for transport management are reduced, as all projects move from one phase to another at in the same time.

2.2.2 Release Categories

Changes need to be allocated/ bundled into a release category. There are generally 4 release categories:

Major release: has a significant release window to introduce major new functionality consisting of large amounts of new development. Major releases are also used to deploy the latest SAP software versions, to immediately benefit from SAP innovations, legal changes and corrections. Time and resources need to be allocated for the required regression, user acceptance and performance testing.

Minor release: has a much shorter release cycle, and is intended for minor enhancements and problem resolution fixes. Due to the much shorter release cycle of a minor release, there will be


11

insufficient time for full regression and user acceptance testing, as conducted in a major release. A limited but targeted testing strategy is needed.

Standard change: is low risk, and the impact is clearly understood, such as certain configuration changes.

Emergency change: must contain only priority 1 changes that will be transported immediately, to solve critical production issues.

In contrast to major releases, minor releases enable changes in weekly to monthly cycles, in a traceable manner. If a user in a business department sees potential for improvement of a certain application, he can create an incident message directly from the transaction. Alternatively, a business process owner can request a small change. The incident appears in the work list of the Service Desk employee, who processes the incident and generates a request for change, if required. The request is approved and classified as an urgent change.

Because urgent changes need to be made in the minor release, the decisions made during the Change Request Management process are sufficient. This saves time, without neglecting the seamless documentation of the change.

Emergency Changes

Standard Changes

Minor Release Major Release

Deployment Cycle

On request only Every 1 - 7 days Every 1 – 4 weeks Every 3 – 6 months

Change Categories

Emergency only

Standard changes only (non-invasive, low risk and well known impact)

Non-invasive changes (+ re-import of emergency changes)

All types of changes, including invasive changes

Priorities Emergency only Normal Priority Normal Priority Normal Priority

Test focus

Regression test based on results of change impact analysis

UAT and Regression test based on results of change impact analysis

UAT and Regression test based on results of change impact analysis

UAT and Regression test based on results of change impact analysis, Interface Tests and Integration Validation.

Examples Changes to solve high priority incidents

Already approved changes, e.g. storage locations, MRP controller

Non-critical configuration, medium priority incidents

New (major) functions, Support/Enhancement Packages, Upgrades medium/low priority

Figure 2: Release Categories - Best Practice example

The test strategies (scope, effort and duration) are different per release category, depending on the level of changes. Figure 3 illustrates the focus and prioritization of test activities.


12

Standard Changes Minor Release Major Release

Test

Typ

es

Unit Test Yes (according to standard change process)

Yes (code inspections and peer reviews if possible)

Yes, including code inspections and peer reviews

Scenario Integration Test

No Yes Yes (important)

User Acceptance Test

No Yes (per correction/change) Yes (usually required for sign off)

Regression Tests Limited, based on results of change impact analysis

Extended, based on results of change impact analysis

Extended, based on results of change impact analysis

Performance/ Load Tests

No No Potentially based on outcome of single activity trace in Integration Validation

Additional Tests (System Tests, Cutover Tests

No Usually no Potentially (depending on request)

Figure 3: Focus and Prioritization of test activi ties

The release to which to assign a change has to be decided during Change Request Management. The decision criteria include the criticality and priority of the change: high risk changes need more testing, and are thus candidates for a major release cycle.

This assignment is made in the assessment and authorization step, which is an early step in the change request management process. It includes:

The definition of the test scope of a change request

The central categorization and prioritization of the change requests according to the change categories (defining the change impact) and change priorities

The assignment of the change request to a release category, based on the change category and priority

Agreement on a go-live date for the change, according to the release category and calendar


13

Figure 4: Change Request Management – Assessment of the Change Request

2.2.3 Change Categories and Priorities

In the previous section, we mentioned that only changes of a certain category and priority can go into a certain release category. It is important that the change categories and priorities are defined explicitly (“positive lists”) in advance, to avoid discussion in the day-to-day change request management process.

Change Categories:

Change categories reflect the impact and the risk associated with a change. Examples:

o Critical (invasive): Any configuration change or development that will, or could interrupt business-critical services, from a business or technical perspective, (e.g. changes to core transactions, user interfaces or common elements of business processes).

o Non-invasive: Any change that is not likely to affect the availability of one or more entire business-critical services, and that can be reversed in the event of an issue.

o Standard: Repetitive non-invasive changes with known outcomes and defined implementation procedures (e.g. new master data type configuration, like storage location).

The change request classification criteria should be defined explicitly, e.g. based on a number of end users/countries/business units affected, need for training of end users, invasiveness of the change (new, enhanced, changed process), magnitude of the change (single module, single application, multiple applications), expected effort to build.

For each change category, levels of decision makers should be defined.

Define the category “standard change”, as this reduces the assessment and approval load.

o The definition of a new standard change type includes the definition of the allowed objects and required test and validation steps.

o Create a standard change list, including owners of standard changes, and a pre-approved list of who can create and/or release transports containing standard changes.


14

o Once a standard change type is approved, a request of this type does not need to be assessed and approved. It will follow the predetermined, documented workflow, including a well-defined test scope.

Change Priorities:

The change priority indicates how urgent the change needs to be to be applied. Best Practice is to start with two levels of priorities, to keep the process simple.

o Normal: Changes of normal priority are those that can be processed in line with the change category definitions and associated target approval/authorization/implementation schedules.

o Emergency: Changes addressing priority 1 incidents. In a priority 1 incident, a severe outage affects multiple business processes, or an entire business unit.

A fast track process should be defined, and used for urgent requests. A typical shortcut is that the change manager approves the request directly, and later asks the CAB for approval in a regular CAB review meeting. Alternatively, an emergency CAB would have to approve an urgent request. In both cases, at least a basic assessment of effort and impact is necessary.

2.2.4 Combining Customer Major Release with SAP Innovation

One key element of an accelerated release strategy, delivering measurable business value with each customer release, is to include the latest SAP software versions (OS/DB version, SAP releases, enhancement packages and support packages) at the beginning of a major customer release. New business developments are then automatically based on the latest SAP technology. Combining SAP and customer releases allows you to benefit from latest SAP innovations, legal changes and software corrections immediately, for example to improve of the level of security and performance of your SAP systems.

The following figure illustrates a typical IT calendar, containing all release categories, including SAP software updates.

Figure 5: IT calendar

Most SAP customers separate the implementation of new SAP software versions and customer releases. The new SAP software is implemented by a “technical upgrade” project, with the goal to not change or enhance any business processes. Only corrections which are required to ensure that everything works the same after the upgrade as before it, are carried out.

In most cases, the reason for this decision is the combination of technical and functional changes increase the complexity of the project and, hence the risk of missing the main project goals, to stay in time and in budget, not to compromise business continuity and stability for the end users.


15

The latest SAP application lifecycle management innovations in the areas of dual landscape maintenance and the management of custom code, testing and business downtime, described in the subsequent sections of this document, mitigate the main risk factors, and allow you to benefit fully from SAP innovations in your releases. 2.2.5 Quality Gates for Minor and Major Releases

There should be at least three quality gates for a minor or major release:

Scope to build. After the definition of the requirement and before the build, all requests for changes except standard changes (pre-approved category of changes) need to be approved.

Build to Test: when development is completed (incl. developer/unit test), and before the release is tested, assess the status of the release and ensure that only transports of proven quality are moved to the testing system. This quality gate is optional for smaller changes.

Test to Deploy: based on the test results before the deployment, the final go/no-go decision for deployment is made. Do this for all changes and check that the operations team is well-prepared.

Large scale changes and projects can have additional quality gates. 2.2.6 Release Calendar (per year)

A release calendar is a planning tool which tells the enterprise what to expect, and when. Ideally, the release calendar maintained for the enterprise contains all hardware and software activity.

Once release categories have been defined, a release calendar, including major, minor and maintenance events, is created, and communicated to the enterprise.

It is Best Practice to align the release Go-Live dates across all SAP applications in the environment, e.g. one go live weekend for both SAP ERP and SAP APO within a region, for regional implementations.

The release calendar needs to be aligned with the business for freeze periods, downtime scheduling and frequency of shipment of changes.

The release calendar should also include cut-off days, CAB meetings and testing periods.

Figure 6: A Release Calendar

2.3 Implementation of Requirements governed by Change Request Management and cProjects Application architects, application experts (customizing) and developers design and program the solution, including adjustment, customizing, and unit testing of their developments.


16

When the developers have completed the corrections, testers can test them. Change Request Management transports the changes into the test system in a consistent manner. SAP Solution Manager supports a dual control principle, to ensure that the developers and testers are different people. You can only transport the changes into the production environment after they have been tested. The release manager implements the changes in the IT infrastructure in an effective, safe, and verifiable manner. The technical operator can then import the changes into the production environment. After deployment into production, the requirement is implemented, and the request for change can be concluded. The typical change request management process for such a change is described in the following figure.

Figure 7: Change Request Management Process

Change Request Management governs the engineering aspect of the project (architecture and design, build, test, deploy), and cProjects on SAP Solution Manager standardizes and improves project management from a PMO perspective (budget, time, skills, resources). It reduces administrative and system costs by providing project management functions that can be deployed independently, or integrated into your back-end systems (such as Human Resources and Financials). Project Management is ideal for managing phased projects. It delivers highly specialized support for product development, IT, or other types of projects. It supports structuring, scheduling, visualization, operative planning, and execution. You can create templates that you can use each time you create a project, to standardize your projects. You can include phases, tasks, and checklist items from project templates or checklist templates, in operational projects, or other templates and their lower-level project elements.

2.4 Roles in Requirements and Release Management

Roles and responsibilities are important, and need to be clearly defined and supported by the executive sponsor and the entire organization. Clarity of roles and responsibilities will have a big impact on how effective and successful software change management will be.

Some of the key roles are:

Business Process Owner: Is operationally responsible for one or more processes in a line of business. The business process owner is responsible for:

o Operational process controlling

o Planning and execution of the operational process

o Competence and resource planning of processes on an operational level. Coordination with other processes

Business Relationship Manager: Orchestrates the collaboration between IT and LOB (business process owner) to identify optimization opportunities for the value chain, in two dimensions. Firstly, identify improvements in Customer/Consumer Experience and improve the integration of suppliers. Secondly, identify efficiency and automation improvements, to reduce selling, general and administration (SG&A) costs).

Create

Request

Review and

Close Request

Test

Change

Build

Change

Assess and

Authorize Req

Deploy

Change


17

Portfolio Manager: Makes investment decisions using other people’s funds. Works closely with business relationship managers and a team of analysts and researchers, and is ultimately responsible for the investment strategy in IT.

PMO project manager: Ensures the project produces the required products, to the required standard of quality, within the specified time and cost constraints. Responsible for the project results according to the benefits defined in the business case.

Change Manager: provides a single point of contact, and is responsible for managing change, and the impact on the environment. Responsibilities include:

o Preside over change advisory board meetings

o Ensure received requests for change (RFC) are documented and addressed

o Monitor the progress of change through production

o Validate and close the change, with change advisory board

Change Advisory Board (CAB): Consists of individual stakeholders who have decision authority over the implementation of changes. CAB members should have a clear understanding of the business and technology requirements.

o The CAB is led by the Change Manager

o The CAB meets regularly to approve/authorize all major and medium change requests, review the closure of completed change requests, and review the the change process performance indicators.

o Participants need to represent the different divisions, and understand the business needs and the dependencies, impact and risk of a change.

Emergency Change Advisory Board:

o For critical changes, an emergency CAB should be defined, to convene and decide about emergency change requests expediently.

Release Manager: Oversees the major milestones of a release, such as development, testing, deployment deployment, and is accountable for the end-to-end lifecycle and quality of a release. The tasks of a release manager include:

o Release plan scope, execution, compliance and delivery, in particular deliverables from multiple projects and their impact that must come together.

o Resolve/escalate issues that impact the release or release milestones.


18

3 MANAGE DUAL TRACK LANDSCAPE FOR MULTI-PROJECT SUPPORT

The system landscape is a key element of a release strategy. A classical 3-system transport landscape is not sufficient to be able to deliver two value releases to the business. You should support such a release strategy with a dual track transport landscape, as described in the following section. 3.1 Implement a Dual Track Transport Landscape with 6 systems The dual track transport landscape, also known as N+1, was designed for customers who need to continuously release a significant number of software updates, regularly, and provide a secure and stable production end user environment. The advantage of dual track transport landscape is the addition of a parallel track to production, which contains a second development and testing instances that will be used continuously to develop, test and release software to the production track, in release waves, according to the release calendar. This design has the salient and distinctive advantage over the single track that it enables the customer to move the entire project development scope, and all project development teams, away from production – a clear segregation of development tasks from production tasks and their personnel. Minimizing the change activity in the production track, plus the personnel that can make those changes, will empower the production support team’s risk management. The dual track allows the project teams much more flexibility, as they are not constrained by production controls. For example, the path to production will not be blocked by project testing requirements or maintenance updates. Testing instances can be refreshed as often as the projects demand. More realistic quality gates can be enforced, and not circumvented by production priorities. For example, testing duration and its iterations can be driven by the needs of the projects, not by a production-imposed freeze period. The dual track strategy establishes a permanent set of instances with a consistent and permanent role, ensuring the SWCM teams know which tasks are performed when, and where. This is an advantage over the single track. A single track that handles large developments and maintenance usually requires the Basis team to intervene manually and establish temporary instances. This intervention introduces more risk, as these changes also change the SWCM processes, such as transport paths. The dual track becomes a permanent software factory, continuously releasing (cutover) new functionality to production, according to the release calendar. The retrofit functionality of SAP Solution Manager synchronizes dual track development instances. A dual track transport landscape can reduce risks to production from project development, e.g. if the solution is still in full roll-out mode, there are different organizations with different skills involved, a lot of invasive transports are expected, or there is high risk sensitivity in the company or for the particular solution.

Figure 8: The 6-system dual track transport landscape

The 6-system dual track transport landscape:

PRD (production instance)

There are two development and three quality assurance instances:

o PSD (production support development)

o PSQ (production support quality assurance)


19

o DEV (project development)

o QAS (project quality assurance)

o PRE (project quality assurance)

The SBX (sandbox) is temporary, and used to prototype new functionality, for sensitive updates, such as OS/DB upgrades, and for SAP maintenance. There is no transport path between the sandbox and the DEV system.

This instance strategy establishes a more secure production support track, that is shielded from major development activities in the project development track. The testing instance (PRE) is added to the project development track, to better stagger, test and manage multiple projects with different go live dates. The following figure illustrates this:

Figure 9: System Dual Track Transport Landscape - Staggering Releases

Multiple releases in parallel:

1. Green Release-1: According to the SWCM Release calendar, Release-1 is scheduled to move to PRE for final testing. At this stage, and as part of the project quality gates, sufficient testing cycles have been executed in QAS to correct all major defects of a project. Otherwise the project is withdrawn from the release, or the Executive Sponsor is engaged. Before transporting all projects, developments, configuration, etc. belonging to Release-1, you copy production PRE into the project development instance PRE. Release-1 can now enter its final regression, user acceptance and performance testing, before being cutover to production.

2. Pink Release-2: Has completed most of the development, and is in scenario testing in QAS, correcting defects DEV.

3. Grey Release-3: Primarily in DEV development phase, initial QAS testing for some developments.

4. Orange Release-4. Development teams are often constrained by project conflicts from a prior release. Customers often use the SBX so that development/configuration teams can be productive with initial proof of concepts, including coding designs. The SBX is not in the transport path, and there are no transports forward from SBX. There are other tools to capture work done there.

The 6-system dual track transport landscape, and the proper usage of SWCM processes, should manage most customers SWCM requirements, so we generally do not recommend another track, i.e. a third development environment (N+2).


20

The advantages and disadvantages of this landscape are summarized in the following table:

Figure 10: System Dual Track Transport Landscape - Advantages and Disadvantages

A dual track transport landscape needs processes for cutover and retrofit. These are described in the following sections. 3.2 Dual Track Cutover Process Cutover is the process in a dual track landscape to move the next release from the project development track to the production support track for go-live. Cutover updates the production track, limiting the impact to production and its supporting instances. Testing, for example, is not a function of the cutover process, as this would considerably increase the time it takes, and would block or complicate production emergency fix capability. Some considerations for cutover are: planned downtime requirements, how to manage production emergencies during cutover, and how long the entire process will take. Cutover requires all instances in the production track be updated from the project development track. If the maximum downtime window is insufficient to update all instances in one step, the cutover must be staggered. For most customers, SAP recommends the following staggered cutover strategy. The staggered cutover, as illustrated in Figure 0.5, is to cutover directly from the project landscape PRE into production PRD. In a second phase, production support PSD and PSQ are updated.

Figure 11: Cutover in a Dual Track Transport Landscape – Option-2

The advantage of this strategy is the cutover directly into PRD, which can be done in a period of least activity, such as a weekend or holiday. Once production has been updated, the supporting instances PSD


21

and PSQ can be updated in a second phase, which may extend into normal operations. The disadvantage of this strategy is that the cutover process requires some manual steps. Note: You should not switch tracks, as this will change instance roles, lose versioning history,and, depending on organizational elements mislead development and support teams. 3.3 Retrofit in a Dual Track Transport Landscape One of the key challenges with the dual track transport landscape is to synchronize (retrofit) changes between the two tracks. This is necessary, to ensure the two landscapes do not diverge. The need arises because changes made to production, to support normal business, must be incorporated into the project track.

Figure 12: Cutover in a Dual Track Transport Landscape – Option-2

This section provides an overview of how to use Solution Manager to support the retrofit process. 3.3.1 Semi-Automated Synchronization of Dual Landscape with Retrofit SAP Solution Manager supports the retrofit process in Change Request Management but also as a stand-alone function. Retrofit in SAP Solution Manager achieves significant improvements in synchronizing dual transport landscapes. The major advantages are:

Conflicts are detected automatically.

Most changes made in the production support landscape can be retrofitted automatically, without manual effort.

A complete work list of all transports to be synchronized (down to object level) is created, and all changes are logged.

The retrofit process with SAP Solution Manager includes the following functions:

Developments in either transport landscape are recorded in SAP Solution Manager, so changed objects are known centrally.

Conflicts between the production support and project development landscape are identified via cross system object lock (CSOL). A conflict occurs when the same object is changed in both transport landscapes.

When you use retrofit in conjunction with Change Request Management, the process offers synchronization methods to align changes from the production support landscape into the project landscape, depending on the type of conflict and type of object:

o All objects without conflict (i.e. changed only in PSD) are transferred automatically. A transport of copies is created and sent to the project development system.

o For objects with conflicts (changed in PSD and DEV), the synchronization is performed semi-automatically or manually.

A conflicting workbench object can be adjusted semi-automatically in a split-screen editor, using the SAP Correction Workbench. In rare cases, if the change was within the same area of context, the adjustment has to be made manually.


22

If customizing settings conflict, the version in the production support system is recorded in a BC Set. During import into the project development system, it is compared with the entry in that system, and can be adjusted accordingly.

o Objects that are not supported by tools in the SAP Correction Workbench must be adjusted manually.

o Retrofit is performed at object level: if one object in a transport request must be retrofitted manually, the other objects can still be transferred automatically.

If an object was changed several times, the changes are retrofitted in the correct sequence.

A retrofit of a change triggered from PSD into the project development system DEV, is considered in DEV like any other project-related development change, so the adjustment in system DEV is recorded in a new transport request. A separate CTS project as the container for all retrofit changes is usually the best option, but the retrofit changes could also be put into a CTS project with other project changes.

o Putting the retrofit change into the CTS project which is scheduled to go live next – together with other developments – has the following disadvantage: If multiple projects with different duration and Go-Live dates are developed in parallel in DEV, strong governance and release management is required. If the project without the retrofit changes goes live first, object versions might be downgraded.

o Putting the retrofit change into a CTS project in DEV which is dedicated to collect all retrofitted objects (with cutover together with any next project which will go live) has the advantage that the retrofitted objects are always cutover – independently of individual project delays.

All Retrofit activities are logged and can be reviewed at any time. 3.3.2 When, and how often, to retrofit As soon as a transport request is released from the production support system (PSD), an entry for the retrofit work list is created. When to retrofit:

The retrofit should be done as soon as possible after the transport request is released, to keep the work list manageable

o In a long development cycle in DEV, the number of objects to retrofit can be quite large. The time needed for retrofit increases correspondingly, and needs to be continuously.

Only tested changes should be retrofitted, to avoid multiple transports to retrofit. So the timing of the retrofit activity also depends on the testing strategy:

o Usually there is not sufficient test data in PSD, and changes are imported into PSQ to be tested. After the change is tested, it can be retrofited. If an error occurred in PSQ and a correction transport is needed, Change Request Management will ensure that the correct sequence of transports is preserved during retrofit.

o The retrofit activity can start immediately after the release of the transport in PSD, if the release of the transport means that the test was OK. (This can be the case if sufficient testing is done in PSD, or if the change is sent to PSQ by transport of copies, and tested in PSQ.).

The retrofit must be complete before cut-over from the project landscape into the production support landscape, for final release testing. Change Request Management will check if the retrofit work list has been processed, before cut-over can start.

When managing production support transports in releases, the best option is to retrofit after/with the weekly/bi-weekly minor release import from production support into production.


23

3.3.3 Prerequisites for Retrofit in SAP Solution Manager The retrofit process in SAP Solution Manager has the following prerequisites: 1. SAP Solution Manager 7.1.

Retrofit functionality already exists in SAP Solution Manager 7.0, but the processing logic is different, and the level of automation is lower than in 7.1. For new Change Request Management and retrofit implementations, use SAP Solution Manager 7.1

2. Change Request Management controls the transports in the production support system, and either Change Request Management or Quality Gate Management (QGM) is used in the project development landscape.

Change Request Management can be implemented in different variants. The tighter the integration is, the more information can be reused.

The minimum retrofit constellation is to use Change Request Management to create/release the transport requests, instead of doing this directly in the development systems. A change document , which automatically creates and releases the transport requests in the development systems, is then created and released in Change Request Management. This central transport management can usually be implemented within a few days, and is a viable option even if a non-SAP change request management or IT Service Management tool is used.

With SAP Solution Manager 7.1, QGM can also create CSOL entries, so a mix of Change Request Management in production support and QGM in project landscape is also aretrofit option.

3. Cross System Object Lock (CSOL) is active

CSOL avoids inconsistencies due wrong transport sequence, even in a single transport track.

With SAP Solution Manager 7.1, CSOL information is used to identify whether an object in the project landscape has been modified. This is used to calculate the status for Change Request Management retrofit. So if there is no CSOL entry, auto-import by Change Request Management retrofit is possible, and if there is a CSOL entry, the system performs some additional checks, for example, whether the retrofit can be processed using the split-screen editor.


24

4 LEAN CUSTOM CODE – AVOID, IMPROVE, MINIMIZE

Customer developments in SAP systems are an important and easy way of implementing highly customer-specific requirements, and closing perceived functional gaps in the SAP environment. However, they are also one of the key TCO drivers in any SAP solution, and one of the biggest blocking factors for the fast implementation of new SAP software versions, so an enhanced and efficient custom code management throughout the lifecycle, is essential to mitigate these issues while still taking advantage of the business benefits. SAP supports your custom code management aims by avoiding, improving and minimizing the custom code and individual enhancements in the SAP solutions run by your company. Following the lean principles, this aim will be accomplished by the phases of transparency & measurement, optimization and control. It provides numerous tailored tools and best practices for effective, holistic custom code management (CCM). They analyze your custom code and modifications and their use in your systems to get an overview of all customer developments. The customer developments that are actually used are identified and controlled better, using the functions provided by SAP Solution Manager. The objective is to improve the quality and technical implementation, while reducing the quantity and impact of custom code. Ways of avoiding modifications and moving closer to SAP are described. This helps you to achieve sustainable cost reductions for the operation and maintenance of your SAP system landscape. Leveraging the innovations to control the gaps and minimize modifications, ensures the value of IT, and increases business value. 4.1 Custom Code Management Summary Today's IT system landscapes are seldom homogeneous solutions. Gaps in the landscape between established software modules are closed ad-hoc, and standard business processes are enhanced as required. Your custom developments are an important element in your system landscape. Such developments are necessary when your standard software cannot map certain business processes as desired, and there is no specialized, ideally certified, solution on the market. A complex amalgamation of standard software, enhancements and custom code results in potential risks, driven by the need to respond quickly to changing business requirements. Program code is implemented quickly, with insufficient focus on sustainability and transparency. Important factors such as documentation, the impact of changes on core business processes, and maintainability, are not taken into account until planned or unplanned events change the overall system landscape and leave a multitude of questions regarding custom enhancements unanswered. Planned, recurring events such as minor and major software updates, or the introduction of new standard functions, can lead to increased testing requirements and significantly higher implementation costs for your custom developments. Unplanned events, such as new legal requirements, new technology or the need to adapt interfaces for external reasons, also frequently present unexpected challenges to custom enhancements. SAP proactively supports you in the targeted handling of all of these aspects. 4.1.1 The ‘green’ City Model – Lean Measurement In light of the known characteristics of custom enhancements and custom code (number, quality, type of implementation, extent of documentation, and so on), four primary dimensions that can be measured and evaluated have been identified. They are quantity, quality, impact on core business processes, and classification of the technical implementation in relation to the SAP standard. The model also considers management and software lifecycle. The visualization of custom enhancements and custom code with these metrics corresponds to the abstract representation of a city with buildings of various heights, colors and locations within it. Every city reflects an individual system within your system landscape.


25

Figure 13: Lean Measurement

Dimensions of the city model Staying with this metaphor, as the forward-looking mayor of your own city, comprised of multiple custom enhancements and custom code, you have a number of ways of beautifying or redeveloping it. To keep this “beautification of the city” from devolving into a costly and arbitrary process, in the following we will present the individual dimensions, tools and services with which SAP supports you in your pursuit of a well-run, cost-effective and forward-looking system landscape. Quantity In the quantity dimension, customer-specific objects are recorded according to their object characteristics, and categorized according to their technical implementation. Quality The quality of program code is an often neglected, but highly important, factor in the development of custom adjustments. In this dimension, SAP has made it possible to measure quality in a comparable way, to maintain quality standards. Criticality and impact on core business processes Your core business processes must be stable, ensure maximum availability and correctly map your functional requirements at all times. SAP supports you in the analysis of the most frequently used system processes, and shows you which of your frequently used core business processes are impacted by modifications or enhancements. You receive important information that is helpful for planning software updates or optimization. Technical implementation SAP NetWeaver provides a multitude of enhancement options that in some cases go far beyond classical Customizing, enabling you to enhance and adapt standard processes to meet your requirements. Beyond the ability to implement and define implicit and explicit extension points (BAdIs, user exits, enhancement spots), you can change SAP standard code through logged and unlogged modifications. Each of these system modifications has specific strengths and weaknesses, which should be evaluated, based on maintainability, risk and complexity. 4.1.2 Custom Code Management - Governance Process and Optimization Effective custom code management ensures the quality of custom code functionality and controls the growth of custom code during the implementation phase. The purpose is to review and analyze the setup of existing custom code management processes and to optimize custom code management according the latest SAP best practices. Before the development organization can design and realize Custom Code for its needs, functional gaps, or competitive advantages in how the customer conducts his business, it is important to establish, that these development activities follow certain rules or standards.


26

It is very important to validate that these standards already exists, otherwise you will need to create and enforce guidelines for the development organization, before any major custom development. The development standards should address at least the following aspects:

End-to-end process flow and procedure for the development of customer-specific coding: This process should be defined throughout your development organization. Some customers maintain offshore and onshore development models, whose regional specifics need to be included. Interfaces between regional teams, different departments which develop custom code, business departments (as the requestors), IT departments (as the operators and support organization for custom code) and other involved parties need to be described, and hand off/hand over procedures need to be established, documented, known and accepted. There must be a complete end to end process, from the request for custom code, followed by functional and technical validation and justification of the request, budgeting, specification, design and sign-off, development, tests, business user (functional) validation, technical validation (robustness, performance and maintainability (by operations support department)), deployment of the functionality, and, most importantly, technical and functional documentation.

The custom development standard must also define and describe the phases in the custom code lifecycle. Similarly to existing standard functionality, applications and systems, your custom functionality passes through different stages of the application management lifecycle. The standard must describe these phases and the related activities. It must be clear who owns which phase, from the request for custom code, through design and development, deployment, operations, maintenance and optimization; who is responsible for which type of action in each phase. Define KPIs, or a general set of criteria are to identify whether it is necessary to enter, e.g. the custom code optimization phase, or replace it by standard functionality (if applicable), and how to retire custom code.

It should be defined on a strategic and company-wide level, when and by whom custom code is permitted to be introduced. A list of principal requirements for the creation of custom code needs to be established, documented and communicated. This ensures that every time custom code is requested, the request is validated against the list of permissible requirements. For example, allow the creation of custom code only if the core SAP functionality is not modified, or insist that workaround processes be preferred to the creation of custom code (under certain conditions, such as economically acceptable effort, or the extent of the workaround). It should be stated in this section of the custom code development standard, which enhancements are allowed, which are not, which type of enhancements are preferred, and so on. That also means that important aspects of quality of custom code are defined and anchored in your development standards.

If your organization has to follow specific custom development procedures, these need to be documented in the standard. Your standard could demand a four eye principle or a technical validation/release by a second or third developer; manager approval could be defined here, or the principle of creation of competing programs (which approach is better will be considered further). Anything that defines your procedures and principles need to be documented or added the standard.

A major aspect and goal of developing or maintaining a standard for custom code development is the quality of custom code. While it is difficult or impossible to define quality in a standard, tools and technology which help to ensure quality, can and must be defined in the standard. The standard can include how requests are formulated and documented, and which tool is used to track and validate requests. For the development activities themselves, tools and technology needs to be mandated, to help ensure the quality of custom code.

As an example, the SAP development standard states that no report, program, or enhancement to existing code, can be deployed (shipped to customers), if the “SAP Code inspector”, a tool in the ABAP Development workbench, reports errors. SAP invests heavily in the maintenance and improvement of rules, which are checked by SAP quality tools (see chapter ‘improve custom code quality’). The basis for this is the SAP Standard for Custom Code Management and related standards. SAP also provides the ESRV MOS Custom Code Management (V1.1) roadmap in SAP Solution Manager, which gives a comprehensive description of all essential parts.

https://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000711194&_SCENARIO=01100035870000000202&


27

4.1.3 Custom Code Lifecycle Management - Transparency & Control For the management of custom code, SAP supplements tools such as the Custom Code Lifecycle Management (CCLM) and the Custom Development Management Cockpit (CDMC) in SAP Solution Manager. CCLM was developed to accompany your ABAP enhancements and new developments throughout their lifecycles. The cycle begins when you create an object (program, transaction, table, class, etc.), is followed by its use in production systems, and extends through the deletion of the object ii it is no longer used or the development is reorientated. This new application is in SAP Solution Manager 7.1. Its core is a flexible and generic library definition, with which you can classify and manage your custom code objects. Information about the use of these objects, their quality (Code Inspector, transaction SCI) and versions in the connected systems, can also be collected. The application that provides full transparency of your custom code and records its use in a complex landscape. 4.1.3.1 Get transparency about custom code The generic library is used by SAP as the central data source for all information on customer objects. You benefit particularly from the being able to assignment of responsibilities and contracts individually, consolidate developments within an organization, and have total control over new developments. You can assign any object or list of objects to a contract, or other predefined attributes. This application ensures that you can achieve the best possible adaptation of custom code to SAP code, and therefore receive the best possible support. You can also save costs in upgrades to higher SAP releases. The version in the SAP Solution Manager currently only applies to ABAP developments, because there are only extractors for them. Expansion to include Java objects is technically possible, and is already supported by the design. 4.1.3.2 Process and Architecture The first call of transaction CCLM uploads the library definition. You can change this definition to add your own input helps for predefined attributes or additional new attributes. You name the library and schedule the data collectors, in the configuration. A periodic process fills the library content. The uploaded definition of the library contains a schema indicating the attributes for objects of a particular cardinality, and can be filled manually or automatically. The periodically scheduled programs ensure that information is collected and written or overwritten in accordance with this active definition. Information which you enter manually is not overwritten, and is retained permanently. You must maintain the attributes for your objects that are not collected automatically, such as a lifecycle status or distribution rule, and particularly references to contracts and persons responsible, manually. Additional manual steps are possible in the analysis and reporting. If you have an SAP NetWeaver Business Warehouse (BW) with the respective content, Web templates are provided. You can also make your own reports. Reporting, and the retention of historical data for use in the BW, simplify the decision to delete or consolidate custom code. The BW is optional, and is not active in the default setting in transaction CCLM. The same applies to ad-hoc reporting, which at the time of delivery is considerably more powerful than BW reporting. The Solution Directory gets information about the solutions and their systems. The system landscape maintenance component (SMSY/LMDB) determines the product and product versions of the systems. The extractor framework extracts data to the BW system (usually SAP Solution Manager). The managed systems contain data collectors, to which the CDMC collector for the collection of customer objects, a collector for quality, and a collector for object versions, are connected. The use of objects – in particular in programs and transactions – is identified in the workload data from the analysis of the Workload Monitor (transaction ST03N), collected by the SAP EarlyWatch Alert, whose collection modules are scheduled with the SAP EarlyWatch Alert, using the Service Data Control Center (SDCCN) administration tool. The data is formatted, and transaction usage passed to a report. The ABAP Coverage Analyzer (transaction SCOV) documents the use of objects in the kernel. This application, also known as Usage Procedure Logging (UPL) as of basis version SAP NetWeaver 7.01 collects considerably more information about usage, in greater detail, and documents dynamic calls not listed in the workload.


28

4.2 Avoid Modifications and get closer to SAP Try not to create new modifications or custom code. Once built, it remains in your system forever. Unobserved custom code footprint leads to high maintenance and operation costs and also can lead to unforeseen risks at run time. This results in a high Custom Code Effect in your integrated solution. In the following we describe how SAP helps you save money and increase the value of IT for the business, and get more out of available functional capabilities. 4.2.1 Gap management by Innovation Control Center 4.2.1.1 How the Innovation Control Center works The Innovation Control Center facilitates the rapid prototyping of new solutions, business models and capabilities. All stakeholder meet regularly in the center, and make decisions about the planned solution. All perceived gaps, open issues and decision requirements are tracked, owners are defined, and the other stakeholder act as review and feedback partners. A central goal of the Innovation Control Center is modification-free implementation, dramatically reducing the cost of implementation. It is our experience that up to 90 % of gaps can be resolved with SAP standard functionality, provided latest SAP software versions are used. SAP development and SAP Active Global Support provide the knowledge and guidance to close such gaps. The Innovation Control Center follows a strict standard about tracking and documenting issues and gaps, and, most importantly, decisions. A KPI framework to measure business benefits is defined, to make the viability visible to all stakeholders. This KPI framework is implemented in parallel to the finalization of the prototype. Business Process Monitoring is a business change management driver. The feasibility is managed through orchestration and integration validation, in which all the solution, operations and product standards are validated. These include the management of data consistency, performance and scalability, end to end monitoring, exception management, and so forth. All of SAP is part of this value realization chain. Firstly, based on the desired outcome, SAP building blocks and best practices are identified and installed as the baseline. This is done by the SAP ICC team together with the SAP Development and SAP Solution Packaging organization. Then, as a team, right away, the solution is configured and customer-specific data loaded. Already then, the Design Thinking iteration process starts to understand what works, what does not work and what is missing. These iterations are again validated in the software solution, with customer data. All perceived gaps and all custom-specific integration is managed as in escalations. SAP development, together with the SAP AGS organization, provide all software-related services, in cooperation with customer and partner resources, to complete the desired, viable and feasible solution. 4.2.1.2 Blueprint Analyzer The Blueprint Analyzer visualizes the status of the deviation from SAP Standard during the implementation. While blueprinting, the Innovation Control Center (ICC) gathers and evaluates all identified gaps. A gap is mainly defined by the need for custom code. The ICC delivers the new Zero Modification service. It evaluates the gaps with SAP MCCs and its functional CoEs, and SAP Development. The evaluation of the gaps usually results in one of the following:

• Gap can be implemented in SAP standard; functional advice on configuration and implementation is provided by the ICC.

• Gap is a localization issue; gap is a bug and will be developed, implemented and deployed within the SAP best practice and model company.

• Gap is a gap in SAP standard and requires SAP development to close it. SAP development provides a solution for the customer’s implementation and go live. It will be retrofitted into the standard and generally deployed with the next EhP.


29

• Gap is a customer-specific requirement and must be developed by customer, their partner, or SAP custom development. The ICC will provide architectural advice on how to best implement the custom development.

Deviations from SAP standard also include customer-specific integration to non-SAP systems. For these customer-specific solutions, the integration design will be reviewed against SAP best practice. The interface design will be reviewed and designed for performance and data consistency.

Figure 14: Blueprint Analyzer and Gap Detail in project language and English

4.2.2 Monitoring and evaluating existing modifications The number of technical modifications in their SAP systems surprises many customers, and the attempt to explain the difference between the technical number of objects and the perceived number is often fruitless. With its modification browser (transaction SE95), SAP does offer a tool for developers, but it does not support targeted analysis or continuous monitoring of modifications. For this reason, there is the Custom Code Apps - Modification Overview, which enables table-based filtering, sorting and classification of modifications. The Modification Overview tool enables you to achieve comprehensive transparency of your modifications, and maintain an overview at all times. It also enables you to find out when a particular developer created what type of modification, and what application area it affects. You can focus your testing activities on the modified application areas, and know beforehand where side-effects may arise. You can use the tool to distinguish between manual activities from SAP Notes, and incorrect operation of the modification adjustment (SPAU) from true modifications. Only with full transparency of modifications can you improve the bad reputation of modifications and cost-intensive clones, through targeted modifications or, ideally, enhancements. Modification is a highly flexible means of adapting your SAP system, but it should always be used judiciously, with an eye to necessity and control. Customers who have already used the analysis function intensively have been impressed by the advantages. Not only were they able to reduce the number of modifications, they were also able to pro-actively limit the creation of new modifications by finding enhancement options instead. They were also able to prevent modifications from their old release from being transferred to their system during an upgrade. 4.2.3 Get Closer to SAP Besides avoiding new customer developments, you also have to eliminate existing custom code. After you have assessed the current situation and transferred to the city model with your key indicators, you can start optimizing individual dimensions or improving your system landscape as a whole.


30

Custom Code Management addresses the aspects of the city model that deal with current business and IT requirements and sustainable use of custom code, and helps you to prepare decisions. This process, with its three phases transparency, optimization and control, is a fixed element of the optimize phase of application management. It reflects the results of the other phases, in particular the early phases design, and build & test. The transparency phase allows you to use the Custom Code Lifecycle Management (CCML) application to make a structured start in the new SAP Solution Manager. The sub-points ensure that the definition is compatible with your requirements for a sustainable, generic and always up-to-date custom code library. The next phase utilizes the transparency and starts optimization. Here we look at the dimension Technical Implementation. This involves analyzing the nature and manner in which customer-specific business applications and enhancements are implemented. The objective is to move the individual implementations back toward the SAP standard. For example, a modification may be replaced by the use of a BAdI implementation. SAP supports this with the Custom Code Apps – Clone Finder tool. Product standards with key indicators such as the performance or maintainability of custom code and enhancements should be analyzed within their life phases, and ideally improved as early as possible. SAP supports this with the SAP Code Inspector tool. Experience shows that within a few years, one third of custom developments is no longer in use, or need to be adjusted. All custom code and enhancements have to be checked and adjusted manually before software update, such as an upgrade to a higher SAP release or the import of a support package. Then all objects have to be checked one-by-one to ensure that they do not cause problems in the new context. The Custom Development Management Cockpit (CDMC) has a project-based approach, and supports you in the first step of analyzing the custom code and enhancements in your system. It also helps you identify obsolete objects and, in a second step, helps you determine the effects of an upgrade or support package installation. Custom Code Lifecycle Management supports you with a long-term approach with current usage key figures. Any insights from the optimization area can be used to identify the optimization potential of other ALM phases and scenarios. Of particular interest here is, for example, raising the bar in the actual decision-making process for or against custom code, or adding an additional check step to ensure quality in the software development process. The final decisive area always reflects the success of the management or optimization. The data from Custom Code Lifecycle Management is extracted to the BW of SAP Solution Manager, and can be used to assess success. Control and checking can thus be performed at any time. 4.2.4 Replace clones In the world of custom code, there are two defining questions. How good is the quality of custom code and how did the customer programs come about? There is no general answer to these two questions, and any attempt to find a generally valid answer always leads to discussions. We therefore want to approach the problem pragmatically and, with the aid of tools, outline a comprehensive analysis of the problem. To this purpose, SAP offers the new Custom Code Analysis tool, which can help you resolve the fundamental issues regarding custom code. We divide the tool into different use cases. Let us begin with the simplest use scenario: identifying clones. 4.2.4.1 Distinguishing SAP Original Objects from Clones An amusing play on words describes the problem with clones quite simply, combining the words clone and own to create “clowns.” While the creation of a “clown” is a simple matter and appears to avoid the need to pursue an unwanted customer-specific modification, shortly thereafter it is creating havoc in the system. Perhaps unknown or seldom executed, the clown always carries the risk of not containing a required standard correction. Perhaps the clown is based on an obsolete software status or release, and is maintained in the customer namespace with each new upgrade. Only in rare cases is it possible to derive the SAP original object from its clone. That would require comprehensive project documentation. While this problem may sound trivial, the potential effects of undocumented clones are difficult to foresee. SAP now offers you an effective tool, the Custom Code Apps – Clone Finder, that finds the SAP original program for a clone. Potential similarities are not determined on the basis of names alone. Rather, notable places in the coding, such as typos in comment lines or patterns in contiguous program sections are used to determine unique system-wide fingerprints for each customer program to be analyzed. In a subsequent step, the logical SAP


31

environment of the customer program is determined, and the potential SAP program candidates output by a complex similarity algorithm. The advantage of this approach is the speed and reduced number of comparison operations theoretically required. The main distinguishing characteristic compared to other tools is the possibility of real similarity analysis. This tool even recognizes sections of code that have been copied and pasted. Using the Custom Code Apps – Clone Finder, in just a few steps, you can determine the name of the original SAP object and how it has been further developed through notes and corrections. It also enables you to identify your custom code which, through inheritance, has followed an evolutionary path of its own, and distinguish between versions. Even without a similarity analysis with SAP objects, the tool analyzes completely unknown user-developed code. You find out which logical application areas, and how many lines of code the program has, and how many versions of it are in circulation. The Custom Code Apps – Clone Finder offers you a fast and simple introduction to the area of custom code management, and helps you actively reduce clones. SAP focuses on the identification and evaluation of clones, and does not compare differences between the clone and the original. Our goal is to reduce clowns, not just make them more manageable. 4.2.4.2 Identifying the Usage Area of Clones To answer the question of where custom code is used, many developers use the familiar where-used list in the ABAP Workbench. This works well, as long as the search index is up-to-date, and a static programming model was used. Unfortunately, in new SAP applications in particular, dynamic use of program elements exceeds the limits of the static where-used list. This becomes clear very quickly when you talk about engines, frameworks or enhancement concepts. Customer developments and customer-specific implementations for such frameworks are generally dynamically integrated; but even customer developments themselves increasingly use modern programming models, such as ABAP-OO, rendering the classical where-used list obsolete. With its Custom Code Apps - Dynamic Interface Analysis tool, SAP has developed a means of closing this gap. From re-implemented classes and interfaces from the ABAP-OO world, to BAdI implementations or framework enhancements and the identification of classical customer exits, to classical user-exits, the tool covers all the bases. The usage of Smart Forms and SAP script programs can now also be checked. The most effective function, however, is the identification of custom code, the control of which is hidden somewhere in Customizing. This is where the tool begins, and it uses all the possibilities of SAP NetWeaver. No other tool is able to utilize this integration aspect so completely. Now you can delete custom code without the risk that it is still used dynamically somewhere else. This enables complete transparency and a basis for long-term code reduction. 4.2.4.3 Cross system custom code versioning Problems distinguishing the different versions of your programs usually only arise in a multi-system landscape in which the systems are distributed around the world, and are subject to different business requirements. The same business processes in different countries often require customer-specific adjustment. Often, the same objects are used, as the differences are frequently marginal. A central development system precludes the uncontrolled growth of customer developments, but can lead to a proliferation of program versions. Strict control of the transports and development policies help to contain the problem. The Cross-System Comparison tool analyzes customer developments across system boundaries and indicates which version of the program in the development system matches the actively used product version. This function enables you to identify where real differences exist and where transports are missing, or have yet to be imported. It is also possible to identify any code differences in the objects of one or more transports. You also receive information about the size and complexity of the objects. One special scenario focuses on the implementation of user exits. Multiple projects change the same user exit and transport it to the project landscapes for testing. Changes due to SAP corrections are usually not taken into account. Use cross-system comparison to monitor code adjustments and support a central code strategy in your company.


32

The top 20 analysis scenario maps out some ideas. Concentrate on your company’s business processes that are used every day. Using the workload statistics and freely definable parameters for the number of objects or the number of periods to be analyzed, the systems are either checked to ascertain which customer developments were cloned or display a marked similarity, or the used SAP programs are checked for the characteristic modified. This analyzes your most frequently used programs in detail, and provides a starting point for other supporting SAP Active Global Support services, such as the modification justification check. 4.2.4.4 Time for Improvement Various application scenarios have been described theoretically. Many more uses will certainly emerge from using the Custom Code Analysis tool daily. The tool has the transaction code CCAPPS or /SDF/CD_CCA. In addition to the predefined application scenarios, you can execute standard runs as background processes, and adapt the results to your requirements, using user-defined layouts. You can also use object lists to further restrict or enrich the results. For more information, and messages from other users, see our blog on the SAP Developer Network (SDN). 4.3 Improve custom code quality Poor quality of custom code often causes unforeseen failures of applications and core business processes. This interrupts business continuity and can be very expensive. Often, only functional quality is considered, but non-functional factors are no less important, and are often the difference between good and bad solutions Good code quality is mandatory for SAP standard program code, and is also essential for custom code or code delivered by 3

rd-party providers. Bugs and errors in your custom ABAP code can be expensive if they

impact critical business processes, which is why quality assurance of custom ABAP code is receiving more and more attention in business. 4.3.1 Custom Code Quality Improvement with SAP ABAP Test cockpit/Code inspector The Code Inspector and ABAP Test Cockpit are check tools for ABAP code and other repository objects. They control the quality of your ABAP code, for example program functional correctness, performance, security, or naming conventions. It can also check a single development object or large object sets, for example all objects in a group of development packages. The ABAP Test Cockpit is a latest ABAP check toolset which allows you to run static checks and unit tests for your ABAP programs. In order to ensure smooth migration and comparable check results throughout your company, the ABAP Test Cockpit is compatible with SAP's Code Inspector, so you can reuse your custom Code Inspector checks and variants in the ABAP Test Cockpit. Developers will like the ABAP Test Cockpit, because it is directly integrated into the ABAP workbench and has better usability. Working with ATC findings is very easy and efficient, using the new ABAP Test Cockpit filter, navigation, and re-check functionality. Team leads and quality engineers will like the ABAP Test Cockpit because it introduces new quality assurance processes like quality gates, a robust exemption approval process, and periodic regression tests in a quality system. ATC’s support for solid quality processes will minimize the errors in your productive system. The ATC also offers tools to analyze the ABAP Test Cockpits results on team or project level. The main benefits of ABAP Test Cockpit:

It is fully integrated into the ABAP development workbench, with high usability for developers and

quality experts.

It offers superior and easy-to-use built-in reporting capabilities, with filters and aggregated levels

It offers a robust process for managing exemptions (false/positive findings) based on the four eyes

principle.

It is fully integrated into the Solution Manager and the application custom code lifecycle

management.

Sustainable quality optimization of custom solutions is a key success factor of the whole custom code management process.


33

4.4 Minimize Modifications Experience shows that a lot of modifications and custom code are not used at all. Because of constant change of business requirements and objectives, a lot of custom developments become obsolete over time. It is very difficult to keep an overview of all these objects, that can become a major TCO driver. The main goal is to identify obsolete objects so that you can retire them. It can also be useful to identify objects with execution problems, for optimization in the technical severity and business criticality dimensions. 4.4.1 Usage and Procedure Logging It is a challenge for every SAP system owner to know what is really going on in their installed systems. What kind of code routines are executed, how often, and whether there is a relationship between the time of execution and the number of executions. Existing technologies to track and log runtime executions cause performance losses because they need resources. And the level of details might be different and will never fit to the requirements. What we are looking for is a technology without system performance impact, with high accuracy and the capability to track dynamically generated and executed code language elements at run time. SAP Usage & Procedure Logging (UPL) gives you all these capabilities directly in your existing SAP solution, without installation of additional software packages or difficult activation processes. Usage and Procedure Logging (UPL) is a new function available in any ABAP-based system, based on the core functionality of SAP Coverage Analyzer. It logs all called and executed ABAP units, such as programs and function modules, down to classes, methods and subroutines. You can also evaluate the usage of SAP Smart forms. This new, enhanced SAP NetWeaver capability will have no performance impact on your system, and will catch usage information of ABAP routines when they run. UPL will give you a 100% coverage of usage, without estimations or evaluation of ABAP call stacks. This includes the detection of dynamically called ABAP elements. UPL is the only technology to close the existing gaps in the SAP workload statistics. With the secured access to the UPL data, your usage information is protected against 3rd party access. The full reporting capabilities, with enriched information in BW of the Solution Manager, will give you the flexibility to analyze ABAP usage on demand. 4.4.2 Obsolescence of customer objects Many SAP customers modify or enhance their SAP standard software. For example, they may create company-specific reports or custom (externally or internally developed) add-ons. The result of this natural development is a multitude of customer objects and modified SAP standard objects in circulation. However, requirements change so quickly that many customer objects and changes to SAP standard objects quickly become obsolete. Experience shows that after just a few years, a third of custom code is either no longer in use or has been modified, and not only due to fast-changing requirements, but also because new versions of the SAP standard software contain objects that render custom code useless. This can lead to unnecessarily high maintenance costs, which in turn cause high operating costs. For customers, it can be difficult to keep up with the pace of modifications to the standard system, and produce custom code. Numerous changes and customer objects also raise the cost of upgrades and importing support packages. Before a system can be upgraded to a newer SAP version, or a support package can be imported, all custom code must be checked and manually adjusted. All objects then have to be checked one-by-one, to ensure that they do not cause problems in the new context. The Custom Development Management Cockpit (CDMC) can determine how custom code is used (based on the call statistics provided by the system) and which customer-specific developments are obsolete. The CDMD evaluates the effects of an upgrade or a Support Package installation on custom code. The business process documentation for custom code is also determined (maintenance using transaction SOLAR02). CDMC supports the project or release manager in evaluating risk, by analyzing objects from transport orders before importing them into the production system. You must ensure that planned changes are implemented in line with business requirements. CDMC simplifies upgrade projects by reducing the amount of obsolete custom code. Upgrades can be performed more quickly because you only have to modify your custom code if it is absolutely necessary. CDMC supports project planning by enabling early estimation of the costs of adjusting object types that are required for a more current version. You profit from better and more reliable planning and shorter project run times,


34

and thus reduced costs. Another advantage is that the objects in transport orders are analyzed before being imported into the target system. 4.4.3 Deleting objects with CDMC Using key figures and collected data, you can optimize the performance of a solution and reduce costs. Custom Development Management cockpit (CDMC) simplifies the deletion of obsolete custom code, based on the usage analysis performed as part of the requirements analysis and the build/test phase. The Custom Development Management Cockpit determines the scope of customer developments. CDMC comprises three phases:

1. Clearing Analysis (CA) analyzes the use of customer objects. Obsolete objects and the corresponding business process documentation of the customer objects are determined (in transaction SOLAR02). The result of the clearing analysis is the starting point for cleaning up the developments. Detailed instructions guide you through the clearing process.

2. Upgrade/Change Impact Analysis (UCIA) identifies the technical effects of an SAP upgrade, or the installation of a support package, on customer-developed objects, and makes it possible to produce an estimate of the time and effort required to adjust these objects. The function determines the custom code to be used after the upgrade, and the scope of the respective business process documentation.

3. The change and transport system (CTS ) analysis analyzes the use of objects in a transport request, the test scope and the test coverage. It determines whether the state of the objects in the transport request is identical throughout the transport system landscape.

The CDMC is in the SAP Solution Manager Custom Code Management work center. Clearing analysis project In the statistics system, statistical data, for example about transactions executed, is gathered and saved in CDMC database tables. All project-relevant analyses are performed in the analysis system. The control system includes the control center, where all activities are triggered and monitored. The systems are connected by Remote Function Call (RFC). Several pairs of statistics and analysis systems can be assigned to a control system. In a typical system landscape, the statistics system represents the production system, and the analysis system corresponds to the consolidation system. The platform for the control system is SAP Solution Manager. Clearing analysis phases The clearing analysis has five phases:

1. In the project settings phase, the system landscape is defined and the relevant SAP Notes are called. You can select the systems for the project landscape from the Solution Manager system landscape.

2. The activities in the data collection phase include collecting statistical data in the statistics system, and identifying the custom code and modified SAP objects in the analysis system. The statistical data collected is then imported from the statistics system into the central system. The scope of the customer-developed objects for the analysis can be selected from the list of development classes, Solution Manager projects and Solution Manager solutions.

3. In the analysis phase, duplicate domains in the customer namespace and empty database tables are determined; syntax is checked; the transport frequency, inactive objects and objects without references are determined; and top-down analysis is performed. These are the most important functions for determining the usage of customer-developed objects. The syntax check and all activities associated with empty databases are executed in the statistics system. You can control the execution by entering date and time information.

4. You can view the results in the display phase, which contains numerous options for displaying and filtering the data.


35

5. The clearing analysis project is completed with the clearing process, in which objects from the customer namespace (Z*, Y* and namespaces with customer-specific prefixes) are deleted, or changes to standard objects in the SAP namespace are undone. The clearing process is different in these two cases. Obsolete modifications to SAP objects are removed using SAP standard tools, while obsolete objects that are assigned to the customer namespace are physically deleted according to SAP clearing guidelines. To optimize the clearing process, the clearing tools you use should correspond to the SAP standard procedure for deleting objects (ABAP Workbench), so that when you delete a master object (for example an object of type PROG) all other dependent objects (for example text elements) are deleted automatically. This ensures that all relevant objects are really deleted. Otherwise, dependent objects would remain in the system even if they are no longer used, and then be found by later clearing projects. This process of deleting and restoring (accidentally deleted) obsolete objects is described in the clearing instructions.


36

5 ONLY ADJUST AND TEST WHAT MATTERS

5.1 Identify change impact on custom developments Adjustments to the existing custom developments are always required when new SAP software versions are installed. Even when the intention of the maintenance project is that everything works as before, customizing, coding, and interfaces have to be reviewed. With the introduction of enhancement packages this challenge has reduced compared to classical release upgrades, because most changes, such as UI, process or data model changes, are not immediately active for the users. Nevertheless, thousands of lines of SAP code could be changed within the system, for example in the SAP NetWeaver basis layer, or because of support package corrections. On the other hand, nobody wants to redo the whole implementation. How is this conflict resolved? The key is to set the right focus and to invest the development resources where it really matters. The first step to accomplishing this goal is to compile a list of all repository objects, customizing settings and business process steps that are affected by an upgrade or maintenance. SAP provides tools to automate this step. You usually analyze modifications with the SPDD (DDIC objects), SPAU (repository objects) or SPAU_ENH (impact to enhancements) tools. Additionally, for planning and preparation purposes, you can use tools such as the Modification Browser (SE95) and Custom Code App – Modification Analysis (see section 4.2.2). Developments in the customer namespace are not directly affected when implementing new SAP software versions. They are kept as they are. Nevertheless, custom development objects which work correctly in one release may not work in an upgraded version. There are a variety of reasons for this. Most important is the fact that custom code usually contains static or dynamic references to SAP objects. If they are changed, the impact has to be reviewed. In particular, if custom transactions of executable reports have been created as copies of SAP programs, these cloned objects present unique challenges after a software change (see section 4.2.4). To identify such critical changes to custom code objects, perform syntax checks using the ABAP Test Cockpit (ATC) or the Code Inspector (transaction SCI), for the most important and critical custom developments at least, as soon as an upgraded version of these programs exists, e.g. after a test upgrade. Additionally, the Custom Development Management Cockpit (CDMC) offers an upgrade impact analysis. It compiles a list of custom objects with a reference to an SAP object which will be changed by the upgrade., The custom objects in this list can be better classified by upgrade impact, and adjustments and testing can be better planned. 5.2 Reduce development scope to used objects

While the technical change impact analysis of custom developments does lead to a better understanding of the overall adjustment needs, it is often not sufficient to significantly reduce the effort. The lists can contain thousands of objects to be inspected in detail, still requiring a lot of unnecessary effort. You should combine this technical approach with a business-related view of the importance of the identified changes.

To keep this task manageable, you need good and complete documentation of the implemented processes and custom developments, as a reference. This documentation should be available in SAP Solution Manager, as described in section 2.6.

Based on this documentation, you can identify those business areas that require most attention, and perform a more detailed technical upgrade change impact analysis of custom developments in those areas. You need to know which of your developments are really used, and how often. Such a statistical analysis should be a regular task of your operations, to have a reliable usage history whenever you conduct your projects. One important information source is the workload and performance statistics provided by transaction ST03N. You can store the ST03N history in the source system for periods longer than the normal retention period. You can extract this information from your managed systems into the BI info cube in SAP Solution Manager. Run the Usage & Procedure Logging (see section 4.4) to track the usage of custom code objects on deeper modularization unit levels. You can use this information to focus your development scope on the objects actually used, which usually greatly reduces the development efforts for upgrade and update adjustments.


37

5.3 Reduced test effort through Test Scope Optimization BPCA provides functionality to analyze the impact of ABAP software changes on your business processes.

The BPCA change impact analysis can automatically determine the regression test scope by selecting tests

assigned to the business processes affected. The BPCA Test Scope Optimization (TSO) functionality - new

in SAP Solution Manager 7.1, you can optimize and reduce the required test scope and effort significantly,

by program-based optimization along the dimensions:

number of changed objects by business process

test effort of associated test cases

The resulting optimized test scope is presented graphically, with a proposed sequence of process steps to

be included in the test scope. The user can apply multiple switches to adjust and optimize the test scope

further, and save them as alternative optimization approaches. Optimized test plans can be generated

automatically for SAP Solution Manager, HP Quality Center or IBM Rational.

5.3.1 Preparing BPCA

BPCA requires a Business Blueprint in SAP Solution Manager, including process steps and assigned

executables, such as transaction codes, reports, etc. which could be SAP standard or custom developed. In

a nutshell, BPCA requires a list of transaction codes and reports for which the customer wants to perform an

impact analysis. There are various ways of setting up and maintaining the Business Blueprint in SAP

Solution Manager:

1. Activate business content (Business Process Repository – BPR) provided by SAP Business Suite

2. Upload existing business process structures

3. Integration with ARIS from Software AG

4. SAP service Reverse Business Process Documentation (RBPD)

5. SAP Solution Manager – Solution Documentation Assistant

6. SAP Solution Manager – EhP Scope and Effort Analyzer1: create an SAP module-based blueprint,

based on customer usage information.

The BPCA analysis requires traces of all business processes which are in the scope of the change impact

analysis. The process trace is called Technical Bill of Material (TBOM). It includes all ABAP objects used

during execution (SAP standard objects and custom objects) and is assigned to the process steps of your

Business Blueprint, in SAP Solution Manager. TBOMs can be created in the following ways (see figure 1).

For approaches 1-4, trace recording is turned on before the business process is executed.

1 Planned for future releases of SAP Solution Manager


38

TBOM creation approach Details

1) Manual - by business analyst Execution of business process by business analyst, in

transaction SOLAR01 in SAP Solution Manager.

2) Manual - by business department Process steps without TBOMs are identified by quality

manager. Workflow is sent to business department.

Business user performs process step as part of normal

routine work while BPCA trace is performed in the

background.

3) Manual - by tester Testers performing manual tests in SAP Solution Manager

can turn on TBOM recording.

4) Automated tests TBOM recording during execution of automated tests using

the following test automation tools:

Test Option 1: eCATT, Component-Based Test

Automation (CBTA)2, Standard Regression Tests

(START)3, HP QTP, WorkSoft Certify, Tricentis Tosca.

Test Option 2: SAP TAO

5) Background job – static TBOM Programmatic approach performing a static code analysis

of SAP transactions included in the customer Business

Blueprint. This approach is not recommended because it is

imprecise.

6) Background job – semi-dynamic

TBOM4

Programmatic approach performing semi-dynamic code

analysis including run-time statistics of SAP repository

objects used by production systems. See section

“Roadmap” for more details.

Figure 1: BPCA TBOM creation

5.3.2 Standard Change Impact Analysis using BPCA

For a change event such as transport requests or SAP support packages, BPCA first compiles a list of all

changed SAP objects. It then identifies all impacted business processes and processes steps of the

Business Blueprint, from the process traces (TBOM) assigned to executables of the business process/step.

Figure 2 shows a BPCA change impact analysis with business processes and process steps affected. This

approach is called “standard change impact analysis”, or bottom-up approach, since every process step is

checked for potential impact by the change event.

2 CBTA available with SAP Solution Manager 7.1 SP07

3 START available with SAP Solution Manager 7.1 SP09

4 Semi-dynamic TBOM creation available with SAP Solution Manager 7.1 SP09


39

Figure 2: BPCA result – list of affected process steps

An alternative view shows the Business Blueprint Hierarchy with impacted process steps Figure 3 shows the

change impact of an EhP deployment for business process Financials – Accounts Receivables, in which 12

of 14 process steps are impacted.


40

Figure 3: BPCA result - Business Blueprint with impacted process steps

BPCA provides additional graphical and tabular views for change managers who would like to investigate the

root cause of the impacts in more detail. The graphical overview is shown in figure 4, with impacted SAP

repository objects classified by type, such as program/code object, DDIC object, user interface or table

content, and a breakdown by SAP software components.


41

Figure 4: BPCA result – graphical view

The table shown in figure 5 provides a lot of detail along the following dimensions, with absolute values and

percentages

Table rows: changed objects by SAP system, e.g. SAP ERP, software component and software

package.

Table columns: Program/Code Objects, User Interfaces, Table Content, DDIC Objects,

Transactions, etc.

Table cells: each cell contains the absolute number of objects impacted, by system/software

component and object type. Relative numbers of changed objects are shown as percentages. Each

table cell includes a link to a detail section below, which lists all objects with more technical

information.

This feature helps your team to become familiar with BPCA, and better understand the impacted software

objects –whether they are SAP standard or custom code objects.

Figure 5: BPCA result – tabular view


42

Change impact can be analyzed by BPCA for the following types of change events:

Impact Analysis Type Software change event description

Transport Requests

Transports between SAP systems, including ABAP objects such as

programs/code objects, user interfaces, Data Dictionary objects,

and customizing objects such as entries from configuration tables.

SAP standard objects as well as custom code objects in Transport

Requests can be analyzed by BPCA.

Support Packages/Support

Package Stacks (SP)

SAP Support Packages or Support Package Stacks deployed in an

SAP development or test system.

Enhancement Packages (EhP) SAP Enhancement Packages deployed in an SAP development or

test system.

Planned Business Function

Activation

SAP innovations, called “Business Functions”, become available

after deployment of an EhP, and can be switched on separately.

Customers can use BPCA to analyze which business processes

are impacted by Business Functions before switching them on.

Object List

Project Management Offices (PMO) often have to take project sign-

off decisions for development projects without sufficient information.

BPCA supports the decision making process, in which architects

can provide information about the most important ABAP objects

(function modules, tables, …) which are to be changed. BPCA

calculates which business processes will be affected by these

developments, and enables the PMO to assess the risk.

Change Transaction

Customers managing software changes withSAP Solution Manager

Change Request Management, can perform BPCA change impact

analysis for change transactions. All objects in the change

transaction are compared against the objects used by executables

of the Business Blueprint, to identify impacted business processes,

and optionally generate a test plan.

Figure 6: SAP software change events supported by BPCA

SP and EhP deployments include a large number of changed objects, so large parts of the Business

Blueprint are impacted. Use the BPCA Test Scope Optimization feature to further reduce the test scope,

based on risk.

BPCA can generate a regression test plan for impacted business processes, automatically. Figure 7 shows

test management applications integrated with BPCA


43

Test Management application Required products/capabilities

SAP Solution Manager

SAP Solution Manager 7.0 EhP1 or 7.1

SAP Quality Center by HP

SAP Solution Manager Release 7.1 SP05

SAP Solution Manager Adapter for SAP Quality

Center by HP

HP Enterprise Integration (EI) 2.7

IBM Rational SAP Solution Manager Release 7.1 SP05

SAP Solution Manager Connector for IBM

Rational

IBM Rational Connector for SAP 4.0

Figure 7: Test Management applications integrated with BPCA

5.3.3 BPCA Test Scope Optimization for large SAP change events

When performing a BPCA change impact analysis for only a few thousand change objects, like configuration

changes or custom code developments, the standard BPCA bottom-up analysis provides a precise analysis

and a resulting test scope with manageable effort. It is different when analyzing change impacts of large SAP

change events, like SAP Support Package Stacks (SP) and Enhancement Packages (EhP), since these

change events can include more than a hundred thousand changed objects. In these cases, BPCA provides

exact results, but because so many objects are changed, it is likely that almost all of your business

processes will be impacted, resulting in a high regression test effort which will require almost all test cases to

be executed. The result is precise, but the resulting regression test scope may have unacceptable time and

cost.

BPCA of SAP Solution Manager 7.1 addresses this problem with the new Test Scope Optimization (TSO)

functionality. This risk-based test scope identification allows you to balance between acceptable test effort

and increasing risk, when reducing the test scope.

Figure 8: BPCA Test Scope Optimization

BPCA TSO assumes that a changed technical object should be tested at least once, but not necessarily in

all process steps that use it.

A Sebastian Gaisbauer

B Sebastian Gaisbauer

C Sebastian Gaisbauer

D Sebastian Gaisbauer

E Sebastian Gaisbauer


44

Instead of collecting all impacted business processes and associated test cases (bottom-up approach), the

BPCA Test Scope Optimization determines those business processes and process steps that are impacted

by a lot of changed ABAP objects in the change event, and that do not require high test effort compared to

other impacted process steps.

Using this boundary condition, BPCA optimizes along 2 dimensions in parallel:

1. Number of changed ABAP objects per process step. BPCA TSO calculates business processes/

steps impacted, with the greatest number of changed objects.

2. Test effort per process step. BPCA TSO calculates business processes/steps with assigned test

cases which lead to the lowest possible test execution effort.

The TSO result is a ranking of impacted business processes/steps as shown in Figure 8:

The blue curve shows the TSO ranking, i.e. TSO result for process step (x axis), test coverage (left

y axis) and test effort (right y axis)

Point A: the very left section of the x-axis shows business processes or process steps that have the

best ratio of changed objects (high) to test effort (low). The test efficiency of the first process on the

left side is 30%, i.e. the test cases assigned to the first process can already test 30% of all changed

objects that impact the Business Blueprint. This is a very good percentage for one business process.

The ranking of process steps from left to right shows the cumulative decreasing test efficiency of

each process step, i.e. the processes on the left can test more changed objects than those on the

right.

Point B: The left y axis shows the test coverage from 0 – 100%. When the blue curve reaches

100%, all changed objects of the change event that impact your business processes have been

covered at least once by test cases in the test plan (see green shaded area of the graphic)

Point C: on the very right side, the ranking includes all impacted process steps. If you include all

processes up to this point, you will test changed objects several times, which is a full scope

regression test for all impacted process steps, i.e. the result of the standard BPCA bottom-up

analysis.

Point D: reducing the test scope below 100%, for example to 99% (or 95%), will leave 1% (or 5%) of

changed objects untested, but the test effort drops significantly. This effect is called long tail: the

blue ranking curve already reaches the saturation area, i.e. the test efficiency of the process steps

on the right side is much lower. For each additional process step added to the test scope, only a

small number of changed objects are added to the test scope.

The vertical bars in the graphic show the cumulative test effort. They show test effort for automated

tests in green (almost invisible, since the effort is small) and for manual tests in orange. You can

assign expected execution times to each test case, or use average values with default settings in the

Test Management work center.


45

BPCA Test Scope Optimization has a set of levers (see Point E) which you can use to influence the TSO

result:

Lever Effect on Test Scope

Test Coverage (%) Starting point is 100%. Reducing to values below 100%

exploits the long tail effect, significantly reducing the

total test effort

Manual Test Effort (hours or days) You can increase or decrease the effort required for

manual tests. If you keep the test coverage constant

(lever 1), a lesser effort for manual tests will pick more

processes with automated tests, to produce the same

test coverage.

Automated Test Effort (hours or days) Opposite effect to lever 2: increasing the effort for

automated tests at constant test coverage, will decrease

the number of processes using manual tests.

Total Test Effort (hours or days) You can specify the amount of time to spend on

regression testing. TSO will identify the most efficient

tests assigned to processes for the specified test effort.

Figure 9: Levers for BPCA Test Scope Optimization

With SAP Solution Manager 7.1 SP05, you can save the TSO settings as Optimization Approach, locally

(for your user) or globally, so that all users can use these settings. Additional levers have also been

introduced with SP05, to further reduce test effort based on smart lever settings – see figure 10.

Figure 10: BPCA Test Scope Optimization - additional TSO levers and settings with SAP Solution Manager

7.1 SP05

When reducing the test coverage from 100% (all changed objects tested at least once) to a lower value such

as 99% (see point D), you run a higher risk that the untested changes might cause problems in your

production systems. You can mitigate this risk by automatic determination of mission-critical business

processes/steps, which are forced into the test scope. This can be achieved by assigning a custom attribute

like “process priority”, with value 1, to all mission-critical business processes/steps in your Business

Blueprint. A setting in the TSO Optimization Approach then forces all mission-critical business

processes/steps that are impacted, into the test scope. These processes are shown in the BPCA TSO

graphic at the very left (“must include area” - see point F in figure 11) up to the vertical line. From SAP-


46

internal testing and customer feedback, the combination of deselecting process steps with a low test

efficiency using 99% test coverage, combined with risk mitigation by forcing impacted mission-critical

processes into the test scope, has led to acceptable test effort and risk levels.

Figure 11: BPCA Test Scope Optimization with test coverage of 99% plus risk mitigation

5.3.4 Quantitative Example

The following quantitative example illustrates the test effort reduction that can be achieved with BPCA Test

Scope Optimization (TSO). The number of business processes and assigned test cases is small, and just for

illustration purposes. Applying a factor of 10 – 20 would indicate typical SAP customer situations.

Business Blueprint

The business blueprint includes

3 business scenarios for Financials, Logistics and Human Resources, containing

8 end to end business processes and

46 process steps in total, with multiple transaction codes per process step.

Test Cases

In total 73 test cases - manual and automated - are assigned at process step and business process level,

as shown in figure 12. Automated end to end tests have been assigned to business processes whose

transactions can not be tested individually because precursor transactions are needed to create business

documents for processing by successor transactions in the E2E business process. This is the case for

business processes like Order-to-Cash and Procure-to-Pay, in this example.

Business Scenario Business Process Process Step

Financials 23 manual test

Logistics 3 end to end tests (automated) 35 manual tests + 3 automated tests

Human Resources 1 end to end test (automated) 8 manual tests

Figure 12: manual and automated tests assigned to process steps and business processes

The test execution effort of all assigned test cases is a total of 132 hours. Instead of assigning specific test

execution efforts to each test case, SAP Solution Manager allows the definition of average efforts by test

D Sebastian Gaisbauer

F Sebastian Gaisbauer


47

case type. In the example, the following average test efforts have been defined, assuming that only human

interaction time is considered:

Manual tests: 2 hours – access and read manual test script, launch and execute process step,

document result, status setting and potential incident creation

Automated tests: 15 minutes –for status analysis by test coordinator after automated test execution.

Change event

Enhancement Package 4 for SAP ERP 6.0 was deployed in the SAP test system, with approximately

180.000 changed objects for software component SAP APPL.

BPCA standard change impact analysis

A standard BPCA bottom-up change impact analysis for the EhP deployment identifies almost all process

steps and business processes as impacted, so only 6% test effort reduction can be achieved compared to

the effort to test all included test cases.

BPCA TSO 1

For large change events, SAP recommends BPCA Test Scope Optimization. BPCA default test scope

optimization without any further user interaction, ranks business processes and process steps, resulting in a

test scope with 58 tests and test effort reduced to 104 hours, a gain of 21% (BPCA TSO 1 in figure 13).

BPCA TSO 2

From this starting point, further reductions can be achieved by applying TSO settings, as described in figure

10

1. test scope optimization with priority for process steps with automated tests

2. test scope optimization using only automated tests of affected process steps with manual and

automated tests

The first TSO setting influences the rank of a process step. Process steps with automated tests will be

shown in the TSO graphic towards the left, -indicating higher test efficiency. The second TSO setting

addresses the fact that most companies add test cases to a process step, but rarely remove manual tests

when automated tests are added. With this setting, only automated tests are used for a process step with

both manual and automated tests.

BPCA test scope optimization with preference for automated tests, and 100% test coverage, reduces the test

scope for the given example further, to 44 tests, and the test effort to 76 hours, a 42% gain compared to the

entire test scope (BPCA TSO 1 in figure 13).

Test Scope No. of tests Test effort Gain

Test Scope without optimization 73 tests 132 hours n.a.

BPCA TSO 1: default, 100% test coverage 58 tests 104 hours 21%

BPCA TSO 2: preference for automated tests, 100% test

coverage

44 tests 76 hours 42%

BPCA TSO 3: preference for automated tests, 99% test

coverage, priority 1 processes and steps in scope

32 tests 52 hours 61%

Figure 13: Results from BPCA Test Scope Optimization (TSO)


48

BPCA TSO 3

The 3rd optimization described in the quantitative example deals with the long tail effect, where the test

efficiency decreases rapidly (see area between points B and D in figure 8). To remove processes with low

test efficiency, the test coverage is set to 99%, i.e. 1% of all changed objects with impact on existing

business processes, are not tested. This significantly reduces test effort by slightly increasing risk. To

mitigate risk, define a custom attribute “Business Process Priority”, and assign the value 1 to it for all

mission-critical processes. In the settings of the BPCA TSO Optimization Approach, you can specify that all

mission critical processes are forced into the test scope, and no optimization be applied to those priority 1

processes. This measure mitigates the risk of excluding a small percentage of changed objects untested.

Combining the settings for test scope optimization produces a good compromise between test effort and risk

level. The resulting TSO ranking list is shown in figure 11. The optimized test scope includes 32 test cases,

with a test execution effort of 52 hours, a 61% gain compared to the complete test scope without

optimization (BPCA TSO 3 in figure 13).

5.3.5 Value Proposition

BPCA Test Scope Optimization provides the following advantage for companies planning to deploy software changes regularly:

1. Identification of impacted business processes and process steps, allowing test teams to limit need for business analysts for identified areas

2. Significantly reduced test effort when using BPCA Test Scope Optimization, saving cost and time, and allowing the focus of the project team to shift to other important tasks

3. Detect impacted business processes with no, or only manual, tests, where automated tests could improve the overall test efficiency

5.4 Increase Test Efficiency by Test Automation Tight timelines of the test phase after a significant software change usually do not allow all core business processes to be tested manually. Based on customer interviews, there are a lot of other reasons to not run regression test using manual tests entirely. The following chart presents these reasons:

Test coverage within tight timelines

Lack of time to execute regression tests may potentially compromise performance & reliability

Overcompensating scope of testing may result in more testing than really required, and project delays

Defects in production Systems

Insufficient test coverage means more defects are not found before cut-

over of changes from test to production landscape

Testing accuracy due to not being able to test all variants

Costs High costs for manual testers in recurring regression tests

High costs to fix errors in production landscape

Finding errors late in the development process could delay delivery

Complexity Complexity increases with the number of business processes and

modules

Manual testing cannot keep pace with expansion of applications

Chart 1: Disadvantages of manual testing compared to test automation Regression testing after software changes is to find defects and unwanted business process behavior. The correction of defects results in customizing and/or development adjustments in the DEV environment, which in turn require re-testing in the TST environment. These iterative activities can best be supported by


49

automated functional regression tests, which free up a significant amount of time for the QA team and the individuals usually involved in manual test execution. SAP and 3

rd party test tool vendors have advanced their test automation tools in the last few years to the

extent that customers now can get the functionality and maturity that they need to setup regression tests by test automation. Most test tools allow semi-automatic creation of test scripts that can handle complex business transactions, without requiring detailed technical expertise. As a result, business process experts and outsource providers can largely handle the creation and maintenance of automated tests. SAP has also made a significant effort to improve the test automation infrastructure, especially the handling of system under test (SUT) information, and test data provisioning, to make the overall process more reliable and efficient. Identify the core/mission-critical business processes and develop automated tests for them.

5.4.1 Test Option 1

With SAP Solution Manager 7.1, customers can integrate SAP and 3rd

party test automation tools, in the Test Automation Framework. Test management with SAP Solution Manager also provides a rich and mature infrastructure to define automatic tests of business processes, manage systems under test used for test creation and execution, and test data provision for automated tests.

Chart 2: Test Option 1 with SAP Solution Manager 7.1 – Test Automation Framework In the Test Automation Framework, customers can easily set up test configurations, which consist of 3 essential parts:

Test Script – definition of test scripts based on SAP test automation applications (CBTA, eCATT) or

3rd

party test automation applications like HP Quick Test Professional, Worksoft Certify or Tricentis

Tosca, with certified integration with SAP Solution Manager 7.1.

Test Data Container – environment to plan or upload test data consumed by test configurations

System Data Container – system landscape information controlled by user, to switch between

landscapes to be tested, e.g. DEV, TST or Pre-PRD

Test Configurations are assigned to process steps or business processes of the Business Process Hierarchy, and can be selected for a test plan, to allow mass execution.


50

Chart 3: Automated regression tests assigned to the business process hierarchy Customers with SAP Enterprise Support can use the SAP component-based test automation

application, CBTA, which provides a better total-cost-of-ownership (TCO). For UI technologies not

supported by CBTA, like process steps using non-SAP applications, companies can use partner test

tools from HP, Worksoft or Tricentis. Customers with SAP Enterprise Support can obtain 2 seats of

HP QTP without additional costs (for details see https:/service.sap.com/testing). Functionality provided by the Test Automation Framework of SAP Solution Manager 7.1 includes:

Test design Seamless creation and assignment of 3rd party test automation scripts to process steps

Central planning of test data and assignment to parameters of the test scripts

Central compilation of “systems under test” (SUT) – no individual setup in each test script

Test execution Standard Test Workbench functionality to set up test plans, test packages and to execute tests and capture test results

New scheduling functionality to allow unattended test execution mode, at any time and at local or remote locations

Test result analysis Standard status and progress reports provided by the Test Workbench and BI

Gap reports to discover business processes without tests, outdated test plans, coverage of new tests in test plans

Accelerated repair Tester can create a repair request for damaged test cases, which is sent to the test engineer responsible, automatically, and includes all necessary context information

Test engineers work in an environment in which all context information about the damaged test cases is available. From here, all functions to run, analyze, maintain and repair damaged test cases are available.

Chart 4: SAP Solution Manager 7.1Test Automation Framework functionality


51

SAP Customers like Colgate-Palmolive/US have observed the following benefits of test automation:

Chart 5: Benefits of Test Automation, described by Colgate-Palmolive

5.4.2 Test Data handling in SAP Test Option 1

Customers using test option 1 (SAP Solution Manager and integrated 3rd

party test automation tools) should plan and provide test data in the Test Data Container (TDC), provided by SAP Solution Manager 7.1, with the following functionality:

User can define the test data structure for a set of single fields and structures, with reference to SAP

Data Dictionary

Manual planning of test data and MS Excel file uploads

Test Data Assignment wizard to map test data in TDC onto parameters of the test script

Step 1: Set Up Test Data Container The test engineer defines the data structure of the test data container. TDCs can be defined for single business transactions or end to end business processes like Order-to-Cash. Subsequently, the business analyst can provide test data in the test data container, or upload test data in MS Excel files.

Chart 6: Test Data Container


52

Step 2: create Test Script At design time, the user creates a test configuration in SAP Solution Manager. After providing header and “System under Test” information, a test automation tool is launched, to create a test script. Replace fields that require data input, with test automation tool parameters. These parameter definitions are sent back from the test automation tool to the test configuration in SAP Solution Manager.

Chart 7: Parameter mapping from 3

rd party test automation tool to SAP Solution Manager test configuration,

and assignment of test data from test data container Step 3: Test data assignment to test configuration A Test Data Assignment wizard helps the user to find suitable test data containers, selecting test data variants stored in the TDC and to assign it to the test configuration. More complex situations can also be handled, since the user can assign data from multiple TDCs containing different types of data.

Chart 8: Test Configuration with linked test data from Test Data Container


53

Chart 9: Test Data handling via Test Automation Framework during test execution A standard SAP interface links 3

rd-party test automation tools with SAP Solution Manager, allowing the

provision of test data from test data container to the test script, at runtime. The following test automation tools can use this approach:

SAP eCATT

SAP Component-based Test Automation (CBTA)

HP Quick Test Professional (QTP)

Worksoft Certify

Tricentis Tosca

During test execution, the test configuration reads the test data from the TDC and transfers it to the test script of the test automation tool for execution. Each test data record from the TDC will trigger a test execution.

5.4.3 Test Option 2

Customers using SAP Quality Center by HP to manage the test process, can use HP QTP to automate tests of heterogeneous business processes, including SAP and non-SAP applications.


54

Chart 10: Test Option 2 with SAP TAO and SAP Solution Manager 7.1 To accelerate the creation of automated test cases, and to lower the maintenance effort of automated tests, deploy SAP Test Acceleration and Optimization (SAP TAO) in conjunction with QC and QTP, to build automated regression tests.

Chart 11: Accelerated creation of automated business process tests with SAP TAO Approach and advantages of SAP TAO

Business Analysts can build automated tests by normal execution of business processes – no

special technical expertise is needed

SAP TAO automatically creates all important test assets in the background

o Test components representing sub-screens of the automated business processes, with

automatically assigned parameters for all fields

o Complete composition of test script, based on SAP TAO test components

o Test data entered by the business analysts is captured in specially tailored MS Excel

worksheets and is used for later test execution

o Validation steps are included automatically in the test script, and can be added by a test

engineer, according to customer needs.


55

Uploading to QC allows customers to use the test management environment of Quality Center to

build test plans and test sets, based on standard QTP scripts and SAP TAO test scripts.

Maintenance of damaged automated test cases is accelerated by SAP TAO by integration with

Business Process Change Analyzer, which identifies damaged test components which can then be

repaired rapidly by SAP TAO

Chart 12: Accelerated repair of damaged test cases with SAP TAO SAP Customers like Baker Hughes/US have realized the following benefits by using SAP TAO in combination with SAP Quality Center by HP and QTP

Cost savings by discovering defects earlier in the lifecycle

40% less testing effort by automating regression testing

Reduced User Acceptance Testing to 3 weeks

Estimated 20% savings due to reuse of existing test cases for future releases

Estimated 25-30% savings in maintenance due to use of SAP TAO

Delivery of high quality complex application release with minimal production issues

Tracking all testing activities using a central test management tool

Source: SAPPHIRE 2009


56

5.4.4 Test data handling in Test Option 2

For customers using test option 2 (SAP Solution Manager, SAP TAO and SAP Quality Center by HP), SAP provides the following advanced capabilities to handle test data in automated scripts:

The user creates a new test script via SAP TAO by executing a business transaction and entering

data for all input fields

SAP TAO creates all necessary test assets in the background, including

o test script

o test components which represent screens/subscreens and parameters for all fields

o MS Excel file with input parameters as column header and 1 data row which contains the

test data from the initial process execution.

The file with the test data can be placed on a central group server, to allow test execution by multiple

users

Users can enter additional test data directly in the MS Excel file, as additional rows. At runtime,

Quality Center will execute the test script as many times as there are test data rows in the data file.

The automatic creation of parameters for input fields allows users to build sophisticated test scripts quickly, and assign test data conveniently, since the MS Excel file already contains the required data structure. Step 1 A user executes the business transaction. SAP TAO creates test components with parameters for all input fields, a test script using test components in the right order, a file with test data, and connects the script parameters with the columns of the test data file.

Chart 13: Creation of test script and test data file with SAP TAO Step 2 A business analyst, SME or test engineer can enter additional test data in the data file. Customers should identify business documents in the production system that reflect standard variations. The data from these business documents can be entered as test data in the test data files.


57

Chart 14: User enters additional test data records in SAP TAO-generated test data file Step 3 Quality Center executes the SAP TAO script and accesses the test data file via the link in the test script. Test data from the file will be retrieved and entered into the input parameter at runtime. The test is executed separately for each test data record.

Chart 15: Test execution with multiple iterations triggered by test data file


58

5.5 Outlook: EhP Scope and Effort Estimator

Customers planning to deploy SAP Support Package Stacks or Enhancement Packages (EhP) would like to know in advance the involved cost and effort for code adjustments and regression testing. In addition, they would like to know impacted business processes to derive the associated development teams and business analysts (see figure 1).

Figure 1: Customers’ perceived challenges for EhP deployment projects

SAP customers have requested an application that provides project scope and effort estimates and satisfies the following requirements:

1. Transparency about change impact of EHP deployments before physical installation 2. Reliable effort estimation for major development adjustments and test activities 3. Tailored impact analysis for custom code and modifications 4. Test scope optimization with significant reduced test scope and test effort 5. Test plan for impacted business processes including custom code and modifications 6. Simple guided tool based procedure without significant preparation effort

SAP has committed to provide a new application EhP Scope and Effort Analyzer as part of SAP Solution Manager 7.1 with planned availability in first half of 2014. Scope and effort of planned SP or EhP deployments can be analyzed without the need to physically install them anywhere in the customer system landscape. A guided activity helps the user to enter the necessary information like current and planned EhP level. The application performs all necessary calculations in the background and subsequently provides the results in a graphical summary for the project team as well as detailed analysis views for involved experts like development and test managers (figure 2). All prerequisites that required manual activities in the past have been automated including

Optional automatic generation of a SAP Module oriented blueprint including executables like

transaction codes and reports used in production systems

Automatic generation of BPCA technical bill of material (TBOM) for all involved executables

Identification of used and unused custom code objects

Automatic test scope calculation plus risk-based approach for optimized test scope


59

Figure 2: SAP Solution Manager – EhP Scope and Effort Analyzer The results of the analysis are presented in graphical and list views to the project team which can discuss the impacted areas during project meetings. Results are presented in aggregated views including the following information

Custom Developments and Modifications – number of impacted objects and estimated adjustment

effort (figure 3)

Impacted business scenarios, business processes, process steps (figure 4)

Total testing effort and risk-based test scope optimization (figure 4)

Recommendation about creation of missing test cases and resulting effort

Figure 3: SAP Solution Manager EhP Scope and Effort Analyzer – expected CC adjustment effort


60

Figure 4: SAP Solution Manager EhP Scope and Effort – expected test execution effort

Development managers get detailed insights using expert views about adjustment efforts for custom objects, modifications and clones by SAP modules as well as object types. Test managers can use build-in simulation features to recalculate test efforts based on various attributes such as test coverage, priority of business processes, etc. In addition, specific test plans can be generated for limited business processes including custom code objects and modifications.


61

Figure 5: SAP Solution Manager EhP Scope and Effort – Expert view Value proposition Project teams will benefit from the application in the following way.

Hassle-free analysis

Change impact analysis without physical EHP deployment

Simple Guided procedure in SAP Solution Manager

No external transfer of customer code to protect Intellectual Property

Custom developments

Tailored impact analysis for custom code and modifications

Early estimation of project effort and required adjustment activities

Overview on used and unused code based on reliable usage statistics

Test Management

Automatic generation of preliminary business blueprint (if required)

Test Scope Optimization with significant reduced test scope and test effort

Additional test plan for business processes including custom code & modifications

Recommendations for missing test cases and process traces (BPCA TBOM)


62

6 PERFORM UPDATES WITH NEAR ZERO DOWNTIME

Downtime is one classical upgrade and maintenance challenge. When implementing an accelerated release strategy combining major customer releases with SAP software updates (SPS or EHP), it is also a key topic for your release deployments, especially in environments supporting global or 7x24 hours business operations. SAP tries to minimize downtimes. In this section, we describe SAP best practices for managing and minimizing business downtime, and the latest SAP technologies to reduce planned outages to nearly zero. 6.1 Typical Pattern of Planned Downtime Business downtime is a time period during which the productive system is not available to the business (end users, interfaces, background processing). It is further divided into types, for example the ramp down phase or technical downtime. We distinguish between “uptime”, the time where the production system is up and running and available for the business, and “business downtime” or just “downtime”. Business downtime usually starts with the ramp down phase, which ensures the consistency of the systems and database, and the controlled ramp down of productive use, such as locking all business users, rescheduling background jobs, processing update tasks, cleaning up data queues, deactivating interface connections, and so on. A consistent back up of the database and file system ensures a proper reset point in emergencies. The technical downtime is followed by the ramp down process. During technical downtime, the maintenance tool runs on the system and the system is updated. During this process, the system can be up and running (but with controlled access only), or shut down, to optimize the deployment process and ensure data consistency. Technical downtime can usually be optimized by adjusting tool-specific parameters and settings, or by increasing the available hardware and disc input/output time, depending on the maintenance event tasks. The post-processing phase follows technical downtime. During post-processing, technical system checks are performed, to ensure the technical correctness of the systems. This can be followed by customer-specific software update tasks, such as importing customer transports, updating software add-ons, supplementing or generating objects and programs, and so on. These activities are customer-specific and can change with the scope of different maintenance events. The next phase is validation, which covers the functional validation of the production system by selected business users (functional core team). These tests decide the go or no-go of the current software solution. They usually take one or more hours, and concentrate on selected business-critical processes. In case of a no-go decision, the system must be restored or reset. In this rare case, all activities are known and planned in detail. The entire team must be familiar with go and no-go decisions. In case of a go decision, the ramp-up process continues. Releasing end users for business, establishing interfaces connections, scheduling background processes, and so on. The regular “uptime”, or production use of the system, follows the ramp down process. Holistic optimization of downtime focuses on all elements of the business downtime, not just on the technical part. To review the activities, and its duration, activity by activity, is an intensive task. Focusing initially on time-consuming activities is a more targeted approach. 6.2 Frequency versus Effort and Business Downtime The frequency of changes in the system is usually a balance between the requirements of keeping the system up-to-date, implementation of new functions or modifications of existing functions (configuration changes), and the availability of the functions (and the SAP system). A typical picture of annual planned downtime frequency:


63

Figure 15: Planned downtime frequency

The effort for a single event includes the manpower required for the update and the effort to test and validate the event. It also covers related hardware and support activities. The downtime required to apply the changes is proportional to this effort. Typically, the activities related to the events, as shown on the illustration, require system outage for a number of hours, or even days. Depending on the criticality of the functions running on the affected system, the downtime is usually planned for weekends – possibly long weekends –to minimize the impact of the planned system activity on business. When combining major customer releases with SAP software updates (SPS or EHP), it is more difficult to find an appropriate time window for the software deployment. The usual weekends –even extended weekends around certain holidays – may no longer be sufficient to meet business requirements. SAP has therefore invested in standard tools and methodologies to allow for nearly zero business downtimes. In some cases, the SAP systems may even stay completely online for planned maintenance activities. What is currently achievable with SAP standard tools and methods is described in the following illustration:


64

Figure 16: SAP standard tools and methods

The following sections describe the methods and their benefits and effort. 6.3 Managing Planned Downtime Business users expect continuous availability of functions provided by SAP systems. Each outage, even if announced in advance (planned downtime), can disrupt business. To reduce planned business downtime, consider the following aspects:

• What is the acceptable business downtime for the business? This business downtime requirement can influence the tool or technique you use to perform maintenance, and the cost of optimization procedures and techniques.

• Which maintenance event is planned? Installation of support packages, enhancement packages, database maintenance, or other activities. Consider the technical dependencies of the selected maintenance event, for example database or operating system patch version prerequisites.

• Which systems participate of the maintenance event (based on technical or functional dependencies, for example)? Define the constellation of systems to run maintenance, based on your needs and dependencies.

Reducing planned business downtime usually starts with a proof of concept project, to evaluate activities, timings and downtime, and specify next realization steps. Agree on Possible Maintenance Windows with Your Lines of Business There should be a general agreement between the parties involved, about the availability of business functions. Depending on the criticality of the supported business, the frequency and the duration of maintenance windows should be aligned between the IT department and the business users. The regular maintenance windows should be used for regular system maintenance activities requiring outage. It is often acceptable to business users to have a short outage (less than 4 hours), monthly, during a period of low system activity– usually at weekends or during the night. The frequent short outage allows maintenance activities and the introduction of minor system changes, improvements or innovations. A 4-hour window is usually too short for major system changes, including update of the SAP software stack – new SAP release, new enhancement package, or new support pack stack. A separate outage needs to be agreed with the business for this. Typically, this longer outage (24-48 hours, or even longer), is planned for long weekends.


65

Planning for Customer Release A customer release is the implementation of new custom development, corrections to the existing custom code, or changes of the system configuration. Try to combine a customer release (customization or new functions and new configuration) with the update of the SAP release or the support package stack. You can then combine the test effort, which is usually the largest component of the effort, and needs to be done only once. If the update of the SAP software stack were executed separately from the implementation of the custom development, each step needs to be tested separately. The planned outage to update the software stack could also be combined with patches of the lower stack, e.g. OS or DB patches. The number of activities performed during a single outage increases the risk of cut-over failure, which might lead to a longer outage, or even to roll-back and the repeated execution of the cut-over. Use the term customer release to include all activities related to a system change. It includes:

New SAP release (major release or enhancement package or support pack stack)

Custom development

Customer transports with configuration changes and lower stack changes

OS patch

DB patch

Others Planning all activities to be performed within a single event – customer release planning – should take into account:

impact on the duration of the planned downtime and

risk of the failure.

Encapsulating the System within the System Landscape Business functions provided by the IT systems have various critical points, across components in the system landscape. In some case, only selected components of the system landscape require an outage (e.g. only a BW system). To minimize the impact on the supported business, consider whether the affected components can be shut down individually, and the remaining components (e.g., the ECC or CRM system), supporting the critical business, stay in operation. This selective treatment requires documented knowledge of business processes across the system landscape, and their criticality. When shutting down system components selectively, ensure that the interfaces connecting the disabled components are deactivated–monitoring these interfaces might cause errors. This should be communicated in advance to the persons responsible for monitoring. Downtime and runtime – cut-over planning Especially in complex customer releases, the duration of the downtime can exceed the standard maintenance window. The impact of the implementation of new release exceeds even the business downtime.


66

48-72 hours before the downtime starts, a restricted phase starts on the system – see the figure below. During this phase, no repository changes can be made in the production system. This phase also impacts the DEV system. No development activities can be performed during the upgrade of the development system.

Figure 17: Downtime and Runtime

In the preparation of the planned downtime, as well as optimizing the duration of the downtime, the uptime part of the cut-over should also be kept as short as possible, to minimize the duration of the restricted phase on the production system, and thus to minimize risk, so it is important to prepare the cut-over plan, to perform the planned event efficiently. A cutover plan is an operative plan, like a to-do list, for all steps of the planned activity in the system – customer release. The level of details in a cutover plan has to ensure correct interpretation of the task execution. Cutover plans are correlated with contingency plans; recovery/ restore must always be possible in case of errors. The duration of the business downtime has to be estimated, for the alignment with the business units. The downtime estimation is usually a two-step process

a rough estimate, matching the business requirements, to allow the choice of tools and methods. This estimate is based on general information e.g. database size, experience from other upgrades, information from subject matter experts

the final downtime estimate is based on the actual values measured during mock runs. This downtime has to be approved by the business as planned downtime.

The cut-over plan lists the activities, steps and timing of the planned upgrade, and lists the people required (and available). Important items in the cut-over plan

Detailed timeline of all steps – automatic and manual

List of check points – quality gates

Security back-up at critical times

A list of key persons and persons responsible for each item, project team members and business key users, including availability, location, contact details, etc.

Contingency plan – time buffer for unexpected situations

Process for emergency corrections or transports on the production system

Fall-back strategy – determination of point of no return


67

For critical events run the cut-over plan twice as a simulation, before the production cut-over. Simulation should be in a representative environment with regard to data volume, performance and hardware. 6.4 Minimize Planned Downtime 6.4.1 Recommendations for ABAP-based systems Kernel updates Every SAP System includes a SAP Kernel, which can be maintained separately from the SAP System itself. Kernel patches contain corrections and enhancements of the SAP kernel. Usually, the Kernel is updated along a support package or other major maintenance events. In certain cases however, the deployment of a new SAP Kernel version is required. To change the kernel separately, you basically have to stop every instance of the SAP system, replace the files of the old kernel with the files of the new one, and restart the instance again. A kernel switch typically takes only a short time, but requires stopping all instances of the SAP system, which in turn stops all active transactions. This is very inconvenient, especially for long-running batch jobs. Shutting down the complete system completely, exchanging the SAP Kernel and restarting the system again, is easiest and simplest way to do this. However, this represents a planned downtime, which might not acceptable. Since Nov 2012, SAP supports the Rolling Kernel Switch for SAP NetWeaver ABAP based systems. The Rolling Kernel Switch procedure enables to change the kernel of all application servers sequentially, and thus a planned downtime of the system can be avoided.

For further details about rolling SAP Kernel switch, see SAP note 953653. System Backups A system backup is an activity in the ramp down and ramp up phase, before and after each maintenance event. Every SAP system of the landscape requires a consistent emergency backup. System backup and recovery is challenging due to data growth and consequent long backup and recovery times. For high-availability systems, you should invest in and improve the backup performance by implementing backup technologies such as snapshot. Further information can be obtained from your hardware partner or backup tool vendor. Support Packages and SAP Notes The tool for handling SAP Notes on SAP NetWeaver ABAP-based systems is Note Assistant (transaction SNOTE). It displays, downloads and implements the latest note versions, creates work lists, classifies SAP Notes, and specifies the processing status. To proactively discover which SAP notes are important for a system, SAP provides the System Recommendations tool in SAP Solution Manager 7.1. System Recommendations provides a detailed recommendation of ABAP and non-ABAP notes which should be implemented, based on the actual status of the system and notes already implemented. This recommendation includes, for example, security notes, HotNews, legal changes, corrections or performance-relevant notes. For more information, refer to the SAP Service Marketplace. SAP Support Packages for ABAP-based SAP NetWeaver systems are deployed via Support Package Manager Tool (SPAM), or Java Support Package Manager (JSPM) for Java based SAP NetWeaver systems. SPAM is an SAP-internal tool, no operating system knowledge is required to run it. SPAM ensures that support packages are imported only in the specified sequence. Settings allows adjustment to your needs, such as the number of parallel import processes. If you plan to import a larger number of support package stacks, or if you want to reduce the downtime during your maintenance event, use Software Update Manager (SUM) tool instead of SPAM. SUM can reduce the technical downtime by 50-70% compared to the standard tool SPAM. Enhancement Packages

https://service.sap.com/sap/support/notes/

https://websmp104.sap-ag.de/~form/sapnet?_SHORTKEY=00200797470000096604&_SCENARIO=01100035870000000202&


68

Functional enhancements are shipped as SAP Enhancement Packages for SAP NetWeaver-based systems or SAP Business Suite products. This enhancement package strategy for SAP ERP was introduced in 2007 to simplify the way customers manage and deploy new software. Customers can selectively implement these software innovations from SAP, and activate it depending on business requirements. As a result, customers can isolate the impact of software updates, and bring new functionality online faster, through shortened testing cycles. The tool to deploy SAP Enhancement Package for ABAP and Java-based SAP NetWeaver systems is Software Update Manager (SUM), which is based on the established upgrade technology. It sets up a slim parallel shadow system, in which major deployment steps of the functional enhancement are made in parallel to the production operation. Technical downtime is necessary to perform the system and kernel switch and further downtime-relevant changes, to ensure the consistency of the database. The Software Update Manager offers several downtime optimizing features, some of which are active by default, and others can be activated on demand. These features reduce business downtime compared to current standard tools, because more of the downtime-relevant deployment phases are executed while system is still available for business users. Some of these features are:

Load generation (SGEN): Scheduling load generation used to be a business downtime activity. Now, SGEN can be scheduled on the shadow instance during the uptime phase. This reduces the business downtime by the runtime of the load generation. This option can be activated in the Software Update Manager advanced tool configuration mode.

Selected, long-running after import methods: Some selected after import methods (AIM) are already scheduled on the shadow instance. They are no longer part of the downtime. This feature is active by default.

Mass generation of enhancement objects, generation of enqueue objects: Generation and mass generation of objects used to be in the downtime. With Software Update Manager this generation has moved into the uptime part of the deployment process. This feature is active per default.

Record and replay technique: This feature is based on a database functionality, record and reply technique. Selected application tables changed by a maintenance event are identified and given database trigger and logging tables, to record table changes, updates and inserts. All changes to this set of tables are recorded during the productive use of the system, and permanently synchronized with the data of the shadow system. This procedure allows shifting several usually long running downtime phases, such as the main import and table structure adjustments and conversions, into the deployment uptime phase, to gain the best downtime reduction currently available with a standard tool. To run the main import during the deployment uptime instead of during the downtime phase involves importing the entire content of the target support package and enhancement package. This record and replay technique can be activated by selecting the advanced Software Update Manager tool configuration mode. It is also referred to as NZDM – Near-Zero Downtime Maintenance technique.

Deployment of customer transports during uptime: Software Update Manager (SUM) 1.0, SP6 or higher, has a new feature to reduce business downtime by including customer transport requests in the update phase. This feature allows shifting most of the transport import runtime to the deployment uptime part of support package or enhancement package installations, significantly reducing business downtime. Further details are in SAP note 1759080 - Conditions for SUM including customer transport requests. This tool feature addresses customers with large customer releases, and customers implementing a large number of transports into the production systems (transport runtime of several hours), as part of the business downtime. This feature can be activated in the advanced Software Update Manager tool configuration mode.

Release Upgrades A new software release comes with improvements and new functionality, and uses state-of-the-art technologies to meet users' growing business requirements and increase their productivity. The transition to a new release presents data and system consistency and business downtime challenges. SAP offers a comprehensive set of technical tools and services to facilitate and safeguard upgrade projects.


69

SAP's upgrade technology is continuously improved, with the focus on unattended operation, usability, and technical downtime reduction. The single point of access for all upgrade-related questions is on SAP Service Marketplace http://service.sap.com/upgrade. Parameter and Configuration Changes Parameter and configuration changes in the maintenance process should be combined with the downtime of the functional deployment process. Changes to SAP profiles are handled by transaction RZ10. Dynamic switching SAP parameters do not require a system restart, but profile changes should be handled with care, and tested in advance, before changing a productive system. OS/DB migrations, HANA migrations, Unicode Conversions The Near Zero Downtime method (NZDT) was developed to reduce the planned downtime caused by SAP software updates or platform changes. This method is especially appropriate in large change events, such as Unicode conversions, migrations to SAP HANA or other OS/DB migrations. NZDT can also be used for classic upgrade projects and the installation of enhancement packages and support packages, if the downtimes achievable with the standards tools are not sufficient. Finally, you can use the NZDT method to bundle several maintenance activities, to fit them into one maintenance window, during which production availability is ensured, so core business processes are always available. However, customizing settings are significantly limited for a duration of up to approximately 14 days. For background information about the NZDT method, see the SAP Architecture blue book Near Zero Downtime - Reduction of Business Downtime, in the SAP Community Network (http://www.sdn.sap.com), using the search term “Near Zero Downtime - Reduction of Business Downtime”. Tools and methods to apply the NZDT method are only provided in the context of an SAP consulting or support engagement. 6.4.2 Recommendations for Dual-stack-based Systems As of SAP NetWeaver 7.0, including Enhancement Package 3 and SAP Business Suite 7i2011, which is based on SAP NetWeaver 7.0, including Enhancement Package 3, SAP dual-stack systems are no longer supported. As of SAP Business Suite 7i2011, it will no longer be possible to upgrade an SAP dual-stack system to a higher release. Split dual stack systems before the enhancement package deployment release upgrade. Downtime minimization of single stack systems is less complex and cost intensive, as some features of standard maintenance tools can be used, so split dual-stack systems, as described in SAP Note 1655335 - Use Cases for Splitting Dual-Stack Systems, and optimize the downtime of each single stack individually. 6.4.3 Recommendations for Databases 6.4.3.1 Any DB Database Maintenance Database maintenance consists of several regular activities. They include database installation software updates or implementing database patches. Further database maintenance activities are: parameter adjustments, profile changes and configuration changes. Each database vendor offers different tools to administrate the database, and to implement patches or software updates. Database maintenance activities can be combined with SAP software maintenance in one major downtime, or scheduled as individual tasks with individual downtimes. SAP release upgrades or enhancement package implementations often required updates of the database software as well, because the latest SAP software versions are no longer released for older database versions. Detailed information about released combinations is in the Product Availability Matrix in SAP Service Marketplace. If possible, update the database in a separate time window, before the SAP software update. This separation allows you to optimize your SAP software update downtime. You may also benefit from new database feature that also speed up the SAP updates. Database Reorganizations Database reorganizations are traditionally made by writing the export dump files of the objects into one or more directories, or a dedicated tape device. The directories must be large enough for the objects to be

http://service.sap.com/upgrade

http://www.sdn.sap.com/

http://service.sap.com/pam


70

reorganized. The scripts, however, are always stored in the working directory on the hard disk. The export and import can be performed in parallel, by setting the degree of parallelism and the number of dump files. Reorganization of databases helps preventing fragmentation of data, and can improve performance and reduce unused database space. For large databases, reorganization can be scheduled after large archive runs or deletions. Several database products offer an online reorganization mode, which reorganizes database tables during production operation. 6.4.3.2 SAP HANA database Patches for SAP HANA database are delivered as revisions, which are implemented with the Software Update Manager (SUM) for HANA. Apply new revisions either in a complete support package stack update for the SAP HANA appliance, or if you experience a serious error that is fixed by this revision but not by the latest support package stack. The downtime for SAP HANA revisions is determined by HANA database startup time after deployment of the new revision. This startup time depends on the size of row-store tables that have to be reloaded to the database, and the hardware, so optimizing the downtime mainly requires careful management of the required row-store size, and optimal usage of the available hardware.


71

6.5 Outlook: Zero Downtime Responding to the continuously growing demands of system availability, SAP is developing a Zero Downtime Maintenance method (ZDM). ZDM method can be used for any major change event, allowing non-disruptive update of the SAP software stack. This includes EHP updates, support package stack implementations and implementation of custom code or configuration changes. In the standard upgrade procedure, the production system needs to be taken out of operation to finalize the upgrade downtime activities. The system is unavailable – this is downtime from the perspective of end users. ZDM method uses a temporary system to continue operations during the downtime of the original system. Using the bridge system, users can continue to work on the system. The bridge system is connected to the data of the original system, so users continuously use the data in the original system, whether they are logged on to the original or the bridge system, so no clone is necessary. A schematic picture of ZDM is shown in the figure below:

Figure 18: Zero Downtime Maintenance

ZDM is an in-place method. It uses the technology which is also used by the current SUM tool. During the implementation of the new software, the core functions are running and are available to the users. During the bridge-phase (users work on the bridge system), some functions might be restricted, e.g. only available in read-only mode. ZDM will be available for most critical ABAP-based software components, including ECC.

www.sap.com

Documents

Two Value Releases per Year - SAPfm.sap.com/data/UPLOAD/files/Two Value Releases per... · Two Value Releases per Year How IT Can Deliver Releases with Tangible Business Value