In my previous blog post, I introduced the second element in our BEANS framework: Extension Apps. Today, we’ll look at the lifeblood of extension apps and really anything we will look to build with BEANS: Application Programming Interfaces (or APIs).

The Importance of APIs

According to Wikipedia, an API is “…a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software”. Although this concept may seem obvious enough on paper, the reality is that few software vendors expend very many resources developing quality APIs. Instead, the focus is primarily on developing shiny apps that users will interact with firsthand — the kinds of apps that convince customers to buy more licenses.

Such a user-centric focus is not a bad thing in and of itself. Indeed, getting the UI right is extremely important since human beings are the #1 consumer of most any software product. However, in a perfect world, the functionality behind any human-facing UI would be driven by a series of APIs/interfaces that do all the heavy lifting on the backend. If that doesn’t happen, then the overall reach of the system/solution will be severely limited.

To put this concept into perspective, consider how much less powerful a search engine like Google would be if the only way to interact with it was through Google’s web UI as shown below.

By going the extra mile to define a series of well-defined search APIs, Google has extended the reach of their search services into a variety of areas that weren’t even on the map at the time Google first launched (e.g., smart phones, Google Home devices, etc.). With programmable APIs, Google has unlocked access to just about any device that can talk HTTP. For a company like Google, the (exponential) ROI on something like this is immeasurable.

The History of APIs and SAP

Over the years, SAP has always said all the right things about API development, but the execution has been shaky to the say the least. This started with the introduction of the Business Application Programming API (or BAPIs) in the early 1990s and continued with Enterprise Services as part of their enterprise service-oriented architecture (eSOA) play in the early 2000s. With the release of SAP Gateway and ever-increased support for OData in the 2010s, SAP continued a trend towards openness using modern RESTful architectures.

Despite these various initiatives, the overall level of API support within even the latest SAP S/4 HANA releases is limited. Although you can find many APIs on the SAP API Business Hub (https://api.sap.com), there are many parts of the system for which there are not defined APIs. Over time, SAP has pledged to continue to fill in those gaps with new releases, services supporting new Fiori apps, and so forth.

Nevertheless, the reality most SAP customers and partners face for the foreseeable future is that many of these gaps will have to be filled in through the development of custom interfaces using tools like SAP Gateway and the SAP Integration Suite.

Refactoring to APIs

Realistically, building up a broader API catalog is not something that happens overnight. However, as the Lao Tzu saying goes, “a journey of a thousand miles begins with a single step”. As part of our BEANS methodology, we recommend putting APIs at the center of any project you’re looking to take on within the SAP space. If there are existing APIs you can leverage for the project, great. Otherwise, we think you’ll find that it’s worth the time to build the APIs that you need up front. Over time, these investments will pay major dividends as your API catalog continues to expand.

To put this concept into perspective, imagine a scenario where a forecasting API is built on top of an SAP S/4 HANA system. Initially, this API might have been built to support a custom Fiori app. However, over time, this API can be consumed in a variety of different ways:

• A BI system might use this API to build a dashboard so that planners can visualize the forecast data in different ways.
• Another app developer might use the API to create an app for planners to tune forecast parameters and run through different simulations.
• An integration developer might use the API to replicate forecast data to/from a 3rd-party optimization system.

One thing to note here is that many of these consumer types might not be SAP-centric. A frequent argument we hear from ABAP developers is that building up full-scale REST APIs is overkill — that building a couple of reusable ABAP function modules or classes is “good enough”. We see this way of thinking as extremely short-sighted. Yes, building an OData service in SAP Gateway is more work, but it’s not that much more work. With tools like CDS, SADL and others, SAP has made pretty easy for developers to create OData services these days.

In his book Clean Code: A Handbook of Agile Software Craftsmanship, Robert Martin talks about applying the boy scout rule for software development: “Always leave the code cleaner than you found it”. We have applied a similar concept to our BEANS methodology: “Always leave the API catalog fuller than you found it”.

Closing Thoughts

At the end of the day, our goal with BEANS is to break down information silos and enable users and processes to run more efficiently. In that sense, APIs are at the core of any solution we build since they are the engine that makes everything go. Whether we’re building extension apps, developing BI solutions, or creating interfaces, it all starts with finding/provisioning APIs. Once we have the right APIs in place, we have all the tools we need to be successful.