The simple act of dressing a salad demands chefs bend the laws of chemistry. They have to coax two substances that barely get along, oil and vinegar, to blend harmoniously. The only way to get them to play nicely is to apply vigorous agitation, and even then the ingredients separate the minute external energy is removed.
The CIOs role is not dissimilar to that of a master chef. Getting modern Web 2.0 applications to market quickly, efficiently and reliably requires a finely balanced blend of deeply skilled professionals. This is easier said than done, especially when their behaviors focus more on meeting the needs of their immediate team than the ultimate outcome. The challenge is that without a “master chef” coaxing them into harmony, and a system for keeping them that way, functionally aligned teams are more likely to split into their separate “tribes” - just like oil and vinegar - creating an unsavory mess.
A systematic approach to IT
We can’t allow this to continue. With industry experts estimating that over 95 percent of all capital projects rely on IT, the majority of IT leaders I speak with find themselves becoming an innovation bottleneck, preventing new initiatives from being delivered on time. The pressure to push under-baked projects into production is often overwhelming.
Forced to rush projects through the system, two in three of these projects fail to deliver against expected outcomes. The root cause is frequently poorly documented requirements, cursory attention to security and QA processes, and an operations team who’d be forgiven for thinking the rest of the organization was running the a secret society for all the notice they’d been given of the project’s production requirements. We need to perform better and I believe this starts by breaking down the silos between the governance, development, QA and operations functions.
I imagine some of you might be thinking, “Hey! Didn’t Adam Smith teach that by specializing and dividing labour a bucket of pins could be produced more efficiently than a group of generalists create the whole product themselves?” Well, yes. I’m not suggesting that your development team should plan, build and support each application on their own any more than I would suggest that a Toyota worker should assemble an the entire car themselves.
What I am saying is that, just like the Toyota Production System, it’s important to recognize that IT delivery is a system. A system where up and down-stream activities impact the finished product so dramatically that we need a connected approach to goals, tools and KPIs that aligns and enables our teams, rather than divides them.
The DevOps Movement
This isn't a new problem, but it is getting harder. I’ve spent the better part of the last two decades helping organizations transform by bringing all IT stakeholders to the table around an aligned set of processes, tools and a measurement system. Starting with Service Management and itSMF and then subsequently the governance, security and application delivery worlds, I've found that each group has its own specialized systems for thinking about its problems largely disconnected from the needs of the others.
The great news is that there are several grass roots movements working to bring together the "tribes" of IT, bringing the opportunity to clear the project backlogs at lower cost, higher quality and greater compliance. Backed by pragmatic standards and technology innovations such as model based automation, rich platform stacks and cloud services, I believe IT leaders have a career defining opportunity to transform IT delivery for the 21st century by changing the way they think about the application and service lifecycle.
The most vocal group by far would have to be the DevOps movement. First coined by Patrick Debois, the DevOps movement and principals aim to recognize and codify the practices and workflows of developers, QA and operations teams to facilitate the rapid build and automated deployment of higher quality applications.
Born in the web operations worlds of the likes of Flickr, Kaching (now Wealthfront), Netflix and their larger cousins, DevOps takes a systems thinking approach to IT delivery, including the full lifecycle of a service. Most powerfully DevOps acknowledgesthat the majority of IT projects are never “done” and instead are in a continuous state of change, which is one of the reasons you’ll often hear about Continuous Delivery, Agile and DevOps mentioned in the same breath. In a tip of the hat to the Toyota Production System and Eric Reis’ book The Lean Startup, you’ll even hear the term Lean IT thrown in for good measure.
Breaking Down Silos In The Real World
A great example of the pay-off of breaking down silos was demonstrated to me by a customer and friend who heads up Systems Management at a major health insurance provider. In his 20 years in IT, he’s been both a developer and operations leader. It’s fair to say there’s little he doesn’t know about building and monitoring mission critical, composite applications.
He recently shared how he’d been able to reduce the number of production incidents by 90 percent. Even better, when problems do occur he now only requires half the number of staff and a fifth of the time to isolate and resolve the problems than in the past.
He shared what I thought were three actionable principals that work for him:
- Operations has a voice in requirements - it’s important that the supportability of the application be part of its non-functional requirements. The Operations teams are best positioned to form those requirements.
- App development and QA should be part of operations escalations - this helps to build a shared understanding of real-world use cases for fault isolation and diagnostics.
- Establish common tooling between the two - in his case he focused on common synthetic transaction and load generators, diagnostics and configuration management tools. This not only prevented his development and operations teams doubling up on tools that essentially did the same thing, but facilitated a common bond between Dev and Ops and that helped bridge what was previously a gap.
You get what you inspect
What makes DevOps such a powerful concept is that it brings the voice of operations into the development and requirements process. It acknowledges and formalizes the requirements of the developer as a customer of operations. And most important, it anticipates the high velocity, high rate-of-change enterprise that I believe will be IT’s new normal. However, I’ve learned the hard way that “you get what you inspect, not what you expect” - blending two teams that often define themselves by their differences requires more than new tools and processes. IT leaders have to establish KPI’s that drive the right behavior across as well as within functional IT teams, for example, looking at unauthorized changes for signs that governance has lapsed.
If you’ve not already looked into DevOps, I recommend that you do. However, it’s worth noting that as a grass roots movement, the DevOps community are wary of vendors misappropriating the term and how to refer to DevOps is itself a subject of much heated discussion, Cameron Haight from Gartner provides an excellent objective summary. The one thing everyone does agrees on is that establishing a DevOps model is not a problem that can be solved by tools alone, a principal I agree with wholeheartedly.
If you’ve had experience, positive or negative, bringing together development, QA and operations, I’m sure everyone would like to hear more. If nothing else, it’s food for thought!
Photo by sffubs - http://flic.kr/p/7u7qX3