In my previous blog post, I introduced the fourth element in our BEANS framework: No-Code/Low-Code tools. Today, we’ll look at the final piece to our BEANS puzzle: Services. Specifically, we’re talking about cloud services (i.e., platform-as-a-service (PaaS) services).

From IaaS to PaaS

For years, the running joke about cloud computing is that “there is no cloud; it’s just someone else’s computer”. While this is of course technically true, that line of thinking is highly dismissive of the value-add that you can attain when you work your way up the cloud service stack. For example, as you can see below, the PaaS layer provides a much higher level of abstraction for developers compared to a barebones server/VM.

For pro-code developers, the level of abstraction provided with PaaS services unlocks unprecedented efficiencies when it comes to app/extension development. To put this into perspective, consider the types of services Microsoft provides with their Azure PaaS that are depicted in the figure below. From lightweight and serverless app hosting environments to services related to integration, machine learning, mobile apps, and so forth, developers have everything they need to kickstart just about any project imaginable.

Innovating Around the Edges

Within the context of our BEANS methodology, PaaS services tend to represent the glue that interconnects our overall solutions. With APIs and low-code/no-code tools, we should be able to address as much as 80% of common business requirements. For more complex requirements that require pro-code development, we can fill in the gaps by creating additional apps, APIs, or workflow processes using PaaS services.

Here, it’s important to bear in mind that PaaS-based solutions can be highly complementary to low-code-based solutions. For example, with common identity management (e.g., Azure AD) and API management services, it’s possible to graft PaaS-based solutions directly into low-code solutions as custom connectors, etc. This concept is perfect for fusion teams where citizen developer types may be capable of building most of an app but might require a little help from a pro-code developer to smooth out some rough edges.

Leveling Up the SAP Development Stack

I once worked with a brilliant embedded systems engineer who swore to me that he could develop solutions faster in Assembler than I could in Java. Although we never had an opportunity to put this to the test, I’m quite confident that I would have won. Not because I’m smarter or a better developer mind you, but because the differences in the level of abstraction were so great that it really wasn’t a fair fight.

These days, I think SAP developers find themselves in a very similar situation. ABAP is truly a great and productive language in and of itself. However, it’s not heresy to say that there are many things that it doesn’t do so well. Honestly, this is true of just about any language/programming environment. So much so that it’s really not a contest of whether ABAP is better than any one particular language. Rather, it’s a contest of ABAP vs. the entire field of modern programming environments (e.g., .NET, Java, Python, Node.js, Go, Rust, and so forth).

Going a step further, it’s also a contest of SAP NetWeaver vs. the field. To put this into perspective, consider the figure below which maps legacy NetWeaver components against Azure-based services. If you’re more of an SAP BTP, AWS, or GCP afficionado, you could perform a similar exercise in those environments. The point is that we have much more modern and flexible tools to work with in the cloud — tools that will make developers significantly more productive.

The Other Side

As we wrap up this blog series, I think it’s important to revisit that status quo of RICEFW conversation we covered in our original post. Our purpose for adopting the BEANS methodology was about way more than coming up with a clever acronym — we wanted to put a model in place that would help our customers achieve more.

One way we can accomplish this is by leveraging low-code/no-code tools which allow us to build solutions faster/cheaper than ever before. And, if we do our job right, eventually empower customers to achieve more on their own with citizen developers and fusion teams.

Beyond the day-to-day though, we want to aim even higher. Apps are nice, but they’re still basically just forms over data. You know what’s even better than a nice shiny Fiori app? An automation or workflow that performs the task automatically so that a human being doesn't have to get involved.

With all the tools we’ve reviewed throughout the course of this blog series, I think it’s fair to say that we’re not lacking for tools. The challenge is in figuring out how to apply these technology innovations towards solving real-world business problems. Identifying these intersections in the wild isn’t easy; it takes time and resources to really get to the heart of the problem.

This is why the fusion team concept is so important. By freeing up pro-code developers to work on the hard stuff that most RICEFW projects never get around to, many of these high-concept items are finally within our collective reach. Technology aside, this is largely about budget allocation. The goal is to balance the budget in order to achieve more and leave room at the end for the value-add stuff that every SAP implementation project swears it will address as a day 2 or day 3 item (and never happens).

With re-imagined project budgets and pay-as-you-go consumption-based pricing models for cloud services, the cost/risk associated with trying to tackle innovation items is much more manageable. In the months ahead, we look forward to sharing some more real-world examples that demonstrate how customers are achieving more with BEANS.