Is the WRICEF term still appropriate in the days of SAP RISE?

[SergioFerrariIt]

In the last days fellow community member saptechengineer posted the stimulating blog Mapping ABAPer (WRICEF) into SAP BTP (Business Technology Platform).

It has awakened me to the feeling that the WRICEF term is outdated and, even worst, that it could introduce a strong inertia to modernizations and innovations at the time of SAP RISE.

As the blog itself demonstrates, there is a need to create a kind of mapping between types of development objects belonging to different historical eras.

Some story with the james.wood that posted the inspiring blog series Modernizing SAP: From RICEFW to BEANS — Part 1-6 (scroll down in the blog list of the author) describing his BEANS framework to better approach the topic. I like it !

Partha Goswami and James Wood did a great job but I believe it is intrinsically wrong trying to map  map as WRICEF several of the most promising SAP BTP services like RPA, Conversational AI, Intelligent Document Processing (IDP), SAP Work Zone digital workplace as well as SAP LaunchPad, Low-code/No-code web and mobile Apps that we can be created via SAP AppGyver or SAP Business Application Studio only to mention some. These are too far from the ABAP workbench taxonomy.

I see some pitfalls if during the RfP process or the Explore project phase WRICEF term is strictly adopt, and you?

In this blog post I am going to share first some background information and then the result of my analysis to the latest version of the SAP ACTIVATE methodology. We will see in detail if and how SAP ACTIVATE for SAP S/4HANA in RISE still positions the WRICEF term.

Important, we will review the crucial concept of the 5 golden roles. They are specifically assigned to the right project activities to help addressing innovations in alignment with the SAP strategy (e.g. keep core clean, low-code/no-code).

To strike while the iron is hot, sympathetically, I would like to launch the #no-wricef campaign to help innovation take-off. The nice is that we do not even need a replacement acronym indeed, IMHO, the acronym WRICEF could be definitively dropped in favor of a modern and harmonized requirement list for business gaps supporting a detailed harmonized taxonomy in the specific repository (e.g. spreadsheet columns).

We will accurately classify the target development option that will include:

• Key Users extensibility


• side-by-side extensibility in SAP BTP, SAP Fiori Launchpad, SAP Process Automation, iRPA, Low-code/No-code


• in-platform SAP S/4HANA extensions with its several powerful options like Migration-cockpit, Embedded Analytics, Flexible Workflow, CDS only to mention few.

Some background information

Collecting GAPS (business requirements not covered by the standard) in the WRICEF list is a practice incredibly ingrained in the SAP ecosystem (here the definition from SAPopenings What is RICEFW in SAP Terminology? and in SAPTutorials Quick Tips To Mastering RICEFW In 2022  ).

If I remember well WRICEF list was introduced by the ASAP methodology and it perfectly mapped the capabilities of the dear old ABAP Workbench (R4.7).

It was a geological era ago, well before BSP, Web Dynpro, SOA, SAP NetWeaver, SAP Portal, Guided Procedures, Visual Composer, SAP BW, SAP XI and many other innovative solutions.

The topic had a deep discussion already around 10 years ago in the blog Don't hold your SAP Custom Development to ransom by 6b8e090ba50d45ec894fcae83b2f8a4a. We can see very interesting comments by valuable community superstars like john.moy3, dj.adams, jocelyn.dart and many others.

In the last 10 years, WRICEF survived to SAP HANA, SAP BusinessObjects, Sybase Unwired Platforms, SAP Cloud Platform and several other innovative platforms and solutions.

All of us, found a way to map new architectural opportunities to the old acronym.

WRICEF at the time of SAP RISE

Ten years later, I would like to re-open the discussion analyzing the impact of SAP RISE for S/4HANA and the included SAP BTP credits.

Leveraging SAP solutions, the intelligent Enterprises can now benefit from Artificial Intelligence and Conversational AI, Intelligent Robotic Process Automation, no-code/low-code platforms as well as infinite SAP S/4HANA extension options.

As per the blog post from PARTHA GOSWAMI, we are trying to extend the initial meaning to include some of the cloud native modern services offered by SAP BTP:

• Workflow to include SAP Process Automation Workflow


• Reports to include Embedded Analytics Query, CDS views, SAP Cloud Analytics, SAP HANA, SAP Data Warehouse Cloud


• Interfaces to include OData, APIs and the other capabilities of SAP Integration Suite


• Conversions to include Migration Cockpit and Selective Data Transition


• Enhancements to include a complete new world of development options including in-App extensibilities, side-by-side extensibility, Low-Code/No-Code and even RPAs


• Forms to include SAP Process Automation Workflow

SAP RISE, the time to innovate

IMHO, it is too much, and it is time to move on!

Let’s also remember that WRICEF is an SAP specific term and that no other solution on the market needed an acronym to describe in advance the taxonomy of the development backlog.

WRICEF was created for the ABAP workbench and misinterpretations can lead to:

• friction with the Clean Core concept - it is common to consider ABAP as the favorite/default option or even the only option. That is in contrast with the 5 Golden Rules of the SAP ACTIVATE methodology


• strong innovation inertia - Intelligent technologies are not well described by the WRICEF acronym and they risk to be not considered


• project estimations based on metrics strictly related WRICEF - several RfPs are still issued asking for estimation in terms of WRICEF objects number per realization complexity (S-M-L). On the market the metrics have been refined during last 20 years but I believe they are mostly still based on ABAP Workbench. Here a big step-forward is required to let innovation take-off


• miss the involvement of the Key-users that could fit some GAPS by themself with the In-App extensibility


• miss the involvement of the Citizen Developers that could fit some GAPS leveraging low-code/no-code platforms as well as Process Automation workflows and RPAs.

SAP ACTIVATE for RISE with SAP S/4HANA Cloud private edition

With focus on Custom Developments, I want now to share what I found about the topic in the fantastic latest version of the SAP ACTIVATE methodology and specifically in the SAP Activate Methodology for RISE with SAP S/4HANA Cloud, private edition.

First of all, let me congratulate the SAP ACTIVATE team for this valuable version that IMO is very well done and mostly coherent with the latest versions, options and solutions.

 

Searching for WRICEF in the roadmap viewer we (unfortunately) get 11 references.

WRICEF search results in SAP ACTIVATE

 

For example, in the Realize / Product Enhancements we have the following page Development of WRICEF Objects

 

The second search result links to the Accelerator Functional Specs (Public) (file S4H_201.zip)

Accelerator Functional Specs (Public) (file S4H_201.zip)

That as from the READ ME file are sticked to the ABAP Workbench ;-(

 

As last example, I include here one from the WBS Explore/Fit-to-Standard Workshop Validation/ ;-(

 

Golden Rules for Implementation of SAP S/4HANA Cloud

Accelerator S4H_552 How to Approach Fit-to-Standard Analysis and Design - Cloud.pptx introduces the Golden Rules where the fourth is “Ensure use of modern Extensibility technologies”.

SAP RISE Extensibility

IMHO one of the most relevant accelerator, is the Guidance on Extensibility for SAP S/4HANA Cloud, extended edition (Public) that cover the full range of options:

In-App extensions (also targeting Key-users)

All the types of In-App extensions are well mapped in the accelerator S4H_951 Enhancements using in-app extensions feature map.xlsx.

Low-code/No-code, RPA, Process Automation, Conversational AI (also targeting Citizen Developers)

I found a couple of accelerators related to SAP IRPA SAP RPA Installation Steps - Vol.1-Tenant and OP Components.pdf (SAP Customer) | SAP RPA Installation Steps - Vol.2-Pre-configured Content.pdf (SAP Customer) .

I did not found something related Conversational AI, Process Automation, AppGyver, SAP BAS.

WRICEF in SAP ACTIVATE

Finger pointing to what I consider critical.

Accelerator S4H_552 How to Approach Fit-to-Standard Analysis and Design - Cloud.pptx still refers to the WRICEF List

On slide 10 we have the link to the ancient file WRICEF Inventory Template .

Conclusions

Obviously I have developed my personal approach with templates and taxonomy to seamlessly manage In-App, side-by-side and S/4 classical extensions. Everyone can do it but, one day, I would be happy to see SAP ACTIVATE dropping the term WRICEF and addressing all the kind of integrations, extensions, developments and automations in a modern and harmonized way.

In the community spirit, it would be great to get some feedback from you and, in case, sustain the  the #no-wricef campaign using the hashtag in your favorite platform.

[janmusil]

Thank you sergio_ferrari for sharing your experience and view on the use of term WRICEF in SAP Activate. I don't think though that your article paints a full picture of what SAP Activate covers in terms of extensibility.

By focusing strictly on highlighting where Activate refers to "WRICEF", term that comes from legacy approaches for modifying code on ABAP stack with so called "classic" extensions you are missing the additions we have done over the years to guide our customers to leverage the capabilities of Business Technology Platform and modern extensibility techniques.

I invite you to dig little deeper into the methodology where we guide project teams to leverage modern extensibility techniques through APIs, additional guidance for use of AI, ML & RPA, and description of the extensibility techniques, including in-app extensibility options with field extensibility, etc. You will also note that we also embraced the broader term "Extensibility" in the work stream name (it's no longer call Developments) for exactly this reason, to help the ecosystem shift and embrace the modern technology in their implementations.

This is similar to the shift from traditional blueprinting from ASAP days towards fit/gap and finally to fit-to-standard which took some time to embrace (we are not fully there across all projects as many still use the fit/gap term, but I'm seeing stronger shift to fit-to-standard mindset in past few years). By providing some traditional templates and terminology for WRICEF we aim to serve our customers for situation where custom code in app makes perfect sense and is more efficient than developing application side-by-side. Consider it easing off the traditions and embracing the change and what's new in the technology.

I hope this provides some color and details that help you embrace Activate in your projects.

[SergioFerrariIt]

Hi Jan and thanks a lot for the comment.

Indeed I deep dived i to the latest sap activate version finding all you are mentioning and the 5 golden rules.

My humble suggestion would be to have a unique and homogeneous collection of gaps and extensions. Currently I still see the excel file to list wricef but none for side-by-side objects.

Same for some word document templates specific for wricef but none for side-by-side.

Thus, SAP ACTIVATE mentions all the options and provides the strategic guidelines but then address in different accelerators and tasks.

In any case, I got the opportunity to address an open discussion aiming to spread around the absolute value of the new SAP ACTIVATE for SAP S/4HANA and SAP RISE.

Thanks agains,

Sergio

[Jocelyn_Dart]

Hi Sergio, I am rather intrigued by this discussion and I agree it is one worth having. The term WRICEF came from projects in the 1990s and is definitely NOT relevant in the same way.  Particularly concepts such as Workflows, Forms, and even Reports have changed extensively - for example Reports are now covered by Analytics which are often mashed up with transactional apps.

The BEANS breakdown is interesting... a good attempt but I don't feel it's quite there yet.  I could make a case for putting creation of custom CDS Views under APIs, but some of the other categories are harder to reconcile. Also would you put configuration *and* adaptation under no-code/low-code ? Maybe...?

It would be helpful to see more thoughts here.

I do like the idea of a new framework for categorising the types of changes that need to be incorporated into a current day solution such as RISE (i.e. SAP BTP services + SAP S/4HANA + Cloud solutions)

Thanks for bringing this to our attention.

[SergioFerrariIt]

Thanks for the valuable feedback Jocelyn.

Regarding the invitation to share thoughts about configuration and adaptation I am tempted to push no-code/low-code but the topic is really rich of options and any summarization brings risks.

Taxonomy is an art or even dark magic.

I would try to simplify moving away from any acronym and embrace a generic term to indicate a list of Personalization, Extensions and Automations that will then be described in a specific sheet.

I think an important goal is to address responsibilities.

Suggesting a for classification to map Key-user Extensibility Low-code/No-code (AppGyver, BAS, Process Automation&RPA) will address to Key-users and Citizen Developers tasks the, potentially, can perform autonomously saving external costs and efforts.

Suggesting classifications for the other main services will also be very useful: for example for Analytics (e.g. Embedded or via SAC) Integrations (Integration Suite, API Manager, Open Connectors...), Migration Cockpit when the object is supported is also interesting, I believe.

Conversational AI, ML/AI models, should also be suggested, mapped and addressed.

We have, fortunately , hundreds of different technologies (even SAP Screen Personas Slipstream Engine and hopefully we should also clearly discourage the adoption of the obsoleted ones (e.g. SAP Console? SAPScript? Batch-input).

 

[Siarljp]

Really interesting topic, thanks for raising it. I coincidentally started looking into this today, as my organisation is using something that originally paralleled RICEFW - ours is RIDEPOS - I won't elaborate, suffice to say - yes its stone age (or more like relevant about 10-20 years ago). My main concern with the old Acronym is that it encourages developers to design and build like its 1999, and whilst I think Prince might approve, its not really what we need today. We need to break this mindset, and stop designing tightly coupled and highly dependent solutions. .

Then I found James Woods blogs, and I have to say that James ideas I think are pretty much on target with his BEANS proposal. Will they adapt to the way my organisations direction going into the future is the question? and how to achieve this. They certainly seem to parallel our high level objectives. It will be a journey that is for sure, but hopefully a fun and interesting one. We should be extending side by side, using PAAS and API based solutions, reducing our code footprint as much as we can and making full usage of the latest Business intelligence based solutions, some really good suggestions from James.

I also agree that this should be reflected and updated into SAPs own recommendations, lets all start thinking for the future and not stay stuck in the past.

[SergioFerrariIt]

Thanks for the nice comments Julian and also thanks for your contributions to SCN like How to keep the core clean, when the tool many customers used for that is no longer there in S/4?

I am happy that you found the topic interesting and I am completely with you about the fun journey we are going to enjoy for the next years.

#nowricef

 

[LuizSouza]

Amazing topic! I hope that more experts can share theirs opinion here! Thank you very much!

[wagener-mark]

I think especially for SAP Activate Methodology for RISE with SAP S/4HANA Cloud, private edition you can / or at least it should be possible, to cover all the needs with Cloud ALM, especially if you go for the greenfield approach.

CALM for implementation

There are some really good blog posts out there on how to best make use of Cloud ALM, also the Cloud ALM homepage is getting better and better, but would also be nice to see it more "integrated" in SAP Activate...

[Jelena]

My "expert opinion on the matter" was shared in this article with self-explanatory title. 🙂

[Sycntegral]

Being less validated member of the community 😉 I would suspect that from the technical perspective the author is absolutely correct. But since I completed both Solution Architect and Project Manager roles on multiple SAP S4HANA transformations I would point to ten matter of the project cost control using WRICEF terminology otherwise the budget will be out of any measurement and therefore the project will not be successful. Also SAP to Blair itself for mixing so many methodologies and technologies - this is not how the main customer base of the enterprise works. The sales cycle of the requirement and the system transformation might be almost the same. The project deliverables depicting the progress on the project and the budget burning rate should be used - so while SAP Solution Manager Focused Build made some attempts to integrate the solution and the project management altogether using requirements based delivery, this was abandoned due to ten SAP CRM UI sunset, while Cloud ALM is far aaay for the project management capabilities. Agile is great . CI/CD is awesome too - but the angle of the budget management for these innovations and alignment to the enterprise strategic roadmap of the organisations ro be enhanced to the modern level, otherwise SAP will remain with bunch of POCs and no successful organisation transformations. 

[rpscg]

I love being told how to document developments by a company that only documented about 3% of theirs in R/3.

[rpscg]

Building new solutions using only references to Steam Age materials.

It would probably have been more apt to rename WRICEF as "Steampunk" rather than stamp it on the newest ABAP flavour.