Versions Compared

Old Version 22

changes.mady.by.user WEINERT-ext, Patrick

Saved on

compared with

New Version Current

changes.mady.by.user WEINERT-ext, Patrick

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Changed the Tiering for Workflows

Purpose

This document defines the use of Development IdsIDs, how they are managed and counted in conjunction with SAP’s Clean Core principles.

Summary

The Development Id ID is a center piece centerpiece to manage, track and measure custom development requirements. Development IDs are lower level than WRICEFs to define and document the needed artefacts. Clean Core principles need to be applied to each Development Id ID object based on feasibility to keep the Total Cost of Ownership for custom developments manageable and explicit.

Table of Contents

Development

...

ID Definition

WRICEF is SAP’s classic "WRICEF" was the traditional 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 , where each of the letters in the acronym stands for Workflow, Report, Interface, Conversion, Enhancement, and Form, respectively. Typically the letter of the acronym is used in combination with a running number. But in the several decades since this acronym entered into use, SAP development has evolved significantly. There are now many more types of developments which cannot meaningfully be combined into an "Enhancement" and treated equivalently; similarly it is sometimes not always easy to assign a meaningful category to a development.

decide on the right category. Instead of the traditional WRICEF approach, we will use Development Ids in IDs in combination with their Type.

The "Type of Development" will be introduced to categorize a development instead of the WRICEF. It is a more detailed version of the WRICEF and has the following classification that more accurately reflects modern SAP development types:

  • Conversion (Load only)
  • Conversion (Transform + Load)
  • EnhancementEnhancement (incl. Conversion)
  • Form (Output)
  • HANA CDS View
  • Integration Process (custom)
  • Integration Process (standard)
  • Metrics/KPI
  • Mobile App
  • Modification
  • Program
  • Report/Analytics
  • System Interface
  • User Interface
  • Workflow (custom)
  • Workflow (standard)
  • Application Job (Custom)API


The Development Id 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 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.

Every development requires at least one Development ID. SAP Notes of type Modification and Consulting require an approved Development ID and a basic Functional Design document as well. Although SAP might provide the code, SAP does not support Consulting Notes or Modification Notes as part of its product support scope. Since the ongoing support and upgrade maintenance are at Syensqo's risk and cost, they are also considered custom developments from a governance perspective.


Conversions are not required to have a Development ID. The Master Data Register number will be used. A Development ID for conversions is only needed if a custom object, such as a load program, needs to be created.

Examples

For example, a custom development request Id 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 IDs will be created.

Sample - : Jira/FD/Signavio : 1234-001 1235 (Type User Interface) and 1234-002 1236 (Type APISystem Interface) 

Sample - : Package: Z[POD]_1234_001 1235 and Z[POD]_1234_0021236

Sample - : SaaS: 1234 1237 (Type System Interface)


SAP 3 Tier classification in Clean Core

Clean Core is SAP’s concept to achieve modern, flexible and cloud compliant custom solutions.SAP  SAP came up with 3 tiers of custom developments:


Tier 3: Classical ABAP development in S/4HANA Core (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, in S4HANA Core systems.

Tier 1: On-Stack (Key User or Developer Extensibility) or in BTP or SAP SaaS customizations.


ABAP Cloud for S/4HANA Core is the programming model for cloud compliant custom developments. Implementing with ABAP Cloud ensures that the code will be considered clean core as compliant with Clean Core and is upgrade stable.

SAP BTP is the platform for SAP SaaS extensions or cross-system processes.


SAP 3 Tier Technology Mapping

Based on the above definition of clean core the following table contains the main development tools objects and approaches used to categorize as tier 1/2/3per type of development.

Standard integration proxies and services in S/4HANA Flexible Custom RAP based oData or REST API
Type of DevelopmentTier 1Tier 2Tier 3
Conversion (Load only)Standard Migration Cockpit objects
  • Custom Migration Cockpit object
    • Custom LSMW* (To be removed after project Go-Live)Released standard APIs called from Syniti
    • Custom ABAP Load program* (To be removed after project Go-Live)
    • Custom LSMW (To stay after project Go-Live)
      • Custom ABAP Load program (To stay after project Go-Live)
    •  
    • Custom ABAP class or function* 

    N/A

    Conversion (Transform + Load)Standard Migration Cockpit objectsN/A
    • Custom
    • Custom Migration Cockpit object
    • LSMW* (To be removed after project Go-Live)
    • ABAP Load program* (To be removed after project Go-Live)
    • Custom LSMW (To stay after project Go-Live)
      • Custom ABAP Load program (To stay after project Go-Live)
    •  
    • Custom ABAP class or function* 

    N/A

    Enhancement
    • Released Badi implementation
    • UI Adaptation project
    • Custom structures or fields included into clean core compliant / EEW append structures
    • ABAP Cloud compliant custom tablesKey User UI Adaptation
    • Custom ABAP Cloud compliant code
    • Custom Tier 2 wrapper
    • Unreleased Badi implementation*
    • Customer exit*
    • Routine exit*
    • Standard (Web) Dynpro enhancement
    • Implicit EnhancementCustom structures or fields included into CI append structures*
    • Custom ABAP Program with user accessCustom Dynpros
    • Custom Classic ABAP for use in background jobs
    • Custom structures or fields directly added to the main table
    • Unreleased custom tables
    Form (Output)
    • Custom Adobe Form with Fragments using a standard oData service
    • Custom Adobe Form with Fragments using a custom oData service
    • Custom Classic Adobe Form*
    • Custom Adobe Form with Fragments using a custom oData Gateway service*
    • Custom SAP Script
    • Custom Smartform
    HANA CDS ViewCustom Released CDS entityN/ACustom CDS view
    Integration Process (custom)
    • Custom released APIsinterfaces connecting via middleware
    • Custom iFlows
    		Custom web service proxy object in S/4HANA
    		N/A
    Integration Process (standard)
    • Standard iFlows
    		N/AN/A
    Mobile AppCustom Neptune app (on Open Edition)Custom Neptune app (on SAP Edition)N/A
    ModificationN/AN/A
    • Standard code modification
    • Implicit Enhancement
    ProgramN/ACustom Classic ABAP program to run as part of CLOCO or custom print program for Adobe Forms*Custom Non CLOCO / print program
    Report/Analytics
    • Custom Fiori Elements Report
    • Custom SAC Report or Dashboard (with Datasphere integration)
    • Custom Business Objects SAP Analytics Cloud, add-in for Microsoft Excel Report
    • Custom KPI report (Manage KPIs and Reports app)
    • Custom AFO Report*
    • Custom Analytical Query app based views
    • Custom ABAP Report with custom transaction code
    • Custom Business Objects Report (Lumira)
    System Interface
    • Released APIs
    • Standard RFCs
    • Custom RAP based oData or REST API
    • Standard integration proxies and services in S/4HANA
    • Custom BTP CAP based services
    • Custom Gateway service*
    • Custom web service proxy object in S/4HANA 
    N/A
    • Custom ABAP Program with direct service calls
    • Custom RFCsRFC service
    User Interface
    • Custom Fiori UX with RAP based service in backendUX 
    • Custom Web App on BTP with RAP based service in backend
    		Custom Fiori UX with Gateway service
    • (React or other non SAP UI libraries)
    • UI Adaptation project
    • Key User extensibility (i.e. UI Adaption, Custom Fields and Logic app)
    • Screen Personas for GUI simplification
    • Standard Dynpro enhancement
    • Standard Web Dynpro enhancement
    • Custom ABAP Dynpro
    • Custom Web Dynpro
    • Custom ABAP dynpro
    • Custom Web dynpro
    Workflow (custom)
    • Custom SAP Build Process Automation
    • Custom
    • Business Workflow
    • Custom
    Business
    • Flexible Workflow
    *
    		N/A
    Workflow (standard)
    • Standard Flexible Workflow
    • Standard Business Workflow
    • Standard SAP Build Process Automation
    		N/AN/A
    Application JobCustom class for Application JobCustom class for Application Job calling a Tier 2 wrapperN/A
    Web API
    Custom Gateway service*Custom RFC service

    ...

    • Actually Tier 3, but due to limited availability of Tier 1 alternatives it is considered Tier 2


    Non-SAP SaaS Customization Tier classification

    For Non-SAP custom development it is also important to stay within the means of provided tools and technologies applying best practices to achieve and maintain a clean core.

    The customizations are approached similar to SAP developments and categorized in Tiers if possible.

    Salesforce

    The two key technologies that are used to enhance the Salesforce standard today are Apex and Lightning Web Components (LWC).

    Apex and LWC are code-based tools. For UI development, LWC-based low-code tools like Gridmate and Omnistudio are preferred before developing a pro-code UI in LWC. Apex is the Salesforce programming language used for custom logic and interfaces.

    LWC based apps use the modern and preferred framework. For workflows, Flow is the preferred no-code tool. Visualforce, Workflow Rules and Process Builder should not be used anymore.


    Either one of these tools needs to be used with best practices in mind. More details are captured in the Development Guidelines. The Guideline is kept up to date. By applying the Salesforce Development Guidelines only tier 1 and tier 2 classification applies.

    Icertis

    Icertis as a SaaS system does not allow access to DB and code. Only enhancements allowed are via the provided framework and UI driven.

    Only standard APIs can be used. 

    In case a custom development is needed Icertis will implement and support it.

    Only the Tier 1 classification is applicable.


    Clean Core Deviation tracking

    All tier 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 IDs are logged in the Clean Core Deviation Tracker. During upgrades, these items are revisited to see whether a Clean Core-compliant replacement is available.

    The deviation tracker header to show The Clean Core Deviation Tracker records the following information:

    S No.Pod / Functional AreaL3 ProcessL4 ProcessSystemDevelopment TypeDevelopment IdRequirement titlePriorityGap ClassificationExtension Tier ClassificationTechnical 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


    Development ID Counting Rules

    Every development requires at least one development Development Id. All will be counted. 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 ID and FD for System Interfaces to describe the business requirement and to cover the needed technical configuration.

    ...

    • But these will not be counted.


    There is no target maximum number of development Ids defined.defined maximum number of Development IDs. Instead, KPIs will be used to measure the degree of adherence to SAP's Clean Core approach: 

    • Average Clean Core Tier Score: Lower value is better. Should be 2 or less. For example 1.4.
      • Formula: (No. of Tier 1 objects x 1 + No. of Tier 2 objects x 2 + No. of Tier 3 objects x 3) / Total Number of Objects
    • Current percentage of Tier 1 Clean Core Developments: Higher percentage is better. For example 56%.
    • Current percentage of Tier 2 Clean Core Developments: This should be lower than the percentage for Tier 1.
    • Current percentage of Tier 3 Clean Core Developments: Lowest of the three percentages. For example 14%.


    Jira will show the approved Development IDs 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.