Green Light, Red Light: IT’s Dilemma After The Cloud Goes Live

November 10, 2011 Appirio

Jason Ambrose (@jasonambrose)

We talk a lot about the benefits of cloud apps in this blog but taking full advantage of the cloud takes more than just a successful roll-out. What happens after go-live is just as important. We’ve noticed a curious – and, in hindsight, unsurprising – trend among some customers and the industry overall when it comes to cloud applications going live in production. The story goes something like this:

  • Company buys in (literally) to the idea that the rate of change for multi-tenant cloud platforms will deliver more innovation over time 
  • Migrates their first major business application to the cloud, their breath taken away by a steady diet of green status reports, weekly changes during sprints, and an implementation five times faster and half the cost of traditional implementations 
  • Experiences an enormously successful launch, resulting in many dogs or children being named Marc and/or Benioff 
  • The good times come to a screeching halt when the app hits production and IT’s governance takes over 

This reminds me of the “Red Light, Green Light” game where kids gleefully run at full speed until the person playing the role of Stoplight says, “Red light!” (Guess which one is IT in this case?) In this game, one of three things happens:

  1. The kids ignore the Stoplight (“Green light! Green light! Green light!”). Usually, it’s all fun until someone falls and scrapes their knee. 
  2. The Stoplight stays red to keep the kids from running so fast. The Stoplight usually doesn’t last long in this scenario. 
  3. Everyone works together to follow the rules (or figure out new ones) and keep the game going. Punch and cookies for everyone! 

The last part is a hard challenge. In the Red Light, Green Light game, the rules are simple and don’t change all that often (depending on who the players are). But it’s different in the fast moving world of enterprise IT, and unfortunately today there are too many “Red Light” moments. Supporting enterprise applications is no kid’s game, and both sides have very legitimate reasons for their behavior. Business users need to sustain a rapid pace of change to adapt to rapidly changing markets. IT needs to ensure that changes don’t do more harm than good.

So what’s behind the challenge, and how can companies adjust?

If you look at how most production applications are still governed, not much has been adapted to the world of cloud applications. Things are still optimized to assume a negligible pace of change punctuated by major changes in keeping with waterfall releases. Consider this list:

  • User Support – Support teams follow detailed, exhaustive scripts and procedures (known as Runbooks). But what good is a runbook if the system changes every 2-4 weeks?
  • Knowledgebase/Documentation – Instead of relying on community knowledge, most companies depend on heavy conceptual documentation which takes a long time to write, update, read and understand. 
  • Change control – Rigorous change control processes borne of fragile legacy apps in complex environments tend to treat all change as equal – adding a field is given the same level of scrutiny as implementing a significant new module. 
  • Data governance – Business logic can change quickly, but it can take time to think through how the data should or shouldn’t change and how users should be educated to consume the changes. Integrations – Teams supporting integration layers or legacy systems cannot keep pace with a cloud platform’s rate of change. 
  • Release management – Blackout periods and boundary system release windows leave limited opportunities to promote changes even if the platform can support frequent deployment cycles. 

That’s enough change to send anyone crying to their parents. Here are some suggestions on how to get started:

Re-think your approach – Rule #1: There is no such thing as steady state. Embed change in the approach itself. Creative destruction within your processes should be mandatory. Leave room in your development planning to simplify your app and the architecture. Create a dynamic where your teams seek the minimum viable level of governance. Simplify.

Not all changes are equal – You need an express lane for changes that can occur with minimal risk. Tier your release schedule to account for light, medium and heavy changes. Heavily favor changes that have a high emotional impact with users – a big reward in relieving pain or thrilling users can overcome a lot of deployment risks.

Don’t be satisfied with the same old support – The good news is there are a lot of risks you no longer have to manage in this new world. With on-premise apps, you are stuck with a model involving heavy triage and oversight because you’re dealing with complex technical environments with siloed expertise. With cloud apps, much of that underlying complexity rests with the cloud provider freeing up teams to think more about the user and what makes them productive. Don’t be afraid to throw out Managed Service Providers who haven’t adapted to the new world and simply want to get paid for showing up and forcing you to live by their rules. Don’t trade low-value hours (commodity support labor) for high-value hours through the inconvenience of deceptively named “self-service” practices.

It can seem daunting to accept these challenges but it can be liberating with the right approach and focus. The very premise of adopting cloud computing is to relieve your team from the burden of managing hardware and systems. With that relief comes the opportunity to think about how to focus more on your users and on finding compromises with the business and less on outdated processes to manage. If you do open yourself up to change, you and the other kids may find yourselves having fun again.

Previous Article
Salesforce Buys Model Metrics – What Does it Mean ?
Salesforce Buys Model Metrics – What Does it Mean ?

Narinder Singh  Today, announced it had entered into a definitive agreement to acquire Model...

Next Article
Ways to use crowdsourcing to increase innovation
Ways to use crowdsourcing to increase innovation

By Sal Partovi A fascinating article made the rounds last month, describing a crowdsourcing success story i...