Adopting SAP Application Extension Methodology

This lesson introduces the SAP Application Extension Methodology and describes the different phases of the methodology. From the evaluation of the extension use case to the evaluation of the extension technology to the definition of the target extension solution, a structured approach to the development and implementation of extensions is presented.

It is essential to develop an extension strategy for your company. The SAP Application Extension Methodology can support and guide you in this process. The SAP Application Extension Methodology provides customers and partners with a structured, technology-agnostic approach to defining a company-specific extension strategy. Applying this methodology ensures that all project participants use the same terminology and quickly reach a common understanding of the use case and the solution to be developed. You will gain an overview of possible technical extension blocks and will be able to make an informed decision about the future extension architecture of your organization. You can define an extension framework that serves as a guide for internal architects and developers.

The primary challenges organizations face that lead to the need of an application extension methodology are:

• Clean Core
• Cloud readiness
• Future-Proof Concepts

Let's take a closer look at these aforementioned challenges:

The SAP Application Extension Methodology is a three-phase cycle that is open to SAP and third party technologies. You can either apply the methodology to a specific use case (start with phase 1) or use it to define your extension strategy and governance (start with phase 2).

The Application Extension Methodology consists of three phases that will guide you through the whole process:

Firstly you access your extension use case. In this phase, you lay the foundation for any extension application use case based on the business context and requirements in a defined area. You'll understand your system context and create your extension application use case descriptions.

In this phase, the methodology introduces different terms and concepts like extension styles, extension tasks, and extension domains. You'll get an overview about various extension technologies that we call technical extension building blocks. These building blocks, in combination with the extension tasks, will help you translate business requirements into technical requirements.

Lastly based on the overall requirements and the technology mapping between extension tasks and building blocks in the previous phases, you can make an informed decision on the technical extension building blocks needed to create your target solution. With the help of various decision guidance assets, such as guidance papers and SAP Discovery Missions, you can further enhance your target solution.

Now that we've gotten an overview of the phases of the SAP Application Extensibility Methodology let's explore each of them in more detail.

The personas involved here are:

• Enterprise Architect
• Solution Architect
• Business User

1 Define System Context

Basic architecture assessment of the relevant systems and components as part of the extension project.

2. Define Business Context & Requirements

A brief description of the general business requirement and its scope for your use cases.

3. Define application Extension Use Case

Define a target scenario for solving your business requirement by creating a detailed description of the use cases.

ACME Corporation needs support in validating new business partners. Therefore, it purchases and uses a service offering from iCredible. John is an employee of iCredible. Every time a new business partner is added to ACME Corporation's SAP S/4HANA system, John wants to receive a notification. John could then check the details of the business partner.

John would check the registered office of the business partner and perform some background checks. As a next step, John would update the verification details. Once the details are verified, the business partner is activated in ACME Corporation's SAP S/4HANA system.

For more information on this phase please see: SAP Application Extension Methodology Phase 1

Let's take a look at a sample demonstrating how to apply the principles of phase 1:

ACME Corporation is implementing SAP S/4HANA along with SAP BTP and needs to engage in extension development. Some of their requirements are:

• Extensions must follow the clean core concept.
• Simple maintenance and use of standard software/services are preferred.
• Only internal employees of ACME Corporation are allowed to access the SAP S/4HANA system.

The Application Extension Use Case Description is the recommended way to make sure there's a common understanding of the business challenge at hand and is one of the main deliverables of phase 1. The use case description is divided into four rows: Actions, Application Logic, System, and Required Data. The rows are modeled in "scenes" (i.e., individual steps the execution of business processes) for a use case. The more detailed and extensive the scenes are modeled, the better for implementing the subsequent phases.

The following is the scene description as an activity diagram to better visualize the use case. The color coding of the components corresponds to the scenes.

1. Find Extension Styles

Framework of the overall technology for the creation of extensions and structural extension tasks. Extension styles can be categorized in the three-tier architecture model:

• Presentation layer
• Application layer
• Data layer

2. Define Extension Tasks

Describe a technology-agnostic extension task to solve a specific part of your extension use case description. Extension tasks can be categorized into extension styles.

3. Map the Extension Tasks to Technology

The extension technology mapping outlines the relationship between extension tasks and technical extension building blocks. Extension tasks can be implemented by using one or more technical extension building blocks. Technical extension building blocks can be categorized into extension domains such as core solution extension domain and side-by-side extension domain.

For more information on this phase please see: SAP Application Extension Methodology Phase 2

Let's continue with our example by looking at the ACME use case and apply the principles of phase 2. The activity diagram shows both extension styles (i.e., presentation tier, application tier, etc.) and extension tasks (i.e., "create custom ui", "add custom field to API", etc.). When looking at the diagram make note of the color scheme:

• Green: Represents scene 1
• Yellow: Represents scene 2
• Blue: Represents scene 3
• Red: Represents scene 4

Looking at the sample diagram you notice in scene 1 "P01: create new business partner in enhanced UI". That falls under the extension style "Presentation Tier" and extension task "Adapt standard UI". Also in scene 1 you see "A02: Extended Business Partner (with flag) API. This falls under the extension style "Business Logic Extension" and the extension task "Add Custom field to API". When performing the "Extension Technology Mapping" step in the SAP Application Extension Methodology P01 could be implemented by creating a key user extension and A02 could be implemented using RAP extensibility.

Looking at scene 2 (the components of which are running on SAP BTP) you will notice "A08: Receive event notification". This would fall under the extension style "Business Logic Extension" and extension task "Choose event broker technology". Also there is the "Partner Validation App" which contains several extension styles / extension tasks. One of them ("A04") is also extension style "Business Logic Extension" but is extension task "Create Application Logic". Similar to what we did with the SAP S/4HANA on-stack extensibility domain when performing extension technology mapping A08 could be implemented with SAP Event Mesh and A04 with a custom created CAP application.

1. Extension technology per extension task

For each extension task (from the previous phase), analyze and decide which technical extension building blocks are suitable.

2. Decision guidance assets

Use the decision guidance assets such as extensibility guides, SAP Discovery Center missions, use case patterns and reference architectures to select your technical extension building blocks.

3. Extension target solution

Develop a target solution for the extension, for example, in the form of a diagram. This is the preparation for your implementation.

A solution diagram is created after the technology mapping. Existing reference architectures that can be found in the Discovery Center can help with this.

An SAP BTP solution diagram is a visual representation that illustrates the architecture, components, and interactions within an SAP BTP-based solution. This diagram helps stakeholders understand how different elements of the SAP BTP ecosystem work together to achieve specific business objectives. Here are some key components and considerations typically included in an SAP BTP solution diagram:

• Data Sources and Targets:
  • SAP Systems: Such as SAP Cloud ERP, SAP ERP, SAP SuccessFactors, etc.
  • Non-SAP Systems: Databases, third-party applications, etc.
  • Data Lakes and Warehouses: For storing and processing large volumes of data
• Integration Layer:
  • SAP Integration Suite: For connecting various systems and applications
  • API Management: For exposing and managing APIs
  • Event Mesh: For real-time event-driven integration
• Runtime Environment:
  • SAP BTP ABAP Environment: For ABAP based applications
  • Cloud Foundry: For Node.js and JAVA based applications
  • Kyma: For container managed applications
• User Experience:
• SAP Fiori: For building modern, responsive user interfaces
• SAP Mobile Services: For developing and managing mobile applications

• For more information on this phase please see: SAP Application Extension Methodology Phase 3 and SAP BTP Reference Architectures
• and

This lesson offers an overview of existing sources of reference architectures. These can be used as a guideline for designing and implementing extensions to existing architectures.