15 ms·

The hard part of Enterprise Software is the Enterprise, not the Software

118 points by mokarma 5y ago

burntoutfire 5y ago
Didn't read the article, but totally agree with the title. Having seen the level of complexity the business-side people (analysts, managers, product owners) have to deal with on a daily basis, I'll gladly work on our ridiculously overengineered k8s-based web app. It still seemed rather sane compared to the business side of bank.
- Guest42 5y ago
  I think for me that sometimes the large companies get over-siloed and that the small companies get over-scattered and under-funded. My best experiences have been at fairly large companies that are able to combine the better aspects of both and have enough flexibility within a defined set of processes, and the budget to support what’s going on.
  - lbriner 5y ago
    I wonder whether there is a curve of profitability that peaks in the middle and then goes down in both directions. We all know that most startups struggle to make a profit because they might not command premium rates and are growing. On the other hand, I can't imagine the crazy overheads of large corporates who can only make so much money because their prices are high. I once heard (a long time ago) about a company who had paid $15K for a custom carpet that was used for one trade show over a week and then thrown away.
- jarym 5y ago
  But the business side is where the big $$ is at.
  - raverbashing 5y ago
    Yes but work-life balance and mental health are priceless.
atonse 5y ago
Is this why Salesforce is so successful? It gives you a million enterprisey features (ad hoc reporting, role based access control, single sign on, user management, field level compliance) out of the box even if you’re managing a glorified spreadsheet?
- fredland 5y ago
  the internet is a glorified spreadsheet.
- zaphar 5y ago
  Salesforce is successful because it tells a story around how easy it it is to just get started. Startup cost in a frequently underrated datapoint in tool selection.
  - thrower123 5y ago
    Then there reaches a point where extracting the data and moving it to some other system becomes such an implacable task that it is cheaper to just keep paying the renewal POs.
    - rsj_hn 5y ago
      Is it really hard to extract data? That would appear to be an unnecessary friction and not in the interest of any serious vendor. I imagine the lockin is all the custom code you wrote for the platform. The data is portable, even the schema can be reproduced in a fairly straightforward way. But all your bespoke automation code is not portable.
      - thrower123 5y ago
        It shouldn't be, but there's always been very healthy industry niches around pulling data from one system and putting it into another one. Nothing ever lines up exactly, and there's always some idiosyncratic remapping or futzing that has to be done manually or with some one-off custom code, so it remains an expensive contract business.
BitwiseFool 5y ago
I would say 75-85% of all client Jira tickets my team receives are actually errors in processing client business logic, not programming bugs. Sadly, all the little edge cases and special processing rules are the hardest to document and capture properly in the code itself because the rationale is paragraphs long and often only makes sense when the product manager explains it.
- lbriner 5y ago
  So true. I commented earlier on another thread about enterprises being intent on very specific implementations and premature optimisation, which leads to very bespoke and therefore expensive software. We have a customer who "needs" to see their branches "scores" on the main dashboard regardless of the fact they could get that data somewhere else. We had to build a feature to win this customer that is only used by them and now have to maintain it forever. The small ongoing cost of maintenance never appears to be enough to say that we're not going to support it anymore and instead concentrating on the wider market and telling this customer to click another button!
  - kspacewalk2 5y ago
    >I commented earlier on another thread about enterprises being intent on very specific implementations and premature optimisation, which leads to very bespoke and therefore expensive software. This is often because enterprises look at total cost, whereas you're focused on software cost. >We have a customer who "needs" to see their branches "scores" on the main dashboard regardless of the fact they could get that data somewhere else. We had to build a feature to win this customer that is only used by them and now have to maintain it forever. Depending on the size of this customer, the frequency of an employee needing this stat, and the amount of seconds/minutes saved per lookup, productivity/salary costs of not implementing this feature might easily dwarf paying someone to maintain it.
    - atatatat 5y ago
      Right. That requires a slight increase in cost. One time very large, or ongoing.
GuB-42 5y ago
I have always wondered why reporting was always so complicated and broken in every company I worked with. By reporting I mean "I spent two days on this project, five on that one and took a day off, I also had to drive 50 km to the the customer's site so that's an expense.". Then I realized a lot was happening behind the scene, some of them being legal requirements with hefty fines if not done right. And all companies are different. And even though we have all these tools, I am impressed by how much tedious manual work is still done. For example, our poor assistant manager has to check that every expense is tied to the correct project, and the tools does nothing to help her (or us for that matter).
- _carbyau_ 5y ago
  I always figured it was because: 1. HR/Finance/etc buys and runs a package from 3rd party to meet their desires. This is fine. 2. Their desires include all employees enter in details and navigate forms for themselves, but they have to be approved by their manager. Top level management decision that this is fine. 3. The group specifying requirements is now divorced from the users. leading to : 4. very little thought given to user experience for vast majority of users.
lbriner 5y ago
I'm not sure if anyone has ever written about the problem with the staff being less committed than the software. It is easy for me to make some big long-lasting decision about something that gets encoded in software and then I can leave next year and everyone else has to live with that decision. I don't know how to solve that unless you write software to be hyper-modular and able to be modified without a complete rewrite of everything. Either that or keep it simple, build it quickly and throw it away after 2 years when everything needs to change.
- dharmab 5y ago
  > I don't know how to solve that unless you write software to be hyper-modular and able to be modified without a complete rewrite of everything. Isn't this how Salesforce ate the universe?
- 0xbadcafebee 5y ago
  Fast cycles are a good solution for a lot of those problems, but they can also be highly wasteful. There's this tendency to think that "building things" is always a good idea in The Era Of Software, but to me that's like a disposable house or disposable car. It's better to build it to last. I think the solution is Shift Left, but with really good experienced leads at every level that have a mandate to reject any shit from being merged that will be a maintenance nightmare down the road. That's the only way to be remotely sure that the launch date you've committed to is reasonable, and that you aren't signing yourself up for years of pain trying to claw back all the terrible crap that got merged just to meet the deadline.
  - neon_electro 5y ago
    What is “Shift Left”?
    - 0xbadcafebee 5y ago
      You should google it, there is a lot of writing on the subject. Suffice to say it is about doing something now once rather than doing it later at twice the cost and time.
gcanyon 5y ago
As a friend once said, "You can't software your way out of a process problem."
- davidivadavid 5y ago
  Pretty much. I'd attribute that common oversight to how natural it is to the average software developer to even think in terms of process vs. the average client they serve.
christkv 5y ago
Sometimes the demands feel like they are just bulletpoints added to make sure the specification document was long enough so it looks like they did some work.
mamcx 5y ago
Is like the old proverb about software: Is far easier to build an OS than an ERP system. I do this for life, and kind of like it. I like working on data manipulation and enjoy using relational databases and the others too. Business app allow you to face EVERYTHING that make you giggle as a developer. Is Monday doing stuff, nice web app, At 1:00Ppm the sky is falling and suddenly you need to port it to iOS/Android. Also the app was invoicing and now is half-debt collector with Uber-like geo support. FUUUUUUNNNNNN!
slver 5y ago
False dichotomy.
avgDev 5y ago
I came in to rewrite software that runs a warehouse. The old software, was half working but used for 10+ years, the source code provided was different than what was in production(original dev lost it LOL). As I decompiled the production version and met with managers to learn/document the process. I quickly learned that nobody knew the process. There were pieces of information in people's head, and in several old apps. However, nobody clearly understood the process, where the data is exactly stored or how the data flows. The app took more than a year to write but could have been written in 2-3 months if previous projects had decent documentation. To develop an app for an enterprise you really need managers to be on board, otherwise, the new app will suck just a bit less than the one it is replacing. There are politics involved and petty arguments. Many people are just unhappy at their jobs and it leaks into their work.
andreskytt 5y ago
I think it’s because enterprise architecture is taught and practiced as “architecture of software in a complex environment” rather than “architecture of a complex organization containing people and software “. A complex system with no architecture governance and rampant complexity cannot function sensibly and mr. Conway tells us there is a homomorphism between software and organization. I have been earnestly trying to fix this with an EA course I teach but the going is slow.
J_cst 5y ago
It's three good years now that I am consulting at a firm as a link between the company and ERP provider. At the time the presented problem was 'the ERP doesn't work'. Today the majority of the issues are resolved and it's pretty clear that the problem was the process, not the ERP (which, btw is far from perfect). My job is something between understanding and fixing the process plus reducing the software customisation requests. On top of that, just add your typical ERP with totally counter intuitive UIs and a bunch of users with an overall general aversion to changes. I love my job btw. (I've not read the article, but I like the topic and felt like to drop this comment).

118 points by mokarma 5y ago

Didn't read the article, but totally agree with the title. Having seen the level of complexity the business-side people (analysts, managers, product owners) have to deal with on a daily basis, I'll gladly work on our ridiculously overengineered k8s-based web app. It still seemed rather sane compared to the business side of bank.

Guest42 5y ago
I think for me that sometimes the large companies get over-siloed and that the small companies get over-scattered and under-funded. My best experiences have been at fairly large companies that are able to combine the better aspects of both and have enough flexibility within a defined set of processes, and the budget to support what’s going on.
- lbriner 5y ago
  I wonder whether there is a curve of profitability that peaks in the middle and then goes down in both directions. We all know that most startups struggle to make a profit because they might not command premium rates and are growing. On the other hand, I can't imagine the crazy overheads of large corporates who can only make so much money because their prices are high. I once heard (a long time ago) about a company who had paid $15K for a custom carpet that was used for one trade show over a week and then thrown away.
jarym 5y ago
But the business side is where the big $$ is at.
- raverbashing 5y ago
  Yes but work-life balance and mental health are priceless.

atonse 5y ago

Is this why Salesforce is so successful? It gives you a million enterprisey features (ad hoc reporting, role based access control, single sign on, user management, field level compliance) out of the box even if you’re managing a glorified spreadsheet?

fredland 5y ago
the internet is a glorified spreadsheet.
zaphar 5y ago
Salesforce is successful because it tells a story around how easy it it is to just get started. Startup cost in a frequently underrated datapoint in tool selection.
- thrower123 5y ago
  Then there reaches a point where extracting the data and moving it to some other system becomes such an implacable task that it is cheaper to just keep paying the renewal POs.
  - rsj_hn 5y ago
    Is it really hard to extract data? That would appear to be an unnecessary friction and not in the interest of any serious vendor. I imagine the lockin is all the custom code you wrote for the platform. The data is portable, even the schema can be reproduced in a fairly straightforward way. But all your bespoke automation code is not portable.
    - thrower123 5y ago
      It shouldn't be, but there's always been very healthy industry niches around pulling data from one system and putting it into another one. Nothing ever lines up exactly, and there's always some idiosyncratic remapping or futzing that has to be done manually or with some one-off custom code, so it remains an expensive contract business.

BitwiseFool 5y ago

I would say 75-85% of all client Jira tickets my team receives are actually errors in processing client business logic, not programming bugs. Sadly, all the little edge cases and special processing rules are the hardest to document and capture properly in the code itself because the rationale is paragraphs long and often only makes sense when the product manager explains it.

lbriner 5y ago
So true. I commented earlier on another thread about enterprises being intent on very specific implementations and premature optimisation, which leads to very bespoke and therefore expensive software. We have a customer who "needs" to see their branches "scores" on the main dashboard regardless of the fact they could get that data somewhere else. We had to build a feature to win this customer that is only used by them and now have to maintain it forever. The small ongoing cost of maintenance never appears to be enough to say that we're not going to support it anymore and instead concentrating on the wider market and telling this customer to click another button!
- kspacewalk2 5y ago
  >I commented earlier on another thread about enterprises being intent on very specific implementations and premature optimisation, which leads to very bespoke and therefore expensive software. This is often because enterprises look at total cost, whereas you're focused on software cost. >We have a customer who "needs" to see their branches "scores" on the main dashboard regardless of the fact they could get that data somewhere else. We had to build a feature to win this customer that is only used by them and now have to maintain it forever. Depending on the size of this customer, the frequency of an employee needing this stat, and the amount of seconds/minutes saved per lookup, productivity/salary costs of not implementing this feature might easily dwarf paying someone to maintain it.
  - atatatat 5y ago
    Right. That requires a slight increase in cost. One time very large, or ongoing.

GuB-42 5y ago

I have always wondered why reporting was always so complicated and broken in every company I worked with. By reporting I mean "I spent two days on this project, five on that one and took a day off, I also had to drive 50 km to the the customer's site so that's an expense.". Then I realized a lot was happening behind the scene, some of them being legal requirements with hefty fines if not done right. And all companies are different. And even though we have all these tools, I am impressed by how much tedious manual work is still done. For example, our poor assistant manager has to check that every expense is tied to the correct project, and the tools does nothing to help her (or us for that matter).

_carbyau_ 5y ago
I always figured it was because: 1. HR/Finance/etc buys and runs a package from 3rd party to meet their desires. This is fine. 2. Their desires include all employees enter in details and navigate forms for themselves, but they have to be approved by their manager. Top level management decision that this is fine. 3. The group specifying requirements is now divorced from the users. leading to : 4. very little thought given to user experience for vast majority of users.

lbriner 5y ago

I'm not sure if anyone has ever written about the problem with the staff being less committed than the software. It is easy for me to make some big long-lasting decision about something that gets encoded in software and then I can leave next year and everyone else has to live with that decision. I don't know how to solve that unless you write software to be hyper-modular and able to be modified without a complete rewrite of everything. Either that or keep it simple, build it quickly and throw it away after 2 years when everything needs to change.

dharmab 5y ago
> I don't know how to solve that unless you write software to be hyper-modular and able to be modified without a complete rewrite of everything. Isn't this how Salesforce ate the universe?
0xbadcafebee 5y ago
Fast cycles are a good solution for a lot of those problems, but they can also be highly wasteful. There's this tendency to think that "building things" is always a good idea in The Era Of Software, but to me that's like a disposable house or disposable car. It's better to build it to last. I think the solution is Shift Left, but with really good experienced leads at every level that have a mandate to reject any shit from being merged that will be a maintenance nightmare down the road. That's the only way to be remotely sure that the launch date you've committed to is reasonable, and that you aren't signing yourself up for years of pain trying to claw back all the terrible crap that got merged just to meet the deadline.
- neon_electro 5y ago
  What is “Shift Left”?
  - 0xbadcafebee 5y ago
    You should google it, there is a lot of writing on the subject. Suffice to say it is about doing something now once rather than doing it later at twice the cost and time.

gcanyon 5y ago

As a friend once said, "You can't software your way out of a process problem."

davidivadavid 5y ago
Pretty much. I'd attribute that common oversight to how natural it is to the average software developer to even think in terms of process vs. the average client they serve.

christkv 5y ago

Sometimes the demands feel like they are just bulletpoints added to make sure the specification document was long enough so it looks like they did some work.

mamcx 5y ago

Is like the old proverb about software: Is far easier to build an OS than an ERP system. I do this for life, and kind of like it. I like working on data manipulation and enjoy using relational databases and the others too. Business app allow you to face EVERYTHING that make you giggle as a developer. Is Monday doing stuff, nice web app, At 1:00Ppm the sky is falling and suddenly you need to port it to iOS/Android. Also the app was invoicing and now is half-debt collector with Uber-like geo support. FUUUUUUNNNNNN!

slver 5y ago

False dichotomy.

avgDev 5y ago

I came in to rewrite software that runs a warehouse. The old software, was half working but used for 10+ years, the source code provided was different than what was in production(original dev lost it LOL). As I decompiled the production version and met with managers to learn/document the process. I quickly learned that nobody knew the process. There were pieces of information in people's head, and in several old apps. However, nobody clearly understood the process, where the data is exactly stored or how the data flows. The app took more than a year to write but could have been written in 2-3 months if previous projects had decent documentation. To develop an app for an enterprise you really need managers to be on board, otherwise, the new app will suck just a bit less than the one it is replacing. There are politics involved and petty arguments. Many people are just unhappy at their jobs and it leaks into their work.

andreskytt 5y ago

I think it’s because enterprise architecture is taught and practiced as “architecture of software in a complex environment” rather than “architecture of a complex organization containing people and software “. A complex system with no architecture governance and rampant complexity cannot function sensibly and mr. Conway tells us there is a homomorphism between software and organization. I have been earnestly trying to fix this with an EA course I teach but the going is slow.

J_cst 5y ago

It's three good years now that I am consulting at a firm as a link between the company and ERP provider. At the time the presented problem was 'the ERP doesn't work'. Today the majority of the issues are resolved and it's pretty clear that the problem was the process, not the ERP (which, btw is far from perfect). My job is something between understanding and fixing the process plus reducing the software customisation requests. On top of that, just add your typical ERP with totally counter intuitive UIs and a bunch of users with an overall general aversion to changes. I love my job btw. (I've not read the article, but I like the topic and felt like to drop this comment).