When discussing the extensibility options (e.g. of SAP S/4HANA Cloud, but also of other standard business software) you may hear the terms loosely and tightly coupled extensions. When you have a closer look, these terms have (at least) four different aspects:

1. Lifecycle: how is the lifecycle of the extension coupled to the lifecycle of the core
2. Data location and transactional processing: where is the data of the core application and the extension located how are the data processed in transactions
3. Stack (Hardware Resources, …): do core application and extension share the same runtime resources (hardware, operating system processes, …)
4. User and Access Management: do core application and extension share the same user and authorization context?

Unfortunately, in many discussions I was involved, it is not clearly specified which aspect the speaker deals with, or some arguments overemphasize one aspect while other aspects are simply ignored. Therefore, I think it is useful to describe the four aspects in detail in a small blog. For architects and senior consultants, it is important to understand if an extension shall by implemented loosely or tightly coupled in the one or other aspect.

1 Lifecycle

For tightly coupled extensions, the lifecycle of the extension is linked to the lifecycle of the core application. This means, when the core application is updated, the extension must be (a) tested and (b) adapted, if regressions are found. This process is time-consuming and prevents fast consumption of updates from the core application.

Loosely coupled extensions are lifecycle-stable, this means that the core application can be updated without mandatory adaptations and without day 1 impact. Lifecycle-stable extensibility requires:

• Modification-free extensibility: Objects can be extended in a modification-free way, in other words, extensions can be developed in technically separated objects, transported, and packaged separately.
• Clash-free extensibility: extensions must not clash with the core objects and/or extensions from other parties (partners, customer). To be clash-free, extension objects must have clash-free names (ensured e.g. by namespaces) and quotas for core and extension objects must be in places ensuring that technical limits are not exceeded.
• Extensions must be implemented based on lifecycle-stable APIs and extension points: This has two sides:
  • The core application is forced to guarantee stability of their APIs and extension points: This means that a release process for APIs and extension points and tools for “LM-stable” extensibility enablement (e.g. contract/compatibility checks) must be in place
  • The extending party is forced to use lifecycle-stable (released) extension points and APIs only, tools for implementing extensions must enforce this. Note that the release process for APIs and extension points will also include a process for deprecation and decommissioning. In the deprecation timeframe, APIs and extension points are still fully functional, but the extending party is warned and requested to change to a successor (e.g. a newer version) of the APIs and extension point. Once the deprecation time is over, the API or extension point will be no longer supported (in status decommissioned).

In SAP S/4HANA, side-by-side extensions, key user extensions, and – new – developer extensions (aka Embbedded Steampunk) are loosely coupled extensions in terms of the lifecycle. Classic extensions and modification are tightly coupled.

2 Data Location and Transactional Processing

The second aspect of tightly versus loosely coupled extensions covers data locality and transactional processing and consistency.

Tightly coupled extensions have a close integration with the core product:

• Data in custom tables and SAP tables are changed together: transactional consistency and ACID (atomicity, consistency, isolation, durability) principle can be achieved
• Data in custom tables and SAP tables are read together with high data volume (i.e. join of data can happen already in the database to ensure good performance)
• Data in SAP tables can be heavily read or written by custom application (e.g. custom list report) without performance penalty.

Loosely coupled extensions are stand-alone applications or new process steps along with occasional usage of core data. Data is read less frequently from the core product (few roundtrips) through an API, or data is replicated. Custom data is not changed together with core data (no transactional consistency required), the so-called BASE semantics (basically-available, soft-state, eventual consistency) is sufficient.

In SAP S/4HANA, side-by-side extensions are loosely coupled. Key user extensions and developer extensions (aka Embbedded Steampunk) are normally tightly coupled extensions in terms of data location and transaction processing. In principle, it is possible to create extensions in Embedded Steampunk loosely coupled, although the extension runs on the same SAP S/4HANA system, but I it is questionably, if there is a good use case for this.

3 Stack

The next aspect we want to discuss is the “stack”. Tightly coupled applications (in terms of stack) share the same runtime, this means they share the hardware and operating system processes. Quotas may limit the resource consumption of the extension, but this may be not achievable and/or may not be wanted.

Loosely coupled applications (in terms of stack) have different runtimes. This makes it easier to scale up resources for extensions that are only needed at peak times.

The stack/runtime decoupling is often also linked with the choice a different programming environment and language. For example, in SAP S/4HANA key user extensions and developer extensions (Embedded Steampunk) that run on the same stack, are written in the same language as the core (ABAP). In side-by-side extensions, developers have the freedom to user different languages (Java, Node.js). But this is not necessarily the case. Side-by-side extension on SAP BTP can also be developed in ABAP. (Side note: for some time periods. ABAP server supported also other languages such as JavaScript and Java on the same stack, but they are no longer available with SAP S/4HANA.)

4 Identity and Access Management

The last aspect of tightly and loosely coupled extensions is the identity and access management.

Tightly coupled extensions typically share the same user (identity) and authorization context. Maybe an example is helpful to make this clear: A user of the core application has a certain set of authorizations, for example for specific organizational units (for example for a sales organization, lets call it US-WEST). In a (in the IAM aspect) tightly coupled extension it is expected, that this user and authorization context is respected by the extension. This means in the extension the user should also have only access to data of this organizational unit.

Another aspect is that a tightly coupled extension feeds needly into the users “workplace” (in the case of SAP S/4 HANA: the users Fiori Launchpad) so that a user can access the extension from the same entry point as the core applications.

Criteria for (in the IAM aspect) loosely coupled extensions are:

• The extension is built for users that are not users of the core application: for example, an extension app that is built for external users of a company (prospects, bidders, candidates, interested parties, etc.) and the extension has access to the core application via a generic user.
• The extension brings its own authorization concepts and access the core via “privileged” access without any further user-dependent authority check in the core application.

In SAP S/4HANA, side-by-side extensions, key user extensions and developer extensions can be implemented either tightly or loosely coupled (regarding the IAM aspect).

5 Discussion: Combinations of the Four Aspects

Having discussed the four aspects of loose versus tight coupling, the question arises how the aspects can be combined.

The data location/transaction aspect is strongly related with the stack aspect. Typically, extensions will be loosely coupled in terms of data location/transaction and in terms of the stack, or vice versa. Although it is not impossible to think of a crosswise combination, it does not make much sense to me.

The lifecycle aspect is again independent of the aspects of data location/transaction and stack. With key user extensibility and developer extensibility, lifecycle-decoupling can be reached on the same stack. Using only released and stable APIs on a side-by-side extensions decouples the extension form the core in terms of the lifecycle.

On the other hands, if not released, not stable APIs are used in extensions (independent of the stack), the lifecycles of core and extension get tightly coupled.

Finally, I mentioned already that the IAM aspect is quite independent and can be combined with the other aspects in any combination.

I hope that this small discussion is helpful when you are pulled into a debate around loosely and tightly coupled extensions the next time.