You are on page 1of 2

TECHNOLOGY RISK REVIEW

Try to avoid writing custom code in SAP


Traditionally strong in the Enterprise Resource Planning (ERP) domain, SAP has rapidly expanded to become the leading supplier of enterprise applications in many domains. The strength of SAP is that its built-in functionality supports common business processes in a wide variety of industries. Whenever the standard SAP implementation doesnt provide a 100% match with the customers requirement, it allows customization -extension or replacement- of the built-in functionality. Few developers are familiar with all SAP products, modules and versions, and thus functionality already available in the standard implementation is programmed out again. If new features become available in a new SAP version, customizations are rarely reviewed for obsolescence. Finally, the benefits of a particular customization are generally not weighed against its maintenance costs; a minor deviation from the standard implementation might require large amounts of custom code.

This customization is also the source of the three most common SAP project risks:
1. 2. 3. Invisible maintenance costs due to overuse of customization. Higher maintenance costs due to use of classical, procedural ABAP for customization. High license fee costs due to infrequent SAP upgrades.

Higher maintenance costs due to use of classical, procedural ABAP for customization
The language most commonly used for SAP customization is ABAP. Dating back to the eighties, this language is verbose and tends to yield below-average maintainability. In recent years, the better maintainable ABAP Objects, an object-oriented variant of ABAP, has become available for use with many SAP products and modules. While recommended by SAP, it is still underused compared to the classical, procedural ABAP. Many developers without object-oriented experience also tend to write procedural-style code with ABAP Objects, thus failing to wield its benefits. For some products, SAP also offers (and recommends) the use of Java, a more maintainable technology that is, unlike both forms of ABAP, also used outside of the SAP world.

These risks could theoretically be avoided by not doing any customization at all, which is impractical. However, clear communication about when customization is used, and enforcements of quality standards can do much to mitigate these three common risks.

Invisible maintenance costs due to overuse of customization


Maintaining customized SAP is more expensive than merely maintaining a standard installation, and from a cost perspective one would like to minimize the amount of custom code. In our experience, SAP installations tend to contain a lot of unnecessary customizations.

High license fee costs due to infrequent SAP upgrades


It is important to keep SAP products up to date. Upgrades offer fixes of old problems as well as new functionality possibly allowing for the removal of customization. Perhaps more importantly, older versions will become unsupported by SAP and maintenance partners, or are only supported for a significantly higher fee.

Technology Overview
Productivity: Maintenance costs: Benchmark maintainability: Staff availability: Tooling support: Libraries support: Vendor lock in risk: Business IT trend: Recommended project size: Average 40% above average

Yet, we frequently encounter SAP implementations that are not or rarely upgraded, usually because of the prohibitive amount of effort and time it is estimated to take. A common reason for these high upgrade costs is the improper use of SAP, such as copies and modifications of standard code, direct access to standard tables and use of non-public interfaces. All customization needs to be checked for such use before upgrading. Moreover, when lacking automated tests, a full manual re-test of the entire application is needed before rolling out the upgrade. Postponing the upgrade usually only amplifies the problems; the longer between upgrades, the more effort it will require.

HHIII
Low Medium Medium Medium Hold Small

Domain: Enterprise software applications, e.g. ERP and CRM.


Values in this table are for custom SAP ABAP (procedural/objectoriented)

Software Improvement Group

February 2011

Terms of Technology Overviews


In the SIG Technology Risk Reviews, you will encounter a Technology Overview table. Here we explain in more detail what the table shows, and how we obtained the values.

Productivity
He we use the average number of function points per staff-month as published by in SPR Programming Languages Table version PLT2007c by Software Productivity Research LLC. From the same publication we use the following (simplified) categories: Low: 18 function points/staff month Average: 923 High: 24+

Libraries support
The availability of libraries to perform common tasks (e.g. graphical user interfaces, accessing a database, parsing XML) differs per technology. Based on this availability weve defined three categories: Low: limited or no libraries available Medium: libraries available, but primarily those supplied by the technology vendor High: broad range of 3rd party libraries available
The set of tasks assessed varies per technology, as not all technologies are a sensible choice for all common tasks.

Maintenance costs
Based on the benchmark maintainability and the productivity, we indicate the maintenance costs compared to a technology with an average productivity and an average maintainability.

Vendor lock in risk


To indicate how dependable you are on the technologys vendor: Low: there are multiple vendors or the language has an active open source community. Medium: there is one vendor, but the technology is actively maintained and supported. High: single vendor, but technology is no longer actively developed. Support only available at additional costs.

Benchmark maintainability
SIG calculates software maintainability according to the ISO/IEC 9126 standard, as described here. The maintainability is expressed in stars, with one star denoting the lowest maintainability, and five the highest. From our benchmark of measured systems, we have calculated the average maintainability for systems primarily written in the technology.

Business IT trend
Here, we indicate what our customers are typically doing with this language: Buy: they have started adopting it for new projects Hold: they are using it for current and new projects Sell: they are actively replacing the technology or the projects using it.

Staff availability
For staff availability, we have looked at the presence of qualified staff credentials on stackoverflow.com. Taking the two most common technologies as the baseline, we divide availability into these three categories: Low: 0-25% of baseline Medium: 25-75% High: 75+%

Recommended project size


Having seen many systems in the technology, we may find the technology is best fitting for projects of a certain size. The sizes used here are: Small: projects smaller than 10 staff-years Large: projects larger than 10 staff-years All: no project size limitations

Tooling support
We have investigated the availability of specialized and generic tools to do software development in a certain technology. We look at writing, compiling, running, debugging, testing, and several other tasks performed during development to get three categories of support: Low, Medium and High.

Domain
While most technologies can be used for any kind of system, many technologies have a primary domain for which it was intended, or in which it is most commonly used. Using it outside that domain often results in additional costs or effort. Here we give a brief description of the technologies intended or actual domain(s).

Technology risk reviews


In the Technology Risk Review series, senior software analysts of SIG review various software technologies and identify the main project risks associated with each technology. The reviews are intended to help CIOs, program managers and other IT decision makers to recognize and avoid such risks early. The identified risks are based on past analysis of enterprise software systems by SIG for its customers. Other reviews in this serie: PL/SQL: Keep it away from your business logic Java: A safe technology choice does not guarantee project success Try to avoid writing custom code in SAP Java: A safe technology choice does not guarantee project success Software Improvement Group

Authors
Jeroen Heijmans is an experienced software analyst with the Software Improvement Group. Working for SIG since 2008, he has investigated some 40 different software systems in most major technologies. Prior to joining SIG, he obtained a Master's degree in Computer Science at Eindhoven University of Technology and worked as a software engineer developing web and mobile applications. Rob van der Leek works as a senior software analyst at SIG. He has assessed over 80 enterprise software systems in all leading technologies since he joined the company in 2003. Rob is lead developer of SIGs Software Analysis Toolkit and has a Master's degree in Computer Science at Delft University of Technology. February 2011

You might also like