Many companies and government agencies adopt a “top-down” approach in setting IT policy, making sure technology is secure before approving it for organization-wide use. Some, conversely, employ a “bottom-up” approach, allowing individuals and offices to innovate, and then adopting those experiments that have successful results to improve the organization-wide technology infrastructure.
Which is better? Or are both needed? How do you choose an approach to moving to cloud?
In the early 2000s, in the wake of the Internet Bubble bursting, the influence of the CIO skyrocketed as they took steps to control costs. Using strategies that were sometimes called “ruthless standardization,” edicts would come from the C-suite about what combinations of technologies could be used in IT. We heard pronouncements like “Thou shalt not use LAMP stacks but instead Java Web applications with Oracle (News – Alert) databases.”
The good news about top-down driven technology decisions is that they tend to be cost-effective. With the CIO behind them, pricing from the major technology vendors, cloud Infrastructure-as-a-Service companies here, is usually excellent. The bad news is that they are typically limiting when it comes to innovation. If the CIO decrees that you can only use Oracle databases, for example, you may miss out on the NoSQL trend that opened up a completely new way of thinking about data management. At the beginning of the 21st century, that happened more frequently than people tend to remember.
What lessons can we learn from the top-down technology decisions of the past when examining cloud adoption? The key to a good top-down approach is flexibility. Technology changes too quickly to rely completely on five-year licensing agreements, but without them costs can spiral out of control. A Cloud First strategy doesn’t mean Cloud Only strategy. Rather, it gives development teams a starting point they can argue out of if they can prove alternatives are more beneficial.
On the flip side of the coin is a bottom-up approach, where executives rely exclusively on developers to push innovations up the chain of command. In the late 1990s, agile development methodologies were a good example of this. Frustrated with waterfall methods that were standard at the time, and which relied on long release cycles with all requirements being specified before any code was written, developers flocked to a very different paradigm where minimum viable products were built and then iterated over many, much shorter releases. This eventually led to the DevOps and Continuous Integration/Continuous Delivery approaches that are commonplace today.
Innovation can spring more easily from a bottom-up approach, but it often takes time for what can be competing alternatives to emerge with a winner. And what works for one part of a business may not for another, given contextual differences. For example, should a particular team use Amazon Web Services (News – Alert) or Microsoft Azure for its public cloud hosting? Ask 10 different development teams this question and you’ll likely get a split vote, with teams basing their opinions on specific features they need that only one vendor provides, or a geographically more advantageous data center that one development team needs but others do not.
Why Both Are Needed
In reality, a little bit of both approaches is needed. An executive might make a declaration like what the U.S. CIO did in 2014 for federal agencies with the Cloud First strategy. In other words, having a default position set by upper management but setting criteria under which another technology choice can be made by development teams is the way to go.
That might mean that the CIO selects (and gets great pricing on) one private cloud and one to two public clouds on which development teams are allowed to deploy workloads as the top-down portion of an approach. But within those clouds, let development teams use whatever derivative services each cloud vendor might provide, along with whatever open source they would like, including making use of more cutting edge technologies like containers or Function-as-a-Service. This gives the bottom-up approach some room to grow innovation, but with some guiderails set by the top-down edict that controls costs without stifling creativity.
This blog originally appeared on The Cloud Computing Magazine.