5 ms·

This is literally enterprise software in a nutshell. If you've ever wondered what the "Enterprise Application Server v21.5™ now with AI, Chatbots, LDAP, Active

This is literally enterprise software in a nutshell. If you've ever wondered what the "Enterprise Application Server v21.5™ now with AI, Chatbots, LDAP, Active Directory Integration, Orchestration, and Web 3.0" experience looks like, this is it. This is what happens when you bring enterprise software into the general public's view. This is what enterprise software customers see every day. Remember, at some point in the rollout of this dog, the team sat in a conference room and came to the right conclusion that the portal is terribly difficult to navigate, and thus the bright idea to write an 21 page PDF instruction manual for the portal was handed off to a 18 person team. Edit update: The "Enterprise Chatbot Integration Plugin v2.1™ for Enterprise Portals - Enterprise Application Server v21.5" was an add on kicker for $1.6MM license revenue and $3.8MM for 21 years of support. This plugin was developed by one person who works for EnterpriseSoftwareCorp Inc at the behest of sales and marketing and management that decried "we must have a Chatbot AI offering for our enterprise customers because they are asking why we don't." The sales exec who inked the contract after the Broadcom merger ended up #4 in the company for sales, went to Hawaii for the EnterpriseSoftwareCorp President's club awards presentation. The Broadcom engineer who was forced to implement this plugin into the Portal just copied the example from the docs (a template of links) and realizes he'll really have to roll his own LLM to add any real capabilities to the bot. But, he was able to check the box that says "we have a chatbot"

antisthenes 2y ago
I don't think all enterprise websites are this bad. Certainly my utility websites (e.g. electric/gas) are a lot more functional and a lot less user hostile, because...those companies would really like it if you paid your bill on time, so at least that workflow is pretty polished.
- fein 2y ago
  You aren't dealing with the enterprise site at that point - rather a public frontend that uses some enterprise-y backend. The real fun begins when you get into the actual enterprise frontends for internal use like SAP Netweaver and Sailpoint, which end up being quite a lot like the broadcom experience in the article.
  - not2b 2y ago
    It's a racket. It might not be as common today, but I remember when there were lots of people whose career was based on their SAP expertise, and the reason they got hired was that no one else could deal with that crap if anything went wrong. Once a lot of those people get into big companies, their career is based on preventing their employer from dumping SAP (or equivalent) for something better. So, it's like they have agents inside all the large companies that use their stuff.
    - eitally 2y ago
      When I worked in manufacturing IT for a F500, a full 20% of our IT organization was various flavors of Oracle support.
  - duozerk 2y ago
    > Sailpoint Oh gods, the painful flashbacks.
- Sesse__ 2y ago
  Wait, you need to go to a website to pay your electric bill? Mine is auto-deducted from my bank (up to a certain monthly maximum that I have set myself). You get bills directly in your bank, and then approve (possibly allowing auto-deduction for future cases) or modify or ignore them as you see fit.
  - MH15 2y ago
    One would figure you'd set up this autopay through the utility provider's website.
    - GrinningFool 2y ago
      Many banks let you set this up directly with them - through their own site - via partner integrations with utility providers.
    - Sesse__ 2y ago
      Uh, why? Why would I need to go through a different procedure between each entity I want to pay? After all, the point of a bank is to make unified transfer procedures between entities.
  - BizarroLand 2y ago
    It's only if you don't set up autopay, but you usually have to go to the website for the first time at least to set up the autopay.
    - Sesse__ 2y ago
      Username checks out. :-)
  - dsr_ 2y ago
    I bet a shiny nickel that you live in a place where the liability for a mistake in this procedure is between the bank and the utility company, not on you. Over in the USA, setting up a bill autopay for a variable amount generally involves a credit card intermediary with a 2-4% rake or a lot of risk to you.
- eitally 2y ago
  I think the point they were trying to make is that enterprise software (served as SaaS for internal-to-the-business users) frequently has awful UX. Think things like SAP & Oracle (or anything Oracle has acquired, like Cerner, AgilePLM, etc) -- those big, heavy, complicated enterprise softwares rife with decade(s) of technical debt and no-longer-understood features that were tied to long forgotten business or technical requirements and created by commodity developers who weren't particularly skilled or particularly knowledgable about their domain. I ran an Enterprise Apps org for a F500 where IT was purely a cost center and we created crap like this all the time.
- kodama-lens 2y ago
  > Certainly my utility websites (e.g. electric/gas) are a lot more functional and a lot less user hostile, because...those companies would really like it if you paid your bill on time, so at least that workflow is pretty polished. Your utility websites are customer facing and everything that the user can't do themselves will result in a phone call or a ticket wich will directly drive up cost. In enterprise it is the opposite. Whatever the costumer cant do themselves requires a ticket. Any ticket or fast ticket response requires support wich increases revenue. I just had a meeting with someone from IBM last week about API Connect, they admit that their docs suck and are wrong in places. It is typical enterprise software, slow and cumbersome, just as reported by OP.
  - Vilian 2y ago
    >In enterprise it is the opposite. Whatever the costumer cant do themselves requires a ticket. Any ticket or fast ticket response requires support wich increases revenue. this make so much sense, but i never thought about it
yungporko 2y ago
honestly this isn't that bad imo. i've seen, used, and been forced to make stuff that is way worse than this. it's just the natural result of the corporate development process and it's virtually impossible to not end up with something that strongly resembles the broadcom site. you get one guy who just comes up with ideas in the shower and then drops a message on microsoft teams at 9:30pm telling the team to make it so, and you also have any manager even remotely involved with anybody who uses the product able to dictate features and functionality too, none of these people have experience in technical roles and are either sales, ex-sales or ex-scrum masters. then finally at the end of the human centipede, you have a bunch of .NET-brained pseudoprogrammers sitting in a circle nitpicking and debating the most "correct" way to split up and size the current thing and then cram it into the existing mess until you end up with a plan of action that is a combination of multiple ideas which may have once been half decent in isolation but the result is a steaming pile of human shit.
- nogridbag 2y ago
  I've been building enterprise software for a while, but in smaller startups. In all cases we've taken pride in our UX. In the current product I'm building, the domain experts are a generation older than myself and the mockups and designs they produce reflect that. If we just recreated their spec to the pixel, our application would fit right in on a Windows 95 desktop. Yet if you were to look at our application, it has a clean, modern, user friendly design. To accomplish that required me to occasionally push back when they were set in their ways or some cases just ignoring the requirements and building out certain functionality my way. The domain is sufficiently complex that we don't have a ton of time to focus on UX. So the most important thing was setting the general UX patterns from day 1 and mandating developers follow that early on.
  - ghusto 2y ago
    > I've been building enterprise software for a while, but in smaller startups. These words you are using, I do not think they mean what you think they mean ;)

antisthenes 2y ago

I don't think all enterprise websites are this bad. Certainly my utility websites (e.g. electric/gas) are a lot more functional and a lot less user hostile, because...those companies would really like it if you paid your bill on time, so at least that workflow is pretty polished.

fein 2y ago
You aren't dealing with the enterprise site at that point - rather a public frontend that uses some enterprise-y backend. The real fun begins when you get into the actual enterprise frontends for internal use like SAP Netweaver and Sailpoint, which end up being quite a lot like the broadcom experience in the article.
- not2b 2y ago
  It's a racket. It might not be as common today, but I remember when there were lots of people whose career was based on their SAP expertise, and the reason they got hired was that no one else could deal with that crap if anything went wrong. Once a lot of those people get into big companies, their career is based on preventing their employer from dumping SAP (or equivalent) for something better. So, it's like they have agents inside all the large companies that use their stuff.
  - eitally 2y ago
    When I worked in manufacturing IT for a F500, a full 20% of our IT organization was various flavors of Oracle support.
- duozerk 2y ago
  > Sailpoint Oh gods, the painful flashbacks.
Sesse__ 2y ago
Wait, you need to go to a website to pay your electric bill? Mine is auto-deducted from my bank (up to a certain monthly maximum that I have set myself). You get bills directly in your bank, and then approve (possibly allowing auto-deduction for future cases) or modify or ignore them as you see fit.
- MH15 2y ago
  One would figure you'd set up this autopay through the utility provider's website.
  - GrinningFool 2y ago
    Many banks let you set this up directly with them - through their own site - via partner integrations with utility providers.
  - Sesse__ 2y ago
    Uh, why? Why would I need to go through a different procedure between each entity I want to pay? After all, the point of a bank is to make unified transfer procedures between entities.
- BizarroLand 2y ago
  It's only if you don't set up autopay, but you usually have to go to the website for the first time at least to set up the autopay.
  - Sesse__ 2y ago
    Username checks out. :-)
- dsr_ 2y ago
  I bet a shiny nickel that you live in a place where the liability for a mistake in this procedure is between the bank and the utility company, not on you. Over in the USA, setting up a bill autopay for a variable amount generally involves a credit card intermediary with a 2-4% rake or a lot of risk to you.
eitally 2y ago
I think the point they were trying to make is that enterprise software (served as SaaS for internal-to-the-business users) frequently has awful UX. Think things like SAP & Oracle (or anything Oracle has acquired, like Cerner, AgilePLM, etc) -- those big, heavy, complicated enterprise softwares rife with decade(s) of technical debt and no-longer-understood features that were tied to long forgotten business or technical requirements and created by commodity developers who weren't particularly skilled or particularly knowledgable about their domain. I ran an Enterprise Apps org for a F500 where IT was purely a cost center and we created crap like this all the time.
kodama-lens 2y ago
> Certainly my utility websites (e.g. electric/gas) are a lot more functional and a lot less user hostile, because...those companies would really like it if you paid your bill on time, so at least that workflow is pretty polished. Your utility websites are customer facing and everything that the user can't do themselves will result in a phone call or a ticket wich will directly drive up cost. In enterprise it is the opposite. Whatever the costumer cant do themselves requires a ticket. Any ticket or fast ticket response requires support wich increases revenue. I just had a meeting with someone from IBM last week about API Connect, they admit that their docs suck and are wrong in places. It is typical enterprise software, slow and cumbersome, just as reported by OP.
- Vilian 2y ago
  >In enterprise it is the opposite. Whatever the costumer cant do themselves requires a ticket. Any ticket or fast ticket response requires support wich increases revenue. this make so much sense, but i never thought about it

yungporko 2y ago

honestly this isn't that bad imo. i've seen, used, and been forced to make stuff that is way worse than this. it's just the natural result of the corporate development process and it's virtually impossible to not end up with something that strongly resembles the broadcom site. you get one guy who just comes up with ideas in the shower and then drops a message on microsoft teams at 9:30pm telling the team to make it so, and you also have any manager even remotely involved with anybody who uses the product able to dictate features and functionality too, none of these people have experience in technical roles and are either sales, ex-sales or ex-scrum masters. then finally at the end of the human centipede, you have a bunch of .NET-brained pseudoprogrammers sitting in a circle nitpicking and debating the most "correct" way to split up and size the current thing and then cram it into the existing mess until you end up with a plan of action that is a combination of multiple ideas which may have once been half decent in isolation but the result is a steaming pile of human shit.

nogridbag 2y ago
I've been building enterprise software for a while, but in smaller startups. In all cases we've taken pride in our UX. In the current product I'm building, the domain experts are a generation older than myself and the mockups and designs they produce reflect that. If we just recreated their spec to the pixel, our application would fit right in on a Windows 95 desktop. Yet if you were to look at our application, it has a clean, modern, user friendly design. To accomplish that required me to occasionally push back when they were set in their ways or some cases just ignoring the requirements and building out certain functionality my way. The domain is sufficiently complex that we don't have a ton of time to focus on UX. So the most important thing was setting the general UX patterns from day 1 and mandating developers follow that early on.
- ghusto 2y ago
  > I've been building enterprise software for a while, but in smaller startups. These words you are using, I do not think they mean what you think they mean ;)