Build It!
In the last section we talked about the importance of starting small (and focused) to enable the organization to learn quickly and show early success. This means the organization’s leaders should foster a culture that promotes trial and error and experimentation. It also means learning how to run effective experiments (with reminders of what we learned in primary school science class about what an experiment is and what it is not).
We’ll call the first two components “getting organized” — why are we doing hybrid cloud and where are we focused so we can quickly show the value (and subsequently continue after that). Now that you’re organized, you need to start building it.
Building what? Building the hybrid cloud platform and all the components required — from standing up the technology, to writing guides on how your IT organization will use it, to ensuring that you have an approach to keep the platform updated and running with zero downtime, to applications running on the platform. The net — it is much more than simply installing a new “hybrid cloud” product from a vendor.
Let’s check in on our hero, Sam, and her organization’s journey to hybrid cloud.
Now that she’s narrowed the scope with the hope of demonstrating the value of hybrid cloud quickly, our protagonist Sam is ready to build the platform. How should she approach this?
a) NBD (no big deal), because while some of her team was working with the application teams to find low hanging fruit to demonstrate quick value, another part of her team was installing the technolpgy and getting the first iteration of the platform operational.
b) Time to call procurement! Sam has the vendors lined up and she needs to get that process rolling. The business case is ready for their projected ROI and approvals will be no issue.
c) It’s not even time to call procurement yet! Sam needs to take the plan to her boss and the project governance board for approval, then she can call procurement.
Unfortunately, too many times we get wrapped up on some of these “required” but non-value activities. They slow us down, which — interestingly enough — when we’re talking about the very survival of the business can have a compounding negative impact.
The saving grace is that vendors want to provide the flexibility for you to grow as you learn and build success. While we have our preferred vendor (you can see some of the technical details of our implementation in the technical article in this series, coming in 2 weeks), we realized that the actual work wasn’t with installing the hybrid cloud platform tech; the hard work was with integrating and operating in a new way — a way that would allow us to create value from the technology and start to fundamentally shift the way the entire IT organization operated.
To sum it up, we developed three phrases that succinctly articulate the work and how we had to approach it: hybrid, integrated, and open. Let me break it down for you:
Hybrid
We have to ensure that our hybrid cloud platform provides a consistent experience, regardless of whether the application workloads are physically running on our private cloud, public cloud, or across both (great examples of microservices and web user interfaces in public cloud containers and the half-century-old massive database running on the mainframe in our private cloud). At the end of the day, our hybrid cloud platform needs to go beyond self-service and deliver the end-to-end experience that gives the types of applications that the IT organization supports one place to do what they need to do.
Integrated
Standing up tech on its own doesn’t have much value if you need to create an entirely new operating model to run it. IT departments have existing tools like the CMDB, existing security standards that dictate decisions on how your platform will be stood up, monitoring tools that need to be integrated, and existing ways that the application teams create and deploy their application artifacts. All of this needs to be taken into account and it’s where most of the work will be.
Open
When you build and integrate, it is critical that you do the “right things at the right time”. Going off and building a platform and then telling the scope of app teams “hey, we’re ready for you now” won’t fly (did it ever?). Getting feedback from the platform consumers every step of the way is critical to success. A great rule of thumb we used was 50% of the capabilities we implement are driven by what the platform consumers need and when they need them. What are some examples? When to implement multi-region capabilities; how to allow application teams to deploy through a consistent and secure approach in ways that aren’t disruptive to their development practices (e.g., do you allow CLI access first to deploy apps or do you allow only bring-your-own-image?) What are some examples of the non-consumer-driven capabilities? IT security standards, integration with the CMDB, artifacts for audit and compliance.
What did we learn here? First, just like starting small allows us to quickly show value, we need to get moving quickly as we’re identifying the initial scope — this will change, but move fast and don’t delay. Second, you need to build in a hybrid, integrated, and open way. With these components in mind, you’ll move quickly and start to generate value for your organization.
Stay tuned for some lessons we’ve learned in this step on leadership and in getting into some of the technical nitty-gritty.
Matt Lyteson is Vice President of CIO Hybrid Cloud Platforms at IBM based in RTP, North Carolina. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
