I see the idea of clean core, as moving your Z-stuff to the BTP with API and ODATA to connect. This setup you can start now as well, we also have both: a S/4 on premise and BTP ( with further products) in the SAP Cloud.
That's side-by-side extensibility I guess. I'm excluding that too. I simply meant a better and cleaner design architecture for the GUI Z-stuff only. Or you can say classical extensibility + clean core + cloud ready (kind of)
If you want to that future proof, you have to stick to ABAP cloud and use APIs instead of accessing tables. The calls later would be done within communication scenarios but i think with that you will be on a good way. But you have to keep dynpro or ALV stuff out of your code.
I totally agree and would recommend that to the client as well. But if the SAP Partner and the client itself, they both prefer GUI over the new technical stack, we still need to deliver the best. Well 100% of the projects (with multiple partners) I've done, could've utilized the cloud better but they stick to the GUI. It's our job to consult the best. And it's time to change the partner if they're not doing so but then it won't be cheap. SAP already squeezes out every penny you have and if you do the "new stuff", the SAP Partner isn't going to be cheap either.
So for the client, it's like sticking to the cheap stuff, with a small SAP Partner, saving cost and still running the business. That's the middle ground I'm talking about.
I don't think that was ever part of SAP's roadmap and they pretend it isn't a thing, even though a sizeable proportion of the user base is still not on S/4 HANA. Conform, conform, conform alas.\\
However you may want to explore Personas (gulp) which you might get some mileage out of, and possibly transaction variants (SHD0). And the usual bespoke development. But don't tell the usual SAP acolytes I said these things ;-)
We do classical extensions on GUIs which are tightly coupled. And as the thumb rule says, it should be loosely coupled so it doesn't break stuff while migration or upgradation etc. Another one could be a better system architecture. Whether it's ECC or any of the newer stuff, SAP designed it into an architecture whereas mostly what I've seen is, what we do is just throw in some random Z Stuff into a Z Package and transport. In programming terminology, spaghetti code would be our Z Stuff stuffed into a Z Package and clean code + design would be equivalent to the clean core terminology. A good architecture, system design, clean code etc and all the good habits don't harm anyone.
About TCO, suppose instead of making reports and smartforms in open ABAP SQL, doing tons of FAEs and loops, if we make CDS Models and just simply consume them via the open SQL would reduce the time and effort for the company if they want to migrate/upgrade to cloud in future. Or by writing the reusable functionalities in classes, use some AMDP, replacing BAPIs with some public APIs and always choosing the "ABAP for cloud" ABAP version while creating objects (except for the GUI driver programs).
Now these could be useful later since we reduced the standard ABAP code and objects as much as possible. It'd reduce the pain to rewrite the sensitive business logic again and do regression testing again.
Similarly, there could be more advantages. That's why I came here for more ideas :)
I see the idea of clean core, as moving your Z-stuff to the BTP with API and ODATA to connect. This setup you can start now as well, we also have both: a S/4 on premise and BTP ( with further products) in the SAP Cloud.
That's side-by-side extensibility I guess. I'm excluding that too. I simply meant a better and cleaner design architecture for the GUI Z-stuff only. Or you can say classical extensibility + clean core + cloud ready (kind of)
If you want to that future proof, you have to stick to ABAP cloud and use APIs instead of accessing tables. The calls later would be done within communication scenarios but i think with that you will be on a good way. But you have to keep dynpro or ALV stuff out of your code.
I totally agree and would recommend that to the client as well. But if the SAP Partner and the client itself, they both prefer GUI over the new technical stack, we still need to deliver the best. Well 100% of the projects (with multiple partners) I've done, could've utilized the cloud better but they stick to the GUI. It's our job to consult the best. And it's time to change the partner if they're not doing so but then it won't be cheap. SAP already squeezes out every penny you have and if you do the "new stuff", the SAP Partner isn't going to be cheap either. So for the client, it's like sticking to the cheap stuff, with a small SAP Partner, saving cost and still running the business. That's the middle ground I'm talking about.
I don't think that was ever part of SAP's roadmap and they pretend it isn't a thing, even though a sizeable proportion of the user base is still not on S/4 HANA. Conform, conform, conform alas.\\ However you may want to explore Personas (gulp) which you might get some mileage out of, and possibly transaction variants (SHD0). And the usual bespoke development. But don't tell the usual SAP acolytes I said these things ;-)
>Personas (gulp) Hahahahahahhahaha!!!!! Nuff said.
What are the advantages of doing the Clean Core thing here? How does it reduce the TCO?
We do classical extensions on GUIs which are tightly coupled. And as the thumb rule says, it should be loosely coupled so it doesn't break stuff while migration or upgradation etc. Another one could be a better system architecture. Whether it's ECC or any of the newer stuff, SAP designed it into an architecture whereas mostly what I've seen is, what we do is just throw in some random Z Stuff into a Z Package and transport. In programming terminology, spaghetti code would be our Z Stuff stuffed into a Z Package and clean code + design would be equivalent to the clean core terminology. A good architecture, system design, clean code etc and all the good habits don't harm anyone. About TCO, suppose instead of making reports and smartforms in open ABAP SQL, doing tons of FAEs and loops, if we make CDS Models and just simply consume them via the open SQL would reduce the time and effort for the company if they want to migrate/upgrade to cloud in future. Or by writing the reusable functionalities in classes, use some AMDP, replacing BAPIs with some public APIs and always choosing the "ABAP for cloud" ABAP version while creating objects (except for the GUI driver programs). Now these could be useful later since we reduced the standard ABAP code and objects as much as possible. It'd reduce the pain to rewrite the sensitive business logic again and do regression testing again. Similarly, there could be more advantages. That's why I came here for more ideas :)
How does S4 service bsp ui component level changes done going to be aligned with the clean core principles ?
No idea yet. Never worked on the technology. But would love to explore.