I was going through a list of upgrade tip articles collected by Demir Barlas (here) in his SAP Watch blog (here). Most of them look unobjectionable, but one touches on a pet peeve. Amit Jain calls them out here (original SDN post here):
6) Cloned programs — Cloned programs are customer programs copied from standard programs… [they] are coded by copying the standard program to a Z-program, having the standard includes or standard function modules. This causes issues after the upgrade, because the standard includes or functional modules might not work with our custom code.
Clones are insidious, because developers don’t think they’re system modifications. They’re right: they’re worse than system modifications. I’ve never heard a compelling case for cloning. Directly modifying the standard program — while not exactly encouraged by SAP — is a more straightforward and honest approach:
- There’s no more pretending that a clone isn’t a modification. Taking standard code, modifying it, tacking on a “Z” to the name, then claiming it isn’t a modification seems disingenous.
- Clones hide from SAP monitoring and other system features. In an upgrade, SPAU has features that attempt to account for mods when updating the code base. It is much simpler to deal with mods in SPAU than by searching through the new SAP program.
- Clones create non-value added work. For example, all of the dependencies to/from the cloned program have to be re-established manually during an upgrade. Never mind the manual bookkeeping involved…
Filed under: IT special interests, Program Management, Project Management, Project Success Factors, SAP Tagged: | ABAP, Amit Jain, Cloned programs, Demir Barlas, Modifications, SAP Upgrades, SAP Watch, SearchSAP, SPAU