Today, more and more customers are requesting our support in navigating the SAP Business Technology Platform (SAP BTP). Whenever I receive these requests, I’m reminded of my own first experiences with SAP BTP. Back then, I was overwhelmed by the vast possibilities this platform offers.

Diving into SAP BTP ignited a creative energy not only within our team but also among our customers. They are eager to harness this energy but often uncertain about where to begin and how to ensure sustainable developments.

These challenges resonate deeply with me because when I launched an internal community at Eviden to cultivate this innovative energy and set up a BTP demo, I faced similar obstacles too.

With our BTP demo, we aimed to create a multitude of demo scenarios to showcase to our customers. These scenarios predominantly support SAP’s Clean Core strategy. At Eviden, we offer an Advanced Preconfigured Solution (Eviden APS) to provide best practices and content for SAP S/4HANA systems. We began integrating elements of the Eviden APS into BTP, such as the Eviden Records Manager. We also started developing numerous other demo scenarios using the Integration Suite, SAP Build Process Automation, Kyma Runtime, and other services offered by SAP BTP.

But as the number of demos grew and more developers got involved, I encountered various challenges in managing BTP, which prompted me to think of solutions. Now, our customers face similar challenges.


Navigating the SAP BTP maze

Let me share the challenges we faced with our Eviden BTP demos, and how we overcame them. You might find them familiar too.

1. Aim to achieve full transparency.

After several months of working with SAP BTP and having numerous developers working on various scenarios, I lost track of what was currently running on BTP, in design, or development. I needed an overview of what was currently implemented and in what state every time I wanted to plan a knowledge exchange in our community or even create a presentation for our clients.

To achieve this, I created several apps where everyone with a scenario running on BTP must register the scenario, including all its components and their statuses. Now, I can easily browse this app to see what’s going on with our demo BTP.

2. Bring order to chaos by setting standards and guidelines.

Initially, developers had their own ideas on how to implement various scenarios. This led to another kind of chaos, as neither I nor anyone else could refer to a scenario just by the name of the implemented component. Moreover, the relationships between all implemented components and scenarios weren’t clear. Each developer’s innovative energy in starting new scenarios on BTP resulted in many applications and configurations that followed no visual guidance. We needed standards and guidelines.

So, when developing the apps to register scenarios implemented on BTP, I immediately saw the need to follow some SAP best practices for setting up BTP and enhance these with our internal real-life practices and guidelines. Within the community, we defined guidelines and naming conventions that everyone must follow when implementing a scenario on BTP. In an attempt to ensure consistency, corresponding information and documentation must be added to the registered scenarios and components in the above-mentioned apps for increased transparency.

3. Maximize efficiency by leveraging reusability across projects.

Once the first draft of my apps was ready and other developers registered their scenarios, I reviewed them. I noticed that many components or configurations seemed to serve the same purpose. Once the various scenarios were finally registered, I reached out to the responsible developers to check those components and configurations. Through this analysis, we realized that some components were redundant — a single implementation would suffice and could be reused by others.

We realized that we had done a lot of duplicate development initially. To avoid this in the future, we established a review process by an expert panel for new scenarios to be registered. Now, developers first register their scenarios and required components. This information must then be approved by the panel, which scans the provided documentation and compares it with existing implementations.

4. Taming the budget beast: Enhancing usage analytics

After nine months of more or less uncontrolled development on our community BTP, we exceeded our estimated budget significantly. As the apps to increase transparency were not yet available, it was challenging to identify the actual cost drivers broken down by implemented scenarios. The usage analytics tools provided by SAP BTP only offered an overview of the costs incurred in the past at the service- or subaccount level.

However, I wanted to discuss the status of certain scenarios and how costs could be saved with the developers in my team, and for that I would need to break down the costs by implemented scenarios. Currently, we are in the process of extending our transparency apps to include better drill-down capabilities for usage analysis and some budget planning options.

From lessons learned to customer success

In various discussions with customers, I discovered that they faced similar issues to what we did with our Eviden BTP community. A colleague and I then decided to compile our lessons into a solution that could be offered to our customers — Eviden’s SAP BTP Governance-as-a-Service offering, a governance toolkit for an  accelerated journey.


I’m eager to hear about your experiences too.

What challenges have you encountered in rolling out and governing your SAP Business Technology Platform?

Let’s connect and discuss how we can run your scenarios on SAP BTP seamlessly.

Take a look at how Eviden’s innovative approach to SAP BTP governance can streamline your cloud management, manage your resources efficiently and accelerate your SAP BTP journey.