photo credit Digital Storm

DevOps – No Strategy Required?

Share twitterlinkedinmail

Having lived in Indianapolis for several years, I’ve gained an appreciation of auto racing.  We have a race that is run annually in May – you may have heard of it.

An IndyCar®[1] is an impressive engineering marvel. And I can tell you from personal experience – seeing a car go around a 2.5-mile oval at speeds upwards of 230 miles per hour is exhilarating.  The car is literally a blur as it speeds around the track. The rush of air from the car as it races by really gets your attention.

While I’m no auto racing expert, I do know that there is a lot of thought and planning that goes into getting an IndyCar ready for race day.  Who will drive the car?  What are the driver’s preferences when racing?  What skillsets and resources are needed for the pit crew? How should the aero kit and the engine be setup?  How and when does the race team test this setup?  When during the race should the car pit-stop?  What is the plan should weather conditions change?  What things need to be measured?  What adjustments might be made depending on those measures?

Suffice it to say, a race team just doesn’t roll a car out onto the track on race day morning and expect to have success.  Race day is the culmination of a lot of planning and the execution of strategy.

What does any of this have to do with DevOps?

Most associate DevOps, like auto racing, with “speed”.  As I’ve been exploring DevOps, I was struck by the similarities between DevOps and auto racing.

Auto racing DevOps
  • Sponsors
  • Executive support
  • The cars and the race
  • Fast deployments with high quality
  • Driver and pit crew
  • Cross-functional team
  • Setup of the aero kit and engine
  • Loosely-coupled architectures, feature toggling, etc.
  • Testing of the car
  • A/B Testing, Automation, Version Control, etc.
  • Setup of the car and the race plan
  • Processes and Procedures
  • Measurements
  • Telemetry and Reporting
  • Pit Stops
  • Learning fast[2]

But DevOps is not just about the speed of transitioning technology-based functionality into operation.  Just as with auto racing, the speed from DevOps only comes after first slowing down and answering some familiar questions:

  • What is the vision?
  • What are the goals and objectives?
  • How are we performing today?  How do we want to perform in the future?
  • What is the plan?

Just as with auto racing, success with DevOps is the culmination of planning and the execution of strategy.  It’s not about just implementing tools and automating a couple of procedures.

Just because you’re adopting DevOps doesn’t mean you don’t need a strategy

In an article appearing on CIO.com, “CIOs need to avoid a mistaken path to DevOps”[3] ,Peter Bendor-Samuel writes, “DevOps is not just a set of tools or a methodology. It’s a fundamental rethinking of what IT does. DevOps takes IT departments to a completely different construct. The key is that there is a different strategic intent – that IT’s purpose is to align with the business users’ needs to create value that is deeply satisfying to the business. That’s the new promise.

Inconveniently, the path to get there is the same general path you have to go from thinking about running very fast to driving a fast car. The strategic intent and organizational change issues are far more challenging that the investment in new technologies. It’s very unclear whether an IT organization can get to an effective DevOps environment that really delivers the promised benefits without investing in the organizational changes.”

Strategic intent. Creating business value. Organizational change.  While DevOps may be a fundamental rethinking of what IT does, the thinking IT needs to do to adopt DevOps is still based on fundamentals.   You need a plan.  You need a strategy.

The fundamentals of (DevOps) strategy 

Strategy is strategy, whether it is a DevOps adoption or any other business initiative.  The fundamentals are the same:

  • Define and share the vision – What is the “to be” state for the organization? Why is it important that the organization reach this “to be” state?  Share this vision with everyone.
  • Define goals and objectives – What milestones and accomplishments indicate progress toward the “to be” state?  How will the organization know that it is on-track for achieving the vision?
  • Define measures – How will progress toward goals and objectives be tracked?  How will the organization “keep score”? Measures make progress tangible and real.
  • Define the plan – What are the specific actions and tasks that need to be done to achieve the goals and objectives?  What is the sequence of these tasks?  What resources are needed?  What investments in training, technology, and organizational change need to be made?
  • Define “success”– “Success” will mean different things to different people.  Paint the picture of what success looks like from the executive, manager, associate, and customer perspectives. Not only will this help manage expectations, it will also help everyone focus on the vision, goals, and objectives.

Considerations of a DevOps Strategy

There are some critical discussions that must be part of a DevOps strategy:

  • Does DevOps make sense for your business?  Too often, IT organizations act as if the only tool they have is a “hammer” – which, in turn, makes every IT problem look like a “nail”.  A DevOps adoption, as with any transformational change, is not about doing what another company has done – it is about doing the right things for your business.   Don’t get caught in hype cycles and marketing messages – identify the problem that needs to be solved and how (if) DevOps can help solve that problem.
  • Have you defined services?  Many IT organizations have not truly defined services – the value chains of people, processes, and technology that work together to deliver business value.  Instead, those IT organizations have simply listed the components they manage or the activities they do, and called that list their “services”.  To be successful with DevOps, IT organizations first must truly define their services.
  • How will you move to a ‘service-aligned’ organization? – This may be the most significant – and most difficult – challenge of a DevOps adoption: moving away from an organization model aligned by function and moving to an organization model aligned by service. With a DevOps adoption, there are no more “development” and “operations” teams – at least not how we know them today.  Instead, there are cross-functional “service teams” that take responsibility for all aspects of a service from point-of-origin to point-of-consumption.

As with auto racing, speed with DevOps just doesn’t happen because some technology gets rolled out. DevOps will not reach its potential if an organization simply decides to co-locate some developers and operations team members in the same room. As the old axiom says, “to go fast, you first must go slow” – and success with DevOps, just like auto racing, first requires a well-thought strategy.

Thinking about your DevOps strategy?  Let Tedder Consulting help you get on the right path with a Visioning and Strategy workshop.  Or maybe you need guidance with identifying  servicescontact Tedder Consulting now and begin transforming to a service-aligned organization.

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo Credit: Digital Storm

[1] IndyCar® is a registered trademark of Brickyard Trademarks, Inc.

[2] Many call this “failing fast” – I prefer to call it “learning fast” – it is a failure only if nothing is learned.

[3] http://www.cio.com/article/3047667/agile-development/cios-need-to-avoid-a-mistaken-path-to-devops.html retrieved 4/6/2017

Share twitterlinkedinmail

One thought on “DevOps – No Strategy Required?”

Leave a Reply

Your email address will not be published. Required fields are marked *

logo