CRM and CX Blogs by Members
Find insights on SAP customer relationship management and customer experience products in blog posts from community members. Post your own perspective today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Kinsbrunner
Active Contributor

The first wave of CRMs helped tidy up customer data and processes, but they didn't really make the customer experience much better. Nowadays, companies of all sizes are focusing on improving customers experience because it's been proven that happy customers are more likely to come back. If their experiences aren't memorable, they might choose a competitor next time.

Because of this, businesses are always brainstorming new ideas to make their products and services even better. But improving things like system stability and scalability is essential for these changes to work smoothly.

In the past, companies could tweak (through exits, BAdIs or, even by copying standard objects) their SAP systems however they wanted because they were usually kept in their own data centers. But things changed when SAP shifted to a cloud-based approach. Now, all Sales/Service Cloud customers share the same SAP baseline, so changes can't be handled any further as they were made in the past. That's where the Clean Core approach comes in—it's a new way of thinking about extending SAP's capabilities specifically for the cloud era.

Understanding the Clean Core Concept

Clean Core revolves around maintaining a clear separation between core functionalities and customizations, with the aim of achieving a modern, flexible, and cloud-compliant system. In the realm of SAP CX extensions, this translates to safeguarding the integrity of the core SAP CX products while allowing for tailored enhancements to meet specific business needs.

blog1_a.png

Think of it as organizing a toolbox where each tool serves for a unique purpose without clutter. Similarly, a Clean Core architecture ensures that the essential functionalities (for example, customer data management, order processing, or marketing automation) remain untouched by customizations. This not only ensures system stability but also facilitates seamless upgrades and future scalability.

Benefits of a Clean Core Approach

Embracing the Clean Core concept offers several advantages for businesses leveraging SAP CX extensions:

  1. Streamlined upgrades: By keeping customizations separate from the core SAP CX platform, businesses can streamline the upgrade process, minimizing downtime and reducing the risk of compatibility issues.
  2. Enhanced agility: A Clean Core architecture empowers businesses to respond quickly to changing market demands and customer expectations. With the ability to innovate without compromising system integrity, organizations can stay ahead in today's competitive landscape.
  3. Improved performance: Removing unnecessary customizations from the core SAP CX platform can lead to enhanced system performance, responsiveness, continuity and stability, resulting in a smoother customer experience.
  4. Simplifying the way of working: Promoting the fit-to-standard compliance with clean core modular innovation makes customers to use “out of the box” SAP solutions and add their additional capabilities at the desired pace.

Additionally, it could be pointed out the fact of making reduction in the TCO (Total Cost of Ownership) by using infrastructure and licenses in a much more efficient way.

Extensibility within Clean Core approach

Clean Core Extensibility is basically a way of extending SAP systems without messing with the core application. It's all about keeping your custom enhancements separate from the main SAP setup, so you can update your system without causing any issues. In simpler terms, when you add extra features or tweaks, they won't interfere with the basic functions of SAP that keep your business running smoothly.

For Sales and Service Cloud products, there are in-app (built-in) tools that help you customize things without getting too technical. But for more complex changes, you might need to consider side-by-side extensions. The In-App tools in v1 are mostly UI related. In terms of more complex extensions for v1, the way to go is through PDI development which has caused (to me) many issues. This PDI developments are introduced through a programming language called ABSL (ABAP Scripting Language) which, for being direct on my words, has nothing to do with ABAP and it is implemented through an SDK. Also, coding this has lots of restrictions in comparison to the coding we were used to develop those who have invested years with ABAP.

In v2, in-app extensibility is limited to fields and can't create full custom objects as possible in v1. So this could be solved by implementing a RAP or CAP solution in BTP and connecting it into the v2, for example, through a Mashup.

blog1_b.png

The concept of clean core extensibility can be distilledin this framework of best practices that a customer adopts when implementing SAP Sales/Service Cloud products:

  • Adopting a policy of zero modifications
  • Eliminating enhancements that are redundant to standard code and functionality and also eliminating copies of SAP objects
  • Using released APIs only ("upgrade-stable interfaces")
  • Leveraging the key user (in-app) extensibility to its full extent
  • Employing the capabilities and services offered by SAP BTP to build larger extension applications
  • Using SAP Integration Suite

Best Practices for Implementing a Clean Core

Implementing a Clean Core approach within SAP CX extensions requires careful planning and execution. Here are some best practices:

  1. Modularization: Break down complex functionalities into modular components, allowing for greater flexibility and easier maintenance.
  2. Encapsulation: Protect core functionalities from direct modification by encapsulating them within well-defined interfaces and abstraction layers.
  3. Version Control: Implement robust version control mechanisms to manage customizations effectively and track changes over time.

Real-World use cases

Over the past decade, I've worked on several projects implementing C4C (now known as Sales/Service Cloud v1) where I tackled various challenging requirements. Looking back, if I would face similar tasks now, regardless of whether it's a v1 or v2 product, I'd opt for a side-by-side extension approach.

For instance, on a Service Cloud project, a client needed a feature where a main ticket would automatically close once all its sub-tickets were marked as 'Closed'. Surprisingly, neither v1 nor v2 had this feature when I last checked.

My approach today (for v2) would involve setting up a trigger using an Autoflow, which activates whenever a sub-ticket is closed. This trigger would then call a service on SAP's Business Technology Platform (BTP), developed using CAP. This service would then check if all sub-tickets are closed and, if so, it would also close the main ticket.

Also, my approach today (for v1) would involve setting up a trigger using Workflow Rules, which calls a PDI action that ends up calling almost the same CAP development from BTP. Although logic would be the same, the only adjustment inside CAP would consist on calling different endpoints.

However, when I encountered this requirement previously, the solution we implemented was a bit different. We created a Workflow Rule triggered when a ticket reached 'Closed' status. This rule would then execute an action developed using PDI, which would check if all sub-tickets were closed and decide whether to close the main ticket. This approach could have been tweaked by integrating the Workflow Rule directly into the PDI solution, triggered by an AfterSave event.

Closing comments

One of the big challenges we face is figuring out how to transition the army of tech experts who've been immersed in SAP CRM technologies like WebUI, BOL, and GenIL for decades into SAP CAP/RAP developers. This is the challenge that really gets me thinking and motivates me to take action.

I think the key lies in finding a balance between employees and employers. It's about consultants being proactive and open to learning new ways of doing things, while companies need to step up and offer opportunities for their teams to not just learn, but actually put their new skills into practice.

What do you think about this? Are you willing to jump into this new Era? Have you already done it? Do you agree with Clean Core principles? Have you already worked with this side-by-side context within SAP CX? I am interested to read your experiences, don't be shy!

2 Comments
Saurabh_Kabra
Participant

Hi @Kinsbrunner ,

I really liked your take on "...my approach today (for v1)... that ends up calling almost the same CAP development from BTP...". I need to start thinking more in that direction, rather than looking for some quick SDK fix 😊

From my personal point of view(and a little experience of working with some apps built on side-by-side manner with BTP), getting a feature built or changed in side-by-side manner via pro code or low-code is not as easy(and very risky) as it was in SDK/PDI. As the apps are built in microservice format on BTP, hence they require through testing before it is deployed in live environment. Also for "net new feature", building a custom BO in SDK took away quite a lot of effort on Analytics, OData/DWB, CodeListRestriction(CLR), Access concept etc. However, when doing such thing on BTP, we need to also build everything on our own like a simple CLR might not be as easy in CAP as it is today in CLR UI or defining the access concept based on Sales Org. Therefore, so far I face many challenge to get upto the speed on getting things delivered in side-by-side manner.

But as things stands today, I think that's the only way to stick around. 

Kinsbrunner
Active Contributor

Hi @Saurabh_Kabra,

I am glad to read that you liked my post!

Also, happy to see your interesting comments and would like to share my thoughts:

  • Regarding your first comment, I believe we all need to go through a mindset change and start thinking this kind of things more often as this is the only way to improve, become better and make happen those things that our customer want!
  • In terms of testing, CAP allows us to do local testing, as well as, writing tests (like here) so I personally do not see this as an issue. If we have to do a paralelism against v1 activities, we are not able to write tests and, apart from testing locally, you could deploy your PDI solution into an additional/paid QA tenant for testing purposes so, long story short, I believe that development within CAP brings us more alternatives.
  • I agree that when creating a custom BO through PDI, lot of effort was taken away by generating UIs automatically. I am not an expert within UIs when working with CAP but, can definitelly confirm that you could create a data model through RAP and then generate the UIs through wizards and/or annotations which makes as simple as with SDK but, from my perspective, easier to tweak.
  • What all my answers also demonstrate is that the skillset required in order to become a real "full stack" developer does not point to being able to handle frontend/backend but, instead, to be able to understanding when to use CAP or RAP and knowing each of its secrets.

Really liked your comments as they have made me think lots of scenarios and alternatives, thanks!