A Tale of Two ABAPs

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:

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!

Composable Enterprise

Composable Enterprise Manual

Composable ERP has been one of those topics everyone loves to talk about, but no one really knows how it is supposed to work. In their usual “hold my beer” fashion, SAP marketing is now also talking about composable enterprise:

Composable enterprise from an organizational perspective means you can recompose processes dynamically and rearrange based on interchangeable building blocks when needed, without specialist knowledge or a developer[…].

Sweet! There is just, excuse my German, “einen kleinen problemo” (and that’s aside from the actual “blocks” and “composition” parts): data.

As the creators of the Master Data Governance (MDG) solution, SAP must realize that making sure that product X or customer Y mean the same thing across the enterprise is important. “Composable enterprise” will just exacerbate this issue, won’t it? What would be the solution? More MDG, more cowbell? You can get any type of “composable enterprise”, as long as it’s composed of SAP products?

Just like in the case of microservices, I suspect “composableish” might be the best one could get. But that probably won’t stop SAP from talking our ears off about the composable enterprise at the upcoming TechEd. Brace yourselves, folks. JP

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

Don’t miss our latest issue!

What do we want? Data from SAP Tables!

When do we want it? Preferably by the end of fiscal year

“How do I just get the data from SAP tables [and dump it into a spreadsheet]”? Questions like this have been regularly popping up on SAP Community and now other media since time immemorial.

No matter how many dazzling digital boardrooms or Fiori apps are offered, all that the business users seem to want is the raw, unfiltered, estate-bottled data. There have been some solutions for this, such as good old SQVI, its heir apparent Key User Extensibility with analytical queries, as well as third-party tools (e.g. well-known Winshuttle, acquired by Precisely last year).

However, IT is typically reluctant to grant access to these tools, much less invest in educating users on how to use them. The usual excuses are security and data governance. What the users do with the data and how they interpret it is a valid concern. But in general, when it comes to the users and SAP tables, I think it’s like with teenagers: instead of flat out denying, it’s sometimes better to let them experience things in a safe, controlled manner. Resistance is most likely futile. JP

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

Don’t miss our latest issue!

Murder by Acquisition

For over a decade, my family has been using Skype to keep in touch. Weekly, we have a video call with my parents across the ocean. Whenever I travel on business, I find time “to skype” with my husband and kid from a hotel room. Many similar applications have come and gone but we stuck with Skype because it was simple and good. Or rather it used to be. Sadly, ever since it got acquired by Microsoft, each update seems to bring a useless feature while making core functionality more difficult to use. It’s now reached the boiling point where we are looking for an alternative.

Skype is not the only application that was made worse by the new corporate overlords. Actually, I can’t even think of one that got better after being acquired… Can you?

Maybe to some it’s exciting that Figma will work with video and 3D models after being bought by Adobe or that Slack is getting more integrated with Salesforce, their new corporate daddy. But as a devoted Slack user, I’m thinking: how about no? There is a great value in applications that do exactly the thing they meant to do really well, and turning them into yet another “jack of all trades, master of none” seems like murder. JP

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

Don’t miss our latest issue!

ZSAP: Unusual Suspect

Five criminals. One ZSAP. No coincidence

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 Sandwich

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!

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!