What's SAP?

The Bloomberg terminal does two things which make it much more approachable for beginners than you suggest. Don't know which function you need to do something? Type in what you want (and possibly hit HELP if it doesn't autocomplete for you) and you'll find it 9 times out of 10. The 1 time out of 10 that doesn't work, you start a chat with support and they'll point you in the right direction pretty well immediately.

The one slightly annoying thing is that for a lot of things there are at least 5 different ways to do the same thing/5 different screens with very similar functionality, and everyone seems to use a different one.

But it's also worth saying it's a tool specifically aimed at specialists - it's not going to hold back on giving you a huge number of options over which data you want and how you want it presented, and it's not going to warn you that some data might be incomplete or not the one 'everyone' uses.

Or instead of being trapped a monstrous framework, you can integrate off the shelf libraries (no forking needed) into your architecture.

Ask Rob Pike about Go vs Enterprise Java.

Nothing? I guess, or maybe I don't understand the question?

The research that was put into finding optimal processes for those non-differentiating business functions can of course be invalidated at a later time. We all put lead in gasoline because it seemed optimal, then later we kept putting it in gasoline well past the point it was known to be harmful, because everything was designed around it.

The author spends a whole section on "The importance of integration", the value being sold as "...the two [SAP] modules were able to seamlessly interact with each other since they shared the same database." and "because these [other] systems don’t interact, they needed to be synced regularly, and that often meant having a human manually move data around." ... "Integrated software solves this by facilitating communication".

In the very last paragraph of the article they then say "...on the back-end, most modern enterprise software (e.g. Salesforce, Jira, etc.) now have good APIs for exporting data. ETL + data lakes are on the rise...".

This is a mistake I see made a lot; not because of naivete tho': usually because the concerns cut across each other so much.

The economic and efficiency incentives around integration are very delicate. SAP is so complex that (assuming you can hire great engineers, which isn't necessarily a given outside the tech sector) you can probably build most of what you need with a small team that's much cheaper than SAP. However, you can't successfully (even with good access to great tech sector talent) grow that software as quickly or as broadly as what you'd get from SAP. You also carry a lot more risk. ...and that's risk outside of the core focus of your business. The article even includes one quote, "competitive advantage in this industry might just come from doing the best and cheapest job at implementing SAP." which recognises this as an operational rather than capital problem.

...but even if you can accomplish it, it's the integration that gives you the value. You're always going to have higher operational costs for your thing if you build it out of something like Salesforce and Jira sewn together with APIs. ETL is hard to do well for anything other than reporting (and even then it's not easy). Data lakes are the epitome of loosely integrated data structures. Most of the time they're a collection of files full of data in weakly-or-stringly typed formats such as CSV, JSON and XML. Getting at the domain models of the producing software is always a pain. For all these things, your talent pool for effective support is small and gets smaller as you add more products to the mix.

So the three options are:

1) Buy (+ professional services)

2) Build

3) Integrate (e.g. "Salesforce + Jira")

3 (Integrate) is the mistake because it's less than the sum of it's parts. You carry all the risk of "Build" and don't get the brand stability and integration of "Buy". Multiple vendors gives you more risk than a single one in this scenario because you're buying different things from different vendors. So now you have more chances for failure: failure or withdrawal of one of the vendors, API changes that you don't control, etc, etc.

As the SaaS markets become more mature I'd hope to see consortiums of vendors who had products that they would certify as working together. I don't think we're quite there yet tho'.

2 (Build) is the Big Bet because you're taking a capital expenditure approach to an operational problem. You're investing in intellectual property outside of your core business. ...and you own all the risk.

1 (Buy) is difficult because it is expensive and loads of things you want are still only sold on a professional services basis, rather than as a product. It's also a market designed for the large companies with between 6 and 9 figures to spend. It's also one of those infrastructure projects that is usually shaped as something that doesn't deliver any value until it has been rolled out everywhere. However, this is the option where you hold the least technical risk and most of the risk you do hold is related to abilities that are hopefully aligned with your existing skills of management and operational delivery.