I like the way @mbilodeau is looking at this:
And Mathieu references the magic word: coupling. What @MikeGross is describing is the tightly coupled world the Epicor universe is. In one of @klincecum’s Wiki Code Camp posts, we talked about coupling and cohesion. The mess of layers and APIs all have to do with this. As time has gone on and more and more has been added to the any software product, it’s unavoidable that the complexity of the product goes up and maintainability gets more difficult.
The ERP Clean Core movement, promoted by SAP says, change your business to fit the domain of the ERP software. Keep customizations to a minimum. Honestly, a noble strategy.
OTOH, we have the Composable ERP people who say that we should be able to pick and choose the best of breed modules and link them together. Again, easier said than done. Here we have to align to the domain of several providers, and we usually tightly couple our integrations with direct API calls or insert a tool like Workato, JitterBit, MuleSoft, etc. in between. This adds coupling.
Since the beginning of this thread, I heard an interview of a couple of German Software Engineers talk about modernizing legacy applications using Domain Driven Design and Event Sourcing. When I found out that Michael Feathers (of Working Effectively with Legacy Code fame) endorsed their book, I started reading it immediately.
How can we make ERP systems easier that adapt to the changes of market, mergers and acquisitions, and process improvement?
There has been an on-going argument between building small tools that do one thing really, really well or building a smart tool that does everything. We see this with operating systems: Unix/Linux/etc. vs. Windows/Mac. We also see it in computer architectures: Complex Instruction Set Computing (x86) or Reduced Instruction Set Computing (ARM). The problem with the smart solution is that it’s more work to add capability over time.
Given that, what would a new ERP architecture look like that combines the best of the Clean Core and the Composable ideas? 
What if we started at the bottom with modules that do one thing really, really well: GL Journal Entry, Material Movement, etc. We would assemble them together to do more interesting tasks. For example, one could combine the material movement tool with others to create a Package Control capability, customer managed inventory capability, etc.
That would be the base layer. At the top, we adopt the ideas from Domain Driven Design and tailor the various capabilities to each company. This layer describes the processes, handles the UI, contains all of the business logic, and performs workflow.
In between these two layers would be an event-sourced system that makes the calls to do the work. Instead of writing tightly coupled REST calls between everything (which @MikeGross rightfully describes as 
), we build loosely coupled events that execute our domain logic.
It takes a bit for me to wrap my head around this because I’ve been immersed in the highly-couples/low cohesion world for a bit. But maybe this would be a better architecture since one could swap out components and not be locked into a single vendor. Software providers might start building tools that do one thing really, really well and not try to write large systems that do everything mediocre.
Anyway, food for thought.