One of the biggest struggles our client executives face when driving application transformation is around the balance between experimentation and control. Infrastructure leaders in particular have difficulty balancing the desire to provide developers the speed the business demands, while at the same time driving adoption of standard enterprise platforms.
This challenge is particularly acute for global enterprises with organizationally and geographically distributed software development teams. As these teams often sit with the business it’s natural that their loyalty is more closely tied to their internal customers rather than IT. As their business customers are providing constant pressure for speed and agility, app dev teams haven’t had the luxury of waiting for Corporate IT.
Application teams with a well-honed sense of survival have deployed Cloud Native application platforms on their own to enable continuous delivery, DevOps and microservices models. Open source tools and cloud platforms have provided applications teams with a variety of options including:
- Container services such as Docker
- Unstructured, ‘roll your own’ PaaS environments built using a tools-based approach with Kubernetes, Mesos, and/or other open source components.
- Structured PaaS platforms like Pivotal Cloud Foundry that native provide services like infrastructure services, logging and monitoring.
Many of the clients we work with have a variety of models in use across their organizations, including combinations of the models above. In fact just last week we met with a client whose CTO was able to identify five different Cloud Native application development platforms in use globally.
While the outcomes and impact from these ‘pockets of innovation’ across the enterprise are often impressive, we’re frequently asked the following questions by client IT executives:
- Do we need to drive a standard Cloud Native application platform across the enterprise? Or should we continue to allow software teams to experiment?
- If we standardize which Cloud Native platforms should we choose? Do we need a standard DevOps process and approach?
- How do we drive adoption of a standard Cloud Native platform without alienating teams who’ve invested in building their own models?
The biggest challenge of all, is that these aren’t really the right questions to be asking!
Given that the Cloud Native application platform space is still emerging, it’s helpful to consider Simon Wardley’s ‘Pioneers, Settlers and Town Planners’ model for how business activities typically evolve. The theory is based on the premise that over time activities evolve from innovative, custom models to productized, industrialized services. This requires different types of internal roles depending on the maturity of the activity:
- Pioneers are initially required who create the new and novel based on available components and services.
- Settlers eventually become involved who identify common patterns in how the services developed by Pioneers are being used across the organization.
- Town Planners figure out how to standardize and commoditize high volume activities and services once consistent, repeatable patterns have been identified.
And so we have the basic issue with the questions our CIO posed above – for most enterprises it’s premature to think about Town Planner issues when the Pioneers and Settlers are still doing their work. In this case the Pioneers are the various software development teams trying different platforms, tools and models to enable a true Cloud Native model. Trying to determine how to standardize and scale a chosen platform across the enterprise is just premature for most organizations today.
So back to our original questions. The right question to contemplate really is the following:
“Given the maturity of cloud native tools and services, what’s a CIO faced with multiple, disparate Cloud Native application platforms to do? Based on our experience here’s our advice:
Develop a point-of-view – first, understand the choices involved with Cloud Native application platforms as well as your desired objectives and business outcomes. What are you trying to achieve and why? What’s your North Star?
For example many unstructured PaaS approaches are perfectly fine if you’re a web-scale IT shop that needs to competitively differentiate on tools and platforms. But most enterprise face a singular challenge – deploy reliable code as quickly as possible to support the business.
Rather than spending time effectively becoming a custom tool chain SI, many enterprises will likely be better off exploring a structured (or opinionated) platform like Pivotal CF that standardizes and automates key platform services. While developers may lose some flexibility in a structured model, it’s important to understand true value of that flexibility and it’s underlying cost.
Regardless of the approach it’s critical to identify an explicit set of goals and objectives for Cloud Native development that will provide guiderails for choices going forward.
Provide carrots, not sticks – software development teams are more than willing to experiment with new tools and platforms. That’s what has created the various ‘pockets of innovation’ to begin with. So if you have a desired Cloud Native platform you’d like them to encourage them to use, create an environment to let them try it. Quickly stand up a test lab or pilot environment using for example EMC’s Native Hybrid Cloud (which can be stood up in just two days), provide some coaching and let them experience the benefits on their own. Provide a compelling vision to developers that drives interest, excitement and actual usage. Let them try it and see the benefits over what they’ve build and deployed on their own. Calling their baby ugly and mandating adoption will just lead to more use of shadow resources. And if the vision isn’t compelling enough to drive bottom-up adoption, well then you have a different problem.
Avoid the big bang – avoid the enterprise IT tendency to drive top-down mandates or policies around DevOps or Cloud Native platforms. In the era of cloud and developer empowerment bottom-up, viral adoption will always trump corporate mandates and policies. Top-down and policy driven mandate will alienate teams whose platform wasn’t ‘chosen’, and in some cases dis-incent experimentation.
Rather than stifle innovation with premature choices, better to let standards emerge based on success patterns and business impact. While there certainly should be an overall vision and guiding principles guiding choices around Cloud Native platforms, getting too prescriptive too early can create significant cultural and organizational risks.
As models and platforms mature over time, preferred Cloud Native models will certainly emerge based on experience. But better to let those choices naturally emerge from front-line success and experience. The key is to preserve the experimentation and empowerment of software development teams while also channeling and aligning these efforts with the Cloud Native vision and objectives.
For more information on application transformation services using cloud native tools please contact scott.bils@emc.com
