Traditionally strong in the Enterprise Resource Planning (ERP) domain, SAP has rapidly expanded to become the leading sup-plier 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 doesn’t provide a 100% match with the customer’s requirement, it allows customi-zation -extension or replacement- of the built-in functionality.

This customization is also the source of the three most common SAP project risks:1. Invisible maintenance costs due to overuse of customization. 2. Higher maintenance costs due to use of classical, procedural

ABAP for customization.3. High license fee costs due to infrequent SAP upgrades.

These risks could theoretically be avoided by not doing any cus-tomization at all, which is impractical. However, clear communi-cation 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 customiza-tion

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.

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 be-come 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.

Higher maintenance costs due to use of classical, proce-dural 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 com-pared 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.

High license fee costs due to infrequent SAP upgradesIt is important to keep SAP products up to date. Upgrades offer fixes of old problems as well as new functionality – possibly al-lowing for the removal of customization. Perhaps more impor-tantly, older versions will become unsupported by SAP and main-tenance partners, or are only supported for a significantly higher fee. 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 up-grading. 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.

Try to avoid writing custom code in SAP

TECHNOLOGY RISK REVIEW

Technology OverviewProductivity: Average

Maintenance costs: 40% above average

Benchmark maintainability: HHIII

Staff availability: Low

Tooling support: Medium

Libraries support: Medium

Vendor lock in risk: Medium

Business IT trend: Hold

Recommended project size: Small

Domain: Enterprise software applications, e.g. ERP and CRM.Values in this table are for custom SAP ABAP (procedural/object-oriented)

February 2011 © Software Improvement Group

ProductivityHe 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: 1–8 function points/staff month• Average: 9–23 • High: 24+

Libraries supportThe availability of libraries to perform common tasks (e.g. graphi-cal user interfaces, accessing a database, parsing XML⌫) differs per technology. Based on this availability we’ve 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 costsBased 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 riskTo indicate how dependable you are on the technology’s vendor:

• Low: there are multiple vendors or the language has an ac-tive 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 maintainabilitySIG 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 writ-ten in the technology.

Business IT trendHere, 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 pro-

jects using it.

Staff availabilityFor staff availability, we have looked at the presence of qualified staff credentials on stackoverflow.com. Taking the two most com-mon technologies as the baseline, we divide availability into these three categories:

• Low: 0-25% of baseline• Medium: 25-75%• High: 75+%

Recommended project sizeHaving 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 supportWe 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.

DomainWhile 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 de-scription of the technologies intended or actual domain(s).

Technology risk reviewsIn the Technology Risk Review series, senior software analysts of SIGreview 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 enter-prise 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

Terms of Technology OverviewsIn 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.

February 2011 © Software Improvement Group

AuthorsJeroen Heijmans is an experienced software analyst with the Software Improvement Group. Working for SIG since 2008, he has inves-tigated 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 as-sessed over 80 enterprise software systems in all leading technologies since he joined the company in 2003. Rob is lead developer of SIG’s ‘Soft-ware Analysis Toolkit’ and has a Master's degree in Computer Science at Delft University of Technology.