We’re all in for profit! But at least we could beat up multiple tool providers easier than one ERP provider. And tool providers would have to compete on each tool, not the whole toolbox.
I’m still up to my 
in EDI stuff. “Standards” only go so far…and they’re frequently up to “Company X’s interpretation” for format/content to better suit their business. No bueno
Right. We’re just talking about tools. No mention of data objects and their formats. That’s probably a harder problem to solve!!!
I just wrapped up a single e-commerce integration that took almost 5 years 
I often use the metaphor of trying to build a new bridge between Jersey and Manhattan. Most people tend to focus on the bridge construction itself, which might be coding the API endpoints and the client side requests. But that is the easy part. Just imagine the architecture and endless approvals from government around traffic patterns, where the bridge goes, and the endless changes and tangential construction that would have to happen on both sides of the Hudson. In construction it’s easy to have intuition that something like this costs billions of dollars (and has a high chance of failure). But most people just don’t have that same intuition about software projects and it leads to significant conflict.
The other metaphor I like is that an integration is creating a Pidgin language between 2 systems.
It’s not just a translation from one language to another. It’s the emergence of something new, a shared understanding built from each language.
Absolutely! It’s a semantic understanding within a particular context - way more than data formats!
Which by the way, is EXACTLY what Domain Driven Development demands: a common vernacular.
Ok, so how can it actually happen? Much like a WIKI that’s that’s been talked about in the past /< cough > it’s easy to wax poetic, what would it take to make it happen? Government intervention? A non-profit organization to create and set standards? An open source project? What concrete steps could be taken to move the theoretical into reality?
Not really. We all have these thoughts, “Why can’t this be better?” But it’s not easy taking those ideas and throw it out there for discussion.
For me, I want a better understanding of Domain Driven Design and Event Sourcing. I would start with a small problem and then make sure I understand the implications of the architecture. Many who go down this route drag old thinking with them and feel that pain. One complaint is tracing since multiple tools are called and errors can happen at any point along the way. I think a big challenge is identifying what the tools are and what should they do really, really well.
“Everyone has a plan until you get punched in the face” as Mike Tyson said.
But I don’t think standards is the way to go and certainly not government intervention. A common understanding will emerge as people try it and share their results.
Gotta persist your commands, states, and adapter config somewhere.
Anyway Radzen scafolds C# model, services from swagger so you can gen an app from any ERP that exposes swagger so it can Read your Invoice during your ApproveInvoice DDD command.
It doesn’t need to persist the invoice neccessarily. For example, here’s a dashboard using github rest API with zero persistance.
Oh and Mark will like this:
Renders md in your Blazor pages plus Blazor components in your md.
Of course! It’s how. Do you maintain state on a single record and replace it as you go on? Or do you record the events that happen and find the state at any point in time? Here are the pros and cons:
I do!!!
Perhaps a move away from monolith would benefit from Master Data Management as a first step. Take control of your master data (customer, vendor, employee, product, service, contact, address) and make disparate systems subscribe to your MDM catalog. This eases lock-in because you own ‘the truth’.
STORY TIME:
Before Epicor (ie… before 1999), I was a computer programmer. I was an expert on “Alpha Microsystems”, and “Alpha Basic” and “Dravac Development Language (DDL)”… DDL had an “Amazing” database structure that allowed me to write a complete custom ERP System that served my company. It had Sales, Production, Purchasing, Inventory control, MRP (Actually i called it MMRP for “Mini MRP”), Human Resources, and Accounting (AR/AP/GL). It was fully lot controlled, and actual cost. Our printed forms were printed using PostScript (I learned the PS Language to generate my forms (SO/PO/Pack/Invoice)… no Crystal was used). It worked EXACTLY the way we wanted it to… therefore, it would probably only work for about 1% of the rest of Epicor’s Customers. For example it had ONE unique restriction that MOST of you would not put up with… you could only sell one part number per sales order. Why? cause that is what we did!
Anyway when Y2K came along, I realized that the software I started building in 1983 was NOT Y2K compliant. I stored ALL dates in an “MDay” format (Manufacting day). It was stored in a 2 byte integer field to save space (Remember… back then I could only store a maximum of 512 bytes in a data record). So… I needed to find a replacement for “shoemakerware”. I did a search. I found Epicor (amoung dozens of other ERP software packages). It met nearly all our needs. We went live without any modifications (except changing logos on forms). We found that with the new software, we were no able to take advantage of multiple part numbers on one order. It supported lot control in the same way my software did. We had to adjust our costing method slightly because we did some weird things to account for excess material.
All this to say… when we looked to replace the software, we wanted something that could be supported and run by someone OTHER THAN “Tim Shoemaker”… When something bad happened in the software, before it was “where’s Tim”.. Now, it was “Let call Epicor”. As a result, I was no longer handcuffed to my former employer, and after being live for over a year, I was able to pass the batton onto another person, and I was able to come to Epicor (the best career change I could have made).
ERP Systems are complicated. Yes, you can write one yourself, but it takes time. And the results may be “Exactly what you wanted” but those desires might not work in the future… there might be another Y2K, or you might want more than one part per sales order in the future.
Love it @timshuwy! That’s exactly why I tagged people who have made their own ERP’s so that we can learn about why they went with an ERP system like Epicor and some of the challenges of having your very own ERP.
Love “shoemakerware” 
. Also, the mini MRP. Very impressive Tim!
Yea, I actually felt slightly trapped by my own programming. If I left, there was nobody to take over, as we were a small company. I actually used this as part of the justification for spending money on a supportable solution. I said “If I ever drive over the cliff on Orgega highway, you lose all your support.”… I drove Ortega on a daily basis… it has a reputation.
There are risks involved with developping home-made ERP, some @timshuwy mentionned. For example, what happens if the deveopper dies in a car crash ? Can I trust my developper/team enough to build/support/maintain/scale the very core of my manufacturing business ?
For management, those risks were enough to justify buying an ERP from a vendor, centralize everything around it and make it the core of the business.
But there are also risks involved with buying an ERP from a vendor, and, from my perspective, thoses risks have increased lately. Like, what happens if the vendor stops being trustworthy ? What if the vendor decides overnight that he stops supporting my on-prem installation ? What if vendor support is so bad that I must do whatever in my power to avoid it entirely ? What about cost-related risks ? What if costs skyrocket in a 10 years span because of 8%-10% increases per year ? What if I only use 10%-15% of the features ? What if sales go down on a market downturn and I cannot scale back the licence and modules costs ?
In the end, vendor lock-in is a risk and every business must balanced thoses risk and decided for itself. My feeling is that with the advanced of AI, businesses big enough to build a good IT teams with competent people can reasonably think of building a core (business logic and rules) completely independant from any vendor, then choose some very good and narrow “modules” to build around the owned core. When a vendor becomes non trustworthy, you simply unplug its module to plug another one.
Can extend this to ANY service vendor that you partner with…ERP, payroll/HR, internet, telco, anything. Having to find a new vendor can consume significant time and resources. Sometimes picking the right/wrong one can make or break your business. Best hope is that it’s a mutually beneficial pairing that lasts a long time.
Yes, this can extend to any vendor.
But changing telco provider usually does not involves a 2 year long implementation and training, associated with a +1M$ internal and external cost