Marrying the Business Need With Technology Drive: Recapping It All
Throughout the past four blogs in this series we have harkened back to some of the same key points. Today, we will recap.
1) Not everything that glitters is gold, so use your common sense. If you can’t find a physical world comparison, don’t do it. A good example here would be if a large cloud provider was trying to explain to you that you’re a bigger cybercrime target than them because you are a well-known company, and they work with several three- letter agencies and your top three competitors. That’s a red flag – they can’t do all that and be a less likely cybercrime target.
2) Try to take the time to understand how it has been done in the past. Sometimes change just for the sake of change can be a bad thing. Yes, Devops teams like to be different and sometimes can use automation to make things more efficient, but that doesn’t mean you should shy away from tried and tested solutions. A good example here is ADCs. Many infrastructure teams use full blown, ADC solutions to optimize application performance (TCP multiplexing, caching compression, HTTP2, etc.), decrease server resource requirements (by offloading resource intensive functions like SSL), application performance monitoring and web application security. Most Devops teams have not realized this and in the quest to be faster, have immeasurably increased complexity and time to market by de-aggregating tools. They still need the functionality but now they are using multiple tools or taking the time to code the functionality themselves.
3) The larger IT concepts tend to return and recede, then return again. Centralized compute used to be housed in a mainframe, then went distributed, now a new type of centralized. As in all things, history tends to repeat itself so don’t forget to look at the past in order to see the future. You don’t have to go full cloud – most companies are saying they can and will, but very few have fully made the move. To be fair, in some cases it simply doesn’t make sense. This decision tree is popular and seems to make the most sense: SaaS where you can, cloud where the business case and economics match up, and use a data center where you must. For those who say there is nothing that must remain in the private data center, I suggest you consider the risk of moving critical infrastructure to a shared environment. However well segmented, it only introduces more risk. The same should be acknowledged for some medical and banking environments. The SaaS world is growing quickly in both the medical and banking sectors, both of which have had instances of institutional failure because of things like DDoS attacks, which would have had limited effects if the systems had been internally hosted.
4) Understand your business’s end goal. This should be obvious but agility sometimes trumps cost and sometimes cost trumps agility. In the vast majority of cases, my friends and clients have had massive increases in costs once they moved to the cloud. Like most, they sold the cloud as a cost-saving mechanism. In reality the spend shifted from CAPEX to OPEX but the spend did not go down. It increased, the enhanced agility coupled with frictionless (baseline purchasing) increased spend significantly by removing many financial controls that were traditionally in place to stop unplanned expense increases. Having said that, agility and time to market have in most cases been increased in a linear fashion alongside cost.
[You might also like: Marrying the Business Need With Technology, Part 3: Re-aggregating the Tools]
5) Lastly, don’t be too rigid. Just because one model works for one part of your business doesn’t mean you can’t have a different model for another part of your business. Too often I see organizations saying we will be “all cloud,” and in some cases they have even sold their data center in order to make sure there is only one way forward. I think this is a very myopic view on the world, because it takes a point in time and makes it the future. Any of us in IT know that the world doesn’t stay the same for long. Instead of picking a model and forcing your business to adopt it, model your IT structure to your business goals and realize that like anything in life, it can and does change.
Hopefully this last blog series has given you some food for thought and stimulated the architectural juices.
