I think most of these enterprise systems do not handle a lot of data. If you look at what they actually do it’s very simple, the implementation is just the most complicated possible.
Because enterprise systems were typically written by people who no longer work for the enterprise (and may no longer be in this plane of existence), because these systems have been adapted over long periods of time to applications and platforms that were never anticipated during the original design, and because writing, testing, and deploying large-scale systems is still not well-understood.
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.
Because the clients are always changing their mind and demanding things quickly, thus the devs who at least make an attempt to do something useful are rushed to add more spaghetti to the pasta
I’m always skeptical when I hear claims that enterprise software can magically be made significantly better. The fact is that an enterprise is a messy beast that defies comprehension, and the software is just a reflection of that reality.
The issue is firmly with stakeholders. Complex business practices, needs, and processes yield complex system(s) to support them. Simplify your business process and practices, and you’ll have a simpler system.
I think it's in part because enterprise systems are often cobbled together from a bunch of different tools usually, with a bespoke interface on top.
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.
Have you actually worked on real world Enterprise systems? It sounds to me as if you haven’t. Some of the posts above (from people who know what they are talking about) might enlighten you.
> Have you actually worked on real world Enterprise systems? It sounds to me as if you haven’t.
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.
I've spent a couple years working on B2B Enterprise SaaS. So, why do these systems suck? These systems are made in environments that simply are not conducive to approach software development in a healthy way. From my experience it's a combo of: bad technical leadership, too many cooks in the kitchen, a lack of knowledge sharing, and a lack of alignment.
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.
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.
One interesting thing about enterprise systems is that you actually have to find out what the client needs. First and foremost to be able to continue running a business, which may be quite complex, with moving parts that can't easily be taken offline while they are overhauled.
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.
Most clients don’t know what they need or disagree internally on what they need. Working on Enterprise systems you are often put in loose-loose situations where no matter what you do somebody will hate it. Kinda like politics actually. No technology will fix that. It is a human/politics problem.
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.
OK, no, there are no silver bullets for Enterprise software, including Logic programming or whatever else. The challenges are human, social and economic, not technical.
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.
I'm 100% for better tools for enterprise development, and consider most/all languages in wide use as subpar (even python!). I bet on it building on the side https://tablam.org because this...
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...
The dude attacks SDSM and says there is some other magic Turing Complete system that solves the "enterprise problem" which is really decidability / halting / etc in computation theory? Right.
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.
Nope. Enterprise systems are terrible because Enterprises are terrible. Politics, silos, bureaucracy, turf wars, egos, non-technical decision makers etc. is all mixed together in a mud pile of complexity that no software technology can fix. It is a human problem not a tech problem.
24 comments
[ 3.5 ms ] story [ 67.3 ms ] threadPredictive 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.
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.
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.
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.
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.
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.
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.
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 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...
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.