I don't think there is a difference. I also think this is part of the reason why so many companies now don't have an Ops department. My own is an example of this, we've outsourced the Operations part to another company because our Developers are doing most of the Ops that isn't related to networking anyway. I'm not saying this is good by the way. It's just that developers tend to get caught in the "company" part of "company vs IT" because developers want to make stuff work first, and work correctly second where as IT has always been the other way around.
I don't necessarily disagree with everything the author writes by the way. There are a lot of good points in there about building things to be operational, but at the same time, what good is an operations department if it can't actually operate it's systems? I know the answer to this often becomes buying third-party software or "standard" systems, but as more and more businesses are realizing, that's often worse than simply using a lot of interconnected excel sheets (which doesn't really scale).
It'll be interesting to see what happens once the newer waves of project managers and it-business partners learn from the successes of companies that build in-house software instead of going to "standard" systems where they'd need the inhouse developers anyway to make the un-Godly amount of API's and data-transfers work. At least here in Denmark, companies like Lego and Vestas are doing some really groundbreaking money making at a much lower cost, by not going to "standard" systems for everything. Not that you should never use standard systems, there are somethings that are shared across businesses after all, but there are typically also a lot of things that just won't fit into some internationally shared box well enough for it to work out as a net bonus.
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?
Agreed, integration can be a challenge, but the key here is good enterprise IT architecture and avoiding SaaS sprawl.
> 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.
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.
> At least here in Denmark, companies like Lego and Vestas are doing some really groundbreaking money making at a much lower cost, by not going to "standard" systems for everything.
Do you have an link to an article about this somewhere?nn
I don't necessarily disagree with everything the author writes by the way. There are a lot of good points in there about building things to be operational, but at the same time, what good is an operations department if it can't actually operate it's systems? I know the answer to this often becomes buying third-party software or "standard" systems, but as more and more businesses are realizing, that's often worse than simply using a lot of interconnected excel sheets (which doesn't really scale).
It'll be interesting to see what happens once the newer waves of project managers and it-business partners learn from the successes of companies that build in-house software instead of going to "standard" systems where they'd need the inhouse developers anyway to make the un-Godly amount of API's and data-transfers work. At least here in Denmark, companies like Lego and Vestas are doing some really groundbreaking money making at a much lower cost, by not going to "standard" systems for everything. Not that you should never use standard systems, there are somethings that are shared across businesses after all, but there are typically also a lot of things that just won't fit into some internationally shared box well enough for it to work out as a net bonus.