Introduction: five tools, no ideal solution to get started
SAP provides several tools for managing and deploying services on its Business Technology Platform (BTP). Each has its strengths. None is truly designed to support a structured start on BTP.
The BTP Cockpit offers a comprehensive visual interface, but remains deeply manual. Each service has its own setup logic. Each system integration follows a different path. Users must master many BTP concepts to navigate effectively. And above all, the interface focuses on technical deployment without guiding on adjacent aspects: who should have access to what? Should this service be integrated with Cloud ALM? Is provisioning properly configured?
Boosters bring automation. They are multiplying and covering more and more use cases. But they are rigid: you deploy "as is", with no customization options. If the template doesn't exactly match your needs, you have to do everything manually. Conversely, if you want to use the booster as a base, it assumes you know what the booster actually does.
The BTP CLI allows you to automate BTP management through scripts. But it requires mastery of scripting and CLI syntax. For an organization starting on BTP, it's not the most accessible tool.
Terraform is the solution for those who want to industrialize their infrastructure as code. But again, you have to know Terraform, create specific scripts, and maintain this codebase. It's an investment that makes sense once you master the construction industry, not to get started.
The Cloud Automation Service is SAP's own automation tool, but it suffers from limitations in terms of user-friendliness and flexibility.
Beyond the tools themselves, a structural problem emerges: information is fragmented. SAP documentation is organized by service. If you want to deploy a service, you consult its documentation. If you want to integrate it with Cloud ALM, you go to the Cloud ALM documentation. If you don't know that this integration is possible or recommended, you simply won't do it.
For a team discovering BTP, whether from an SME or a subsidiary of a large group, this creates significant cognitive load: you need not only to know how to do things, but also what to do, and especially where to look. The first step is consequently high. Moreover, BTP never arrives as such; it comes through a middleware migration project to Integration Suite, SAC deployment, or as part of the transition to S/4HANA. In this context, we do our best to move the project forward.
The challenge of getting started: a matter of maturity, not size
Whether you are an SME or a subsidiary of a large group, starting with SAP BTP poses the same challenges: understanding a complex ecosystem, avoiding configuration errors that will follow you for years, structuring your environment from the start according to best practices.
But there's another observation: until now, only large organizations with mature and structured IT teams could afford the necessary rigor standards such as complete traceability of actions, formal approval workflows, centralized governance, or continuous auditing. For others, it was an inaccessible luxury, reserved for those with the resources to implement it.
Our approach: democratize this rigor. Make accessible to everyone, from day one on BTP, what was reserved for large accounts with dedicated teams. Not to infantilize, but to allow everyone to start on solid foundations, regardless of their maturity level on the platform.
Our approach: from field observations to specifications
Faced with these observations, we could have launched directly into the development of yet another tool. We have chosen a different path: to take a step back and first define rigorous specifications, based on experience in the field.
These specifications are not theoretical. It is the result of our accumulated experience at several levels:
- As internal BTP users, confronted daily with these tools
- As consultants, supporting clients in their implementations
- By auditing existing BTP systems, where we identified recurring gaps and systematically neglected improvements
This approach illustrates our Collaboration pillar: we don't build in an ivory tower. We define needs with those who experience the problems daily.
The tool we're designing must position itself as a supervisor above the BTP Cockpit, at the crossroads between the manual interface, automated boosters, scriptable CLI, and Terraform. The objective: take the best of each and make it accessible from the start, with a triple objective: support, structure, train.
- Support the start: Enable quick setup of a functional and well-structured BTP environment
- Guarantee rigour: Integrate governance, traceability and audit standards from the outset
- Promote skills development: Do not create dependency, but allow progressive learning
The tool is not designed for users to simply press a button without understanding. It's designed for users to do things right from the start, while progressively understanding what they're doing.
For an SME, the primary objective will be to quickly have something reliable and well-structured. Skill development will happen naturally, without pressure.
For a large group starting on BTP, the emphasis can be more on deep understanding, to then create their own templates and industrialize their practices.
In both cases, we apply our Human pillar: the tool adapts to the user's pace and needs, without infantilizing or overwhelming them.
Here are the four functional pillars that structure these specifications.
Pillar 1 - Operational support: simplify without hiding
The objective: Enable a user discovering BTP to deploy and maintain services autonomously, while understanding what they're doing.
Customizable deployment templates
Where SAP Boosters require a fixed deployment, we want to offer editable templates based on best practices.
A template is a succession of tasks: provisioning licenses, creating a service instance, configuring access, integrating with Cloud ALM, etc. These templates are the result of our field experience and embody the best practices we have identified.
User can:
- Use the template as is for a quick and structured deployment (like a Booster, but going further)
- Duplicate and customize the template to adapt it to its specific context
- Enable or disable task blocks according to their needs (for example, enable Cloud ALM integration or not)
This flexibility is crucial. Not all organizations have the same constraints. A template should be a smart starting point based on experience, not a cage.
For those who are maturing, the possibility of creating their own templates will allow them to industrialize their own best practices.
Multi-environment management (DEV / QA / PROD)
Most BTP services must be deployed across multiple environments: development, test, production. Technical configurations may differ (endpoints, access, quotas), but the structure remains similar.
We want the templates to allow you to deploy a complete environment at once, while automatically managing the specifics of each layer. In the same way that a developer does not code directly in production in an SAP system, the logic must be respected for BTP services.
Hybridization, automation, and manual guidance
Some tasks can be fully automated via BTP and Cloud Foundry APIs: provisioning, instance creation, role configuration. Others require manual intervention, either because they touch third-party systems (for example, SSO configuration on Azure side), or because they involve a business decision.
Our tool must not pretend to automate the impossible. It must be honest: automate what can be automated, and guide the user step-by-step for the rest. Each manual step is documented in context, at the moment it's needed.
Contextualized documentation and integrated learning
Rather than forcing users to juggle between five different SAP documentation sources, the tool integrates information at the right time, in the right context.
Each task in a template can include:
- The action to perform (automated or manual)
- Contextual documentation: links to relevant SAP documentation
- Explanation of why: not just "do this", but "why it's important"
The result:
- User doesn't just "click next"
- He see what's happening
- He understand why it's done this way
- He can go deeper if they wish
- He progressively builds competence
Deploying a service? You can see directly if a Cloud ALM integration is recommended, why it is recommended, and how to do it. You don't need to know that it exists or where to look for it.
This is our Human pillar in action: the tool adapts to the user, supports them, and allows them to learn at their own pace.
Pillar 2 - Proactive governance: structure and advise
The objective: Not only to simplify the existing system, but to help the user make the right decisions and structure their construction environment according to best practices from the start.
360° View of the BTP Account
The tool will have a complete view of the global account and all subaccounts. This view allows you to quickly identify:
- Suboptimal configurations (over-provisioned or under-utilized licenses)
- Potential security vulnerabilities (overly broad access, weak authentication)
- Services that are not integrated when they should be (e.g., systems not connected to Cloud ALM)
For someone just starting out, it's a safety net. For someone who inherits from an existing system, it's an instant audit.
Contextual recommendations
Rather than letting users discover by chance that a feature exists, the tool proactively suggests improvements. For example:
- "This service could be integrated with Cloud ALM for better monitoring"
- "Your authentication configuration could be strengthened with SSO"
- "You're currently using 80% of your quota, an increase may be necessary"
These recommendations are not raw technical alerts. They are contextualized, prioritized, and explained.
Support in good practices
When a user deploys a new service via a guided template, the tool explicitly asks them if they want certain integrations or recommended configurations. Rather than letting them ignore Cloud ALM because they don't know about it, the tool asks the question and, if accepted, executes the integration automatically.
This is a form of governance by design: best practices are integrated into the workflow, not added after the fact when it's too late.
Pillar 3 - Integrated technology watch: anticipate, not suffer
The objective: Relieve users of technology watch and enable them to anticipate evolutions of the SAP Cloud ecosystem.
Alerts on new features
SAP is constantly enriching BTP with new services, new integrations, new options. For an organization focused on its core business, keeping up with these changes is time-consuming and often impossible.
The tool must do it for them, and notify only relevant new features for the user's context.
Not a generic RSS feed of all SAP news. "This new service could replace your current configuration and save you time" or "This new feature meets a need you have expressed".
Service deprecation notifications
This is perhaps the most critical feature. SAP regularly deprecates services or versions. Discovering too late that a key component of your system is no longer supported can create a major blocking situation.
The tool must detect deprecated services in the user's configuration and alert early enough to allow a smooth migration. Even better: it must propose a migration path and, if possible, automate it via a template.
This feature alone can avoid major crises and justifies the investment in the tool.
Support in migration
When a change is necessary (migration to a new service, major update), the tool doesn't just notify. It supports: documentation, migration template, validated steps, feedback.
The user is not left alone facing an anxiety-inducing alert like "This service will be deprecated in 6 months, figure it out".
This is our Efficiency pillar: rather than reinventing the wheel for each migration, we capitalize on migrations already performed and provide proven paths.
Pillar 4 - Audit and traceability: ensure compliance and transparency
The objective: offer complete traceability of all actions performed on the BTP environment, to meet IT compliance and governance requirements. Democratize what was previously reserved for large structures.
Workflow Draft → Validation → Traced execution
Each modification to the BTP account should not be applied immediately. It first goes through a Draft state. This draft can be reviewed, modified, commented on. Once validated, it's transformed into tasks that will be executed.
Each executed task is traced:
- Who initiated the change?
- Who validated it?
- When was it applied?
- What was the state before and after?
This traceability is essential for internal audits, compliance audits (GDPR, ISO, etc.), and for understanding change history in case of problems.
For an SME, this brings a level of professionalism and control they could never have implemented otherwise.
For a large group, this meets the standard requirements of their IT governance.
Environment promotion with formal validation
A classic use case: a modification tested in development, validated in quality, must be applied in production. The tool should allow changes to be reapplied from one environment to another, through a formal validation process.
This feature drastically reduces production deployment errors and ensures that production exactly reflects what was validated upstream. While maintaining a complete trace of the DEV → QA → PROD pipeline.
Untracked modification detection (Drift Detection)
If a user directly changes the configuration in the BTP Cockpit, bypassing the tool, it creates a discrepancy between the expected state (defined in the templates) and the actual state.
The tool must be able to detect these drifts and warn. This helps maintain consistency between what is documented, what is approved, and what actually exists.
This is especially important when several people are working in the same environment, or during team transitions.
Configuration versioning
Each evolution of a subaccount's configuration must be versionable. This allows rolling back if necessary, comparing states at different times, and documenting infrastructure evolution.
For an audit, it's the ability to say, "Here's exactly what was in place on January 15, 2026, and here's why we made this change on February 3."
Use Case: deploy SAP Ariba Central Invoice Management with S/4HANA Cloud Public Edition
To make this specification more concrete, let's take the example of the deployment of SAP Ariba Central Invoice Management (CIM) connected to S/4HANA Cloud Public Edition. This is exactly the type of complex scenario that motivated the creation of our platform.
The reality: 96 pages of technical documentation and siloed tools
The official SAP guide for this deployment is 96 pages long. It covers the configuration of multiple interconnected systems: SAP BTP Cockpit, S/4HANA Cloud, Master Data Integration, Identity Authentication Service, Business Data Orchestration, and SAP Integration Suite.
Of course, SAP offers a guided workflow tool (CIAS) and a BTP Booster to try to simplify the operation. But in reality, automation remains fragmented: the Booster is limited to BTP and sometimes fails without a clear explanation, the CIAS is a separate tool, and many critical manual steps persist.
Even with standard SAP tools, deployment requires:
1. Prerequisites Activation and BTP Configuration
Ensure activation of Scope Items 4N6 (Invoice Processing) AND 5LE (Data Protection and Privacy)
Run the BTP Booster (and manually manage potential failures or timeouts).
Establish OpenID Connect trusts with Identity Authentication Service
2. Configuration of Multiple SAP Communication Arrangements
SAP_COM_0008 : Business Partner, Customer and Supplier Integration
SAP_COM_0091 : Business Partner Blocking Integration
SAP_COM_0516 : Central Invoice and Purchase Order Satellite Integration
SAP_COM_0659 : SAP Master Data Integration
SAP_COM_0594 : SAP Business Data Orchestration Integration
SAP_COM_0897 : User Interface Integration
SAP_COM_0179 : Accounting Master Data Integration (essentiel pour la comptabilité)
3. Hybrid Master Data Integration (Complex Architecture)
Master data doesn't pass through a single channel. Two separate flows must be configured:
Via SAP Master Data Integration (MDI): Create instances and configure Business Data Orchestration with distribution models (push and pull) for Business Partners, Cost Centers, Project Controlling Objects, and Exchange Rates.
Via SAP Integration Suite, managed gateway (ex-CIG): Manage the creation of a dedicated P-User account to specifically replicate Company codes, G/L accounts and Tax codes.
4. Certificate Management and Authentication
Download and upload client certificates
Configure OAuth 2.0 with mTLS (highly recommended by SAP over Basic Auth).
Manage service keys with clientid, clientsecret, certurl.
Required Knowledge:
SAP BTP architecture and Identity Provisioning.
Master Data Integration (MDI) et SAP Integration Suite (CIG).
SAP arrangements communication (logic of each scenario).
SSL/TLS and OAuth2 certificates.
Major risks:
Forgetting to activate Scope Item 5LE, blocking the rest of the process
Silent BTP Booster failure requiring clean cleanup (Booster Cleanup) before being able to restart
Forgetting CIG configuration (SAP_COM_0179), resulting in missing basic accounting data
Drift between DEV/QA/PROD environments.
Lack of consolidated traceability
With the expert tool
Our platform acts as a global supervisor, unifying what SAP has fragmented between the Cockpit, CIAS and Boosters.
1. Select the "Deploy SAP Ariba CIM + S/4HANA Cloud Public Edition" Template The template is based on the 96 pages of SAP documentation, but transforms them into an executable and centralized workflow.
2. Guided setup with validation
The tool asks the right questions in the right order:
Automated verification of the activation of Scope Items 4N6 and 5LE in S/4HANA.
Which environment? (DEV/QA/PROD)
Authentication: mTLS (recommended and configured by default).
Integrate Cloud ALM? (Yes, and here's why).
3. Automated workflow with hybrid tasks
Automated tasks (via API):
Reliable execution of the BTP configuration (Subaccounts, Entitlements, Instances).
Generation and exchange of mTLS certificates.
Creating all communication arrangements in S/4HANA (including the often forgotten SAP_COM_0179).
Setup of distribution models in Business Data Orchestration (including Exchange Rates)
Guided tasks (requiring manual intervention):
Step-by-step guidance for CIG P-User activation for accounting replication
IAS configuration if customer particularities.
4. Integrated Traceability and Governance
Every action is logged: who, when, what.
Draft mode: review before execution
Rollback capability if problem detected
5. Continuous Checks
The tool continuously checks:
mTLS certificate validity
Proper execution of replication jobs (MDI and CIG)
Drift detection (alert if manual change in BTP Cockpit).
6. Contextual documentation: the right information at the right time.
Rather than letting users search through 96 pages of PDF, the tool pushes the architectural explanation or official documentation exactly where it's relevant.
Example view of the "Deploy SAP Ariba CIM + S/4HANA Cloud Public Edition" Template:
Task 1: Create CIM subaccount in BTP → Auto-Run
📚 Documentation: "BTP Architecture for SAP Ariba CIM" (Link to SAP Help Portal)
Task 2: Configure Master Data Integration → Semi-Automatic
📚 Documentation: "Understanding MDI: Why Two Instances (S/4HANA + MDCS)?" (Link to SAP Best Practices)
Task 3: Create SAP_COM_0008 communication arrangement → Automatic with guidance
📚 Documentation: "Business Partner Integration: what data is replicated and why?" (Link to SAP Help)
Task 4: Configure mTLS certificates → Semi-automatic
📚 Documentation: "Why favor mTLS over Basic Auth for security?" (Link to SAP Security Guide)
Task 5: Setup Business Data Orchestration distribution models → Automatic
📚 Documentation: "Push vs Pull models: when to use each distribution type?" (Link to SAP MDI Documentation)
Conclusion: from a need to a platform
These specifications concern our first module, the one that gave birth to the platform idea. By exploring other areas of the SAP Cloud ecosystem, we identified similar issues: information fragmentation, complexity at entry, lack of integrated governance, absence of traceability.
Rather than developing a suite of isolated tools, we made the architectural choice of a unified platform. This approach allows us to share common features like audit, template concept, validation workflow system, technology watch, common landscape configuration, all while offering a single access point, designed as a hub in Fiori Launchpad format. Each module remains an application focused on a specific need, making it easier to get started.
This article deliberately focuses on this first module, the most mature in our thinking. Other modules are still at the idea stage and will be the subject of future articles when we begin working on them.
This blog format, from specifications to structuring, then unveiling, will become our common thread for documenting the evolution of each platform module.
By sharing our approach at the specification stage, we remain faithful to our Collaboration pillar. We don't deliver a finished product in secret. We build in a transparent way, by documenting our thinking, our choices, our learning.
Next step: AI as an economic accelerator
Developing such a platform with traditional methods would be economically unsustainable. Templates must be maintained at the pace of SAP evolutions. Recommendations must be contextualized. Documentation must be constantly up to date. Technology watch must be continuous.
This is where our second axis of experimentation comes in: using AI in software development.
In our next article, we'll share our AI evaluation protocol in an enterprise context: how do we test AI on the real development of our tools? What solutions are we evaluating to guarantee data sovereignty and protection of our intellectual property? How do we structure development so that AI is a lever for rigor and efficiency, not a dangerous shortcut?
The specifications have been established. The action begins.
To be continued...