2 Value Releases Per Year PDF

Two Value Releases per Year
How IT Can Deliver Releases with Tangible Business Value

Every Six Months
TWO VALUE RELEASES PER YEAR
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
2
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
3
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.
4
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
5
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.
6
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.
7
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
8
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.
9
Figure 1: Releases and S ync hronized Tes ting 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
10
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 Standard
Minor Release Major Release
Changes Changes
Deployment
On request only Every 1 - 7 days Every 1 – 4 weeks Every 3 – 6 months
Cycle
Standard changes Non-invasive
Change only (non-invasive, changes (+ re-import All types of changes, including
Emergency only
Categories low risk and well of emergency invasive changes
known impact) changes)
Priorities Emergency only Normal Priority Normal Priority Normal Priority
UAT and
Regression test UAT and Regression UAT and Regression test based
Regression test
based on results of test based on results on results of change impact
Test focus change impact
based on results of
of change impact analysis, Interface Tests and
change impact
analysis analysis Integration Validation.
analysis
Already approved Non-critical
Changes to solve New (major) functions,
changes, e.g. configuration,
Examples high priority Support/Enhancement Packages,
storage locations, medium priority
incidents Upgrades medium/low priority
MRP controller incidents
Figure 2: Release Categori es - Be st Pra ctice 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.
11
Standard Changes Minor Release Major Release
Yes (according to
Yes (code inspections and Yes, including code inspections
Unit Test standard change
peer reviews if possible) and peer reviews
process)
Scenario
No Yes Yes (important)
Integration Test
Test Types
User Acceptance Yes (usually required for sign

No Yes (per correction/change)
Test off)
Limited, based on
Extended, based on results Extended, based on results of
Regression Tests results of change
of change impact analysis change impact analysis
impact analysis
Potentially based on outcome
Performance/
No No of single activity trace in
Load Tests Integration Validation
Additional Tests
Potentially (depending on
(System Tests, No Usually no
request)
Cutover Tests
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
12
Figure 4: Change Reque st M anagement – As sessment 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.
13
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.
14
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 Rel eas e Calend ar
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.
15
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.
Create Assess and Build Test Deploy Review and

Request Authorize Req Change Change Change Close Request
Figure 7: Change Reque st M anagement 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).
16
 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.
17
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-s ys tem dual trac k tran sport landscap e
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)
18
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: S ystem Dual Tr ac k Tr anspor t 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).
19
The advantages and disadvantages of this landscape are summarized in the following table:
Figure 10: S ys tem Dual Tra ck Transpor t Landscape - Ad vantages 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
20
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.
21
 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.
22
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.
23
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.
24
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.
25
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.
26
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.
27
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.
28
• 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.
29
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
30
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.
31
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
rd
code delivered by 3 -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.
32
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,
33
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.
34
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.
35
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.
36
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
1
6. SAP Solution Manager – EhP Scope and Effort Analyzer : 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
37
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
2
Automation (CBTA) , Standard Regression Tests
3
(START) , 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 Programmatic approach performing semi-dynamic code

4
TBOM 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
38
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.
39
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.
40
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
41
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 SAP Support Packages or Support Package Stacks deployed in an

Package Stacks (SP) SAP development or test system.
Enhancement Packages (EhP) SAP Enhancement Packages deployed in an SAP development or

test system.
Planned Business Function SAP innovations, called “Business Functions”, become available
Activation 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
42
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.
E
S
e
b
a
s B C
tiS S
a e e
D b b
S n
G a a
e s s
b ai
s ti ti
a a a
s b
A a n n
ti G G
S u
a ai ai
e e
n s s
b r
G b b
a
ai a a
s
s u u
ti
b
Figure 8: BPCA Test Scope Optimization e e
a
a
BPCAnTSO assumes that a changed technical object should be tested at least
r once, but not necessarily
r in
all process steps that use it. u
G
e
ai
r
s
b
a 43
u
e
r
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.
44
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-
45
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.
F D
S S
e e
b b
a a
s s
ti ti
a a
n n
G G
Figure 11: BPCA Test
ai Scope Optimization with test coverage
ai of 99% plus risk mitigation
s s
b b
5.3.4 Quantitative a Example a
u u
e
The following quantitative e
example illustrates the test effort reduction that can be achieved with BPCA Test
r r
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
46
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 44 tests 76 hours 42%
coverage
BPCA TSO 3: preference for automated tests, 99% test 32 tests 52 hours 61%
coverage, priority 1 processes and steps in scope
Figure 13: Results from BPCA Test Scope Optimization (TSO)
47
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  Lack of time to execute regression tests may potentially compromise
tight timelines performance & reliability
 Overcompensating scope of testing may result in more testing than
really required, and project delays
Defects in production  Insufficient test coverage means more defects are not found before cut-
Systems 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
48
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.
rd
SAP and 3 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

rd
With SAP Solution Manager 7.1, customers can integrate SAP and 3 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
rd
3 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.
49
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
50
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

rd
Customers using test option 1 (SAP Solution Manager and integrated 3 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
51
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.
rd
Chart 7: Parameter mapping from 3 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
52
Chart 9: Test Data handling via Test Automation Framework during test execution
rd
A standard SAP interface links 3 -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.
53
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.
54
 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
55
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.
56
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
57
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
58
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
59
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.
60
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)
61
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:
62
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:
63
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.
64
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.
65
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
66
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
67
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.
68
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
69
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.
70
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.
71
www.sap.com

2 Value Releases Per Year PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2 Value Releases Per Year PDF

Transféré par

Droits d'auteur :

Formats disponibles

Two Value Releases per Year

How IT Can Deliver Releases with Tangible Business Value

5.3 Reduced test effort through Test Scope Optimization .............................................................. 37

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

1.2 IT & SAP - the Business Contribution and Value Center

Typical questions from customers are:

5. Near-Zero Downtime updates

2 REQUIREMENTS AND RELEASE MANAGEMENT COMBINED WITH SAP UPDATES

2.1.2 Gathering Small Ideas: Requests for Change

 Short description of the request for change

o Chand advisory board

2.2 Release Management

Figure 1: Releases and S ync hronized Tes ting of Projects

2.2.2 Release Categories

Figure 2: Release Categori es - Be st Pra ctice example

Standard Changes Minor Release Major Release

User Acceptance Yes (usually required for sign

Figure 3: Focus and Prioritization of test activi ties

Figure 4: Change Reque st M anagement – As sessment of the Change Request

2.2.3 Change Categories and Priorities

2.2.4 Combining Customer Major Release with SAP Innovation

2.2.5 Quality Gates for Minor and Major Releases

2.2.6 Release Calendar (per year)

Figure 6: A Rel eas e Calend ar

2.3 Implementation of Requirements governed by Change Request Management and cProjects

Create Assess and Build Test Deploy Review and

Change Request Management governs the

2.4 Roles in Requirements and Release Management

3 MANAGE DUAL TRACK LANDSCAPE FOR MULTI-PROJECT SUPPORT

3.1 Implement a Dual Track Transport Landscape with 6 systems

Figure 8: The 6-s ys tem dual trac k tran sport landscap e

The 6-system dual track transport landscape:

o DEV (project development)

Figure 9: S ystem Dual Tr ac k Tr anspor t Landscape - Staggering Releases

Multiple releases in parallel:

3.2 Dual Track Cutover Process

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

3.3 Retrofit in a Dual Track Transport Landscape

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

3.3.1 Semi-Automated Synchronization of Dual Landscape with Retrofit

 If customizing settings conflict, the version in the production support system is

3.3.2 When, and how often, to retrofit

3.3.3 Prerequisites for Retrofit in SAP Solution Manager

1. SAP Solution Manager 7.1.

3. Cross System Object Lock (CSOL) is active

4 LEAN CUSTOM CODE – AVOID, IMPROVE, MINIMIZE

4.1 Custom Code Management Summary

4.1.1 The ‘green’ City Model – Lean Measurement

Figure 13: Lean Measurement

Dimensions of the city model

Criticality and impact on core business processes

4.1.2 Custom Code Management - Governance Process and Optimization

4.1.3 Custom Code Lifecycle Management - Transparency & Control

4.1.3.1 Get transparency about custom code

4.1.3.2 Process and Architecture

4.2 Avoid Modifications and get closer to SAP

4.2.1 Gap management by Innovation Control Center

4.2.1.2 Blueprint Analyzer

4.2.2 Monitoring and evaluating existing modifications

4.2.3 Get Closer to SAP

4.2.4 Replace clones

4.2.4.1 Distinguishing SAP Original Objects from Clones