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.