| This is a great comment and thanks for the feedback. I should have clarified the context and my experience. I was thinking this is a process for dealing with legacy bloat and mostly internal IT systems (IT Architecture) in mostly stable Fortune 500 size companies that are already operating at scale. From what I’ve seen, big shifts are often a one time “transformation” with lock-in to a service. In cloud it’s azure or AWS or GCP. Or companies are stuck on legacy exchange and can’t move to O365 without a major initiative. Or there is no viable path to move from Microsoft to Google. These things only occur with great pain, and resources aren’t often provided to reconsider alternatives and to stay current. I picked three years because things tend to operate at that pace at large organizations. It’s probably a faster upgrade cycle than where most of those companies are today. It would be interesting to go back to the drawing board with the business lines to develop tech internally to better support them. Lots of stuff is just operating on terribly outdated systems. There is some lock-in (e.g. we’re going to use O365 for our office products for the next 3 years), but it would increase bargaining power because your org could actually migrate away. For a lot of applications I agree with what you are saying - pick a good architecture and stick with it. And I don’t think there would be a need to change the way the company works for the sake of change, but I’ve seen enough big shifts that it makes me think a total redesign of an organization’s architecture every few years (or at least considering it) would be useful. Right now a big advantage to startups is that they can design much more efficient IT models than most legacy large corps. I know if I could start from scratch I’d do a lot of things very differently and could show major cost, efficiency, and security improvements. So the idea would be to take a team who knows the company, break them off and say “build an architecture for the organization that will go live in 3 years” - take the best of the current environment and tool set, integrate new tech and security, and we will start moving users to the environment in 3 years. Then you get to run that for 3 years while the other team does the same thing. You’re right on turnover point. I think the whole goal of this would be to never go more than 3 years without seriously considering alternatives for major systems (ERP, HR, Security tools) while giving the chance to have it all be integrated and put into place as a cohesive design. |