API SmackDown: Round Two. BAPIs

Can we all just be friends?
Can we all just be friends?

After covering the “EDI vs API” controversy in the last issue, I didn’t expect to write about the APIs so soon. But this SAP Community post asking to “comment your views on using an API over IDOCs or BAPIs” made me think oh boy, here we go again. 

In common parlance, API means a piece of code that does certain thing(s). APIs typically have some input/output parameters but “what happens in API, stays in API”. One could think of an ATM machine as an API: we put our bank card in and get money out. What exactly happens inside the machine, we don’t know or even care.

In SAP, the earliest implementations of APIs were the function modules. And BAPIs (“business API”) are just a special type of function module. Later, global classes came around, then the SOAP / REST APIs. The latter are now commonly referred to as “APIs” and are exposed on SAP API Hub.

Based on the development context, the choice is obvious. If you’re building a web application or an external interface, then use the APIs. If for any reason it’s not feasible, then look for other options, which might include eventually using a BAPI (either via RFC or wrapped in an OData service). But if you are working “within SAP”, then web APIs are not going to be very helpful in ABAP code, wouldn’t they? So there is simply no scenario in which the thought “hmm, should I go with BAPI or API” would be relevant. JP

What’s The Deal With Agile?

Traditional product development methodologies rely on the “big bang” delivery process. Sadly, this tends to cause the “oh, hamburgers!” moments when it turns out that the customers don’t like what they got after waiting 6 months for the product.

Agile was supposed to solve that by working in iterations, to “fail fast”, get frequent feedback, and adjust. Wash, rinse, repeat. This is a great idea on paper but, as usual, reality ruins everything.

YouTube is full of the videos making fun of Agile, Agile is Dead talks, and even the Agile Manifesto creators “disowning” it. Twitter is full of posts like “you’re doing it wrong!”, “there are many flavors of Agile”, “Agile is waterfall with micromanagement”. So, is Agile a good or a bad thing and are you doing it “right”?

The article Agile / Scrum is a failure by Richi Jennings points the main problem that matches my own experience as well:

The Agile Manifesto paints an alluring picture. … The problem is, it’s almost always implemented in workplaces devoted to the bottom line, not to workers’ well-being[…]

[…]Taken to heart [it] means that anything larger than a developer can do in two weeks is infeasible. This often happens when the team building the software is not considered [as] stakeholders.

No wonder developers end up with “post traumatic scrum syndrome” when instead of creativity the process becomes all about the story points.

Main benefit of Agile is the product focus. When this is forgotten, the methodology doesn’t matter anymore. If your vision of “Agile” is a development sweatshop, then sorry, its failure is on you. JP

SAP Community Meets AI

Elevate User Experiences with AI-Powered Personalized Recommendation Service | SAP Community Call

No, this is not about a bot that prevents the monthly “extract Excel from ABAP” blog posts and redirects to ABAP2XLSX instead, sorry!

We’ve written about the SAP Community calls before (e.g. Event Mesh and SAP CAP). These are usually covering cutting-edgy subjects with less marketing speak and are very helpful. But lately I’ve not heard of any calls and was wondering what’s up.

Turns out that instead of visiting the SAP Community page, now we need to sign up for the upcoming calls on YouTube channel. Community calls are listed as ‘Upcoming live streams’ (look for the pink-orange background). The upcoming call on August 31st will be about AI-Powered Personalized Recommendation Service, which sounds pretty cool.

Continuing AI theme, there are also 2-minute videos about different SAP AI offerings. I find the Document Information Extraction service particularly interesting and recommend exploring it at your leisure. JP

Check out this issue for more!

Accounting For Developers

If you don’t get the joke, you definitely need to read this!

Enterprise software development is not just about algorithms and programming languages. It’s also about business processes. And for every enterprise, this means accounting. 

It’s always weird hearing the accountants talk. “Clearly, this chargeback goes to a revenue recognition account. – Indeed. But we need to offset tax liability for asset depreciation. – Quite!” I imagine that’s also how accountants feel when developers are discussing OData filters.

One does not need to go back to college though to learn just enough about accounting to understand that the dialog above is pure nonsense. Recent article Accounting for Developers explains accounting basics very clearly and is reasonably short for the volume of information it covers. I highly recommend it to all the SAP developers in particular. (As we know, all roads in SAP lead to FI.)

And for those partial to YT 10-minute video format (no judgment!), there is an excellent video Accounting Basics Explained Through a Story and more on Leila Gharani’s channel. JP

Check out this issue for more!


Just like Godzilla vs King Kong, EDI vs API battle is only imaginary

In a recent LinkedIn post, SAP integration expert Michal Krawczyk inquired what do others think about an EDI myth “APIs are better suited than EDI for small to medium enterprises”. As an IDoc book author, of course I have an opinion to share.

This is not really about the enterprise size. “EDI vs API” is not even apples vs oranges, it’s more like HTTP vs bananas. While both apples and oranges are fruit, EDI and API are different species.

EDI is a standard format for business information exchange. It signifies agreement between everyone involved that specific data would have specific format, place, and meaning. One might say that API kind of does the same thing (it tells you what data in what format it needs). But API is not a standard per se, while EDI has specific global standards. Also, API is more about the means of information exchange, it’s about functionality itself.

You can even use APIs, if you wish, to implement an interface based on an EDI standard (heck, you can even blend IDocs and APIs). So “EDI vs API” is just not the thing for any enterprise size. Myth busted! JP

Check out this issue for more!

Microservice Megadisasters

In the beginning, there was the big, bad monolith that did not want to change. Then along came Netflix and said let’s break the monolith apart into the small pieces. These pieces could then be put into the containers and shipped off to the Cloud to be easily scaled up or down, depending on the demand.

These Lego brick-like pieces called “microservices” and they are supposed to make it as easy to scale SAP systems as to open more cash registers at a supermarket. Except when not.

Turns out monolith is not necessarily bad and microservices are not always great. In this interview, the author of Monolith To Microservices book Sam Newman talks not just about how to break up a monolith but also when you probably shouldn’t. This quote could not have been truer in the SAP world that is sometimes too tech-obsessed after being tech-starved:

We focus on the tech tool, not the thing that the tech tool lets you do.

When considering microservices for your next project, think what they would “let you do” and if they’re the right solution in the first place. To avoid, you know, a megadisaster. JP

This story appears in Issue 20 of The Boring Enterprise Nerdletter

Psst, Want to Influence SAP?

It takes 10 votes for a request to be accepted, so we’ll need a bigger car

Discovering that there is a place to submit ABAP improvement requests to SAP feels like stumbling upon a magical portal accidentally left open by a scatter-minded wizard.

I certainly hope though that the Influence Opportunity “SAP BTP ABAP Environment” (the official name) will not just disappear. It runs continuously, i.e. there is no specific deadline for the request submission, and is accepting new requests for anything ABAP related. Don’t let the BTP nomenclature scare you, there is an option to enter requests even for classic ABAP.

If you have any improvement suggestions for ABAP or development tools, go to this page (registration required), click Submit Improvement, and influence away. While there, check out the existing improvements too and vote (see some of my recommendations). But shsh, don’t tell anyone I sent you! JP

This story appears in Issue 20 of The Boring Enterprise Nerdletter

Of Bulls And Bears

The article Of Bulls And Bears (Von Bullen und Bären) by Peter Hill is written with German precision, brutal honesty, and trademark humor (so subtle that you don’t recognize a joke until it suddenly hits you 3 sentences later). This expose talks about the different types of SAP customers:

  • the “powerful and well organized” bulls, large global corporations that run a tight ship;
  • the bears that “roar – and lose sight of the project”.

Peter’s description of the bears is chillingly accurate:

[…]those corporations that – out of sheer company politics and preoccupation with themselves – often lose sight of the real work on the necessary changes. Huge sums of money are sometimes spent just to end up with fewer functions and automations than before.

I bet every seasoned SAP consultant has encountered those projects where whoever screams the loudest gets their way, even if it adds no value for the business at large. Yikes.

Peter also offers solid advice for the consultants. The bull “can be tamed with a lot of patience and brain power” and the bear, “requires a thick skin and a lot of caution”. Power up your trusted translator and read the article in its entirety to avoid getting mauled on your next SAP project! JP

Check out more from this issue!

Got My Mind On My Product, And My Product On My Mind

Typical project NOT involving any product-minded developers

Many IT projects are poisoned by the “give us all the detailed requirements and we will build exactly that, whether it makes sense or not” mindset. The antidote is the product-minded developer (or engineer). As Gergely Orosz describes them, they want:

[…]to understand why decisions are made, how people use the product, and love to be involved in making product decisions.

Gergely Orosz, “The Product-Minded Software Engineer”

In the SAP world, product-mindedness comes with some special challenges because SAP standard is part of our product. Typically, SAP developers need to work with it to avoid another ZSAP or work against it to implement something the business users really need but SAP just doesn’t deliver. I think curiosity and not being afraid to ask “why?” is the key to not confusing one with another.

Also, in too many projects SAP developers are separated from the consumers of their product farther than from Kevin Bacon. This is a sure way for your product to end up like the tire swing meme. Want to avoid that? Then hire, support, and promote the product-minded developers. And let them ask the right questions to the right people. JP

See more at this story’s original home.

20 Years a Developer

Historical photo of the first ABAP developer

Seasoned developers, like myself, tend to reminisce about the “old days” (about 5 years ago) and either admire or grumble about the progress made since. In his article How is computer programming different today than 20 years ago? ex-Microsofter Sedat Kapanoğlu makes interesting observations on how programming changed in the last two decades.

Some items on his list, such as garbage collection, won’t ring a bell to SAP developers, but I found many of his observations quite relevant:

  • “Language tooling is richer today.” Probably less so for SAP proprietary languages but still, just 10 years ago our choice of tooling was like in the famous Henry Ford quote, “any color as long as it’s black”.
  • “IDEs and the programming languages are getting more and more distant from each other.” But, of course, we are still having debates on how SAP GUI is better than Eclipse. Time to move on, folks.
  • “Unit testing has emerged as a hype and like every useful thing, its benefits were overestimated and it has inevitably turned into a religion.” This perfectly reflects my own POV on unit testing. Debating with its adepts is definitely as pointless as trying to talk someone out of their religion.

Bring on the angry letters! JP

Don’t miss our latest issue!