> The "not built here" attitude can create a serious sustainability challenge. There are a lot of problems that businesses need to solve for that are well solved already. It's very easy to assume you're the first to do or need x, but often it's not the case. As such, why create a development and support burdon when you can simply buy x at $/seat?

I don't disagree with your theory on this, and it's what is being preached at a lot of softer IT educations as well as IT management. The unfortunate truth is that it rarely plays out that way in the real world. At least not in my experience.

Not because it couldn't work, but because organisations tend not to do the necessary change-management to actually implement the standard system in a way that allows your "well solved problems" to fit into the box. This is why it's a very lucrative business to sell third party API's to standard solutions, because organisations always have their own little variations and differences. Maybe those variations and differences could be solved by changing the way the organisation does business, but that's not what happens, instead they buy extra development to get the API to make their square fit into the round hole, and the consequence is an endless line of in-house data services that translate and move data between systems.

Sometimes things gets so bad, that the business itself, actually goes back to solving things in Excel, and then have people manually move that input into the "standard systems" before it eventually becomes a nice RPA project, leading to even more technical debt.

This is not to say that it doesn't work. Because it does. You can run a business like that for a long time, but you're not going to maintain the growth you had before you settled into these.

> Agreed, integration can be a challenge, but the key here is good enterprise IT architecture and avoiding SaaS sprawl.

I wonder if there has ever been a place where the Enterprise Architecture wasn't a bunch of outdated documents that lived in a digital drawer somewhere because the only one who actually used it was the Enterprise Architect.

And I say this as someone who's worked on the national Enterprise Architecture of Denmark. https://www.kl.dk/okonomi-og-administration/digitalisering-o...

I don't think the theory of it is wrong as such, but I do think the academics who came up with it, expected the real world to be a better place than it is. You're never going to succeed with IT architecture in a world where every non-IT manager doesn't care, and that's the world we live in. Even here in Denmark in one of the most digitalized countries in the world. You can feel like you're succeeding within your own ivory tower, but if none of your projects reap any form of benefits from it, and the organisation still violates everything you've build because they wanted X and signed the contract before they even asked you if it would fit in, well...

I'm not against standard systems, mind you. I completely agree that if you can find a box that fits, then you should certainly buy it. I just rarely see that outside of support systems like HR systems, because as soon as it's about the actual business of an organisation, then it's never similar to others. Because if it was, then there likely wouldn't be a company to begin with, as you can't compete by doing exactly what others do. At least not until you're big enough to stagnate.