Comment by blantonl | Hacker News Reader

Comment by blantonl | Hacker News Reader

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"

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.

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.

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.

When I worked in manufacturing IT for a F500, a full 20% of our IT organization was various flavors of Oracle support.

> Sailpoint

Oh gods, the painful flashbacks.

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.

One would figure you'd set up this autopay through the utility provider's website.

Many banks let you set this up directly with them - through their own site - via partner integrations with utility providers.

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.

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.

Username checks out. :-)

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.

People in the USA need to lobby for better and modern banking

https://en.wikipedia.org/wiki/Direct_debit#United_Kingdom

Not only does it not cost anything to the payer, the "Direct Debit Guarantee" also protects the payer from mistakes and fraud.

This isn't a new system, it's over 50 years old.

Paying bills shouldn't be a risky or expensive thing to do.

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.

> 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.

>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

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.

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.

> 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 ;)

Reply on news.ycombinator.com