Introduction
Ever since the introduction of new extensibility framework(In-app, Side-by-side, Developer extensibility ) and Business Technology Platform along with RISE with SAP movement, it has being argued that RICEFW(or WRICEF) is outdated and no longer the correct terminology to categorize development objects.
This has being discussed internally in my project and SAP clients that have being working with, as well heated discussion on internet can being seen to whether to create a new terminology and make the RICEFW term obsolete. Selected blogs and forums below:
Is the WRICEF term still appropriate in the days o… – SAP Community
Modernizing SAP: From RICEFW to BEANS — Part 1 | by James Wood | Switched On: The Bowdark Blog
Mapping ABAPer (WRICEF) into SAP BTP (Business Tec… – SAP Community
This blog will be one addition to the above articles questioning the purpose of RICEFW, but one argument this blog adds is that we cannot eliminate or replace RICEFW, not just yet. In my humble opinion, RICEFW still matters and will matter for another decade at least.
What is RICEFW?
In case you are new to the RICEFW stuff, please see What is RICEFW in SAP? Meaning and Examples | LeanIX for what kind of SAP object represented by each letter, and an article for understanding why it’s needed in your SAP ERP landscape. In short, W(Workflow), R(report), I(Interface), C(Conversion), E(Enhancement), F(Form).
History of WRICEF
To begin with, we must know how RICEFW came about and why it’s being the solid definition of SAP custom development objects for so long. It’s uncertain who or exactly when this term is created but as I believe it must be at least after R/3 and after the SAP NetWeaver was introduced around 2004(otherwise there was no Interface, where SAP system communicates with the internet and ABAP to handle http request or connect with SAP Process Integration ).
Fit-Gap analysis
When an organization implements SAP software, the project will most always start with Fit-Gap analysis involving business users, technical and function consultant. The identified gaps will be filled with custom solutions and to have some idea what custom solution and the effort for the design, build and testing, RICEFW has been the perfect categorization. Why? Because majority of custom solutions implemented in SAP system are by ABAP and RICEFW perfectly captures the type of solutions ABAP development workbench can build. Categorizing solution with RICEFW has especially being effective when single business solution/process requires multiple types of custom implementations.
For example, S/4 receives accounting document from an interface from a 3rd party systems and when the document is posted, a workflow must be triggered. This requires RICEFW objects Interface and Workflow. This requires building of x number of Interface and x number of Workflows, which both technical/non-tech project members can understand. We don’t want to see a list like, “6 ABAP classes, 2 ABAP HTTP service, ABAP Proxy Objects, Workflow object, 5 workflow tasks”.
This goes vice versa, if the business process is only defined as “Incoming Interface with xxx system where accounting document posting is processed in SAP”, business or functional consultant may understand the requirement on the very high-level but nobody will know what to do after that. The solution/process must be broken down into bits and pieces of technical details so that technical consultant and developer can work on the deeper level.
Clear measurement and categorization
This makes it clear for project manager and technical consultant what development objects are expected and how much developer resource and time should be allocated. Especially in today SAP project where multiple vendors and SAP partners maybe involved, it’s used for clear segregation of duty and responsibility, as well as for project governance monitoring the project process. This also helps business to understand, if even a little, how much effort needed to achieve their hopes and dreams that they would be so eager to see in the system.
In short, RICEFW is a categorization, an approach to measure and client requirement specification that helps transform business requirement(often vague and fuzzy) to something technical consultant and developer can understand. It has also become a standard process governance methodology in modern SAP projects.
SAP RISE/GROW and new extensibility frameworks
Although ABAP workbench captured majority of development required by the business gap, things have started to change after the emergence of non-SAP GUI products such Fiori, Business Warehouse and Process Orchestration, which was around early~mid 2010’s.
New ways of extending ERP
SAP Customer started to experiment with Fiori based analytical report and performed consolidated reporting in Business Warehouse, instead of classic ABAP GUI based report. These new report frameworks were success in the way that OLAP engine revolutionized the reporting with analytical features, which was empowered further by HANA database. This entails that organization’s new reporting requirements gradually shifted from classic ABAP GUI based reports to Fiori analytical report and Business Warehouse query.
Above was just one example for Report but for Interface a similar shift could be observed. After the introduction of Process Integration(PI)/Process Orchestration(PO), classic ABAP based interfaces and their logins are gradually replaced, making PI/PO the unified platform for communicating between SAP ERP system and external systems.
Are reports(BW query) created in BW system still considered part of RICEFW objects? Although they are not in SAP ERP client and not built by ABAP per se, it must still be considered as R in the RICEFW objects. They are still used heavily by business operations, to check the financial statement, perform customer/vendor aging analysis and daily production reporting. The significance of the applications are the same, just the different extensibility frameworks, and separate deployment system.
Having understood this, let’s talk about the modern SAP landscape when RISE and Buesinss Technology Platform(BTP) are in the picture. Let’s break down the term S/4 HANA cloud, RISE and GROW with SAP
SAP S/4 HANA Cloud offerings
Two options for customers to upgrade their system to SAP S/4 HANA Cloud: GROW and RISE.
GROW is a offering targeting organization who can immediately go ahead with Greenfield implementation, which is typically midsize organization that previously had no SAP footprint in their system landscape and can implement SAP to start fresh.
RISE on the other hand targets organization who already runs with SAP on-premise ERP and ready to move the whole infrastructure to Cloud, and RISE comes with two flavors: Private cloud and Public Cloud. Public SAP defines the the two offerings as below: (citation source below)
Public Cloud:” For customers who desire standardized processes that are always on the latest release and prefer their cloud provider to manage their infrastructure, SAP S/4 HANA Cloud Public Edition is the cloud-native ERP that delivers the latest industry best practices and continuous innovation.“
Private Cloud: “For customers who require a high degree of customization in their processes, prefer to innovate at their own pace, and require more control over their solution, SAP S/4HANA Cloud Private Edition is the tailored-to-fit cloud ERP that adapts to an organization’s unique transformation.”
Reference and citation from Differentiating GROW and RISE with SAP
What “standardized processes” in Public entails is that there is limited extensibility option. What “high degree of customization” in Private Cloud means that all the extensibility options are open(Classic Extension+ new frameworks). To Summarize:
| S/4HANA Public Cloud | S/4HANA Private Cloud | |
| Classic Extensibility | No | Yes |
| Side-by-side Extensibility | Yes | Yes |
| In-App Extensibility | Yes | Yes |
| Developers Extensibility | Yes | Yes |
Public Cloud or Private Cloud?
As you can see, unless it’s SAP Public Cloud edition, Private Cloud edition can still use classic extensibility to control the custom development done by classic ABAP Workbench. The primarily reasons why classic extensibility is still allowed in Private Cloud are:
1. to lay the cloud migration path for existing SAP customer who’s invested tremendous amount of budget, resource and time to implement S/4 HANA On-prem or SAP ECC system.
2. Those existing customers are well aware that their system cannot easily go to Public Cloud Directly, due to the jungle of extensions built in their SAP system(Cannot blame anyone as it was the common approach to fill the gap with custom solutions for the last few decades). So to make it technically possible with Private Cloud, first move the whole infrastructure to the cloud while still migrating the invested custom solution to the new cloud landscape.
Cloud migration, slowly but surely
In my view, majority of SAP customer will go for Private cloud, trying to move to the cloud fast without losing their investment on custom solutions. Although Private cloud holds the classic ABAP Workbench solution, this does not mean that organization should lift and shift them to the new cloud environment(as it clearly says not recommended in the above image). This is because classic ABAP Workbench solutions are not upgrade-stable, possibly resulting in effort to adjust the solution every time S/4 upgrade is performed.
From this point, sooner or later, organization must gradually shift their current custom solutions to the new framework(In-app Extension, Developers Extension and Side-by-side Extensions) which is upgrade stable much less likely to be impacted by S4 version upgrade(it is still uncertain whether this means SAP will safeguard 100% or still can cause minimum impact and result in customer to adjust the solution).
RICEFW = Classic Extensions?
Now that we understood the types of SAP’s new offerings and where extensibility approach is going, a question must be asked, “Is RICEFW only for Classic Extensions?” Will it be obsolete when your SAP custom solutions are only implemented with new framework(In-app Extension, Developers Extension and Side-by-side Extensions)?
It’s fair to say that since RICEFW came from the classic ABAP workbench and the development objects created from the new framework uses UI5, OLAP based analytical CDS view, SAP Build Apps and Processes, RICEFW is considered irrelevant more often than not.
If it’s irrelevant, should we completely eliminate the term? In my humble opinion, the idea of RICEFW should not(cannot) be eliminated completely. As written in the first chapter of this blog, “solution/process must be broken down into bits and pieces of technical details ” and RICEFW has being served as “clear segregation of duty and responsibility, as well as for project governance monitoring the project process”. As long as organizations run system implementation projects, something similar to RICEFW is always needed to measure and categorize client requirement and boil them down to technical specifications.
Do we need a new acronym?
Moreover, even in the time of new frameworks and RISE/GROW, in my humble opinion RICEFW should not be replaced at all to a new acronym. This is because even if we have BTP and S/4 HANA Cloud and enforcing Developer Extension + In-App Extension in the ERP core, S/4 Core is still holds the business data the same way and transaction will be processed by the core modules(Finance, Supply Chain, HR) the same way and this has not changed ever since SAP has started as ERP company. The essence as ERP core is still the same and RICEFW still perfectly captures what ERP system does by nature.
RICEFW
- Report. Accurate and timely business insight is crucial to make informed business decisions. Reporting is a process of presenting, analyzing and transforming data to meaningful and actionable insight.
- Interface. No organization in the world runs SAP without system integration with their ERP systems. Interface exchanges data and seamlessly integrate transactional/master data between SAP ERP and external systems, ensuring rapid data flow and real-time data for business to make informed decisions.
- Conversion. Required to load mass transactional/master data to SAP ERP. Although used only in the system conversion process or large data recovery in the production system, data is center of all business operation in ERP and loading best quality data is a backbone of any business processes.
- Enhancement: ERP may fit for many organizations but is definitely not a one-size-fit-all. Enhancing SAP application process can improve business operations, adapting to the niche requirements of business, and enable competitive advantage against other organizations.
- Form: Invoice, contract, purchase order, delivery note, packing slip, etc. Forms are formal confirmation of certain business operations to either conclude that process or is a sign-off of the process to initiate a new one.
- Workflow. Business processes are not always straight line. Some processes requires business decisions and some processed require verification and approval.
SAP Accelerators + SAP Activate
To further support relevancy of RICEFW, SAP official document also states that meaning of RICEFW should not be used the same way and it goes beyond the classic extension framework.
- “Understanding the new technological options and how they map to the traditional RICEFWs is essential.” – “S4H_881 Custom Extensions in SAP S_4HANA Implementations – A Practical Guide for Senior IT Leadership.pdf“
- “Note that extensibility goes beyond the traditional topics of custom development of Workflows, Reports, Interfaces, Data Conversions, Enhancements, and Forms (WRICEF) objects.” – SAP Activate Project Management for SAP S/4HANA® and SAP S/4HANA® Cloud 2nd edition 2022
How about changing to process/solution based, and eliminating RICEFW?
Some argued that using ther term RICEFW at confuses business and whole SAP implementation project management. This maybe true if the audience only understand the system implementation on very high-level and often do not view the project on the deeper technical level. Of course, if you ONLY use RICEFW then only technical consultant and developer would understand and nobody from the project governance and functional counterpart would be able to track the custom solution implemented in SAP system(and often it’s the most important to make project management understand the custom solution as non technically as possible.).
Let’s take a look at below 3 types of backlog tracker for project management:
1. Too high-level
Requires deeper analysis and breakdown of required technical tasks.
| ID | Line of Business | Region | Scope Item | User story title | Responsible |
| 1 | Financial Accounting | EU | Profit Center | Profit Center hierarchy configuration | John A |
| 2 | Financial Accounting | EU | Profit Center | Adding profit Center hierarchy to G/L reporting | John B |
| 3 | Financial Accounting | EU | Journal Entry Verification | Adding organization specific check on journal entry posting | John C |
2. Too technical
Nobody would understand except technical consultant and developer.
| ID | Line of Business | User story title | Object type | Responsible |
| 1 | Financial Accounting | Manage Global Hierarchy Configuration | Manage Global Hierarchy Configuration | John A |
| 2 | Financial Accounting | Extension CDS view of C_xxxxx | Custom ABAP CDS view | John B |
| 3 | Financial Accounting | Create custom BADI from Fiori to check the journal posting | Custom BADI implementation | John C |
| 4 | Financial Accounting | Create Workflow process to request approval | Process with approval form in SAP Build Process Automation in BTP | John C |
3. High level business requirement + RICEFW
Description with high level business requirement + RICEFW boils down the requirement to more technical details. This way project management, business consultants as well as technical consultant and developer understand the custom solution scopes..
| ID | Line of Business | Scope Item | User story title | Story type | Responsible |
| 1 | Financial Accounting | Profit Center | Manage Global Hierarchy Configuration | master data configuration | John A |
| 2 | Financial Accounting | Profit Center | Adding profit Center hierarchy to G/L reporting. Extending standard Fiori app “View G/L account xxxx” | Report | John B |
| 3 | Financial Accounting | Journal Approval | Adding xxxxx check when journal entry is posted in Fiori app ‘XXXXX’ | Enhancement | John C |
| 4 | Financial Accounting | Journal Approval | Adding custom workflow to request approval for authorized user | Workflow | John C |
The takeaway from this section is that additional layer of RICEFW to the project management backlog will enhance the visibility of what are needed to implement in the system corresponding to each high level business requirement. In the time of RISE/GROW and S4/HANA Cloud, this principle will not change and it’s inseparable part of the SAP project methodology.
Mapping classic RICEFW to modern RICEFW
Having understood that 1. RICEFW is still inseparable to in SAP implementation project. 2. definition of each letter in RICEFW is defiantly not used the same way. What we need as the last step is to map the classic RICEFW technologies to the new one. SAP has published a very good overview in “Custom Extensions in SAP S/4HANA®
Implementations A Practical Guide for Senior IT Leadership“. Every organization should update their RECIEFW definition and establish a common understanding of new RICEFW with new extensibility frameworks. The document is from 2021 so the naming of technologies, especially the BTP services are obsolete. Please check the corresponding service names in SAP Discovery Center – Service Catalog.
Adapting to the new RICEFW
In addition, to adapt to the the modern extensibility frameworks, which extensibility method is used(In-App Extensibility, Developer Extensibility, Side-by-side extensibility) must be added from project management to track custom solution. This is because RICEFW solutions can be implemented in multiple systems.
Let’s say that we have S4 on-premise or private cloud. Reports can be implemented in both S/4 HANA core and in BTP WorkZone+CAP/RAP. For Interface, ABAP RAP based Odata service can be created in S/4 HANA system as well as an integration flow in BTP Integration Suite. For Conversion, you could be loading data into S/4 HANA or you could be loading the data to HANA Cloud service or ABAP Environment in BTP. You can picture that without specifying where to deploy/implement the custom solutions, there is no clear visibility to what is implemented in where.
So the project backlog file would look like this
| ID | Line of Business | Scope Item | User story title | Story type | Extensibility type | Responsible |
| 1 | Financial Accounting | Profit Center | Manage Global Hierarchy Configuration | master data configuration | N/A | John A |
| 2 | Financial Accounting | Profit Center | Adding profit Center hierarchy to G/L reporting. Extending standard Fiori app “View G/L account xxxx” | Report | Classic | John B |
| 3 | Financial Accounting | Journal Approval | Adding xxxxx check when journal entry is posted in Fiori app ‘XXXXX’ | Enhancement | In-App | John C |
| 4 | Financial Accounting | Journal Approval | Adding custom workflow to request approval for authorized user | Workflow | Side-by-side | John C |
What about AI?
After the redefinition and mapping to the new RICEFW, there is still one thing that it does not cover. Custom AI solutions. Ever since emergence AI, it has rapidly matured and has hit ERP industry. AI is used by developer, business user that operates daily in SAP systems, SAP project manager, consultants and include all persona working in the SAP system.
When we look at AI capabilities offered by SAP in term of extensibility, you can build and train own model in BTP AI core/AI launchpad and configure an out-of-box file data reader in Document Information Extractor. The custom AI solutions are so far only in BTP, but to adapt to this, perhaps an A(AI) should be added to RICEFW as RICEFW(A).
Conclusion
This blog is 100% based on my own research and experience and after rounds of discussion and thoughts, RICEFW somehow cannot seem to leave SAP ERP implementation projects. They are deeply ingrained in the history of SAP projects as well as the nature of SAP as an ERP system. Regardless of how many new extensibility methods are and will be introduced, as long as SAP ERP as core is served the same way, RICEFW or some kind of similar specification is required.
Obviously every SAP implementations project is different in the complexity and scope management strictness and client requirement so I want to make a disclaimer that this blog is not to state that using RICEFW is the only way. Projects can free to come up with new acronym or not use the acronym at all to and use high-level process/solution based approach.
This blog is a bottom-up approach to whether RICEFW is still relevant in the days of RISE/GLOW and S/4HANA Cloud and as I laid down all the facts and logic, the outcome of the argument is that RICEFW is still indeed relevant and only adjustment it requires is to redefine each RICEFW components with new frameworks + add RICEFW(A) to adapt to custom AI solutions in the SAP landscape.