Purpose
This document defines the use of Development Ids, how they are managed and counted in conjunction with SAP’s Clean Core principles.
Summary
The Development Id is a center piece to manage, track and measure custom development requirements. Development IDs are lower level to define and document the needed artefacts. Clean Core principles need to be applied to each Development Id object based on feasibility.
Development Id Definition
WRICEF is SAP’s classic way of categorizing business requirements that will be implemented with custom development.
WRICEF stands for:
W-orkflow
R-eport
I-Interface
C-onversion
E-nhancement
F-orm
But it is not always easy to decide on the right category. Instead of the WRICEF we will use Development Ids.
The "Type of Development" will be introduced to categorize instead of the WRICEF. It is a more detailed version of the WRICEF and has the following types:
- Conversion (Load only)
- Conversion (Transform + Load)
- Enhancement
- Form (Output)
- HANA CDS View
- Integration Process (custom)
- Integration Process (standard)
- Mobile App
- Modification
- Program
- Report/Analytics
- System Interface
- User Interface
- Workflow
- Application Job (Custom)
The Development Id is the number assigned to developments. The development Id consists of the approved request Id and, in addition to that for S/4HANA/GTS and BTP developments, a running number. The Development Id will be used in the functional design (FD) document title, the development package name and needs to be assigned in all relevant L5 business process steps in Signavio.
For example, a custom development request Id 1234 of type User Interface has been approved. The UI development requires a UI5 app and an oData service. That means, 2 Development Ids will be created.
Sample - Jira/Signavio : 1234-001 (Type User Interface) and 1234-002 (Type API)
Sample - Package: Z[POD]_1234_001 and Z[POD]_1234_002
Sample - SaaS: 1234 (Type System Interface)
3 Tier classification in Clean Core
Clean Core is SAP’s concept to achieve modern, flexible and cloud compliant custom solutions.
SAP came up with 3 tiers:
Tier 3: Classical ABAP development (deprecated legacy code/tools with exceptions where still required).
Tier 2: Cloud API enablement (custom wrapper to use unreleased APIs in Tier 1) or mandatory use of legacy tools, i.e. pricing routines, user exits.
Tier 1: On-Stack (Key User or Developer Extensibility) or in BTP or SaaS customizations.
ABAP Cloud is the programming model for cloud compliant custom developments. Implementing with ABAP Cloud ensures that the code will be considered clean core and is upgrade stable.
3 Tier Technology Mapping
Based on the above definition of clean core the following table contains the main development tools and approaches used to categorize as tier 1/2/3.
| Type | Tier 1 | Tier 2 | Tier 3 |
| Conversion (Load only) | Standard Migration Cockpit objects | Custom Migration Cockpit object / LSMW / ABAP Load program (To be removed after project Go-Live) | LSMW / ABAP Load program (To stay after project Go-Live) |
| Conversion (Transform + Load) | Standard Migration Cockpit objects | Custom Migration Cockpit objec t/ LSMW / ABAP Load program (To be removed after project Go-Live) | LSMW / ABAP Load program (To stay after project Go-Live) |
| Enhancement | Released Badi / UI Adaptation project / Key User UI Adaptation / ABAP Cloud | Tier 2 wrapper / Unreleased Badi / Customer exit / Routine exit / Standard (Web) Dynpro enhancement | Implicit Enhancement / ABAP Program with user access / Dynpros / Classic ABAP for use in background jobs |
| Form (Output) | Adobe Form with Fragments | Classic Adobe Form | SAP Script / Smartform |
| HANA CDS View | Released CDS entity | N/A | CDS view |
| Integration Process (custom) | Custom released APIs / Custom iFlows | Custom web service proxy object in S/4HANA | N/A |
| Integration Process (standard) | Standard integration proxies and services in S/4HANA / Standard iFlows | N/A | N/A |
| Mobile App | Neptune app (on Open Edition) | Neptune app (on SAP Edition) | N/A |
| Modification | N/A | N/A | Standard code modification |
| Program | N/A | Classic ABAP program to run as part of CLOCO | Non CLOCO program |
| Report/Analytics | Fiori Elements Report / SAC Report (with Datasphere integration) | Business Objects Report / KPI report / AFO Report | ABAP Report with custom transaction code |
| System Interface | Custom released APIs / Standard RFCs | N/A | ABAP Program with direct service calls / Custom RFCs |
| User Interface | Fiori UX with RAP based service in backend / Web App on BTP with RAP based service in backend | Fiori UX with existing Gateway service and clean core compliant code | Custom ABAP dynpro / Custom Web dynpro |
| Workflow | SAP Build Process Automation / Flexible Workflow | Business Workflow | N/A |
| Application Job | Custom class for Application Job | Custom class for Application Job calling a Tier 2 wrapper | N/A |
Clean Core Deviation tracking
All tier 2 and 3 Development Ids will be logged in a deviation tracker and need to be revisited during upgrades to see if a clean core compliant replacement is available.
The deviation tracker header to show the following:
| S No. | Pod / Functional Area | L3 Process | L4 Process | Development Id | Requirement title | Priority | Gap Classification | Extension Tier Classification | Technical Details |
Custom Development Request
Each business process step that requires a development Id will need a development request, specifying the system, development type and high level requirement.
Tier 3 needs to be justified in detail before DA approval and is only allowed by exception. It is legacy and considered deprecated. In certain circumstances classic ABAP development must be used due to lack of clean core replacements. These special cases are considered Tier 2.
Tier 2 needs to be justified in detail before DA approval. SAP is still adding clean core compliant APIs and enhancements each release and using tier 2 offers the needed flexibility to achieve the successful implementation of a business requirement.
Tier 1 is clean core compliant and upgrade stable. No detailed justification is needed.
Development requests are managed in Jira.
WRICEFUM Count
Every development requires at least one development Id. All will be counted. SAP considers all custom code as a core change. The type of it is irrelevant.
Standard interfaces or workflows require a development object Id and FD to describe the business requirement and to cover the needed technical configuration. These will not be counted.
SaaS system customizations require a development object Id and FD to describe the business requirement and to cover the needed technical configuration. These will not be counted.
There is no target maximum number of development object Ids defined.
A report that shows the approved Development Ids per Pod, L3/4 Process, Development Type, System, Clean Core Tier and by Release needs to be created in Jira.