Sharing IT stories is the backbone of Cisco on Cisco, and architecture is the backbone of IT. What happens when you outsource ALL of your IT, including the architecture? Sure, it may sound like a good idea, and there definitely are positive aspects to outsourcing some parts of IT; but when you lose control of your architecture, IT becomes slow and outdated. In the video below I share how I respond to this common question of whether or not it is a good idea to outsource IT – the good, the bad, and the very ugly.
And the moral of this story: Outsource anything in IT – except architecture
Look around in your IT shop. Do you have a single large printout page denoting the graphic of the IT Enterprise Architecture in your company? Does Zachman ring a bell? Do you have Data, Process and Deployment views documented? Do you have an Enterprise Architect?
If you answered YES to most if not all of these then you better take a seat and then throw this all out. Get the biggest shredder you can or just light a match to those artifacts. Big IT architecture is dead. Some would say we the practitioners never really got there. I agree with that. Management turnover and turnover again, ITIL deployments, imploding financial systems and reductions in funding, virtualization that sneaked in the back door, cloud that entered through the front door; this all worked against us in building the perfect system model to live out the decade, let along the most recent fiscal quarter.
If you answered MAYBE or NO to most of those questions, good for you, but be careful. I will explain about that later. Monolithic IT architectures are gone. Do we really have a single version of the truth in that relational database? Probably not. Why is this important? The pace of innovation in the deployment of IT systems to solve real life problems at speed and scale has increased. In some ways we are willing to compromise on those desires for five nines of reliability to get the business results quickly.
Do you still need a well thought out architecture for your deployed systems? Of course! Do you need to design those deployment views for new models of application resiliency, ecosystems of federated data models, and the conclusion that even the CIO’s office can’t really control what the end users do with technology? Absolutely.
Why is this important to you? No matter what part of IT or the business you are in, make a small subtle shift in your psyche. Stop trying to control what you cannot. Focus on the end outcomes, and strive to make your piece of IT process or technology listen to your customers. If you are an architect, go broad, real broad, but focus on the micro-architectures. If you are a technologist, don’t just dwell on the speeds and feeds. Live a few days in the life of your users. Manage the change that occurs through small impactful steps.
Back to building flexible automation for fast moving architectures.