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
The WRICEF category is used in combination with a running number. But it is not always easy to decide on the right category. Instead of the WRICEF approach, we will use Development Ids in combination with their Type.
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 (custom)
- Workflow (standard)
- Application Job (Custom)
The Development Id is the number assigned to developments. The development Id will be created after the request has been approved. The Development Request How-To details the process in Jira.
The Development Id will be used in the functional design (FD), the development package name and needs to be assigned in all relevant L5 business process steps in Signavio.
Every development requires at least one Development Id. SAP Notes of type Modification and Consulting require an approved development Id and FD as well. SAP does not support the solutions most of the time and it is a "do at your own risk" approach or are yet unreleased features.
For example, a 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/FD/Signavio : 1235 (Type User Interface) and 1236 (Type System Interface)
Sample - Package: Z[POD]_1235 and Z[POD]_1236
Sample - SaaS: 1237 (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 objects and approaches per type of development.
| Type of Development | Tier 1 | Tier 2 | Tier 3 |
| Conversion (Load only) | Standard Migration Cockpit objects |
|
|
| Conversion (Transform + Load) | Standard Migration Cockpit objects |
|
|
| Enhancement |
|
|
|
| Form (Output) | Custom Adobe Form with Fragments using a standard oData service |
|
|
| HANA CDS View | Custom Released CDS entity | N/A | Custom CDS view |
| Integration Process (custom) |
| N/A | |
| Integration Process (standard) |
| N/A | N/A |
| Mobile App | Custom Neptune app (on Open Edition) | Custom Neptune app (on SAP Edition) | N/A |
| Modification | N/A | N/A |
|
| Program | N/A | Custom Classic ABAP program to run as part of CLOCO or custom print program for Adobe Forms* | Custom Non CLOCO / print program |
| Report/Analytics |
|
| Custom ABAP Report with custom transaction code |
| System Interface |
|
|
|
| User Interface |
| Custom Fiori UX with Gateway service |
|
| Workflow (custom) |
| Custom Business Workflow* | N/A |
| Workflow (standard) | Standard Flexible Workflow | Standard Business Workflow | N/A |
| Application Job | Custom class for Application Job | Custom class for Application Job calling a Tier 2 wrapper | N/A |
* Actually Tier 3, but due to limited availability of Tier 1 alternatives it is considered Tier 2
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 | System | Development Type | Development Id | Requirement title | Priority | Gap Classification | Extension Tier Classification | Technical Details |
Development Id Counting Rules
Every development requires at least one Development Id. SAP considers all custom code as a core change. All development Ids will be counted. The type of it is irrelevant with the following exceptions:
- Standard interfaces or workflows require a development Id and FD to describe the business requirement and to cover the needed technical configuration. But these will not be counted.
- SaaS system customizations require a development object Id and FD for System Interfaces to describe the business requirement and to cover the needed technical configuration. But these will not be counted.
- Conversion developments that will be removed after project go-live will not be counted.
There is no target maximum number of development Ids defined. Instead, we will use indicators that show how much we adhere to SAPs Clean Core approach.
- Average Clean Core Tier Score: Lower value is better. Should be 1 or less. For example 0.8.
- Current percentage of Tier 1 Clean Core Developments: Higher percentage is better. For example 56%.
- Current percentage of Tier 2 Clean Core Developments: Lower percentage than Tier 1 should be our goal. For example 30%.
- Current percentage of Tier 3 Clean Core Developments: Lowest of the three percentages. For example 14%.
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.