Why are enterprise systems so terrible?
juliustech.co
juliustech.co
By definition ERP software are low trust: they involve multiple groups of people: IT, business teams, software vendor, integrator. Even if you combine all of these into one somehow (in-house software, low code, whatever) there are still multiple teams: today's and +5 years from now when that ERP will still be around.
Low-trust and long-term ROI mean extensive (often excessive) documentation, auditing, specs, testing, etc. Long timelines means much different economics than consumer software: investment is up front and paid off over a long time period, which means risk has to be mitigated up front. Cloud/SaaS has changed that last part a bit, in terms of external costs (software) but not internal (change management, disruption).
Bottom line: ERP is to consumer software what building a bridge or a subway is to building a house: a different beast, done by different people with different tools at different scales.
Source: 22 years in ERP, including yes Logic-programming based ERPs.
In addition, the people buying the software are often not the ones using it, so optimizing end-user satisfaction is not a priority.
In other words, it's software that's built to be sold, not to be used.
But honestly that's not going to cut it. The Enterprise is the issue. The software is a physical manifestation of the dysfunctionality of the underlying organization.
It's a symptom not a cause. Glorious tools will at best more elegantly generate similar headaches.
Bad technical leadership: Basically, everything's a free-for-all. Teams are unbounded to do whatever they want. You end up with a Frankenstein technology stack. Technical debt grows, nobody does anything about it, and slows down your ability to quickly pivot over time. New execs join and are flabbergasted when they can't fix everything in a quarter due to the lack of adequate process instituted in healthier software organizations.
Too many cooks in the kitchen: The lack of standards means re-implementations of product features numerous times, in different technologies, with no awareness across silos.
Lack of knowledge sharing: often times there's supposed to be cross-cutting features that would impact every microservice (eg: multi-tenancy) and you'll have one microservice team implement support, and another one won't. Inevitably, someone will eventually notice and you end up with a support ticket.
Lack of alignment: One part of Product thinks the multi-tenancy feature really isn't that important, but the other does. They lead their engineers to skip that feature.
Predictive optimization may have something to do with it, in the same way that maybe RMS Titanic might not have hit the iceberg if they'd been able to make the gin-and-tonics consumed by first-class passengers colder.
This has all the hallmarks of a common enterprise software crap shovel fest:
Enterprise computing isn't HARD in the computing/algorithmic difficulty/mathematical theory hard sense. It's virtually all database <-> data transport <-> data presentation/entry. It's just HARD in the chaotic sense, where Conway's law says your system will mirror your human organization, and your human organization is cacaphonous and chaotic.
Enter some "expert" who declares a seemingly tangential/obscure/academic concept X (in this case stack machine implementation of turing machines) is the problem and other seemingly tangential/obscure/academic concept Y will solve it.
Which is utter hogwash. It's the chaos complexity/nonlinear dynamics which is hard to solve.
Everyone, every org every human of every size & shape could benefit vastly from better general systems research. Rather than endless applications, we ought be trying to pool our efforts to develop direct manipulable systems that can underpin many apps, & have apps serve as a set of schemas & supplementary (concatenative) tools for the common baseline interface.
instead we're endless mazes of twisty little bespoke passages, all unlike. our knowledge/learnings never ports between systems. we keep trying to build worlds but each time, we over specialize & miss the fundamental reverberations & interaction mechanisms.
platforms like Tim Berner-Lee's Solid propose a common data system. I don't think there's quite enough appreciation for processing & manipulation to make a real threat to enterpriseality, but it's striving for generalicity is well worth paying attention to, trying to find next from.
boo
I called out one part that I thought would be helpful & you show up & say thinking that means I don't know anything thing. this is ridiculous of you & unkind. it feels maximally ungenerous.
I wasn't making a grand statement about the whole picture. wasn't trying to crack the whole iceberg. I called out one specific part. and you had to come & rain on me for offering my 2c.
I'm tryin my to move towards a moment of finding some technical insight here. something technically nuanced & interesting that we can begin to say. i'm tired of most of the other replies, which cite the real world stakeholders, clients, legacy, politics & other real world clusterfscks but I think our deep technical inferiority & shitty substratums & fabrics speak endless volumes about how badly the techies bungle it up, haven't found truer mechanistically sympathetic systems to work atop. ideas like the ESB died, but as good as they are microservices & grpc aren they aren't as coherent concrete enough a starting spot for enterprise architecture, for how data moves.
data flow is untamed. esb, remember that? when we tried to abstract messaging? and never quite got it? then projects like airflow, or nifi. mq's proliferated. a lot of this stuff isn't enterprise but if the ESB world hadn't fallen over it was on course to be, it was specialized advancements of the bus. the bus of enterprise.
there are so many adequate decent tools. so many. so many good enough platforms that can be well adapted to do the job. but;. think we're missing core pieces of how to draw things together. in ways that only general systems research & augmentronics can start us climbing upwards to.
but each company is kind of welding together the flows, busing the skeleton of systems themselves out of these bones.
and yes they struggle immensely to do that well, to be converted about it, to wayfind their systems forward.
1. Politics. Conways Law more or less applies here.
2. Finance puts a hard border on the playground and forces everyone to play together even when it makes zero sense from a product, efficiency, or maintenance perspective.
3. Even with maintenance teams in place, the enterprise typically elects to use a consulting firm like Accenture for net new builds. This kills the crab.
In contrast, the vast bulk of software addresses a perceived need -- perhaps as perceived by one individual. The "need" is a hypothetical that is then tested in the market. It then becomes wanted or needed through its adoption. Most non enterprise software can also apply the 80/20 rule and implement features incrementally if at all.
I think this isn't just true for enterprise software, but for software used for disciplines that have a lot of descriptive domain knowledge and arcane methods.
In the case of languages, exist many things that they could have to help:
- In-built AND first-class decimal/money types + assorted math functions
- Top-notch data manipulation features (like relational model/array/linq) that are first-class.
- Good ways to transform/manipulate data.
- Excelent database drivers
- First-class support for windows.
- Great ways to parse data, including in weird encodings/mis-shaped formats
- Data-frames or similar
- Good JOINs support, or at least, goods ways to summarize data (aka: "GROUP BY, sum, avg...")
- Excelent repl and/or notebook support
You can argue many languages fit this description, but after using more than 12 I think only FoxPro and maybe kdb+ fit, somehow. Is kinda you know it only IF you experience it.
THEN we also need:
- Excellent UI builder, not terrible like VS Studio, GOOD ONE, like Foxpro or Delphi.
- That generate GOOD UIs, not terrible and slow.
- Excellent GRID component
- Excelent validation libraries
- Excellent way to make reports
And baaam! then your option were in the PAST - and that considering what was good/need at the time-.
Today? Nope, nothing cut it. ---
With any/most of this, the job is good. Then also it will NOT solve the major problems of enterprise development, but honestly? We enterprise developers need any help we can. I wish exist more investment in the area, but another big problem here is that is very hard to get it. You can get (greasing hands!) a billon dollar over-priced service contract but not get 1 million to fund development of the tools.
So what I see is that many of us just do some of them on the side, but too unpolished or niche to make it useful at large...