In my previous blog post, I introduced the third element in our BEANS framework: APIs. Today, we’ll look at how these APIs can be quickly put to work by a much larger development audience using Low-Code or No-Code tools.

Why Low-Code / No-Code?

Although low-code/no-code platforms have skyrocketed in popularity of late, experienced SAP developers have been working with low-code tools for years. In the early days of SAP NetWeaver, you had Visual Composer (RIP) which bore many similarities to modern low-code platforms such as SAP AppGyver or Microsoft Power Apps. Going back even further, you could make an argument that the ABAP programming environment itself was low-code given its 4GL foundations and built-in ABAP Dictionary integration.

We’ll the let historians sort out which programming environments were “low-codier”. However, to answer the question of “why low-code / no-code”, we need to get past pro-code developer biases and take a closer look at development economics.

SAP Development Economics

Since this blog series is focused on SAP-based development, let’s consider the TCO of some common SAP solutions. We’ll start with a pretty typical request from the business: we need an app to perform a common business function (e.g., submitting and managing customer service orders). In this scenario, we’ll assume the business wants a web/mobile-friendly experience and doesn’t want to use any of the OOTB apps provided via the Fiori Apps library. So, we’re talking about building custom Fiori apps from the ground up.

If you’re familiar with Fiori app development concepts, then putting together the bill of materials for a solution like this isn’t particularly difficult. First, we’ll need an experienced ABAP developer that can develop OData services on SAP Gateway. This ABAP developer will need to know their way around a variety of modern(ish) technologies to accomplish this task: OOP with ABAP Objects, REST API design concepts, Core Data Services (CDS) to optimize lookups/queries, SADL to bind the CDS views, and so forth. Plus, from a functional perspective, they will need to understand concepts around SAP Customer Service (CS) and the related APIs (BAPIs). Although such developers can definitely be found, it can be difficult at times to find resources that are up-to-speed with these newer technologies.

In addition to our ABAP developer, we also need a web/UI developer that has experience working with JavaScript and SAP’s UI5 SDK. Although there are some SAP full-stack developers out there that know both ABAP and JavaScript, such resources are extremely rare. Fiori/UI5 specialists come a bit cheaper and are generally very good at what they do. However, since such resources usually don’t speak much SAPese, it’s crucial that we find that right ABAPer to pair them with.

Assuming we’re able to line up the right ABAP and UI5 developer resources, then our Fiori apps can probably be built out in about a month or two. So, we have the developers hand over their code, do a little bit of knowledge transfer, pay them for their services, and send them on their way, right? Well, if we happen to have a mature DevOps environment in place, maybe - but there’s still a question of on-going support. Does our in-house development team have the ability/time to maintain every aspect of this app? Plus, what happens when we accumulate many of these apps (both SAP and custom)?

The reality for most SAP customers is that ABAP developers are in short supply. For example, here in the U.S., the job site Zippia recently performed a study which estimated that there are approximately 8,500 ABAP developers within the U.S. Although the study did not look further at individual skillsets, our experience here at Bowdark has been that less than 1-in-10 ABAP developers has working knowledge of new-dimension SAP technologies like the ones present in SAP S/4 HANA.

For these reasons, and many others, business users are often floored by estimates that come back for what appear to be very basic requests. When a simple request to add a couple of custom fields to a form is estimated to take several weeks and cost more than $10K USD, the TCO of the solution has gotten way out of whack.

But this isn’t just a Fiori or new-dimension technology story; there are similar examples to be found up and down the entire SAP Business Suite. We’ve seen horror stories at some of our customers running modules built on specialty frameworks that aren’t widely known (e.g., BOPF, FPM, BRF+, and so forth). The same sort of issues apply with older modules of SAP that make heavy use of archaic frameworks such as SAPscript or classic Dynpro.

Giving Power Back to the Business

Economics aside, one of the major frustrations of business users is that they know exactly what they want — they just lack the tools/access to do the work themselves. If we zoom out and look at this problem at the enterprise level, it’s plain to see that most organizations have access to an army of citizen developers who are more than willing to help the IT team work through a never-ending backlog of change requests.

Historically, the challenge in all this has been finding that right balance between citizen developers and pro-code developers. As the technology landscape became more and more complex, IT naturally took more and more ownership of day-to-day tasks because, quite frankly, less experienced resources could cause some damage if not properly supervised.

When you get past the hype/novelty of many of these new low-code/no-code platforms, one of the more notable benefits that modern platforms bring to the table is a more secure, “on rails” experience to development. These environments have significantly lowered the barrier for entry for citizen developers while simultaneously reducing the risk(s) associated using with less-experienced developer types. Tactically, this allows SAP development organizations to stretch their limited ABAP resource pools by letting them focus on value-add tasks such as API-enablement as opposed to widespread RICEFW development tasks that crosscut a plethora of proprietary toolsets/frameworks that are oftentimes not well known.

The Low-Code Difference

Once we have the proper APIs in place, the business/IT can pull from a much larger pool of resources to build apps on top of these APIs. In our experience, such apps can be developed in less than 50% the time it would take for pro-code developers to build the apps from scratch (and that number’s pretty conservative). Add in the reduced TCO and you’re looking at a significant savings overall.

Of course, we’re not just limited to building web or mobile apps. For example, with Microsoft Power Automate, we can build complex workflows and automations on top of these SAP APIs. With Microsoft Power Pages and Power Virtual Agents, we can build self-service portal experiences that allow customers and partners to (securely) monitor the status of related requests. And, as we observed in my post on BI in this series, such APIs can also be used to enable business users to perform self-service analytics in tools like SAP Analytics Cloud or Microsoft Power BI.

Reducing the Time to Innovation

Here at Bowdark, our mission is to “develop thoughtful and creative software solutions that help our customers run their businesses more effectively”. In our mind, this is about way more than delivering super shiny apps (even if they are a technical marvel). After all, if these fancy apps are bookended by inefficient processes which slow the business down in other areas, then we’ve really failed the business.

In this new fusion team development paradigm that we live in, the stakes have changed. In order to enable the business to achieve more, we have to put the tools and resources in place for multidisciplinary teams to be more productive. From an IT/pro-code developer perspective, more than ever that means that we have to put developer egos aside and focus on the hard work it takes to empower the business to reduce its time to innovation — from building behind-the-scenes APIs to workflows/automations or even reusable UI components.

As the saying goes, “teamwork makes the dream work” and with low-code/no-code tools, teams finally have the tools they need to unlock productivity levels that can scale to meet the needs of the business.