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!

Fundamental Conference Coming Up

Be there or be 4:3 aspect ratio!

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.

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

Salesforce Dethrones SAP

Everybody wins! Mostly shareholders.

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