- SAP Managed Tags
A slightly late Halloween blog this one, focusing on the haunting themes of RICEFW…
Way back in the dawning of current SAP history, when dinosaurs ruled the earth or at least old grey haired SAP consultants had their intros to SAP and the dawning of R/3, there started a concept of RICEF(W) objects. This was then latterly bundled into the ASAP methodology that later partly evolved to the Activate methodology. When I look around today, with what grey hair I have remaining, I still see clear signs across customers in Sweden (where I work) that RICEF is still very much alive and kicking. Then I even notice the term popping up occasionally in marketing and trainings from SAP.
This Halloween I encourage everyone to start the journey to finally put RICEF(W) to rest.
So lets look at what RICEF stood for again:
Reports: This originally is a GUI driven ABAP report, and latterly could then also include BW analytical reports, and then any kind of ABAP that could be executed from SA38 (etc).
Interfaces: This started out I think as flat file and IDOC based, and then morphed to include more modern technologies, web-proxies, ODATA and so as a concept is almost current (you could argue). But where does event driven technology fit into this picture I wonder. Is it an enhancement or an interface? (we often have borderline questions like this, and different teams can confusingly chose different answers in a large organization)
Conversions: Data conversions and then transformations
Enhancements: Mods, User Exits, Implicit and then Explicit enhancements.
Forms: Sap-Script then Smartforms, then Adobe PDF forms etc. (categorizing by print outputs is really old school!)
And W when used is for Workflows, which you could argue evolved to Build process automation.
But what really was RICEF(W)? Well we used it to catalog all of our custom development work in SAP. Back in the 2012s I have a photograph of all of my customers requirements in a large stack of documents, each of which represented a RICEF for our SAP implementation, it was our full RICEF Catalog. RICEF(W) to be fair has tried to morph over the years to fit with modern developments, but I still argue, it is not fit for how we should plan, design and build modern developments.
So today I frequently here the question: Should we still use RICEF(W). and my answer today is “Hell NO!”.
My reasoning is: RICEF(W) encourages our developers to develop like its 1999, a good thing for Prince fans perhaps, but for modern developers we really need to move on. Clean core is the direction that we must all travel, and to achieve this we need to very much adopt the SAP best practice, and that really does mean removing RICEF(W) and so we must adopt a new direction.
Modern development encourages a decoupled component based build, where software components interact and can be plug and play replaced by newer versions, where systems can be freely upgraded without having to investigate all the custom built extensions.
So what is the alternative to achieve this?
Well the really good news is that SAP have new methodologies and frameworks, that are here and ready made for the brave new world we find ourselves in. In particular for this question I would point everyone to the SAP Application Extension Methodology.
In the old days we would get a requirement, and spend about five minutes before deciding it was to be one (or more) RICEF(W) objects.
In the new world we throw this approach away and instead we are given a 3 phase cycle (that is open to SAP and 3rd party technologies) to follow. Here I will just describe at a high level, I highly recommend studying the SAP whitepaper here, which is an excellent document, and shows some concrete examples. I would also encourage everyone to try to dry run follow through this document for an extension that they either already have (needs to be a modern extension), or are about to build. This way you fully learn how to use this new methodology.
The 3 phases of the methodology
- Assess extension use case: The first being to really understand the use case, and the existing architectural context, and the business context. This means we are following a business first design approach, which then should result in us delivering something that actually meets the business needs (for our context).
- Asses extension technology: we assess the extension target solution, taking our use case(s) and defining the actions application logic, system, and required data for the extensions, we then separate this out to extension tasks. The extension tasks are placed in extension styles that are Presentation, Application, Data (Think: Model = Data; View = Presentation; Controller = Application). These extension tasks will be implemented by component building blocks in our solution.
- Define extension target solution: The third phase then takes these extension building blocks, and defines the extension target solution. This for me as a software engineer is where I start to see light bulbs flashing on. Now we are going to build our extensions in components (not necessarily in SAP), that are placed in one of 3 extension styles, and in the latest whitepaper this then also takes into account clean core classifications.
My current thinking then is that the old RICEFW is now replaced by an Application Extension catalog.
The catalog then could be represented as an equation, something like
AE01 (Application extension 01) = D01 + D02 (data extension building blocks) + A01 + A03 (Application extension building blocks) + P04 + P06 (presentation layer building blocks).
And we could then also have
AE03 = D02 + A03 + A05 + P04 + P07
An example of a Data extension could be the behavioral definition and implementation for say updating a customer master.
An example of an Application extension would be any necessary business logic implemented in SOLID designed classes
An example of the Presentation extension would be the Fiori UI or the API that we generate from our projection views and based on our annotations.
This means our future solutions now are essentially a lego brick construction comprised of Application extension building blocks. This then gives us the flexibility to build other Application extensions, and reuse some existing blocks again.
We then need to keep a catalog of building block equations to represent all of our Custom Application extensions, and ideally track their clean core scores. We also need to keep track of the testing statuses and versioning of all of these components.
This to me indicates the need for thoughts around how to keep track of status of these new solutions? Possibly some new tooling is needed here (possibly a good first usage of the methodology to design this). The various versioning of the components, and testing statuses in particular, then how to connect these to the business processes and business capabilities for the organization all needs to be managed. Not all these thoughts and questions have answers yet, but I think the journey to our future development work has started, and its time for everyone to get on board.
So this Halloween I encourage everyone developing SAP extensions, to really study the SAP custom extension methodology, and to then say RIP to RICEF(W).
SAP Application Extension Methodology Overview | SAP Help Portal
sap.application.extension.methodology.pdf
Footnote 1: RICEF(W) should only be used to keep track of our legacy solutions that are not built in this new world, that cannot morph to this new world, as quite simply, they are not clean core and not decoupled, and then also not MVC designed and built, and so we should aim to retire these as soon as we can, they represent our legacy design and code debt, our clean core journey is to move away from these so that we can fully leverage the modern solutions that SAP are providing for us.
Footnote 2: Last but not least I would really like to thank @HrishikeshMangi who has been the brains behind a lot of joining the dots behind how the application extension methodology is our and hopefully too your way forwards.
Footnote 3: apologies to SAP if in places I may have used slightly the wrong terminology (this often happens in my blogs).
Bluesky| User | Count |
|---|---|
| 12 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
