SAP Application Extension Methodology
The SAP Application Extension Methodology allows you to create a customer specific, organizational framework to guide solution architects for defining the right technology choices for an extension.
Simplify Extensions by a Systematic Extension Approach.
- Helps enterprise architects to shape their extension strategy
- Collection of typical extension styles and patterns
- Mapping to extension services (based on customer context)
- Architecture blueprints for extensions including decision criteria
- Open to SAP and Non-SAP integration technologies
- Target Group: Enterprise Architects / Technical Architects
Extensibility is essential for an Intelligent Enterprise
Extensibility is a key enabler for intelligent enterprises to ensure rapid and continuous innovation. SAP Application Extension Methodology complements SAP’s technology portfolio by a methodology that helps enterprise architects to shape their extension strategy. SAP Application Extension Methodology provides a holistic view on extension including different types of extension domains.
SAP Application Extension Methodology Cycle
Let’s start with a little bit more details of the SAP Application Extension Methodology:
| Term | Definition |
|---|---|
| Extension Domain | An Extension Domain describes the relation of an extension to it‘s Core Solution and it‘s level of dependency. An extension always belongs to an Extension Domain. Example: Side-By-Side, Cross-Domain or In-App |
| Application Pattern | An Application Pattern describes a combination of Platform Technologies. It can also be referred to as architecture that describes the different levels of an application. In case of integration being part of such a Pattern – these can be a way to map possible integration styles according to ISA-M. Different Application Patterns can implement the same programming model in different Extension Domains. Example: Key-User Extensibility S/4HANA, Full Stack Application Side-by-Side on S/4HANA custom APIs or Native Mobile App. |
| Operation Concept | Each Extension that is implementing an Application Pattern has certain requirements towards it‘s operations. E.g. used services an technologies need to have ownership within an organization. Also there might be requirements for global/local teams enabling necessary SLAs, etc. |
| Platform Technology | The main goal of SAP AEM is to identify the Platform Technologies to be used for implementing extensions. Different Solutions, Systems or Platforms offer certain Frameworks and technologies that can be used to implement extensions. These different technical capabilities are referred to as Platform Technologies in SAP AEM. |
| Key Criteria | To be able to identify a suitable Platform Technology for a set of requirements, it is necessary to characterize each Platform Technology which is achieved by using Key Criteria. These Criteria are properties of a technology that can later be mapped to requirements which can be assessed with Questionnaires. |
| Decision Matrix | To be able to easier map requirements to Platform Technologies and its Criteria, a Decision Matrix is used. Such Decision Matrix can either be best practices summarized by SAP or can be customer specific findings including non-SAP technologies. |
| Extension Task | What are the things that I need to do for implementing the requirements of my extension use case. |
High-Level Assessment of Your Extension Architecture
| List of Core Solutions | |||||||
|---|---|---|---|---|---|---|---|
| ID | Core Solution Type | Version | SID (host) | Owner | Solution Lifecycle | Deployment | |
| As Is | To Be | ||||||
| 01 | SAP ECC | 6.0 Ehp 7 | PR3 | Max Mustermann | To be replaced during S/4 conversion; redesign required | Customer data center in Frankfurt | Hyperscaler (in context of S/4 conversion) |
Extension Domains
Extension domains provide the entry point into SAP AEM and can be used as a “big picture” for extension. You can do an assessment of your extension architecture by selecting the extension domains that are relevant for your organization or that you might want to further evaluate. Next, you can list your current extension technologies / services and skills (As Is) and also derive your future target architecture (To Be). Extension domains are technology agnostic and can therefore also help in blueprinting a hybrid extension platform consisting of multiple extension services/technologies (SAP/Non-SAP). You could also remove extension domains that are not relevant in your organization.
Structure of a System-Landscape
High-Level Assessment of Your Extension Architecture
| Extension Domain | Relevance | Extension technologies and skills | |||
|---|---|---|---|---|---|
| Relevant | Not Relevant | Under Evaluation | As Is | To Be | |
| In-App Extension | |||||
| Side-by-side Extension | |||||
| Hybrid Extension | |||||
Extension Capabilities
Extension capabilities describe the focus of an extension towards the Core Solution: UI, process, business object-, business logic-, and data model extension. Each extension capability has specific characteristics and can be refined by extension tasks (see following slides). Extension capabilities are one of the key pillars of SAP AEM.
Five Fundamental Archetypes of Extension Capabilities
| UI Extension | User interface extensibility deals with surfacing field definitions in UIs. This can be done in either of two ways, by modifying existing user interfaces or by providing new ones. |
|---|---|
| Process Extension | Extend Core Solution by providing consumable events. Logic inside a business process step is not extended, but instead whole business process steps might be added, exchanged or rewired. |
| Business Object Extension | Custom business objects are more flexible and more complex to adapt than data models, UI and business logic. They require a combination of additional data models, additional business logic, and additional APIs. |
| Business Logic Extension | Business logic extensibility concerns extension within a business process step. Depending on the business requirements, such business logic can be executed asynchronously or synchronously. |
| Data Model Extension | Existing data models are often not sufficient to cover the individual business requirements. In almost every implementation project the standard data model is extended by fields and nodes |
Extension Tasks for UI Extension
As the UI is the central access point for end-users it is important that the UI screens fit the specific end-user’s needs. That includes the option to build custom UIs on top of the existing backend functionality. But if the existing UI mostly fits the use case, it is important to have upgrade stable extension mechanisms to avoid the additional maintenance efforts. That includes hiding irrelevant information, but also moving, combining or adding new information available in the standard backend functionality as well as via extensions (e.g., custom fields).
| ID | Extension Task | Description |
|---|---|---|
| UI1 | Extend Core Standard UI with Field | Display additional information in the standard UI |
| UI2 | Modify Standard UI | E.g. rearrange standard UI or mash-ups like integrate custom content as iFrames |
| UI3 | Create Custom UI | Create separate UIs as alternative to adapting existing standard UIs |
| UI4 | Create Custom Form/ Template | Create a new custom email template or form template based on an existing data source |
Extension Tasks for Process Extension
As opposed to business logic extensibility, process extensibility concerns extensions on a more coarse-grained level. Logic inside a business process step is not extended, but instead whole business process steps might be added, exchanged or rewired through either extending and adapting standard integrations or rewiring services for innovative business processes.
| ID | Extension Task | Description |
|---|---|---|
| PE1 | Extend Core Process by consuming external event | External Events e.g. from SaaS solutions can be leveraged to extend core processes. |
| PE2 | Extend Core Process by consuming external API | External APIs e.g. cloud based services like machine learning can be leveraged in core solutions processes. |
| PE3 | Extend Core Process by additional SaaS solution integration | In a hybrid landscape, SaaS solutions are further extending the existing core process. Particular integration technologies are relevant for such scenarios. |
| PE4 | Extend Core Process by additional onPremise Solution Integration | Integrating core solutions with each other in order to extend a standard process of a single core solution requires particular integration technologies to realize. |
| PE5 | Extend Core Process by publishing consumable event | Especially to enable side-by-side extensions, the core solution needs to be capable of providing events that can be subscribed and consumed. |
| PE6 | Extend Core Process by publishing consumable API | Especially to enable side-by-side extensions, the core solution needs to be capable of providing APIs to integrated. |
| PE7 | Extend Core Process by workflow (human centric process) | Workflow Requirements can either be in scope of the core solution or can span multiple core solutions. This specific task needs to evaluate the different technical possibilities how to implement such requirements. |
| PE8 | Extend Core Process by business rules | To enable business users to enhance a process in the core solution, this can be achieved by business rules that allow de-coupling of rules from the application lifecycle. |
Extension Tasks for Business Object Extension
Business object extensibility is more flexible and more complex to adapt than Data Models, UI, and Business Logic - especially when implemented in the strategic side-by-side approach. Custom business objects require a combination of additional data models, additional business logic, and additional APIs. Can be mapped to "Develop your own custom application" from extensibility Explorer.
| ID | Extension Task | Description |
|---|---|---|
| BOE1 | Create Custom Business Object Data Model Layer | Creating custom objects (e.g. own tables) |
| BOE2 | Create Custom Business Object Business Logic Layer | Creating bigger parts of custom logic |
Extension Tasks for Business Logic Extension
Business logic extensibility concerns extension within a business process step. To adapt the Intelligent Enterprise to individual business needs, there are two ways to execute business logic, depending on the business requirements: asynchronous execution or synchronous execution in order to influence the control flow of the standard application.
| ID | Extension Task | Description |
|---|---|---|
| BLE1 | Add Custom Business Logic (asynchronous) | Asynchronous execution, e.g., either scheduled (batch) runs or on occurrence of a certain event to trigger subsequent process steps (e.g., send notifications, calculate KPIs, etc.). |
| BLE2 | Add Custom Business Logic (synchronous) | Synchronous execution in order to influence the control flow of the standard application (e.g., validation logic to check conditions before a binding sales quote is released to the customer). |
Extension Tasks for Data Model Extension
The data models of different solutions often represent either the same business entities or related business entities. Typically, a consistent extension of the related data models across different products in the landscape is required. This includes the consistent integration of the extension fields together with the standard parts of the data model.
| ID | Extension Task | Description |
|---|---|---|
| DME1 | Add Custom Field to Standard Object | Enhancing existing business objects of the core solution in order to store additional information. |
| DME2 | Creation of own application objects | Creating custom business objects including persistence to enhance the standard data model. |