From Chris “Woody” Woodruff" on simplicity:
4 Likes
Yeah, a lot of ‘Cloud Native’ stacks really aren’t suitable for ERP either. Strict isolation and proper ACID database transaction scopes and stacks are far too important. Separating out services, and or lots multi-threading, often just do not work consistently and properly for transaction integrity.
Overall, IMO, Kinetic already has the best core application server stack overall within the mid-tier ERP space for either Cloud or On-Premises via containers. I don’t see how there would be much benefit in Epicor substantially changing the stack and or architecture. Simply working on building out the Linux containers for general access and improving and optimizing the Kinetic framework and business logic seems by far the best opportunity for Epicor to improve the Kinetic product and offering.
1 Like
BankBalDeferred
GlbCustCredDeferred
PartBinDeferred
PartLotDeferred
PartQtyAttrDeferred
PartQtyDeferred
Even on-prem, Kinetic uses eventual consistency. No?
1 Like
For some synchronization and processing aspects, yes. But I was referring to lower-level data transaction management, including the implementation ACID transactions. What Are ACID Transactions? A Complete Guide for Beginners | DataCamp
Many of the ‘cloud first’ service models and non-relational database management systems do not properly implement, or support, ACID transactions and therefore can easily result in partially processed and partially committed/unbalanced transactions. Not really a problem for a comment on a social media application but definitely for ERP transactions.
1 Like
I agree. Is any cloud ERP company suggesting NoSQL? 
I guess when I think cloud ERP, I’m thinking more architectural changes. Someone I follow on LinkedIn is an architect named Yves Goeleven and he explains how the data first approach differs from a task oriented approach. Those of us who learned to code before 2010 often start with the database first. We think in terms of entities. Our REST resources are nouns. The domain first people think in tasks, processes, capabilities, etc.
THIS is what I want to see in an cloud-first ERP system - even if we run it in our own private cloud. Less coupling, more cohesion, and better telemetry. One wouldn’t have to switch the whole system over. Both methods could exists, but eventually the more task/event-oriented would take over.
1 Like
There were multiple ‘startups’ trying at one point.
I think both methods already exist to a large extent today. ERP databases are naturally data model driven, which it’s hard to imagine an ERP not being considering how much the same data is used across many tasks or actions. While many of the services, methods, and UI are far more task orientated.
2 Likes
Yes, they are. And sharing data in this way is what makes them inflexible and difficult to change as they get bigger. It is also the biggest reason we see this error message in Kinetic:
“Record Updated By Another User”
This happens because we think data first and not the capabilities we want the software to have. I’ll let Derek explain it better than I can:
1 Like