"I feel there is a lot of room to develop better tools that are not so horrid"
Probably not. SAP is an everything-to-everyone product. Using Fred Brook's terminology for essential versus accidental, the problem with everything boxes is that even just the essential complexity of such a product is so insanely large that they are sufficient to produce a "horrid" product. Of course they don't have just the essential complexity and add a healthy dose of accidental complexity, but so would any putative "less horrid" replacement by the time it successfully solved the same essential problems as SAP.
Closer to home, "bug tracking" is an example of an everything-to-everyone product. I can't even count the number of times I've seen a "simpler, less horrid" bug tracker get started due to the perceived horribleness of the current bug tracker, but the new bug tracker simply became the old one once it tried to grow into the same niche. This may sound strange to 2022 ears, but I remember when JIRA was being pitched as the simpler solution and developers were pretty keen on it. There will never be a mature bug tracker that is any fun to use, because by the time it's everything to everyone it'll just be the same morass of being everything to everyone again. It turns out that the "less horrid" bug tracker wasn't actually intrinsically less horrid... it just wasn't everything to everyone. Instead it was a bug tracker for developers, so developers love it. But then if developers are going to be allowed to use it everywhere, it has to satisfy all the other stakeholders too, and it inevitably mutates into an everything for everyone product.
(See also: Salesforce. Letting users configure custom DB schemas is a key indicator of being an everything to everyone product. To some extent, programming languages too; there's a lot of people who pine for something simpler (such as the people who think that if we just went to visual languages, or tried to jam everything into "no code") and don't understand that by the time you have a general purpose language that is truly general purpose you've got a large amount of irreducible essential complexity whether you like it or not.)
While it's true that there's a huge amount of essential complexity in this kind of software, there's also a lot of completely unnecessary bad UX and user-hostile design. This is caused by lock-in and not selling to the end-user. If they don't think bad UX will lose them any customers, no effort will be put into it.
It can work for a long time, but eventually it does create opportunities for competitors.
You're absolutely right that there's a floor for how simple these products can be, but most of the incumbents aren't anywhere close to that.
Yes, the platforms essentially get locked-in the UX level that existed when they were initially built. Small incremental changes can be made, or they can be "reskinned" but total rewrites are basically impossibly once there are tens of thousands of customers in hundreds of distinct niches.
Yes. Reminds me of the ol' classic, "Things You Should Never Do, Part I" by Joel.
However, I do believe a (slightly) better competitor could be created, with better technology, better workflow, etc. If well-capitalized. If it had well-factored plugins. If you had a top-notch team to design all that and then build it.
That's a lot of ifs. Joel says it isn't guaranteed a brand new team will even do better than the old on the essential angle. It's risky and costly enough to prevent it from happening.
I love to read this kind of articles. The kind that clicks in your mind right away.
Experience probably has already taught you some of these ideas, but you hadn’t invested the time to reason about them and putting them together.
Then you read an old blog post, from two decades ago, putting all those ideas into words and it simply clicks in your mind.
Thanks for posting the link - funny part about his blog is coming across articles multiple times years apart. Had a hunch I'd read this particular one before and when he started talking about the 'fckedString' that was when I knew. Love the persistence of his blog as this was written decades ago.
Exactly right. Everyone dumps on enterprise software in general, not just SAP, but the truth is that enterprise software is hard. There are so many requirements and specific workflows that it becomes everything to everyone and thus “horrid”.
Sorry but have you actually used a SAP system. I worked at a company that spent $80m on a SAP system that was comically worse than the system that came before it. To the point that people left the business because it made their working days so unpleasurable. This same story has happened at multiple businesses I know. But it's sunk cost fallacy - once the CEO and board has endorsed spending $80m everyone's just going to pretend it's fine.
I’ve worked in shops that built enterprise software. It’s not that hard.
SAP and Jira are just not great software. They’ve got excellent sales teams, connections, and probably great support. That’s the key to getting user-hostile software into big orgs.
You (and maybe GP) seem to be assuming that a SINGLE competitor would theoretically try to replace SAP and fail.
But the most likely scenario, I think, is that built-for-purpose competitors will build products that peel away small pockets of SAP's customer base over time.
The irony of course is that a product like SAP is the end result of similar built-for-purpose products being hoovered up and merged together in the first place.
Bit of both. Their (SAP) Convergent Charging module, to which a lot of legacy Sales and Distribution solutions are trying to move to, was acquired. I think they even have patents on the decision trees used in this module?
How does this idea merge with the idea of "unbundling"? For example, I think of Craigslist, and its famous "unbundling" story[1]. For Aibnb, fiverr, Getaround, etc., the individual niches were enough to build a big product off of, and there was no need (or maybe no ability?) to grow that product back into the "everything for everyone" of Craiglist. What is different about SAP/JIRA/Salesforce? Why can't "not bad" niche-focused subsets of these products become big and profitable while still focusing on their initial niche/area?
Cross-functional workflows within enterprises. Developers can have their own nice, but what about working with tech-writers, oh now we need to have approval processes for third-party systems and idea-gathering from customers for pms, and integration with internal case-management for Customer support escalations and some acquisition uses a different methodology so now we merge on a single platform that contains slight variants or what really are the same states for status. And marketing needs support for the product launches, and we now integrating security scanning tools automatically filing bugs ... oh security has new process steps because we all are doing DevSecOps. And for this special process we need 3 layers of managerial approval. First it was email based, then Slack, then MS-Teams, then back to Slack. And the Old-school QA team for the hardware component has different metadata requirements and internal IT-bug tracking has different requirements than the product-engineering group. And now we want to track cloud spend so every ticket has to have a cost estimate.
The requirements change, merge, flow. In theory each department within the enterprise could have their own optimized, silo'd tool ... but then you need "enterprise integration platforms" to glue together all the workflows between them.
Likely because of B2B vs B2C. Individual users can easily switch when a better solution appears on the market. Business use cases tend to involve a little more friction in those decisions.
If you think about it, all of those niches were naturally unbundled. The people who were looking for vacation rentals had no need to also look for gig work within the same product. The same isn’t true of enterprise transactions - everything is always related, with cross-function impact. There is always a GL that needs to be updated, you need a common vendor list, budget allocation constrains procurement, and on and on.
Spot on. Also, SAP’s “everything” really does cover everything a big business is likely to encounter, which is a lot of things that all have to be interconnected
Thank you for this "everything for everyone" term.
I was not aware of it until now, and it perfectly explains those examples you provided.
It also explains why product managers are so focused on "personas". I guess that this, along with push-back on feature creep is a way to combat becoming "everything for everyone".
Of course that's true for small-medium companies, after a certain size it seems you welcome becoming "everything for everyone" as you're already entrenched in so many businesses.
Probably not. SAP is an everything-to-everyone product. Using Fred Brook's terminology for essential versus accidental, the problem with everything boxes is that even just the essential complexity of such a product is so insanely large that they are sufficient to produce a "horrid" product. Of course they don't have just the essential complexity and add a healthy dose of accidental complexity, but so would any putative "less horrid" replacement by the time it successfully solved the same essential problems as SAP.
Closer to home, "bug tracking" is an example of an everything-to-everyone product. I can't even count the number of times I've seen a "simpler, less horrid" bug tracker get started due to the perceived horribleness of the current bug tracker, but the new bug tracker simply became the old one once it tried to grow into the same niche. This may sound strange to 2022 ears, but I remember when JIRA was being pitched as the simpler solution and developers were pretty keen on it. There will never be a mature bug tracker that is any fun to use, because by the time it's everything to everyone it'll just be the same morass of being everything to everyone again. It turns out that the "less horrid" bug tracker wasn't actually intrinsically less horrid... it just wasn't everything to everyone. Instead it was a bug tracker for developers, so developers love it. But then if developers are going to be allowed to use it everywhere, it has to satisfy all the other stakeholders too, and it inevitably mutates into an everything for everyone product.
(See also: Salesforce. Letting users configure custom DB schemas is a key indicator of being an everything to everyone product. To some extent, programming languages too; there's a lot of people who pine for something simpler (such as the people who think that if we just went to visual languages, or tried to jam everything into "no code") and don't understand that by the time you have a general purpose language that is truly general purpose you've got a large amount of irreducible essential complexity whether you like it or not.)