To borrow from Dickens, last week in ABAP “it was the best of times, it was the worst of times”.

Let’s start with the worst. SAP ABAP Developer Edition got gone officially. This is extremely disappointing, especially for those who are stuck with old versions of ABAP at work. From what I see, this leaves ABAP enthusiasts with either very limited Cloud trial option (used in the openSAP classes, for example) or free-not-free systems in SAP CAL. I hope more information from SAP is forthcoming, ideally before TechEd.

On a more positive note, Devtoberfest is now in full swing and there are some interesting ABAP sessions. My recommendations so far:

• ABAP on Exercism? Demo and Presentation from Lars ‘The Legend’ Hvam. One might look at this and think “oh, hey, this looks like a replacement for ABAP Developer Edition!” and I wish it was that simple.
• Developer Extensibility and Business Events with RAP on SAP S/4HANA Cloud: ABAP RAP with Event Mesh, oh my!

There will be more coverage of Devtoberfest content in our next issue(s), stay tuned! JP

This story was originally published in Issue 25 of The Boring Enterprise Nerdletter.

Don’t miss our latest issue!

ZSAP is how we jokingly describe an SAP ERP system that has been customized up to eyeballs (“Z” is the prefix for custom objects). ZSAP crimes are typically blamed on the stubborn, “that’s how we’ve always done it” customers and clueless consultants. But there is another, unusual suspect: SAP SE.

To do stuff in SAP, customers must use standard functions/APIs: BAPIs, global classes, web APIs, etc. Sadly, these APIs are sometimes missing features or just plain don’t exist. SAP’s approach seems to be “we give you what we think you need and, if anything is missing, just enhance or create your own”. However, SAP notoriously underestimates the customer needs and then thousands of customers are creating the same Z-things. Examples? 14 years of editable SALV, the crusade for a Purchasing Organization API, missing associations in standard CDS views, and many more. 

While this might look like the perfect case for an open-source project, not all customers are open to open-source (no pun intended). It also raises the 1 million USD question of who would be responsible for maintenance of such software?

There ought to be a better way for SAP to identify what customers need and deliver it as standard functionality instead of becoming a ZSAP crime accomplice.

Don’t miss our latest issue!

Data mesh has been generating buzz as a “hot topic in enterprise software” and “more than just hype”. But what even is “data mesh”?

The term’s creator Zhamak Dehghani defines it as “socio-technological concept”. Her 2020 article describes 4 main principles that I think can be interpreted in simple terms with… a grilled cheese sandwich. Hear me out on this.

1) “Domain-oriented decentralized data ownership and architecture.” It makes sense for the bread data to be owned by the bakers and cheese data by the dairy folks. In the real world, this can be a tricky architecture and “ownership” of anything in big enterprises is a minefield.

2) “Data as a product”. Imagine ordering a grilled cheese sandwich and getting a loaf of bread and a hunk of cheese? But that’s exactly how data delivery works in many enterprises. Wouldn’t you prefer to get what you ordered?

3) “Self-serve data infrastructure as a platform” – since the self-order kiosks got installed at Panera Bread, I haven’t spoken to a single person there (an introvert’s dream!). Being self-sufficient is empowering.

4) “Federated computational governance” – there should be a general agreement on what a grilled cheese sandwich consists of. Not an easy task since many people are super passionate about their regional recipes. And governance is where projects go to die.

Overall, I think data mesh is an interesting concept that goes well with tomato soup… err… event-based and microservice architecture. It might not be for everyone but is worth considering.

Don’t miss our latest issue!

I can’t believe I’m late to this party. Fundamental Conference is an event “designed to highlight the best of front-end development and design in one place”. It’s brought to you by a team of SAP folks who work closely with Fundamental Library Styles, which works to bring Fiori’s look and feel to web apps from a multitude of UI frameworks (in reality, that means mostly Angular, React, and Vue these days – but the fundamentality of it means that it can extend to others as developers wish). As a developer, I deeply appreciate the work that is being done with those popular frameworks to make Fiori design mesh nicely with the functionality of their individual component systems.

Fundamental feels like a friendly place where designers and developers put their heads together to think about the future of design, front-end development, accessibility, and performance. If you visit the conference page you’ll see a link to their call for content, so make sure to submit hare-brained ideas. Their SAP blogs, Twitter, and YouTube let you learn quite a bit more, but the best place is really the documentation.

What I like most – perhaps because of my design blind spots as a developer – is the consistent up-frontness of accessibility. I am far too often blasting out web pages and mobile apps without even a second thought to accessibility. Making accessibility a first-class design concern makes the web a tool for everyone – and that most definitely those PO-approving biz apps.

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

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

If you look at the latest quarterly numbers for SAP and Salesforce, you’ll see that Salesforce ($7.72 billion) just edges past SAP (€7.517 billion, at pretty much 1:1 Euro to dollar) in revenue. If the name of the game is counting fat stacks of cash, Salesforce just moved ever-so-slightly into the lead.

Interesting to note that only $3 billion or so of SAP’s dollars are cloud revenue dollars. There is a TON of opportunity for both SAP and other players to mine that slowly shrinking space of large on-premises SAP installations, and on the flip side I imagine that SAP’s cloud ambitions are still only just getting started. Meanwhile, Salesforce lives entirely in the cloud and still puts up double-digit percentage growth numbers, so there’s no reason to think that train will derail anytime soon.

I’ve worked the majority of my career in the SAP world, but I (weirdly, maybe?) am not really a fanboy. It’s not that I don’t enjoy working with SAP solutions, it’s more that…I don’t have a dog in the fight over who dominates what enterprise software market. I just want to be there to do cool things that solve interesting problems. PM