Cloud Migration

Ask Alex Part 5: There is no Cloud

Alex Jauch is a Group Product Manager for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.

In part five, he’ll answer the question: “What organizational changes should I make to prepare for the cloud era?”

As we discussed in our previous post, the primary difference between cloud and traditional IT is a fundamental shift in business model.

Or to put it another way, there is no cloud, there is just someone else’s datacenter.

The reality is that the center of gravity for enterprise IT has swung back and forth several times over the past 30 years. We have already seen multiple shifts of this type and thus, it is possible to make predictions about how this will evolve in the future.

Looking at the history of enterprise IT, we see several paradigm shifts from things like mainframes, to minicomputers and then later distributed computing. During these shifts, vendors have been disrupted and overall IT operating practices have shifted radically.

However, if you look closely, you will see a distinct pattern emerge. This is the shift in budget from central IT to the operating units and back again. This has happened several times. Normally, a shift in budget to operating units is made to allow them to move more freely and to push decision making down closer to the business owner. The theory here is that things will happen faster and better decisions will get made.

Over time this inevitably results in duplication and unnecessary spending. This, in turn, leads to centralization of budgets to contain costs. This centralization tends to lead to cost controls that ultimately lead to less freedom of choice and usually results in less innovation within the organization.

If we concentrate on the difference between velocity driven IT decisions vs. cost driven IT decisions, the cloud transition becomes easier to conceptualize and manage. In this case, the decision is not cloud vs. on-prem, the decision is cost optimized vs. velocity optimized. You may still wind up on the same platform, but the reason why you made the choice is different.

In this context then, the question is a little different. The question now becomes:

“How do I optimize my IT organization for velocity-based IT decisions?”

And

“How do I optimize my IT organization for cost-driven IT decisions?”

These two questions have very different answers.

For most IT organizations, the idea of managing a stable infrastructure with a focus on ROI is already something you know how to do. Standardization, change management, architecture review, all of these processes are designed to manage cost and risk within your organization.

On the other hand, most IT organizations don’t have a strong background in velocity driven decision making. The implications of velocity driven decision making are that you may choose to accept a higher cost or take on additional technical risk in order to increase velocity.

The other aspect of this is that when we talk about velocity in the cloud sense, we are not simply talking about doing things faster. What we really mean is doing things MORE OFTEN. That is to say, rapid short cycles are preferred over infrequent larger cycles. The reason for this is the uncertainty inherent in velocity driven IT. Since you don’t know if the decision you are making is correct, don’t commit to it for a long period of time. Cycle very rapidly, find out if that’s the right thing and be ready to change as needed.

Thankfully, the software industry has done a great job of learning how to make velocity driven technology systems work. The entire concept of agile, scrum and other related systems comes from this notion of velocity requiring rapid iterations in the field of software development.

There are many, many variations on the theme, but there are some common threads here:

  • Focus on customer success. Build your backlog with customer stories, prioritize those stories, execute against that backlog in priority order.
  • Rapid iterations. Take projects and break them down into very small iterations. Two weeks is ideal. Try to ship every day.
  • Test. Once you have a story that works, test that story with your customers. You can actually do this internally much easier than externally because your customers are right there inside the company.
  • Make data driven decisions. Measure everything. The only way you know what to do is if you have data, if you don’t measure, you won’t have data. How do you know if your customers are happy? You ask them.
  • Small teams. Scaling agile up is hard. Most software companies who do this well, focus on enabling smaller teams with tools to help them execute. Amazon’s famous “two pizza rule” is a great example of this.
  • Re-use. Whether you’re talking about github or SaaS, great software teams steal… ahem, they “re-use” existing code, services and ideas. You need to do the same.
  • In summary, you can best prepare your organization for the cloud era by focusing on velocity driven IT and the principles that drive great software teams to higher velocity.