I think the mistake with SAP, as with that other article about a modelling pyramid at Ikea, is assuming that it is possible to create one system to rule them all without it being extremely inefficient and expensive.
It mirrors a dysfunctional business run on command-and-control rather than, like AWS, you have a large set of loosely affiliated teams and although you risk some duplication, it makes for much more agile work.
Imagine you have a supplier who supplies "products" but your system calls them "items", SAP would say that you have to standardise the nomenclature. Agile says, let them call them whatever works for them and lets build small systems with just the interfaces we need.
Sure, the senior management don't get their dashboards but it is still possible to get metrics from disparate systems and form pretty basic cashflow and inventory reports.
This seems like an easy way for money and stuff to start going "missing".
One has to remember that many large companies don't have an in-house set of software engineers to kludge things together, or a set of people to audit and make sure problems aren't accumulating silently somewhere because of some bug or some vendor changing their API or whatever. Even if they did, the supposedly "agile" solution proposed here just sounds rather fragile. You even see this in codebases that are built on a "microservices" mindset -- you start getting weird emergent patterns in internal dependencies that start bogging things down.
For a smaller or even medium-sized business, sure, maybe a custom solution works. But it looks like for the scale of organization SAP works on, it seems difficult for an individual to even understand all the components of that organization, let alone build something maintainable for themselves and their eventual replacements.
I think part of the problem is driven by the desire to create a slick UI and wizards. These systems then underperform. I wonder if you could instead expose more of the underlying computer science stuff to the user. Give them an interface to push transactions. And a set of widgets to pull data. Keep every operation seperate and discrete even when part of a process. And let documentation and training teach the business process.
I used to think this, but then I started interacting with actual end users (normal, non-engineering people). There are 2 main problems with exposing more barebones stuff to non-engineers:
1) Problem solving (thinking about how to compose the raw primitives) takes a lot of creativity. Most normal people only know what end outcome they want, not how to engineer their way there*. The reason wizards are so common is because they address this exact need. Wizards try to figure out what you want to do via a series of questions (and then do it for you) rather than have you come up with how to do it yourself. They are so common because when designed correctly they work very well!
2) Understanding errors is also very hard. Just because something didn't fail doesn't mean it worked correctly. Sure, anyone can file a transaction into a database, but they can just as easily file an incorrect one either by mistake or due to inadequate understanding. The complexity of the systems are their to catch problems before they become problems.
Sure, sometimes there will be corner cases that aren't accounted for by the existing system. And these will be frustrating. But taking away both the end users' guide and also removing their guardrails just so they can maybe solve the problem themselves is not generally a great idea.
*: This is not meant to disparage the normal users, but different people just have different interests and goals. Not everyone should be forced to know exactly how a machine works just to operate it.
It mirrors a dysfunctional business run on command-and-control rather than, like AWS, you have a large set of loosely affiliated teams and although you risk some duplication, it makes for much more agile work.
Imagine you have a supplier who supplies "products" but your system calls them "items", SAP would say that you have to standardise the nomenclature. Agile says, let them call them whatever works for them and lets build small systems with just the interfaces we need.
Sure, the senior management don't get their dashboards but it is still possible to get metrics from disparate systems and form pretty basic cashflow and inventory reports.