It's worth considering what impact using the term RICEFW or FRICE has on actual SAP projects, and when forming personal impressions about SAP products for that matter.
Are there any benefits to under-estimating, over-simplifying, and under-mining development efforts which make up such a big piece of SAP projects -- by conveniently wrapping them up into this common term 'RICEFW'?
Through this blog, I ask you to think about whether we should even use 'RICEFW' or 'FRICE' at all?
For a good crash course on this acronym, Salai Sivaprakash has captured some helpful background about the term in this wiki.
The Problem with RICEFW
The issue lies in the letters. As with all acronyms, each letter represents a specific word or concept (in the case of RICEFW -- a development object).
I would contend that referring to all objects as 'RICEFW' often leads to development efforts being misconstrued or overlooked when implementing / upgrading SAP technology -- thereby leading to inefficient / ineffective object development.
What does RICEFW really stand for?
RICEFW stands for something very complex:
Each letter represents a critical component of most SAP projects.
Such a simple acronym reveals a world of complexity in terms of the possible tools and technologies to use. Furthermore, we now have so many choices for object development (each one having its associated pros and cons), given the capabilities of SAP's latest platform. This wasn't necessarily the case in the R/3 era or before.
See the below image, in which 'Interfaces' alone has 6+ different tools/options for development:
This image provides just a sample of tool choices for each object type. Every tool / approach has their own set of features & processes to work with -- so how can they be generalized so much by throwing around the acronym RICEFW just for the sake of convenience? (or perhaps ignorance??)
RICEFW stands for 6 completely separate object types:
When estimating development effort required or level of complexity in a solution approach using the term RICEFW, practitioners often overlook each object's importance and its independent significance within the whole development approach. So all the object types end up getting clumped together as 'RICEFW'.
Can Reports really be tacked in the same way (and with the same set of skills) as Interfaces? Not really. So then why are they so casually combined as part of the overall development effort?
Again, the term 'RICEFW' is to blame for generalizing the approach when developing these totally separate objects.
The impact of RICEFW on projects
This habitual use of RICEFW can have serious consequences on the way projects are carried out. It is all too common for project teams to under-estimate the effort involved in each object type by assembling them into of 1 not-so-simple acronym.
How RICEFW is ruining SAP implementations:
1) Under-mining the role of an ABAPer because he/she is deemed to be able to develop 'everything under the sun' when assigned to the vague term RICEFW. In fact, this terribly non-specific term actually deflates the ABAP SKILLSET. So individual or specialized ABAP skills are not really given their due importance when factoring and executing RICEFW object development, since it's treated as just one big animal.
2) Inhibiting the process of performing important ANALYSES that would determine the most suitable tools for each of these development objects.
3) Not completely satisfying the customer's requirement when the incorrect TOOLS end up being selected -- which likely results in way too many customizations / codes.
4) Diminishing the importance of INNOVATION in SAP. There's an unfortunate trend that not enough project teams take the time to select the right tools that are right for the requirements. This would suggest that SAP's efforts and money spent on introducing innovative tools and methods are not being effectively utilized.
The need to eliminate RICEFW
Some negative outcomes of using RICEFW:
1) Invites unnecessary customization. Since the correct tools are not selected according to development object type, it can lead to SAP getting a bad rap due to the negative impression that it creates for end users: "SAP is too complex and not user-friendly."
2) The ABAP skillset has become highly commoditized. Particularly in the context of RICEFW, specific ABAP skills around the relevant tools often get disregarded. It's like saying "Since RICEFW objects are in scope, we need an ABAPer" (therefore any ABAPer will do). It's a shame that ABAP developers generally get herded under the whole RICEFW umbrella, which really de-values what they bring to the table for actual SAP projects.
Possible solution...?
I would propose to either ban RICEFW altogether or start analyzing each 'letter' as a separate entity when planning SAP Projects.
And let's not forget that SAP has evolved a lot over the years and has introduced more innovative ways of implementing their software. So as SAP practitioners, it should be a challenge and goal (if not a responsibility) to assimilate those changes into the way we approach projects.
Spelling out RICEFW is a small step in that direction and ideally will lead to more clarity in project planning. We owe it to our customers and the developers in our current and future projects to give attention and due importance to the details behind this acronym.
6 Comments