Vendor Lock-In Thoughts and Composable ERP

Kinetic ERP
1

To continue this part of the discussion…

There’s a thought going around in some of the ERP blogs/LinkedIn/etc. on the idea of “Composable ERP” The idea is there is a core ERP system (GL/AP/AR/etc.) that offers API access and then one adds the CRM, EDI, Scheduling, etc. modules. Easier said than done since the effort of integration is always under appreciated.

However, I’ve been thinking about what Haso said:

What if there was an actual ERP Framework product that was segregated from the ERP system? :thinking: What if one could take a page out of the Domain Driven Development playbook and implement a custom front-end to all of your ERP systems? Hold your nose, but this might even be a place where AI could help.

Imagine describing your business capabilities in Markdown using an event-driven narrative which would include your authorization logic. Feed this into your favorite AI code generator to generate UI, business and authorization rules. This layer would enforce all business logic. Now, for each ERP system you have (if you have acquired some or migrating from one to another), implement the persistence logic for that ERP system. For example, if a user in the Ohio office - which uses Oracle’s NetSuite, they would enter a part in the framework Part screen and it would add the part to NetSuite. A user in Missoula enters a part, but it persists the part in Kinetic via API as well. Both Part screens look the similar in Toledo and Montana and the users don’t have to know which systems they are using on the backend. In fact, when the Ohio team is on-boarded into Epicor, nothing changes for the user. No extra training required. One could do the same for CRM, payroll, etc. Since authorization is centralized, it would make a lot of things easier to manage.

More importantly, if one needs to switch from one ERP system to another, you implement a new persistence layer. Again, that’s not easy, but it might be easier than a wholesale ERP system changeover.

It’s something I’ve been thinking about for years, but it suddenly was rekindled for some reason…

8 Likes
2

I think in 2035 once folks ride out the 2028 wave, AI will be so advanced, they could Vibe Code a Quote to Cash ERP in a day.

Most small mid-sized businesses only use a 1/3rd of Epicor anyways, and business processes most of the time remain the same.

Do you need WordPress anymore, when you can just prompt AI to make you a .html site.

Internally we use, maybe 10-15 screens, most of the extras are just Dashboards. In 2035, im sure everyone will just make their own in-house ERP.

UFP is a 10 billion dollar company, they have their own ERP in-house, works, they keep getting richer. They also have Epicor on-prem and are completely limited there too.. Owning their source code, makes them agile. They run WinForms, and every year grow by a billion, why change :slight_smile:

Anyways AI in 2035 will be a game changer.

3 Likes
3

And that’s true. Do we want to Vibe Code the whole thing or just the part that describes our business and use well-tested components (G/L, etc.)?

1 Like
4

Id say just what you need, with Epicor you buy the whole QA Module, and you only use the RMA Screen, sounds like a waste – yet we complain about Cloud being more money.

How many of us have Modules, we pay full price only to use 10% of it.

5 Likes
5

.ERPCore :grin:

2 Likes
6

We’ve discussed the exact same thing this morning.

We’ve change ERP system last year, from an old legacy system to Epicor classic on-prem (implementation started 4-5 years ago). When you think about it, the company has not fundamentaly changed with the ERP ; the same product are manufactured the same way, but we had to reimplement all the business logic from the old system to Epicor.

For us, the switch from classic to Kinetic feels like a re-implementation since the users need to be re-trained. But, the business logic will not change.

And with the forced switch to the cloud, what if the costs becomes so high that management want to change ERP ? That need another implementation and we will have to rebuild all the same business logic in another ERP once again. And we would also need to retrain everyone on new UI…

We will experiment with our independent website (Blazor) and try to decouple from Epicor

5 Likes
7

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? :thinking:

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 :poop:), 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.

6 Likes
8

One wrench in the works is there is always something that doesn’t translate. Just look at something that should be something as simple as UOM. Translating something as simple as weight to get to eaches when you go through the steps of manufacturing becomes way harder than it seems like on the surface.

The concrete example is a mfg can order steel sheets by the pound. Then get into the facility and that actually are consumed by area because they are cut on a 2d laser cutter. But in that process there is a wildly variable amount of scrap that happens depending on model mix and other factors that go into that days production, so on the final good has say 1 lb of steel in the part, but you had to order 1.6 lbs of steel to make the part. But on the next day it was 1.2, and the next it was 2.5. It’s all over the place.

Pallets to eaches is the same way. One day it’s packed with 48, the next with 52 because another person was working and decided to go another layer higher.

So these are physical examples of breakdowns of standards that shouldn’t be that hard to translate but wreak havoc on something as “simple” as keeping track of inventory.

Now extrapolate that to business and programming ideas of how one system does something compared to how another system does something. How can we standardize those translations when there simply isn’t a way to translate it? Sometimes the very idea of something simple doesn’t exist, and approximation is the best you can get. Computers DERP when “It depends” come into the mix.

Soooo… not a helpful post in that I have zero solution to this problem, just pointing out that it’s something that has to be solved somehow, and it’s probably going to have to be through cooperation across disparate businesses willing to lift the industry as a whole instead of trying to corner the market for themselves.

4 Likes
9

@jdewitt6029 built his own ERP for his prior company, what are your thoughts, Joe?

2 Likes
10

There would be one tool that just did UOM conversions, and that’s it. Above that would be a nesting tool, which did that.

The idea is not to come up with a standardized solution for everybody but to give companies the “lego blocks” to assemble the solution that fits their domain. In other words, you’re not buying an ERP system that you customize to fit your business. You buy a tool that builds the domain layer and then customize the event layer to assemble the correct tools to perform the domain event.

Would there be a market for people in particular industries to assemble tools for their domain?

Iron Man Reaction GIF

What were looking for is a way to decouple the logic to make it easier to adapt to different situations and not build a single solution that does all.

4 Likes
11

You’re not talking about Kevins, are you?

:rofl:

5 Likes
12

And it’s not just how the base systems do things… A successful integration needs to deal with how the particular instances of the systems are being used and all the unique business logic in place.

We have done a lot of the best in breed approach and I think it does yield better outcomes, but the integration cost is enormous (to do it right) and is always severely underestimated by anyone who’s never actually written an integration themselves. It can be great, but requires significant integration talent or it will crumble to pieces quickly.

3 Likes
13

Couple of years ago I would have said probably not, but I feel like structuring things this way would let you insert AI into everything easier, and your AI of choice, so maybe there would be a force that would support this movement.

Otherwise it doesn’t seem like there is a lot of interest from companies on working together, either you get bought out or the government forces you to work together..

2 Likes
14

I love this conversation/angle and its potential. Went down a rabbit hole this morning with a colleague and got to a point that I just fell in love with - but also ended with ‘vendors’ still being the failure point.

Taking the concepts above, consider a method where an “AI” engine takes input prompts such as DB Schema, Business Domain Logic, destination app specs, and app workflow - and builds the App. In my mind this goes back to the ‘citizen developer’ concept.

But could allow IT groups to keep the infrastructure out of reach and supply the necessary prompts for their part, while the citizen gets the app that they need. Each person in an AP department could have a different AP app, all working on the same infrastructure.

A market that comes to mind - prompt generators for (1) the data layer and (2) App pseudo-code tools.

2 Likes
15

That might be the breakthrough that makes it work, is somehow get AI to help do the translation pieces to rounds those corners to get square pegs into round holes easier. Things like MCP servers (I had a cool lesson from @josecgomez about that last night after work) are a cool way that we can build up reliable ways to use AI to speed up tasks.

3 Likes
16

:100:

I agree with both of you. I worked in EDI integration for five years. There are multiple issues with integrations:

Identity

  • Org 1 calls it an “A” and Org 2 calls it a B
  • It doesn’t have a part number at all, it’s a base plus options like a car

Data Format

  • Order number is integer for Org 1 but String for Org 2
  • PO Number is 30 Characters in Org 1 but 60 Characters for Org 2

Data Structure

  • Ship to is on the order header for Org 1 but on the Order Line or Release for Org 2
  • Org 1 has top level customers but Org 2 has one level of customers

Missing Repository Items

  • Org A passes a data item to be returned (internal release number) and there’s no place for it
  • Org 1 does release accounting, Org 2 only has Sales Orders

Org Structure

  • Org 1 receives all communication in one endpoint but it needs to be distributed to one/several sites.

Integration is hard no matter how you organize your ERP system. Nobody (I think) disputes that obvious fact. The question is:

Would it be easier to assemble a solution from smaller tools or to continue to add onto a bloated monolith? :person_shrugging:

3 Likes
17

Radzen Blazor Studio is a great rapid development tool with CRUD scafolding from MSSQL/
WebAPI/swagger/OData. Mileage may vary with Epicor-flavored RPC method dance & unorthodox APIKey Auth, but those are doable and v1 OData enpoints should be straight forward.

1 Like
18

Yes, you’re closer! Except, we’re never building the WHOLE app. I love the idea of describing our business capabilities and have AI generate the domain portion. AI could even help with the tool assembly. But we shouldn’t have to write everything. We want to lean on tools that do one thing really, really well. Otherwise, we’re just recreating monoliths (modular or not) in a new way.

2 Likes
19

Linking together 15+ tools of many vendors the total cost could be much ither than monolith ERP. As each tool vendor is in it for profit too.

1 Like
20

:nauseated_face: :face_vomiting:

NO CRUD!!! Well, maybe for very simple maintenance tools like entering ABC codes.

1 Like