Steampunk is going all-in

In Poker, going all-in can mean you’re really desperate. Or pretty confident that it’s the right thing to do. Judging by the spirit of optimism in our ABAP Platform dev teams, I don’t think we’re desperate, and here are some of the reasons why:

◉ The ABAP Platform unit has sort of rejuvenated. More than half of our employees have joined us during the past 4 years. ABAP is ready for the years to come.

◉ We feel we’re relevant. Our biggest issue now is to handle the growing demand of customers, partners, and internal stakeholders. Could be worse.

◉ We’ve invented Embedded Steampunk. In addition to running side-by-side on the SAP Business Technology Platform (BTP), the Steampunk dev model will now be offered for extensions directly within SAP S/4HANA as well, both in the Cloud and on-prem. Hence the pun: all-in. See below to learn more.

Read More: C_TAW12_750 Key Points

It’s been two years after our last blog post in August 2019. About time again to anticipate the questions you might have and, as always, honestly answer them (resisting the urge to get carried away, which is not easy this time, as you will see ;-).

I’m lost already. Could you give us a quick recap what this Steampunk thing is all about?

I’ve learned that roughly three quarters of the world’s business transactions touch an SAP System. Most of them are probably running on ABAP, and probably on-prem. You can argue about the length of the transition period, but there is little doubt that someday the software replacing today’s business transactions will run in the Cloud.

From my point of view, there are two risks for SAP. Number one, we can be too conservative and stick for too long with outdated concepts that are no longer required. And number two, we can be too radical and leave our current customers behind, or even worse, introduce technologies with a short half-life.

This is exactly why we have invented Steampunk (aka SAP BTP ABAP Environment) with a sharp focus: provide an ABAP Platform that is not only the benchmark for enterprise-readiness, as today, but is Cloud-ready as well (I prefer this term over Cloud-native). The main Steampunk properties are:

◉ a dedicated stable public interface between platform and solutions on top, ensuring upgrades without hiccups,

◉ an enterprise-ready environment for Cloud development, including a new ABAP language version and the ABAP RESTful Application Programming Model (RAP),

◉ a Cloud-ready runtime environment with BTP integration, standardized system updates and configuration, and automated operation,

◉ a Cloud transition path for our current customer base, carefully balancing between the two risks mentioned above.

Today, Steampunk is offered on BTP only, running side-by-side to the core ERP systems. With Embedded Steampunk, this will radically change. And this change will make the so-called clean core a lot cleaner. But let’s start with Steampunk on BTP first.

Steampunk reality check – what happened since your last blog post in Aug 2019, and what’s next?

There is still a lot to be done. We know. But it feels as if we’re on the right track, and what the teams have delivered during the past two years is simply amazing.

The prio 1 feature that was postponed in our last blog post has been delivered in 2020: support for multitenancy. This means a significant cost reduction for our partners who can now provide a SaaS solution to multiple customers within the same Steampunk system. For ABAP insiders: the Steampunk multitenancy architecture is based on the Client field and thus provides full isolation between consumers (tenants) with minimal costs per additional consumer. For real ABAP insiders: I think with this we have now implemented all theoretically possible multitenancy variants ;-).

Apart from that, Steampunk came with so many enhancements that I want to refer to Florian Wahl‘s release blog posts for all the details. An improved ABAP language optimized for the Cloud, more efficient support for developers, better tools for administrators, migration tools for ERP custom code, reuse services, or extensibility for partners are just a few of many.

And what are we currently working on? Well, this list is long, too. Cost savings by elastic scaling of application servers with Kubernetes, zero-downtime updates, a reduction of the minimum HANA memory size (30GB instead of 64GB), high availability and disaster recovery, more data centers and hyperscalers, to just name a few items. So, enough topics for future blog posts.

To me, the important message for now is that we have a powerful Cloud offering for all ABAP minded customers and partners, no matter the use case. Today, Steampunk on BTP is live in the following usage scenarios:

◉ customers extending their ERP applications side-by-side (clean core initiative)

◉ partners offering SaaS applications to their customers

◉ partners developing SAP Solutions Extensions for the SAP price list (e.g. Vistex)

◉ SAP products (e.g. Market Communications for Utilities, or SAP Master Data Governance, Cloud Edition)

◉ SAP’s own internal ERP extensions

Not enough? Well, we’re working on another one: Embedded Steampunk!

What is Embedded Steampunk? Embedded where? And why?

Steampunk is a great option for loosely coupled side-by-side extensions or for partners offering SaaS solutions written in ABAP. This is somewhat comparable to the solutions that were running side-by-side on NetWeaver. Let’s take a short trip back in time.

In the on-prem world, customers could adapt SAP software by modifying it, or by writing custom code that could make use of any SAP object (red in the drawing). There was no dedicated stable and public interface, and that was exactly the reason for annoying upgrade hiccups. With NetWeaver Standalone, it was at least possible to write loosely coupled extensions with a lifecycle separated from the ERP core.

The situation today looks like this (at least from the ABAP perspective, I’ll leave out our BTP Java and Node.js universes for simplicity).

Regarding the extension mechanism, nothing much changed on the on-prem side (bottom left). But in the Cloud, it is a must to only offer Cloud-ready extension mechanisms that survive upgrades without hiccups. For all loosely coupled ABAP scenarios, the solution is Steampunk on BTP (top right), with a stable public interface (green) between platform and layers above.

Extending the ERP core side-by-side is great for many use cases. But not for all of them. Think about custom code that needs to run close to the app that is being extended. Within the same context, calling local APIs, e.g., to avoid huge data replication, or to run within the same logical unit of work (database LUW). For these cases, S/4HANA Cloud so far only offers key-user extensibility (top left). A powerful mechanism that allows for field extensions or custom business logic but cannot be compared to the classic extension possibilities on developer level. And offering the on-prem extension style is of course not an option (not Cloud-ready, not upgrade-stable).

So here we finally go: Embedded Steampunk!

Internally, S/4HANA Cloud and Steampunk share the same ABAP Platform code line anyway (marked blue), with Steampunk being a kind of frontrunner for innovations. So, it is just a logical next step to embed the Steampunk development model directly into the S/4HANA Cloud stack. Custom extensions developed with Embedded Steampunk now have the same properties that made Steampunk Cloud-ready and upgrade-stable:

◉ Usage of stable public interfaces only

◉ No modifications of SAP code

◉ Restricted usage of the ABAP language and other technologies

◉ Restricted usage of system functionality

◉ Efficient development with RAP

Developing extensions with Embedded Steampunk using ADT (ABAP Development Tools) feels exactly like developing with Steampunk on BTP. With one important additional benefit: Embedded Steampunk extensions can not only call the more technical ABAP Platform interface (green), but also a local(!) public S/4 interface (orange) containing the business functionality (e.g., CDS views like I_Product, replacing direct access to table MARA, or RAP facades for the creation of purchase orders). In S/4HANA Cloud, the custom code itself is either an own app or service, or implemented via public extension points, using the well-known BADI technology.

If you are an ABAP developer and willing to familiarize yourself with RAP, with ADT instead of SE80, or with clean APIs instead of freestyle modifications, you will feel directly at home with Embedded Steampunk. You can use all the tools and processes you already know. And these are the same tools and processes thousands of developers are using each day at SAP.

Sounds good. Anything else planned?

Yes. Embedded Steampunk for S/4HANA on-prem!

S/4HANA on-prem still allows for classic extensions, shortening the migration path from the classic ERP world, but leaving the upgrade issues. With Embedded Steampunk in S/4HANA on-prem (bottom left below), we want to support the transformation of these systems to a cleaner core, with a stable public interface between SAP and extensions. Of course, we cannot enforce such a move overnight, due to the vast amount of classic custom code and missing public SAP APIs or extension points. That is why on-prem ABAP custom code can now set a flag telling the ABAP compiler whether to allow classic code or enforce strict Steampunk checks. On-prem S/4 customers thus have a free choice on ABAP class level: stay with the classic extension method or refactor it. Needless to say, refactoring makes the core cleaner step-by-step, reducing upgrade issues and preparing for a future move to the Cloud.

The Steampunk development environment is exactly the same in BTP, S/4HANA Cloud and S/4HANA on-prem. The local public S/4 business interface (orange) is currently created using the Cloud-first approach but will grow over time in S/4 on-prem as well.

From our point of view, Steampunk and Embedded Steampunk make the long transition period from on-prem to hybrid to Cloud a lot easier. And both fully support the clean core strategy.