Professional Documents
Culture Documents
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.
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
February 2011
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.
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+%
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).
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