The Boring Enterprise Nerdletter #22: Agile, Salesforce/SAP, API/BAPI, Fundamental, RICEF, Odoo
Hi there,
We hope everyone had a great summer and received less than 500 emails upon returning from a vacation.
This issue is chock full of controversial topics: Agile, Salesforce / SAP competition, open-source ERP, and more. Bring on angry letters: we’re ready for a SmackDown, like APIs versus EDI and BAPI!
-Jelena and Paul
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
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
API SmackDown: Round Two. BAPIs
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
Fundamental Conference Coming Up
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 brings 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 includes those PO-approving biz apps. PM
RICEF Must Die
Some acronyms are funny or useful (hello, TLDR, LOL, and FOMO!) but some, like RICEF and its cousin WRICEF, are “dumber than spit”.
RICEF stands for Reports, Interfaces, Conversions, Enhancements, Forms. The W part is for Workflow. Recent blog post raised a question: is WRICEF still appropriate in the days of SAP RISE? The answer is: heck no. And this abomination should’ve never existed in the first place.
No self-respecting developer would say “oh, I’ll be working on RICEFs all day!” It’s just not the thing. The only demographic saying “RICEF” with a straight face are the project managers who seem to think it’s cool or something.
It’s not cool, folks. It’s just plain dumb and rather demeaning to SAP developer’s work. We do not invent acronyms like MMMSR (Micro Management, Meetings, and Status Reports) for what the managers do, even though that would be way more accurate. So, please don’t do that unto others.
Next time, when anyone asks what RICEF is, the correct answer is: it is an anachronistic acronym for custom SAP development used by those who can't say real words like adults. JP
Do You Odoo?
Major enterprise software vendors using open-source code in their tools has been amazing. UI kits, machine learning features, and other bells and whistles exist because communities have put in the effort to ensure that some things are available to everyone.
But what about an entire ERP constructed on open-source? Enter Odoo. Like many open products, it has a pricing model based on a limited "Community" free version and a more feature-complete "Enterprise" edition. Note that the Community version is the version maintained in their open GitHub repository, so any features you might want to add on top of the free version can be forked from that code.
There are some cool things about this community.
A game designed to help you learn how to use it.
Pretty transparent and easy-to-understand pricing.
Adding new apps is relatively inexpensive on top of the base price.
The Odoo site appears to be made with the Odoo site builder (developers, you should read the source code)
Refreshing. PM
Support Starving Artists
Do you love this newsletter, but are disappointed you can’t give the writers loads of cash? Worry no more! We’d love your support!