Custom Code Management

SAP Standard Custom Code Management

© 2009 SAP AG Custom Code Management Version: 1.0

of 50

Version: 1.0

May 2009


Whitepaper

Active Global Support SAP AG



of 50

Table of Content:

1 Management Summary ........................................................................4

2 SAP Standards for E2E Solution Operations.....................................5

3 Custom Code Management Standard at a Glance.............................8

4 What is the Basic Concept of the Custom Code Management Standard? ...........................................................................................10

4.1 The Four Dimensions of Custom Code Management...................................... 10 4.1.1 Quantity............................................................................................................. 10 4.1.2 Quality ............................................................................................................... 10 4.1.3 Technical severity ............................................................................................. 11 4.1.4 Business criticality............................................................................................. 13 4.2 Custom Code Optimization............................................................................... 13 4.2.1 Awareness level and optimization commitment ............................................... 13 4.2.2 Visualization of analysis results........................................................................ 14 4.2.3 Quantity optimization ........................................................................................ 16 4.2.4 Quality optimization........................................................................................... 17 4.2.5 Technical severity optimization......................................................................... 18 4.2.6 Business criticality optimization ........................................................................ 19 4.3 Guidelines and Documentation ........................................................................ 20 4.3.1 Guidelines ......................................................................................................... 20 4.3.2 Documentation.................................................................................................. 22 4.4 Governance Integration .................................................................................... 24 4.5 Custom Code Lifecycle..................................................................................... 25 4.6 Custom Code Operations Preparation ............................................................. 28 4.6.1 Requirements.................................................................................................... 28 4.6.2 Design ............................................................................................................... 30 4.6.3 Build & Test....................................................................................................... 32 4.6.4 Deploy ............................................................................................................... 34 4.6.5 Operate and Optimize....................................................................................... 36

5 How to Implement the Custom Code Management Standard? ......37 5.1 Methodology...................................................................................................... 37 5.2 Tools.................................................................................................................. 43



of 50

6 How to Measure the Success of the Implementation?....................44

7 SAP Services and Trainings..............................................................46 7.1 Custom Code Management Services............................................................... 46 7.2 Custom Code Management Trainings.............................................................. 47

8 Further Information............................................................................48



of 50

1 Management Summary

SAP custom developments, enhancements and even modifications of SAP software are not rare at companies today. They are implemented in order to extend the functionality of the SAP standard software and to adjust it to the company-specific needs and business proc-esses. This is often needed and a legitimate intention. But over time such changes very often become one of the main cost drivers and performance bottlenecks. Additionally, custom code is developed despite standard enhancement possibilities or due to insufficient information about standard functionality that is regularly provided by SAP. Besides, custom code can become obsolete over time and developments that are not used anymore are still maintained. Poor software quality often causes problems in productive environments and drives costs for improvement and adaptation. All these are reasons for implementing sustainable Custom Code Management in your organization. Custom Code Management is the process of con-stant state exploration and optimization of the four dimensions of custom code: quantity, qual-ity, technical severity and business criticality, as well as preparation and adoption of SAP custom developments for daily operations and support. Thus Custom Code Management provides a holistic view on custom developments from the operations perspective, not from the development itself. The topics and methodology described in this document are purely ABAP oriented. Variations and specific issues in the case of Java will be mentioned.

At first, this documents provides a brief overview of the SAP Standards for E2E Solution Op-erations in general (section 2) and the custom code management standard (section 3). The basic concepts of Custom Code Management are then described in section 4, including the four dimensions of custom code and their optimization, documentation and guidelines, gov-ernance integration, lifecycle of custom developments and preparation for operations. Section 5 gives a description of the Custom Code Management process, including all major steps. Section 5 also provides overview of the tools that can be used in order to automate and sup-port the process. Section 6 provides suggestions for the measurement of the results of the process. The available Custom Code Management trainings and services provided by SAP are presented in section 7. Links to further material available for the described topics can be found in section 8.



of 50

2 SAP Standards for E2E Solution Operations

Mission-critical operations are a challenge. While the flexibility of SAP-centric solutions rises, customers have to manage complexity, risks, costs, as well as skills and resources efficiently. Customers have to run and incrementally improve the IT solution to ensure stable operation of the solution landscape. This includes the management of availability, performance, proc-ess and data transparency, data consistency, IT process compliance, and other tasks.

Typically, multiple teams in the customer organization are involved in the fulfillment of these requirements (see Figure 1). They belong to the key organizational areas Business Unit and IT. While the names of the organizations may differ from company to company, their function is roughly the same. They run their activities in accordance with the corporate strategy, cor-porate policies (for example, corporate governance, compliance and security), and the goals of their organizations.

Figure 1: Organizational model for end-to-end solution operations

The different teams specialize in the execution of certain tasks: On the business side, end users use the implemented functionality to run their daily business. Key users provide first-level support for their colleagues. Business process champions define how business proc-esses are to be executed. A program management office communicates these requirements to the IT organization, decides on the financing of development and operations, and ensures that the requirements are implemented.



of 50

On the technical side, the application management team is in direct contact with the business units. It is responsible for implementing the business requirements and providing support for end users. Business process operations covers the monitoring and support of the business applications, their integration, and the automation of jobs. Custom development takes care of adjusting the solution to customer-specific requirements and developments. SAP technical operations is responsible for the general administration of systems and detailed system diag-nostics. And the IT infrastructure organization provides the underlying IT infrastructure (net-work, databases …). Further specialization is possible within these organizations as well. For example, there may be individual experts for different applications within SAP technical op-erations.

Efficient collaboration between these teams is required to optimize the operation of SAP-centric solutions. This becomes even more important if customers engage service providers to execute some of the tasks or even complete processes. Customers have to closely inte-grate the providers of out-tasking and out-sourcing services into the operation of their solu-tions.

Key prerequisite for efficient collaboration of the involved groups is the clear definition of processes, responsibilities, service level agreements (SLAs), and key performance indicators (KPIs) to measure the fulfillment of the service levels. Based on the experiences gained by SAP Active Global Support while serving more than 40,000 customers, SAP has defined process standards and best practices, which help customers to set up and run End-to-End (E2E) Solution Operations for their SAP-centric solutions. This covers not only applications from SAP but also applications from independent software vendors (ISVs), original equipment manufacturers (OEMs), and custom code applications integrated into the customer solution.

SAP provides the following standards for solution operations:

• Incident Management describes the process of incident resolution

• Exception Handling explains how to define a model and procedures to manage excep-tions and error situations during daily business operations

• Data Integrity avoids data inconsistencies in end-to-end solution landscapes

• Change Request Management enables efficient and punctual implementation of changes with minimal risks

• Upgrade guides customers and technology partners through upgrade projects

• SOA Readiness covers both technical and organizational readiness for service-oriented architectures (SOA)

• Root Cause Analysis defines how to perform root cause analysis end-to-end across dif-ferent support levels and different technologies

• Change Control Management covers the deployment and the analysis of changes

• Solution Documentation and Solution Documentation for Custom Development define the required documentation and reporting regarding the customer solution

• Remote Supportability contains five basic requirements that have to be met to optimize the supportability of customer solutions



of 50

• Business Process and Interface Monitoring describes the monitoring and supervision of the mission critical business processes

• Data Volume Management defines how to manage data growth

• Job Scheduling Management explains how to manage the planning, scheduling, and monitoring of background jobs

• Transactional Consistency safeguards data synchronization across applications in dis-tributed system landscapes

• System Administration describes how to administer SAP technology in order to run a customer solution efficiently

• System Monitoring covers monitoring and reporting of the technical status of IT solutions

• Test Management describes the test management methodology and approach for func-tional, scenario, integration and technical system tests of SAP-centric Solutions.

• Custom Code Management describes the basic concepts of custom code operation and optimization

Out of this list, this white paper describes the standard for Custom Code Management.



of 50

3 Custom Code Management Standard at a Glance

It is very difficult to comprehensively analyze and evaluate the complex structure of standard software, enhancements, and custom developments of your current IT system landscape using simple methods. Since the variance and interconnectedness of the business require-ments are so big, it is difficult to measure the influence on your critical core business proc-esses comprehensively.

As long as your IT system landscape and the most important business processes are running smoothly, and costs remain within an acceptable range, important questions about custom enhancements and developments are often neglected. These include the following:

• How different is the custom developed solution from the SAP standard?

• How well have customer-specific programs been implemented?

• Will the development continue to run smoothly in the future?

• Who will take care of custom developments when the responsible developers are no longer available?

• What unforeseeable maintenance costs are hidden in the custom development?

• What optimization potential can I realistically attain?

• Will the custom developments still be needed after an update of the SAP standard soft-ware?

• How will the custom developments be influenced by an SAP upgrade?

During customization, the SAP standard software is being enhanced and even modified. Dif-ferent custom solutions exist, primary developed in ABAP, but also in Java, interacting and integrated with each other. With this complexity and with strong focus only on functional re-quirements, important factors of custom solutions like their documentation, their impact on core business processes, their quality, their operability, supportability and maintainability are often left without proper attention. This standard shows how to avoid this situation through sustainable optimization and how to manage important factors from the operations and main-tenance perspective. Custom Code Management can be described as a process of perma-nent optimization of custom developments based on an as-is analysis and their preparation for and integration into solution operations and support.

The key to successful Custom Code Management is awareness and constant optimization of the quantity and quality of custom solutions, their impact on business processes and their technical severity. These topics are the basis of this standard. The focus is on achieving op-timal operability, maintainability and supportability of custom developments. This should al-ready be considered during custom development and implementation projects. The standard shows why and how all relevant aspects must be considered already during these projects and in all phases of the custom code lifecycle. The technical preparation activities for optimal integration of custom developments into solution operations are described separately. These topics and methodologies are ABAP oriented. Variations and specific issues in the case of Java will be mentioned in the chapters, but not covered in all details.



of 50

SAP provides several services and tools, including SAP Solution Manager, in order to sup-port the flawless process of Custom Code Management. These are described in sections 5.2 and 7.1. The SAP Solution Manager enterprise edition is the foundation for SAP solution operations and support services and also provides powerful tools for Custom Code Manage-ment. The Solution Documentation functionality makes the documentation of custom code much more productive and provides the central point of information that can be used for changes, adjustments or support activities. The Custom Development Management Cockpit is also part of the SAP Solution Manager enterprise edition and provides possibilities for iden-tification of obsolete customer objects and especially for a change impact analysis that helps to optimize efforts in case of technical upgrades or business functionality innovation with enhancement packages. SAP is providing the Code Inspector tool as part of the ABAP Work-bench and comprises functionalities for code quality reviews. In addition to the two last men-tioned tools that are purely ABAP-oriented, SAP NetWeaver Developer Studio (Developer Studio) for J2EE development integrates the JLin tool for static code reviews and tests of Java programs.

The allocation of Custom Code Management in the model for solution operations organiza-tion, presented in section 2, can be described as follows. Application Management owns Custom Code Management and has to ensure that the process is constantly contributing to overall improvement of the maintainability, operability and supportability of custom code. Therefore several other organizational units need to be involved, first of all Custom Develop-ment, that adjusts and enhances SAP solutions to customer-specific requirements. Beside technical knowledge provided by custom development, Custom Code Management also needs business process expertise that is delivered by the business process champions. To-gether, these units ensure that the main task of Custom Code Management is achieved – avoidance of unnecessary modifications. Additionally, the deviation from SAP standard should be at a minimum level. Providing this, they lower the total cost of ownership (TCO) and enable reduction of the impact of future changes. At last, SAP Technical Operations and Business Process Operations units are involved in the process of preparation and integration of custom developments into solution operations and support.

The Run SAP Methodology comprises approaches, relevant material, tools and services for the implementation of SAP E2E Solution Operations (for further information, see section 8). It can be seen as Accelerated SAP (ASAP-Methodology for implementing SAP software) only for operations. Custom Code Management is part of it. Run SAP can be referenced and used for the implementation of the Custom Code Management process, which is described in this document (see section 5.1).

Through the remainder of this paper, the term custom code will refer to modifications, en-hancements and composite applications.



of 50

4 What is the Basic Concept of the Custom Code Management Standard?

4.1 The Four Dimensions of Custom Code Management

Custom code including enhancements and modifications that exist in a company’s SAP sys-tem landscape can be evaluated in four dimensions. These dimensions are quantity, quality, technical severity and business criticality. The goal is to establish a constant evaluation proc-ess of custom solutions in these four dimensions, to optimize the solutions on the basis of the results that were obtained and in alignment with the goals that have to be achieved. How this can be done for existing developments is described in section 4.2. For new developments, the four dimensions should already be planned and taken into account during development projects as outlined in section 4.5.

4.1.1 Quantity

It is essential to be aware of the quantity of your custom objects. In the ABAP environment, an object can be for example a program, a customer-specific transaction, a function but also a self-implemented SAP user exit or SAP enhancement interface. In the Java environment, objects can be modified archives of SAP standard scenarios, different types of development components or portal content. Each group of objects has its attributes and a technical realiza-tion type. It is important to know which objects exit, in order to evaluate which are still in use and what custom code is probably obsolete. Reduction of obsolete objects contains signifi-cant potential for lowering total costs of ownership. The main tool that can support this opti-mization in the ABAP environment is the Custom Development Management Cockpit (CDMC) in SAP Solution Manager enterprise edition. The relevant features are presented in section 4.2.3.

The quantity dimension gives answers on the following questions:

• What groups of custom code objects do I have?

• How many objects exist?

• Am I still using them?

• Can I remove the obsolete ones in order to optimize TCO and operability?

4.1.2 Quality

A bad quality of custom code often causes unforeseen failures of applications and core busi-ness processes. This interrupts the business continuity and can become very expensive. Often only functional quality is considered but the non-functional factors are not less impor-tant and make often the difference between good and bad solutions. The ISO 9126 standard defines six major categories of software product quality: functionality, reliability, usability,



of 50

efficiency, maintainability and portability. Each of them is further subdivided into subcatego-ries see Figure 2.

Figure 2: The ISO 9126 standard quality model for external and internal quality

The ISO 9126 can serve as basis for establishment of a company specific quality model and quality measurement system. This should enable constant awareness of the quality of cus-tom solutions that is a prerequisite for improvement actions. Beside the technical quality of custom code, additional factors exist like side effect impacts. It has to be assured that they are minimized as much as possible. The measurement of quality should optimally be sup-ported by a tool. The Code Inspector provided within the ABAP development environment is a tool for formal ABAP code quality analysis (see sections 5.2, and 8). It has to be differenti-ated between the formal quality of the code, like for example applying of naming conventions or documentation in the code, and the overall product quality represented by the ISO stan-dard. Formal code quality is typically obtained by analyzing only the source code. It is very important for quality exploration but can’t give information about all relevant quality catego-ries, for example usability.

The quality dimension should answer the following questions:

• What are the main quality criteria?

• How can I measure and improve the quality of my custom code?

• How can I automate the quality assurance process?

• What is the functional quality of my code?

• What is the non-functional quality of my code?

• What is the formal quality of my code?

4.1.3 Technical severity

There are several ways to add, extend or adopt the functionality of ABAP-based software delivered by SAP. SAP programs can be enhanced by enhancement technologies like user exits or BAdIs. The enhancement and switch framework (see section 8) is making this proc-ess very flexible. SAP standard software can also be changed by modification. This is a more



of 50

radical way in comparison to enhancement and has to be done very carefully and only if it can not be avoided.

The functionality extension can also be achieved by custom applications, standalone or with reference to SAP objects. Generally, all ABAP custom objects can be divided in four catego-ries:

• SAP Standard Configuration (customizing, e. g. IMG table entries or personalization)

• Enhancements

- With standard interfaces (BAdIs or Customer Exits…)

- Without interfaces (implicit enhancements, explicit enhancements)

• Modification

- With tools that assist the modification

- Without tool assistance

• Custom

- With reference to SAP objects released or SAP-internal interfaces

- Independent (standalone and composite applications in customer namespaces)

The goal of the technical severity dimension is to minimize the technical deviation of customi-zation from the SAP standard. It is recommended to avoid custom developments whenever it is possible and to stay as near to the standard as you can. Thus this is often not the case and a lot of custom code already exists, clearing of unnecessary and problem causing custom developments should be done. The clearing can only been achieved with successfully align-ment with activities done in the business criticality dimension. In general, the first recommen-dation is to avoid modifications at all. Enhancements with interfaces should be the preferred technology for custom development, complemented with custom applications (SAP refer-enced or composite) in cases of more comprehensive requirements. It is also important to know the readiness for future changes, like upgrades, for existing custom developments. The technical severity dimension should give answers on following questions:

• How far away is my custom solution from the standard?

• Is the technical realization of that deviation optimal?

• How can I reduce the technical severity of my custom code?

The possibilities for adjustment and adoption of Java based SAP software are different. They can be mainly realized with the SAP NetWeaver Development Infrastructure (Development Infrastructure). Modification in Java is restricted, because SAP delivers no source code (some exceptions) where the customer is able to modify. Basically, all custom objects will be in the category of custom solutions developed in the Development Infrastructure based on the SAP component model, which is used to structure applications as reusable components. The main goal for Java customization stays the same, reducing the deviation from the stan-dard.



of 50

4.1.4 Business criticality

Smooth and correct flow of the business processes is essential for success of every com-pany. Custom solutions should have the same level of quality as SAP standard. Especially it is important to enable the smooth support of the core business processes. The goal of the business criticality dimension is to get awareness regarding which business processes are using what custom code. This helps in achieving two major goals: to find possibilities for clearing of customer objects and to margin the impact of future changes on core business processes.

The business criticality dimension gives answers on following questions:

• What are my core business processes?

• Which of them are using custom code?

• What is the impact of future solution transition events (e. g. upgrades) to my custom code?

• What potential for clearing of custom objects do I have?

• How can I make my business processes more resistant to change and problems with custom developments?

4.2 Custom Code Optimization

4.2.1 Awareness level and optimization commitment

In order to have a chance to optimize the four dimensions of Custom Code Management, it is essential to be aware of the current and planned state of custom solutions. It is also neces-sary to have a constant optimization process and not only to act when issues already oc-curred. Custom enhancements and developments are generally handled in one of the follow-ing four ways:

Reckless own developments

Customers whose handling of developments falls into this category do not have information about how customer-specific programs impact core business processes, quality criteria can-not be measured and custom developments are insufficiently documented., When problems arise, they can quickly have a critical impact on the business functions in the company if the support infrastructure is inadequate and the developers of the customer-specific enhance-ment are not available. In this case, support services of the standard software provider can only be offered to a limited extent and are associated with unforeseen additional costs.

Wait and postpone

Customers whose handling of developments falls into in this category have long since real-ized the risks associated with their own developments, but are afraid to take the initiative to improve their systems. Custom enhancements and developments are only checked and op-



of 50

timized when necessary. This is usually the case shortly before larger updates of the stan-dard software or when severe problems occur. Such events can lead to significant, un-planned additional costs, because the system availability – and therefore also the smooth flow of important core business processes – may be endangered.

Avoid and optimize

Customers whose handling of developments falls into in this category are proactive and are actively working on optimizing the overall system. They evaluate changes that are planned for their core business processes and try to avoid custom enhancements and developments where possible. The company follows the basic strategy of using standard processes or processes that are as close to the standard as possible. These customers carefully consider the risks and potential of custom developments. They use different methods such as project management, project planning, and creating internal guidelines for custom development. When they update the standard software, they always subject custom enhancements and developments to a cost-benefit analysis. Based on the results of this analysis, custom devel-opments may be replaced by standard applications, if possible. Thereby, additional mainte-nance costs for custom developments can be minimized and the overall cost for the operation of the IT system landscape is reduced.

Manage and control

Customers whose handling of developments falls into in this category always have complete control over their core business processes and understand the impact of custom enhance-ments and developments. Processes are thoroughly documented, and the customer can control the processes using effective project management. Furthermore, using internal guide-lines safeguards the quality of the custom enhancements and developments. New require-ments in the company that are not covered by processes in the standard software are cen-trally managed, using SAP Solution Manager as a centralized data pool.

Using the available methods for the as-is analysis of your IT system landscape, it is still diffi-cult to clearly illustrate the optimization potential that can be attained., SAP provides you with a model you can use to visualize the analysis data to see the results in a clear and coherent manner. Using this multidimensional abstraction model, you can measure and evaluate your custom enhancements and developments.

4.2.2 Visualization of analysis results

The basis for every optimization is the state exploration in the four dimensions. It is important to have a good and easy to understand concept for presentation of the analysis results in order that not only experts can understand the information.



of 50

Figure 3: Visualization of Custom Code Management dimensions

Figure 3 shows a multidimensional metrics model for the visualization of the analysis results. The shown bar chart contains the four dimensions of Custom Code Management. Each di-mension includes an assessment method:

• The quantity dimension defines the height of the bar chart and counts the custom objects. It must be defined what is distinguished as a custom object. As mentioned in section 4.1.1 the candidates are custom programs, functions or transactions, as well as user exits or other enhancement interfaces.

• The business criticality dimension defines the width of the bar chart. A grading system should be developed depending on the company’s specific environment. The example contains five categories. The first category is Non-Mission Critical and contains objects that have a marginal impact on the core business processes. The fifth category Mission Critical contains custom object that are significantly used by core business processes and are crucial for their successful accomplishment in daily operations.

• The technical severity dimension defines the depth of the bar chart. For ABAP, there are seven categories in which development objects can be placed regarding their technical realization (see Figure 3). All categories refer to custom objects except the SAP standard category

• The quality dimension is represented by colors. The quality category of objects with same technical severity and business criticality is defined based on their fulfillment of the quality criteria. There are three categories in the example: appropriate, represented by green, to be improved, represented by yellow and inappropriate, represented by red. The quality categories have to be developed company specific.

Visualization of results is the basis for effective decision making and improves the application of the governance model. The metrics do not have to describe the whole SAP IT landscape of the company. They can even improve effectiveness by describing smaller systems.



of 50

Figure 4: Optimized state of the ABAP custom developments

Figure 4 shows an optimized state of the SAP solution regarding ABAP custom develop-ments. In general, custom code is reduced to its minimum. The business functionality is mainly covered by SAP standard functionality. If custom code exists, it is mainly realized by enhancement technology. Business critical processes do not use any modifications. These could exist but they affect only non mission critical business processes. All custom develop-ments have a very high or good quality level.

4.2.3 Quantity optimization

Experience shows that some parts of custom developments 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 in the quantity dimension is to identify obsolete objects and to produce the basis for their clearing. In addition to this, it can also be very use-ful to identify objects with problems in execution as potentials for optimization in the technical severity and business criticality dimensions.

For ABAP, this process can be automated with the CDMC (see section 5.2) tool of SAP Solu-tion Manager enterprise edition. The clearing analysis of CDMC consists of two major phases helping producing a list of clearing potentials. First the tool selects customer objects in the concerned system and stores them according to their object types, like tables, transactions, function groups, programs and classes.

After that, the objects are analyzed and categorized among others as: customer objects, modified SAP objects, used objects, objects with no reference, inactive objects, objects not marked as used, short dump objects and transportation frequency. This categorization can be used as a starting point for the clearing process that can be completed after additional activi-ties in the technical severity and business criticality dimensions (see sections 4.2.5 and 4.2.6). Additionally, a “How to guide for clearing” is provided with the CDMC and can be viewed directly in the SAP Solution Manager environment. It gives recommendation on how



of 50

to proceed while clearing obsolete custom objects and what should you keep in mind regard-ing the different object types and their possible uses.

4.2.4 Quality optimization

Sustainable quality optimization of custom solutions is a key success factor of the whole Cus-tom Code Management process. Precondition for success and main potential for optimization in the quality dimension is in the establishment of a quality measurement system. This can be done based on the ISO product quality model (see section 4.1.2). The main challenges for this are:

• Establishment of one common measurement system for all development areas.

• The most important aspects of software quality must be covered with metrics.

• Proper comparison and aggregation of metrics for different solutions has to be ensured.

• Acceptance in the development teams has to be ensured.

• Actions based on the measurement results have to be triggered

• Regular quality measurement execution during project and operation phases has to be established.

Independent of the type of the technical realization of custom code like enhancement or mod-ification, independent of the application type that custom code is developed for like CRM or a portal solution, and also independent of the underlying technology ABAP or Java, only one measurement system has to be established. The most important aspects of software quality must be covered by metrics. Metrics can be different for various technologies, thus ABAP metrics will in most cases differ from Java metrics. The best measurement system does not provide much help without the acceptance in the development teams. Developers have to recognize the approach and the KPIs and must know that their work will be evaluated based on them. Last but not least, it is clear that a measurement system has a meaning and is not useless when improvement actions are triggered based on the obtained knowledge. The action possibilities are:

• The results have to be communicated to development and business units, e. g. based on a balance score card.

• The problem fields have to be handled according to their priority. Attention has to be paid especially to issues that endanger the productive use of custom code, like performance.

• The metrics should be evaluated regarding their effectiveness and improved constantly by changes or better threshold values.

• The measurement system and process has to be discussed with the development and operation teams. Attention has to be paid to constant improvement of the measurement system.

• The measurements, reviews and their results have to be documented. The documenta-tion is used for controlling and improvement.

The Code Inspector should be used in order to automate the formal ABAP code quality checks. Among others, it provides the topics for performance, security and syntax checks



of 50

based on metrics. The scope and metrics definition can be enhanced and adapted to specific needs. The tool is directly available in the ABAP development environment and can directly be used by developers and technicians. For further information on Code Inspector, see sec-tions 5.2 and 8.

In the Java environment, the JLin test tool can be used in order to meet the high demands placed on quality assurance for Java-based application projects. It can be used to investigate the properties of Java source files and check the syntax of their semantics. Some of the checks are delivered as standard, but it is also possible to create own checks by specifying check parameters. For further information on JLin see section 5.2 and 8.

SAP provides services that can help optimize the quality of custom solutions. The SAP re-mote performance check service is provided remotely and checks the overall performance of SAP systems. The SAP business process performance optimization service is more compre-hensive. It is delivered partly remote and partly onsite with concentrating on the identification of main performance bottlenecks and providing improvement for selected parts. For further information on SAP services, see section 7.1.

4.2.5 Technical severity optimization

As already mentioned, there are several possibilities for custom adjustment of the SAP ABAP environment, like enhancements, modifications or standalone custom applications. It is im-portant to keep the complexity level of these custom developments as low as possible and the best way to do this is to stay as close to the standard as possible. Modifications should be generally avoided and done only in exceptional cases where enhancements are not possible. Custom code with or without SAP references should only cover those parts for which the standard does not offer any functionality.

The optimization potential of the technical severity dimension is limiting the deviation from the standard and in reducing it by clearing of custom objects. Therefore, the results of the quan-tity dimension can be used and further categorization of the objects should be integrated. First of all, the objects need to be further grouped regarding their technical realization. The clearing candidates can be further prioritized based on this obtained information and the re-sults of the clearing analysis done in the quantity dimension. For example, modifications with performance problems that are not frequently used are perfect candidates for clearing.

Anyway, the clearing of objects can only be done after the results of the business criticality dimension are obtained. After that, the connection of objects to business processes is clear. Save alternatives for their replacement exist.

In order to optimize the technical severity of custom developments, the adjustment alterna-tives of SAP software have to be carefully analyzed already during development and imple-mentation projects. The following is the preferred order of custom adjustment alternatives: SAP standard functionality, possible workarounds, enhancements with interfaces, implicit enhancements pre/post standard code, explicit enhancements and classic modifications. For more details see section 4.5.

The implementation of ABAP modifications must be justified. All alternatives like the SAP standard functionality scope, enhancement framework or even business process change



of 50

need to be considered. Additionally, this can only be achieved with taking the business rele-vance of the modification into account. The justification has to be repeated constantly for all planned or implemented modifications. SAP provides the SAP modification justification check service for ABAP-based systems, which helps in analysis of modification and in providing alternative implementation possibilities (for further information, see section 7). It is also es-sential to assure maintainability of custom code, especially the resistance to future change. This process has also to be repeated constantly and the SAP custom code maintainability service for ABAP- based systems supports this (for further information, see section 7).

4.2.6 Business criticality optimization

The final results for clearing of custom objects and especially modifications have to be pro-vided during business criticality optimization. Identification of the connections of custom ob-jects to business processes and software modules is essential for this. The next step is to analyze the alternatives for custom code clearing:

• Business process change – make custom objects obsolete by redesign of business proc-ess steps.

• Eliminate or reduce – clear custom objects if they are not used at all or check the return to the SAP standard (check for new or explore deeper the SAP standard functionality).

• Optimize and adjust - by reducing the technical severity level (e. g. replace modifications by enhancements).

• Do not change anything – sometimes the effort for clearing and redesign is too big and the results can’t be exactly estimated. The best alternative is to leave it like it is and to analyze the possibilities again in next optimization cycles.

The alternatives can only be analyzed in close cooperation of the development teams with business process champions and core users that provide the business knowledge. The alter-natives have to be prioritized in alignment with their realization complexity, costs, time effort and implication of business process execution improvement.

Business processes can be seriously affected by every software change or actualization, for example an upgrade. Changes could have an impact on current functioning of custom devel-opments and business processes using it. Additional potential in the business criticality di-mension is in the improvement of the knowledge about which business processes will be affected by a change. Upgrades and solution transition events could have impact on the un-derlying custom code. This knowledge helps to estimate, plan, prioritize and effectively allo-cate the development effort for upgrade and change adoption. The process can be auto-mated with the Custom Development Management Cockpit (CDMC) and the change impact analysis as part of it. There are three major steps in order to identify impacts of changes for custom developments (see Figure 5):

• All SAP objects that are used by custom repository objects have to be identified.

• Every SAP object has to be classified on the basis of the impact level of change.

• Every custom object has to be classified based on its relationships to SAP objects af-fected by changes.



of 50

Figure 5: Change impact identification

SAP also provides a service, the custom code change impact analysis, which can assist in the process of analysis itself and in estimating the adaptation effort after changes. It also helps in identification of obsolete objects and candidates of clearing and can therefore also provide assistance in the quantity and technical severity dimensions. For further information see 7.1 and 8.

Proper custom code documentation is critical for the success. All relevant documentation according to the SAP Standard for Solution Documentation and the SAP Standard for Solu-tion Documentation for Custom Developments (see section 8) has to be provided in SAP Solution Manager. The level of documentation has to be checked constantly and existing gaps have to be closed.

4.3 Guidelines and Documentation

4.3.1 Guidelines

Development guidelines are typically provided by the customer development organization, which is responsible for creation, maintenance, executions, and publication of the guidelines. Development guidelines and rules cover the complete development process from functional requirement approval via technical evaluation to technical implementation and functional approval.



of 50

Since development of custom code is kind of creative work, any developer tends to create a unique and individual implementation. The quality of delivered coding is very much depend-ing on the level of expertise of the individual developer which mainly consists of knowledge and experience. Different developers most likely will deliver different code, fulfilling the same functional requirement.

Development guidelines address the requirement to ensure the maintainability, readability and stability of coding, to name just a few aspects. Development guidelines define the com-mon base for all custom development and may vary from customer to customer.

Guidelines need to cover the following topics:

• Build the awareness for the necessity of a common sense in custom development and enable the commitment of the individual developer to observe the defined rules and regu-lations.

• Reference the implemented development process, its roles and responsibilities, its ap-proval steps and its quality guardrails and provide access to its documentation.

• Reference the guidelines for documentation of custom development and provide access to its detailed descriptions and documents.

• As an essential part of the functional requirement phase which precedes the development implementation phase, different possibilities for functional enhancements to the standard and their impact on the solution lifecycle need to be evaluated. Guidance on how to de-cide in which way the functional requirement should be implemented needs to be pro-vided (customizing only, custom programs standalone in add on process, enhancement of standard coding or modification to standard coding as the last possibility).

• Name the enhancement technologies used in existing custom developments, i.e. user exit form routines, customer functions (CMod), Business Transaction Events (BTE), Business Add-In (BAdI) or Enhancement Framework. Give the direction for the preferred enhance-ment technology (i.e. Enhancement Framework) and state customer policy concerning modifications of standard coding.

• State the programming language to be used for custom development and the language to be used for documentation (including inline documentation in the coding). Take notice of the language requirements of SAP support. In object oriented environments, the lan-guage used for modeling needs also to be defined, i.e. Unified Modeling Language (UML).

• Reference the access to functional and technical requirement documents and their ap-proval processes.

• State the custom namespaces and their use in custom development (global reserved or strictly defined customer namespace). Provide naming conventions for custom develop-ment objects in detail, based on the SAP standard recommendation available in the SAP NetWeaver section of the SAP Library under Namespaces and Naming Conventions.

• Define and provide programming naming conventions for definitions and declarations inside custom code (i.e. internal tables, global variables etc.). Some examples for ABAP-development can be found using the Code Inspector check variant for programming guidelines).



of 50

• Provide the architecture of the development landscape used and publish the software logistic regulations (including naming conventions for transports).

• Name tools and procedures to be used during modeling and implementation in order to achieve readability, maintainability, stability and performance (i.e. UML, pretty print func-tionality, inline documentation, runtime analysis, Code Inspector, coverage analyzer etc.). Include documentation on how to use the different tools and at what stage of the imple-mentation process (i.e. developer test, user acceptance test, and so forth).

• Reference common sources for information on development (i.e. SAP Developer Network http://sdn.sap.com/, SAP Service Marketplace http://service.sap.com, SAP Help Portal http://help.sap.com/ and available internal sources)

• Append examples for proper use of development language statements and provide hints on tips and tricks available for example in SAP transaction runtime analysis (SE30). In-clude examples for performance optimized or maintainable programming.

• Provide templates to be used during the development process (i. e. development request form, technical implementation evaluation form, acceptance protocols etc.)

4.3.2 Documentation

The functionality delivered by standard applications does not always match completely with the requirements of a customer. Therefore, some projects may include the development of additional functionality or the change of existing functionality. These custom developments may be done by customers themselves, by third-party companies, or by SAP Custom Devel-opment. Supporting customer developments is often more difficult than the support of stan-dard applications. For SAP applications, the documentation is already provided by SAP. For functionality developed by customers or third-party software providers, the availability of re-quired documentation is not always ensured. Therefore, additional requirements regarding Solution Documentation exist for such custom developments.

At least the specification of the development project, a list of all related code objects, and of the required configuration settings have to be available. A standard application is typically used by more customers than a specific custom development. In most cases, there is much more support experience regarding a standard application than there is regarding a custom development. And the risk gets even higher if the people involved in the development project have left the customer or the involved third-party company does not exist anymore.

The technical custom development objects can be derived from the technical implementation and compared to standard objects, but their judgment is only possible in context with the functional requirement they have to fulfill. Since documentation of custom development is the only way to connect the technical objects of the implementation with its functional require-ments, it needs to reflect the complete development lifecycle from initial functional request to the end-of-life decision. End of development can be considered whenever the function that was implemented is replaced by standard functionality or is not needed anymore from the functional perspective.

The existence of proper, at least minimum documentation is crucial to enable decisions on continuation or discontinuation of custom developments. This occurs during the processes of evaluating new or enhanced standard functionality or conflict resolution during solution transi-



of 50

tion events (support packages, upgrades or enhancement packages). The custom develop-ment process needs to ensure that no custom development exists without sufficient docu-mentation, for example by implementation of respective quality gates. Proper documentation helps both customer support organizations and SAP support organization to deliver adequate support for custom developments in an efficient way.

Proper documentation of custom developments should provide answers to the following questions:

• Which parts of the implementation project are impacted by the custom development?

• Why has the custom development been done (business requirements)?

• Who is the business owner of the development and who participated in the decision proc-ess for the development?

• Which systems are involved?

• Are there dependencies between the custom development and other systems/functions?

• Which business processes and process steps are changed?

• What are the transactions or entry points of the custom development?

• Which interfaces are used to integrate custom development with standard applications?

• Which development objects have to be transferred from development to quality assur-ance and production system?

• How to operate the custom development in the future?

• How to set up and execute integration-, volume- and regression test for the custom-development?

• How could a proper handover from the project to the production be ensured?

The minimum documentation required for custom development projects shall be stored within the project documentation tools provided in SAP Solution Manager located in the customer solution environment. In case of multiple SAP Solution Managers in the customer landscape it is expected that the complete set of minimum documentation is located within the SAP Solution Manager that is also used for managing operations and maintenance tasks for the involved system landscape. It is possible to start a project within one SAP Solution Manager during the development phase and later on transfer it to another SAP Solution Manager.

In order to ensure the optimal delivery of SAP support services, it is important for SAP to find the minimum documentation in a standardized location and format. On the other hand, this lays the ground for leveraging many operation support functions offered via SAP Solution Manager (e. g. identification of affected custom business process by requested software or customizing change requests). Certain parts of the documentation are required to be stored in structured format – for those parts the project documentation in SAP Solution Manager offers dedicated screens and structuring elements that shall be used. For unstructured type of information (textual descriptions), there are special template documents to be used to pro-vide this information.



of 50

It is required that all documentation requested within this standard is provided in English. In case where SAP services shall cover this project, it is important that SAP support engineers are able to read it. Without additional translation effort, this can only be guaranteed in a 24x7 mode if the documentation is available in English.

The SAP Standard for Solution Documentation for Custom Development provides detailed information and tools to support custom development documentation.

4.4 Governance Integration

The major topics of governance of Custom Code Management are definition of roles and responsibilities, as well as development of rules and tasks. The goal is not to develop a spe-cific governance model for Custom Code Management. It is the integration of Custom Code Management into the overall governance model of SAP Solution Operations. The organiza-tional units that participate in Custom Code Management are described in section 2. SAP recommends the establishment of the Customer Center of Expertise (Customer COE, for further information see section 8), as the central organizational unit at customer side for driv-ing transparency and integrated quality management for resolution of critical challenges across SAP solution operations. Besides the head quality manager (QM) the Customer COE also comprises four more quality management roles, the QM for safeguarding, QM for busi-ness continuity, QM for business process improvement and QM for protection of investment. Quality management for protection of investment is the place of Custom Code Management in the Customer COE and the corresponding quality manager is responsible for this process (see Figure 6).

Figure 6: Customer CoE quality management

Independently of the Customer COE and the QM for protection of investment role, custom code management specific roles and responsibilities have to be defined on the level of the process execution. This must be done based on the specific customer situation. The Custom Code Management process needs roles containing following responsibilities:

• Responsibilities in the quantity dimension in means of the management of permanent tracking and transparency on custom objects and especially for lowering the TCO by re-ducing obsolete objects. Application of the custom development management cockpit.

• Responsibilities in the quality dimension in order to align quality with the ISO standards for product quality. Coordination of automation of this process by ensuring effective appli-cation of existing tools and permanent search for new tools. Responsibilities for guide-



of 50

lines and documentation governance and controlling. Application of existing tools for qual-ity management, Code Inspector and JLin.

• Responsibilities for permanent reduction of technical deviation of custom developments from the SAP standard and especially for avoiding unnecessary modifications to SAP programs. Also optimal use of the enhancement framework by close cooperation with business process stakeholders.

• Responsibilities for permanent change impact analysis that allows estimating the implica-tion of future changes on custom developments and in this way directly on business processes. This includes controlling of proper documentation of custom developments and their relations to processes in SAP Solution Manager, permanent analysis of busi-ness process changes and going back to the SAP standard possibilities, and application of the CDMC.

• Responsibilities for smooth integration of custom developments into SAP solution opera-tions and support by assuring that all preparation steps are executed, optimally already during stages of development and implementation.

• Responsibilities for permanent improvement of the Custom Code Management process and methodology itself: Monitoring of the practice of Custom Code Management in the company, adjustment of the process to company-specific needs, and looking for possibili-ties of optimization, for example by permanent tracking of possibilities for further automa-tion with new tools.

Beside people having the described responsibilities, other resources with special skills re-garded in the different areas of Custom Code Management are participating in the process (compare the organizational description in section 8). Concrete tasks have to be assigned to the participating actors. All activities have to be executed according to predefined rules that should generate a framework for all actions and help clarifying the goal of the process. Fol-lowing rules for the Custom Code Management process are recommended:

• Avoid custom developments and try to stay close to the SAP standard

• Especially avoid modifications of SAP software

• Aspire clear and reliable information about the quantity, purpose, priority and business relevance of your custom developments

• Align the preparation of your custom developments for SAP Solution Operations with the custom code lifecycle and related SAP projects

• Automate the Custom Code Management process with software tools

• Visualize the results and communicate them

• Custom development is an asset within your company

4.5 Custom Code Lifecycle

The lifecycle of custom code must be considered in Custom Code Management. The custom code lifecycle consists in general of six phases. These lifecycle phases are applying to both, ABAP and Java technologies:



of 50

• Requirements – Collection of requirements for new applications or for adapting existing applications. This includes the business case, the evaluation of the benefits, costs esti-mations and the value proposition. At least a kind of asset management should be put in place. Also it must be checked if the planned requirement is not available as SAP stan-dard solution or partner solution.

• Design – Conversion of requirements into detailed specifications. This includes detailed planned design documentation with a rough description of the technical implementation idea.

• Build & Test – Application configuration and creation of an operating model in accordance with specifications. Test cases must be provided in a written format by the business proc-ess owners also with the possibility to create automatic tests (eCATT).

• Deploy – Transfer of any changes and the operating model into the existing, live IT land-scape. This includes transport management, approval process, and a fall-back strategy to ensure best run business and continuity of core business processes.

• Operate – Provisioning of IT services required for ongoing operations.

• Optimize – Analysis of service level fulfillment and possible start of activities to improve the results.

During the last two phases that are ongoing processes, custom solutions can either be defi-nitely taken out of productive use or can be modified and adjusted in order to meet new re-quirements. In the last case they run through the lifecycle phases again.

During the first four lifecycle phases custom developments are purpose and object of SAP custom development projects. These are either standalone projects or parts of bigger under-takings like SAP implementation projects. SAP implementation projects should follow the proven AcceleratedSAP (ASAP) methodology. It is essential to prepare custom develop-ments for solution operations and support already during development and implementation projects. Doing so is cheaper and better then making it afterwards. Central activities are de-scribed in section 4.6.

The optimization potential of the four dimensions should also be used already during devel-opment and implementation projects. The following recommendations should be taken into account:

• All alternatives like SAP standard functionality, business process redesign, and reduction of the technical severity of the custom implementation has to be considered already dur-ing implementation. Custom implementations should only be done in cases where gaps between business requirements and the SAP standard can’t be eliminated with other al-ternatives.

• Modifications of SAP standard should be avoided. The purpose and priority of every mod-ification, enhancement or any other custom implementation has to be clearly documented and especially the connection to business processes should be pointed out. This can sa-ve time and effort during later optimizations.

• Reviews of formal code quality should be started already during the realization phase of development. This should optimally be supported centrally by automatic tools. The Code Inspector can be used directly by developers and is integrated into every ABAP develop-



of 50

ment environment. For Java-based application projects, the JLin test tool is provided as an integral part of the SAP NetWeaver Developer Studio.

• The provisioning of documentation and compliance with the documentation standards and guidelines should be controlled during development project phases. In parallel, their acceptance and applicability in practice should be monitored in order to identify further improvement possibilities.

• The documentation of custom developments should be done with SAP Solution Manager according to the SAP Standard for Solution Documentation of Custom Developments (see section 8). The existence of minimum documentation has to be guaranteed.

• Experience from earlier optimization cycles should be communicated. The typical problem fields identified in the four dimensions should be clearly pointed out and prioritized. Mis-takes should not be repeated during development and modification.

It is important to keep the technical severity in mind before starting adjusting SAP software. The following list summarizes all possible approaches in an order that should be preferred:

• All requirements should be realized within the SAP standard functionality scope. There-fore customizing possibilities have to be used as much as possible.

• If the SAP standard is not sufficient possible workaround solutions have to be taken into account, like for example business process adaptation.

• Enhancements with interfaces, like BAdIs or Customer Exits, should be the preferred technology when enhancement to SAP software cannot be avoided.

• Implicit enhancements (pre and post) on appropriate places within SAP’s modular units. You have to reckon with conflict adjustments (transaction: SPAU_ENH) by choosing this way. So before implementation, it is important to carefully examine the following issues:

- Versioning: How often has SAP changed the code in context?

- Complexity: The shorter the coding is, the more stable is the implementation.

- Preferred alternative: Post enhancements should be preferred

• Explicit enhancement points are the next preferred possibility for adjustment. It is recom-mended to set own enhancement points.

• If SAP coding has to be overwritten, explicit enhancement sections or implicit overwrite enhancements are the alternatives. You should be aware that SAP does not provide any maintenance for this sections and possible corrections to overwritten SAP standard code has to be adapted by yourself.

• Classical modification should be the last instrument for adjustment that is used only in exceptional cases.

Explicit enhancement points and enhancement sections or implicit overwrite enhancements have two major advantages compared to classical modifications. They can be developed in own packages and they can be transported independently. So the development bundling and transport layer are independent from the SAP standard.



of 50

4.6 Custom Code Operations Preparation

The operation of custom code comprises the same processes as operation of standard solu-tions. They are described in the SAP E2E Standards for Solution Operations (for further in-formation see chapter 8). As already mentioned, preparation steps should be done in each phase of the custom code lifecycle and during implementation projects in order to ensure that custom developments are implemented according to the SAP E2E Standards for Solution Operations principles and that they can be well supported and maintained. If the preparations haven’t been done yet, they have to be done afterwards, but this can mean much more effort than realizing them from the beginning on. The following sections describe the detailed activi-ties to be performed in the different life cycle phases. They can be used as a checklist before the start of development. If this is not interesting for you yet, we recommend reading these sections later after the rest of the document.

4.6.1 Requirements

In the Requirements phase, you already have to plan how E2E solutions operations can be enabled, integrated and established. That means getting the awareness and knowledge for:

• Remote Supportability

- Planning of remote access to custom solutions in order to enable safe log in of the support organization and SAP support employees from any place in the world

• Incident Management

- Planning a Service Support Help Desk that can cover Incident Management for custom applications

- Planning of responsible and appropriate networking to ensure message flow and its completion. In cases that an incident is raised for a custom solution, there should be a strategy to manage and complete this task successfully

• Root Cause Analysis

- Getting awareness and planning roll out of E2E Root Cause Analysis components such as workload analysis, trace analysis, and change diagnostics

- Planning of possible knowledge transfer for usage of new tools that can help in Root Cause Analysis

- Planning of the involvement of E2E Root Cause Analysis trainers

• Change Management

- Planning of the networking of the custom development team with other organiza-tional units, so that changes can be performed effectively according to the ap-proval procedure that is in place

• Business Process and Interface Monitoring

- Planning of a team responsible for developing a monitoring concept, for driving custom Business Process and Interface Monitoring and later for operational tasks in this area



of 50

- Planning the testing of Business Process and Interface Monitoring

- Planning of hand-over of the monitoring concept to operations

• Data Integrity and Transaction Consistency

- Rollout of awareness of risks concerning Data Integrity and Transactional Consis-tency that may arise due to the non-optimal integration of custom developments into a distributed landscape and a high need to prevent this

- Setting up of the responsible for the concept of prevention and reconciliation

• Data Volume Management

- Planning of roll-out and sharing awareness of the Data Volume Management me-thodology (such as avoidance, summarization, archiving, deletion after defined times)

The information that is needed in order to achieve E2E solution operations readiness has to be evaluated:

• System Administration

- Evaluation of the influence of your custom developments on the administration tasks and estimation of corresponding workload such as number of jobs or work-flow items

• Change Management - Evaluation of the covering of business requirements by required changes and their

alignment with existing services


- Evaluation of core business processes using custom code and the necessary in-terfaces

- Identification of business requirements regarding the execution of custom busi-ness processes or custom steps included in core business process

• Job Scheduling - Analysis of expectations regarding throughputs and time windows, e. g. need and pos-

sibility of parallelization


- Evaluation of the Data Volume Management strategy for custom developments

• Upgrade

- Evaluation of how custom development objects could be reduced

- Decision about possible tools or services to support the approach



of 50

4.6.2 Design

For the concept of E2E solution operations, it is essential to define your solution landscape and your core business processes in SAP Solution Manager as basis for further operation needs. So custom development can produce need for redefinition of business processes or adding of new ones, as well as redefinition of the solution landscape. This must be consid-ered already in the design phase together with following important activities:


- Evaluation of sensible information, to make sure secure remote access to custom solutions is guaranteed and it is prevented that any secret information is being vis-ible outside

- Ensure that the solutions use technologies that can be supported remotely


- Concept for logging messages from custom user interfaces, that means possibility to allow creation of messages directly from the user interfaces, attachment of technical documentation as well as transferring message to SAP Solution Man-ager. SAP delivers templates to be included in custom code when developing in SAP environment.

• System Monitoring

- Consideration of logging and tracing mechanisms to enable monitoring


- Consideration of impact on system and operations administration


- Definition of a concept for workload analysis, tracing, logging and high availability which should cover following aspects:

Description of agents for collecting custom information (such as traces and performance measurements, resource metrics) in satellite systems

Collection of log entries, dumps, queue errors, workload data

Tracking of changes such as configuration of custom solution

Requirements for custom instrumentation and dashboards

Integration of custom components in a high availability solution and de-scription how to set the component as high available

- Definition of detailed requirements for root cause analysis in an E2E environment


- Definition of a concept for version management and for deployment of applications in a consistent and systematic manner



of 50

• Business Process and Interface Monitoring - Definition of a concept for monitoring which includes custom development:

Definition of monitoring objects (errors, throughput, backlog, performance)

Definition of monitoring activities including procedures and frequency

Definition of error handling procedures

- Definition of communication and escalation procedures Interface to Incident Management

Interface to Change Request Management

• Data Integrity and Transaction Consistency

- Minimize risk for data inconsistency with appropriate data design (e. g. redun-dancy because of performance requirements)

- Identification of possibilities for data inconsistency (description of business proc-esses and system landscapes that could lead to potential data inconsistency)

Detailed understanding of involved business processes and their flow, mon-itoring, reporting activities and technical objects that could lead to data in-consistency

Categorization as permanent or temporary data inconsistency

Evaluation of severity together with the business continuity disruption

- Definition of an inconsistency monitoring concept for custom applications

- Definition of an reconciliation strategy (e. g. reconciliation report, work around, re-covery)

Definition of the leading system and how data has to be distributed to other systems

Definition of what can be changed and how

Definition of the data model that could lead to inconsistency

- Definition/design of the inconsistency report

• Job Scheduling

- Definition of batch programs to be run as scheduled jobs during later operations

- Integration of custom development requirements into Job Scheduling Management


- Definition and description of custom tables and corresponding fields and their need

Definition and description of the business context of custom tables

• Which business processes are updating custom tables (e.g. trans-actions, reports)



of 50

• What are the relations between custom and other tables and up-date steps (sequence of db updates to be described)

• What are the expectations in terms of table growth

- Definition of a DVM strategy Definition of archiving methods for custom tables (retention period, resident

time, deletion period), specification of scheduling and frequency

Archiving with two possibilities

• Include of custom tables in table groups of existing archiving ob-jects

• Creation of new custom archiving objects

• Upgrade

- Applying of the development standard and guidelines for writing maintainable code

4.6.3 Build & Test

In this phase the activities for ensuring E2E solution operations readiness are realized:


- Follow the design and check that it is realized

• Solution Documentation

- Create documentation according to this standard and the standard for Solution Documentation for Custom Development (for further information see section 8)


- Including custom applications in the monitoring environment For custom applications developed in SAP development environments, this

is achieved automatically via the Computing Center Management System (CCMS) infrastructure.

For other custom applications, agents have to be set up that deliver System Monitoring information to the open interfaces of the CCMS infrastructure


- Providing technical and functional content for SAP standard support services

- Providing information for System Monitoring in SAP Solution Manager


- Ensuring the coordination of developments and packaging

- E2E Change Analysis



of 50


- Implementation of the monitoring concept for custom objects

- Implementation of error handling

- Creation of documentation Business process model including core custom business processes or cus-

tom steps

Monitoring guide updated with custom requirements

Escalation procedure updated with custom requirements

- Integration with Change Request Management

- Integration with Incident Management

• Data Integrity and Transactional Consistency

- Realization of inconsistency report

- Implementation of reconciliation report

• Job Scheduling

- Maintaining of the operation handbook


- Implementation of archiving objects and methods (write, delete and read) accord-ing to development guidelines

- Include of checks for archiving periods according to data creation and last changes time

E2E solution operations readiness requires careful testing of the realized preparation activi-ties:


- Testing of the secure accessibility of custom applications from outside


- Testing the creation of messages directly from custom user interfaces and verify-ing correctness of information in the messages


- Testing that custom applications are visible and integrated into System Monitoring


- Testing that the workload generated by custom applications is considered and that there is a strategy in place to administrate tasks such as reorganizing jobs, paral-lelization of jobs to fulfill requirements of a high available solution



of 50


- Testing visibility of custom changes and their tracking

- Testing performance and resource measurements collection

- Testing E2E trace and passport handling


- Unit testing: correctness of error handling management and routing via Incident Management

- Testing custom steps in a E2E core business process

- Stress test and evaluation of performance monitoring correctness (throughput and thresholds evaluation)

- Testing backlog monitoring correctness


- Automated test scenarios to identify business processes affected by the occurred inconsistency

- Testing of the check and reconciliation report with mass volume


- Non functional performance and load tests

- Testing of the archiving and check deletion reports

4.6.4 Deploy

The affected people have to be prepared for E2E solution operations:


- End user training and certification for Root Cause Analysis technical core compe-tence


- Deployment after the request is released according to central strategy of trans-ports in place


- End users training to ensure successful completion of the business process steps

- End users training to ensure management of exceptions

- End user training for creation of awareness of the underlying data model that could cause inconsistency



of 50

Following has to be handed over in order to assure successful E2E solution operations:

• Solution Documentation - Collection of all information that should be handed over and stored centrally in SAP

Solution Manager as described in the Standard for Solution Documentation for Custom Development


- Description of responsibilities for handling messages between different potential support levels


- Operation guides covering aspects of administration tasks related to custom appli-cations

- Description of the high availability concept


- Root Cause Analysis checklist and test cases descriptions plus status


- Documentation of the changes and their justification


- Concept for Business Process and Interface Monitoring

- Error handling procedure

- Escalation procedure

- Monitoring guide

- Checklist for completeness of BPM (including test cases results and procedures)


- Documentation of check reports

- Documentation of reconciliation and recovery procedure which describes Possible inconsistent data models

Data dependency identification

Data to be used for reconstruction

Data model (list of business objects and instances affected)

Backup availability

Estimation of the time for running the procedure

• Job Scheduling

- Operation handbook covering the Job Scheduling Management of custom reports



of 50


- Description of custom tables specifying content, field description and purpose

- Description of business content information (depiction of relation with other tables using data base diagram, sequence of update in relation with other tables, infor-mation on how tables are updated, business process flow and update)

- Archiving and deletion strategy, scheduling and frequency

4.6.5 Operate and Optimize

As minimum for running of custom solutions at all, the areas of Incident Management, Root Cause Analysis, System Administration and Monitoring, Change Management, Test Man-agement and Solution Documentation have to be covered. In order to operate these proc-esses seamlessly across standard applications and custom code, the development invest-ments in supportability done in the earlier stages start to pay off. With the E2E solution opera-tions program, SAP guides how to set up and run the operations of SAP-centric solutions. Based on continuous experiences of SAP experts and customers, the framework provides best practices for IT operation processes. The different processes are described in the Stan-dards for E2E Solution Operations and the Run SAP methodology accelerates the process of solution operation readiness (for further information see section 8).



of 50

5 How to Implement the Custom Code Management Standard?

5.1 Methodology

The process of Custom Code Management is presented in Figure 7. It consists of two logi-cally separated parts, the optimization and operation sub-processes and the guidelines and documentation sub-processes. This section describes the single process steps. The process is oriented for management of ABAP custom code. The integration of Java has to be done company specific and depending on the amount of Java implementations that exist in the company’s SAP application environment.

Figure 7: Custom Code Management process

Sub-process: Governance Integration

• Step 1: Define and review roles, responsibilities, tasks and rules

- Initially, Custom Code Management specific roles with corresponding responsibili-ties have to be defined on the process level based on the recommendations in section 4.4. They have to be adjusted to the needs and situation of the specific company. More than one role can be assigned to the same person.

- Rules have to be defined as a framework for the Custom Code Management proc-ess showing the desired development direction. After initialization, roles, responsi-bilities, tasks, and rules have constantly to be reviewed with focus on their appli-cability, value, and correctness based on the results and experience of the Custom Code Management process execution in practice.



of 50

• Step 2: Improve tasks and rules

- Especially needs for adjustment of tasks and rules are often identified. In this step, they have to be analyzed in more detail. Interviews with parties involved in the Custom Code Management process can help to identify gaps. The practical rele-vance of the tasks and rules is an important issue. They have to be constantly im-proved in this step.

• Step 3: Incorporate into overall governance model

- The incorporation of Custom Code Management into the governance model of a company with a Customer CoE is described in section 4.4. Independently of the existence of the Customer COE, Custom Code Management has initially to be in-corporated into the existing governance model of the company and the integration has to be continuously adjusted if the overall governance model changes.

Sub-process: 4 Dimensions State Exploration

• Step 1: Explore quantity

- The quantification of custom objects and their categorization have to be done as prerequisites for further custom code optimization. This has to be complemented with the identification of obsolete objects. This process has to be repeated in regu-lar time intervals depending of the custom release management or business proc-ess change frequency of the specific company. The execution can be done with the clearing analysis of the CDMC tool. As a result of the quantity exploration a clearing potentials list has to be produced. First the clearing potentials list should contain all objects that seem not being used or belong to the category of objects that produce short dumps. The next version should contain further categorization and prioritization. For example types of objects or functional groups that contain a large number of clearing candidates have to be pointed out. A prioritization of these groups regarding later optimization can be done already at this stage. The clearing potentials list should serve as basis for the next steps of object clearing done in the technical severity and business criticality dimensions.

• Step 2: Explore quality

- A uniform quality measurement system has to be defined and established based on quality KPIs. The measurement process has to be automated as much as pos-sible and the results have to be visualized. The measurement and review of cus-tom code quality based on the ISO 9126 criteria should be repeated in constant in-tervals. This process has to be done in close cooperation and communication with the development teams. The clearing potentials list should be supplemented with the results of the quality exploration, especially pointing out the custom objects with very poor quality.

- There is big potential for automation in the area of formal code quality reviews. Code Inspector can be used for this in case of ABAP and JLin in case of Java. Op-timally, this should be done already during development and implementation pro-jects. The measurement process should be documented.



of 50

• Step 3: Explore technical severity

- Based on the results of quantity exploration, further categorization of custom ob-jects regarding optimization potential has to be done. The technical realization of objects has to be obtained first. After that, the performance of custom applications containing the considered objects has to be analyzed. Objects with high technical severity, like modifications additionally producing performance problems, are for example primary candidates for clearing. As a result, a new version of the clearing potentials list, complementing the results from other dimensions, has to be pro-duced containing further prioritization of objects regarding their clearing relevance.

• Step 4: Explore business relevance

- Until now, only technical factors of objects like their severity or frequency of usage were taken into account. But clearing of custom objects can only be done with close cooperation with business process champions and key users. Only together, they can analyze the business relevance of custom objects, their relation to core business processes. A (re-) comparison of business requirements with SAP stan-dard processes and checking modifications and enhancements versus SAP stan-dard functionality has to be done. The following alternatives, already mentioned in section 4.2.6, have to be analyzed: business process change, eliminate or reduce, optimize and adjust or leave it like it is. These alternatives have to be prioritized and analyzed regarding their pros and cons. The next version of the clearing po-tentials list has to be produced and should contain an action plan for the clearing of custom objects based on their prior categorization in other dimensions and analysis of existing handle alternatives done in this dimension.

- Further, the impact of future changes, like upgrades, on business processes con-taining custom steps and using custom objects has to be obtained. This can be automated by the change impact analysis feature of CDMC. The results can be used to estimate the adaptation effort after changes, to reduce the test effort and to provide further orientation on problematic custom objects.

- The level of documentation of custom developments that is done in SAP Solution Manager has to be analyzed and can serve as basis for improvement in later steps. Proper documentation is essential for analysis of connections between cus-tom objects and business processes and is fundamental for actions described ear-lier.

Sub-process: Optimization Realization

• Step 1: Optimize quantity

- The clearing potentials list produced during exploration can serve as the basis for quantity optimization as well as for optimization of other dimensions. Those ob-jects where the alternative of elimination has been identified as proper and without implications on business processes can be deleted. By repeating the exploration and optimization of the four dimensions constantly, the experience regarding the appropriate number of custom objects compared to their technical severity grows. This experience should be documented and used in order to identify the critical number of custom objects, even with acceptable quality, that starts bringing costs and maintenance efforts to an unacceptable level.



of 50

• Step 2: Optimize quality

- Quality improvement actions have to be triggered based on quality analysis re-sults. It must be assured that actions are not done for objects that are meant to be cleared. So the activities have to be aligned with activities in other dimensions. It has to be checked constantly that the measurement system complies with chang-ing requirements. It has to be assured that quality measurement does not produce additional complexity but improves the state of custom developments. Essential for this is that the quality metrics are constantly checked and adjusted and that threshold values are constantly optimized. Acceptance in the development teams is a key success factor. The optimization process has to be repeated constantly. The search for new tools and automation possibilities should be done regularly.

• Step 3: Reduce technical severity

- The realization of the alternatives described in the clearing potentials list has to be continued in this step. Thus the elimination of objects was already done during quantity optimization and business process change is done during business criti-cality optimization. At this stage, the adjustment alternative has to be realized, with accent on reducing of the severity of objects. The main potential exists in replace-ment of custom developments with new SAP standard functionality, which is con-tinuously provided by SAP. The replacement of modifications with enhancements with interfaces is a second important issue.

• Step 4: Optimize business criticality

- The first optimization task during this step is to improve the documentation level of custom developments within SAP Solution Manager. This is essential not only for any further business process relevance analysis but also for successful support and service from SAP. The next step is to make a preparation for future changes based on the results of the change impact analysis by addressing problematic is-sues in areas identified as especially endangered. Business process changes identified as possible and applicable for custom objects clearing have to be real-ized (for further information on clearing alternatives see section 4.2.6.).

Sub-process: Custom Code Operation

• Step 1: Define and complement operational areas

- The operation of custom developments has to be conceptually aligned with exist-ing operation. It has to be evaluated what E2E solution operation areas are espe-cially important for effective support of custom code and which could bring addi-tional value in order to achieve optimal performance. In the majority of cases, some operational areas will already be covered due to the operations of already existing solutions. The whole situation must be reviewed and if needed the opera-tions spectrum has to be complemented. As minimum for running of custom solu-tions at all, the areas of Incident Management, Root Cause Analysis, System Ad-ministration and Monitoring, Change Management, Test Management and Solu-tion Documentation have to be covered.

Step 2: Prepare for operational activities

- It has to be assured that custom solutions are meeting the requirements to be op-erated. The preparation steps described in section 4.6 have to be done. It has to



of 50

be assured that every application containing custom developments fulfills the op-erability criteria.

- For every operational area a detailed description of activities has to be done, roles have to be defined and people who are responsible for the execution. These tasks are described in the SAP Standards for E2E Solution Operation.

• Step 3: Carry out operational activities

- The carrying out of operational activities is a continuous process that is affected by the results of step 1 or step 2.

Sub-process: Guidelines and Documentation Improvement

• Step 1: Analyze/assess guidelines and documentation

- Prerequisite for this step is the availability of a defined development process. This includes the definition of roles and responsibilities as well as the definition of ap-proval-steps and sign-off procedures during development process (quality gates). Ownership for development process and its guidelines must be defined. Existing guidelines need to be reviewed and verified for re-use in the target guidelines. En-hance target guideline with valuable details from previous guidelines.

- Existing development documentation needs to be collected and verified. The do-cumentation must fulfill the minimum requirement which is to establish the rela-tionship between functional requirement and its technical objects. Adjustments to meet the minimum requirements need to be applied. Organize and migrate ad-justed documents in SAP Solution Manager as described in the SAP Standard for Solution Documentation for Custom Development.

• Step 2: Improve custom development guidelines

- Improving custom development guidelines in first place demands to develop or ad-just the guidelines to meet the recommendations in chapter 4.3. To implement the guidelines and to bring it to life, the guidelines need to be communicated to the development team. To achieve a broad commitment, a kick-off event should be planned and training for the tools and templates used in the guidelines should be provided. Implement a feedback process to improve the usability of development guidelines. Different opinions on code quality may occur during approval proc-esses. Therefore, set up an escalation instance that should also serve as a Q&A contact. The developer commitment to defined rules and regulations is the key to successful implementation of development guidelines. As mentioned in step 1, de-velopment guidelines need a defined ownership. The owner of the guidelines is responsible to adjust the guidelines from time to time and to inform the developer community about changes and improvements.

• Step 3: Establish standard for custom development documentation

- According to the SAP Standard for Solution Documentation for Custom Develop-ment, the target is to store any development documentation in SAP Solution Man-ager. In order to enable the development team to follow this strategy, trainings should be planned to support the change process. These trainings should also be used to leverage the awareness of the importance of proper documentation for the development lifecycle and the accompanying approval processes.



of 50

Sub-process: Guidelines and Documentation Monitoring

• Step 1: Monitor the guidelines appliance

- This step is embedded in the general monitoring of the fulfillment of the custom code development standard that should exist in the company. It focuses on the approval processes for technical development approaches and approval of imple-mentation of custom code together with review of required documentation. These process steps are owned by the development department. Execution of approvals requires solid knowledge of development- and enhancement technologies in SAP systems and strong commitment to apply the defined guidelines and rules. Moni-toring instances need to be defined according to the roles and responsibilities con-cept. Passing these quality gates is prerequisite for the corresponding follow-up step (development or handover to productive). Automated procedures for code in-spection assist in the approval process.

• Step 2: Monitor the fulfillment of the standard

- Monitoring the fulfillment of the standard for custom development documentation requires the appliance of defined quality gates. In essence, this needs to be done by monitoring the approval results during development process. The following quality steps must be achieved step by step during custom code development:

Approval of the functional requirement, its decisions and its documentation

Approval of technical implementation approach, its decisions and its docu-mentation

Approval of fulfillment of functional requirement and its documentation

• Documentation of unit test results

• Documentation of integration test results

• Documentation of mass test results (if applicable)

Approval of appliance of development guidelines and decided implementa-tion approach and its documentation

• Documentation of code inspection results (tool based if applicable)

• Documentation of runtime analysis results (if applicable)

Approval of development handover to productive

• Documentation of completeness of required documentation and its fulfillment of the documentation standard

Following this approval process for custom development aims to provide custom code that meets functional requirements and is of high quality.



of 50

5.2 Tools

SAP Solution Manager provides major capabilities for management of custom code. Solution Documentation for custom code is one of these capabilities providing all functionality for proper documentation of custom developments especially in the context of their business relevance. Second part of SAP Solution Manager important for Custom Code Management is the Custom Development Management Cockpit (CDMC). Besides that, SAP Solution Man-ager provides all capabilities for the integration, everyday operation and support of custom developments by being the central tool for SAP E2E solution operations.

CDMC is part of the SAP Solution Manager enterprise edition. The clearing analysis and change impact analysis are the two features of CDMC that can significantly help to automate and to improve Custom Code Management. The clearing analysis helps to identify custom objects and their attributes relevant for Custom Code Management like: type, frequency of usage or referencing. These results serve as basis during optimization in all dimensions. Change impact analysis is a powerful feature for estimation of possible negative change im-pacts and adaptation effort. Information about CDMC documents and material can be found in section 8.

Solution Documentation in SAP Solution Manager enables proper documentation of custom development projects from the beginning on. The documentation is centrally stored in the SAP Solution Manager environment in a standardized location and format that is very impor-tant for SAP support services. The documentation capabilities comprise and describe differ-ent aspects, like system and landscape of a solution, application components, business sce-nario and business process documentation, interfaces, transactions, development object lists as well s application operation guides.

Code Inspector is a tool integrated into the SAP environment to perform predefined checks of static ABAP coding and DDIC objects. Single and mass tests are possible and new checks can be implemented. The tool is constantly improved from SAP and optimized with new checks. It can significantly improve the work in the quality dimension. For further information and material reference, see section 8.

JLin is a tool that performs static checks of Java source code. It is delivered as part of the SAP NetWeaver Developer Studio (Developer Studio). Checks for metrics, conventions, compatibilities, authorizations and language restrictions, for example, are delivered as stan-dard. It is also possible to create and perform own checks by specifying custom parameters. A check run can include several single checks, which can be performed on one or more Java source code files. After the check run has been completed, the system displays a list contain-ing the test results as information, warnings, or errors, along with location of the problem in the source code. For further information and material reference, see section 8. JLinEE (JLin enterprise edition) is an extension of JLin, introducing new checks for assuring the consis-tency of J2EE applications and fulfillment of the Sun J2EE and SAP J2EE Engine specifica-tions. The JLinEE functionality is available since SAP NetWeaver Developer Studio 7.0.



of 50

6 How to Measure the Success of the Implementa-tion?

For the measurement of the success of implementation and execution of Custom Code Man-agement key performance indicators (KPIs) have to be developed. They have to indicate the success of reaching the desired optimization targets in the four dimensions. Guidance that can help in creating the KPIs is presented below.

What is the optimization target of the quantity dimension? Basically, it is to minimize the number of unused custom objects. The information can be obtained during the clearing anal-ysis with CDMC. The definition of unused objects has to be specified. For example, it can contain all objects not marked as used, with no reference, and inactive.

What is the optimization target of the quality dimension? It is the optimization of the ISO qual-ity categories of products including optimization of formal code quality. Internal and external metrics of the ISO model can be used to develop a company specific KPI measurement model for overall quality. The measurement model for formal quality checks should be based on the quality models of the tools that are used to automate the process. Typically, every tool has an underlying quality and metrics model.

What is the optimization target of the technical severity dimension? It is to minimize the de-viation from the SAP standard. Different realizations should have different impact severity on the KPI’s calculation. For example modifications are the least desired technical realizations and their significant existence states ineffectiveness of Custom Code Management.

What is the optimization potential of the business criticality dimension? Basically, the target is to improve the documentation level, to have very good knowledge about the impact of future changes and to have knowledge about the business relevance of custom solutions. It is im-portant to restrict the dependence of core business processes on custom solutions.

It is recommended to carefully define and document the details in KPI fact sheets. Below you find an example how KPIs can clearly be described:

KPI fact category How to use the categories

Name Avoid misunderstandings

Definition Be specific

Justification Measure only what you want to control

Formula Explain in detail how the figure is calculated

Target Value Determine your goal

Danger Value Define thresholds

Measurement frequency Keep measurement efforts in mind



of 50

KPI fact category How to use the categories

Data source Detect the origin of data

Responsibility Determine the person responsible to deliver the KPIs

Audit frequency Stay up to date – review your defined KPI fact sheets at defined intervals

Be sure that the defined KPIs are measured regularly according to the definition given in the fact sheets. The data should be stored together with their historical values to derive trends. Every time a danger value is reached, follow-up actions should be defined, documented and tracked.



of 50

7 SAP Services and Trainings

SAP supports customers in managing custom code by providing corresponding services and trainings. This section gives a brief overview of these offerings. Links to further information on these offerings are available in section 8.

7.1 Custom Code Management Services

Custom code change impact analysis is an SAP service that is concentrated on the evalua-tion of impact of change on ABAP custom code and on the analysis of potential obsolete objects that are main candidates for clearing. The service can provide assistance in the quan-tity, technical severity and business-criticality dimensions.

Solution transition assessment is an SAP service that is supporting any transition like an upgrade or migration with focus on the analysis of the flexibility and readiness of the solution for such action. The service is provided remotely and works on the basis of collection and evaluation of technical KPIs relevant for following areas: custom developments, modifica-tions, business process documentation, custom code documentation, transport management system, system load and performance, implemented code pages and more.

Modification justification check is an SAP service that is provided remotely for an ABAP-based SAP system. Based on the specified business needs, SAP solution experts verify whether SAP standard functionality or SAP standard enhancements can be used to achieve the functional requirement instead of the evaluated modification.

Custom code maintainability check is an SAP service that is provided remotely for an ABAP-based SAP system. It evaluates the quality of custom developments with regard to upgrade-ability and maintainability.

Business process performance optimization (BPPO) is a comprehensive SAP service that is delivered partly remote and partly onsite. It has been tailored to tackle specific issues and common performance issues of customer programs, logistic processes, and financial period end processes. The service can be ordered specifically for one of the above areas and, in case of Custom Code Management, it can be used to support customer program issues.

Remote performance optimization is an SAP service that is delivered remotely. It can be used when performance problems occur in order to identify the bottlenecks and to make an action plan for their elimination.

SAP custom code management evaluation is an SAP offering that is concentrated on the evaluation of Custom Code Management for your solution landscape. It evaluates the system architecture and some specific key aspects of your SAP solution with regards to Custom Code Development. An additional objective is to understand the risks and challenges of your custom-developed solution. It supports the customer to be as close as possible to the SAP Standards for E2E Solution Operation.



of 50

7.2 Custom Code Management Trainings

E2E 500 Custom Code Management is the SAP training that covers the topics described in this document. In general, it teaches how to handle custom code in the four dimensions and provides practical exercises, for instance, the CDMC exercises, including the clearing and change impact analysis features, documentation in SAP Solution Manager, as well as exer-cises with Code Inspector. It also gives an overview of the Run SAP methodology for imple-mentation of E2E solution operation.



of 50

8 Further Information

ABAP-Programming Guidelines book

• SAP Press: http://www.sap-press.de → search for title

Customer CoE

• SAP Service Marketplace: https://service.sap.com/coe

Code Inspector

• Manage Code Quality with Code Inspector: service.sap.com/solutionmanagerbp

Custom Development Management Cockpit

• Custom Development Management Cockpit Guide: service.sap.com/solutionmanager • Media Liabrary • Technical Papers • Custom Development Management Cockpit

Custom Code Maintainability Check Service

• SAP Service Marketplace: service.sap.com/supportofferings • SAP Enterprise Support • Scope Description

JLin

• Manage Code Quality with JLin: service.sap.com/solutionmanagerbp

E2E500 Custom Code Management Training

• SAP Education Portal: www.sap.com/education

Run SAP

• SAP Service Marketplace: https://service.sap.com/runsap

SAP Business Process Performance Optimization Service

• SAP Service Marketplace: https://service.sap.com/supportservices

SAP Remote Performance Optimization Service

• SAP Service Marketplace: https://service.sap.com/supportservices

SAP Enhancement and Switch Framework

• SAP Developer Network: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12225

SAP Modification Justification Check

• SAP Service Marketplace: service.sap.com/supportofferings • SAP Enterprise Support • Scope Description



of 50

SAP Standards for Solution Operations

• SAP Service Marketplace: https://service.sap.com/supportstandards

SAP Standard for Solution Documentation

• SAP Service Marketplace: https://service.sap.com/supportstandards • Media Library

SAP Standard for Solution Documentation for Custom Development

• SAP Service Marketplace: https://service.sap.com/supportstandards • Media Library



of 50

Copyright 2009 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software compo-nents of other software vendors.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or

registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed are the trademarks of their re-

spective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only in-tended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP

assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. 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 shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in

cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does

not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

Custom Code Management

Documents

Transcript of Custom Code Management