IT is War : DevOps & ITIL through the lens of military history

Climbing into the DevOps vs. ITIL debate is like stepping into a minefield, as least from my vantage point. Both have serious-minded proponents, and engender the kind of passion that lesser methodologies only dream of.  But, after this very issue has come up multiple times recently, I really felt compelled to think more about it. Most of the attempts at reconciling the two haven’t resonated with me. So, I have tackled this issue the way that appeals the most to me – using military analogies.

Military history is probably my favorite part of the huge topic of history. I particularly enjoy understanding how advances in weapons, tactics, and organization have influenced the course of events. The evolution of IT over the years has been a lot about adjusting process and tactics to the available tools and competitors. The evolution of military strategy boils down to the same thing, so I think a quick look at the evolution of military tactics over time can shed some real light on the DevOps & ITIL debate.

Discipline and Organization beats Chaos

Success in war usually favors the bold – those who embrace new technology and changemacedonian pike phalanx their tactics to deal with new situations and threats. A few days ago I watched a documentary on the massive defeat of the invading Persian army by the Greek city states in 490 B.C.. What many people don’t know is that it was the technological advantage of iron lances and large shields, and the highly coordinated group maneuver called the Phalanx that gave the Greeks the edge. Moving as one unit, with shield interlocked, spears pointed front, the Greek hoplites were an unstoppable force cutting a swath through the Persians

Fast forward a thousand years. The Europeans, with their endless wars of the 17th, 18th, and 19th centuries made an art napoleon-army-salamanca-spainform of the highly trained foot soldier with a musket. Napoleon represents the pinnacle of that art. Coordinated volleys of musket fire from trained soldiers, supported by well-placed cannon, and fast moving light cavalry, could wipe out less well-equipped and trained troops. Napoleon also worked at a scale unheard before of his time, mastering logistics for hundreds of thousands of troops in the field. With his armies, Napoleon was able to dominate the Europe for 20 years, and his ideas lasted longer.

Tools can obsolete Tactics

The effectiveness of these large scale maneuvers was upset by the advances of the 19th century, particularly during the U.S. Civil War. The vastly increased accuracy of rifled muskets and cannon, and the high rate of fire afforded by caplock (percussion cap), meant that the magnificent infantry charges of the 18th century only made for easier targets and mind-blowing casualty rates. This reached a peak with the mindless violence of trench warfare in World War I.

MarineRaiders

And again, armies adapted. Along with the introduction of the tank, it was small group tactics that won the day and broke the stalemate in World War I France. Instead of ordering breathlessly stupid charges into the face of machine gun fire, small squads of soldiers could adapt to the circumstances and more rapidly advance.  World War II continued the refinement of those tactics. This didn’t mean that large scale coordination wasn’t still necessary. Artillery and air support still needed to be coordinated with the soldiers on the ground. Tanks and mobile infantry could move quickly and pack a powerful punch (which the Germans perfected with Blitzkrieg).

Very interesting, but what’s the point

Other than indulging my need to geek out with talk of weaponry, this rapid flyby of history does have a point. Successful armies over time have adapted their tactics and tools to meet the threats at hand. The ancient Greeks and Napoleon used organization and discipline to overwhelm their enemies. In the face of the devastating weapons of the 21st century, successful armies used more flexible and fast-moving tactics to dominate their slower moving enemies. All of these militaries adapted to their circumstances and made the most of what tools they had.

I don’t think IT is all that different. ITIL made a lot of sense when confronted with the chaos of IT operations, and the need to provide stable services for a business questioning the value being derived from their investment. With well-documented processes and coordination, IT departments could confront and conquer the chaos.

Conversely, DevOps has arisen in the wake of the pressures exerted by a hyper-competitive business environment and hard-to-please users with no end of choices. Just like the soldiers facing rifled carbines at Gettysburg and those facing machine guns nests in French trenches, IT operations teams trying to please the 21st century Internet user can’t march into battle with the highly coordinated, but rigid, maneuvers of ITIL. By the time they perform the service management equivalent of a pivot, the business has lost customers and revenue. In the word of U.S. General George S. Patton of World War II fame –

“A good plan violently executed now is better than a perfect plan next week”.

On the other hand, DevOps teams need a backdrop of coordinated services (e.g. cloud services or automation) to enable their agile methods, just like the U.S. Marines in World War II needed artillery and aerial support.

So, what’s the takeaway? We should never compare methodologies in a vacuum. Any methodology needs to solve today’s problems, not yesterday’s. The whole point of methodology is to provide a way to repeat the successes of the past. So, you need to find the Von Clausewitz that has succeeded where you want to succeed, and follow their lead. The methodology that best helps you meet your goals today is the right one every time.

The Mythical Application Owner – And Why They Matter to DevOps

I have been on both the customer and the vendor side of Application Management over the last decade. So, I was surprised how much trouble my team and I had really defining the Application Owner as a sales target. With our collective backgrounds, I expected it to be a breeze. Of course the CxOs, VP Operations, and others are well know entities. So why is the application owner so difficult to find? One reason is because the definitions are all over the place.

For example, one definition on the IT Law Wiki says:

An application owner is the individual or group with the responsibility to ensure that the program or programs, which make up the application, accomplish the specified objective or set of user requirements established for that application, including appropriate security safeguards.

Snore… I could be in charge of Microsoft Office for my company and fit that technically focused, but inherently logical, definition. NIST has a similarly technically oriented definition. Now in all seriousness, we can see that part of the problem is that I really mean a business application owner, not a technical owner. In that vein, a definition much more to my liking can be found on this blog entry from Nick Spanos on his Lean IT blog. In the spirit of lean methodology, he brings in business/customer outcomes, business processes, etc.

So, who cares? I think anyone who cares about DevOps should care. As DevOps expands from a grassroots movement to a business-changing phenomenon, it needs to continue to develop thought patterns that appeal to those footing the bill. This is where so much good thinking in IT falls down – the inability to articulate the value to the business. That said, I don’t think it has to be complicated. I see two over-riding characteristics:

They live, eat, and breathe application revenue

For every revenue-generating application out there, there is someone being measured on that revenue. For a small company, that might be the CEO. For a Fortune 500 company, there could be dozens of applications, each with an owner. Regardless of industry, somebody goes to sleep at night worrying about whether whatever.com is measuring up to expectations.

They care (or should care) about customer value

Customers pay the bills, so worrying about revenue means obsessing about customers. I think that one of the common themes for companies successfully implementing DevOps is the over-riding need to deliver customer value. This is coincidently very much in line with lean methodology – which is why lean and DevOps are so good together. An application that is always in danger of losing customers and competitiveness is fertile ground for DevOps. If your application isn’t in a competitive space, why would you even bother?!

Pretty much everything else is going to be different by industry. An application owner at SuperCoolStartup dot com will likely be very different than the app owner at BigRetail dot com or the MBA educated person running SomethingOrOtherFinancial dot com. What they should have in common in the commitment to increasing revenue by increasing customer value.

Now, one caveat. Not every application has revenue. I would argue that the lack of the profit imperative makes a wrenching change like DevOps much more difficult, but you can insert “mission” or “fund raising” for most of these points.

So, why does this matter? DevOps practitioners, and IT organizations in general, have an unprecedented opportunity to make IT matter to the business more than it ever has before. IT can become an enabler for revenue, rather than a pure cost center. However, to do that, they need to learn to express the value of DevOps in revenue and customer-focused terms, and begin to make the case directly to the application owner. Over time, I think the pendulum of power is swinging from the CIO and VP operations to the application owners. So, IT needs to make some new friends!

IT has been deposed – Long Live King User

Most of us (if you are reading this, you are a self-selected subset) are fascinated with trends in technology and IT, which is great. The problem is that, with all the activity and progress going, it is easy to miss the forest for the trees. I think it is really instructive to take a step back sometimes and ask the big questions. Like this one – Are some of the major technology trends of our day – Cloud, DevOps, App Performance Mgmt (APM), Smart Phone and Tablets, etc. – completely separate trends, or all part of a larger narrative? I don’t ask that to reduce the power of those trends – I just think that it is worth asking if something more seismic is going on.

So, to answer my own annoyingly rhetorical question – I think there is a bigger trend. The user, in whatever context in which he, or she, operates, wields more power today than ever before. Entire industries are being built for the sole purposes of making users happy – or least making them think they are happy. And for those verticals that aren’t so obviously pandering, any competitor that ignores the experience of their end-users is bound to crash and burn. And I am not just talking about reverse voyeurism of over-sharing Facebook users and the beauty of Apple products. Staid and complacent industries everywhere are being shaken to their core as users demand the same level of experience in the business world that they experience when interacting with applications in their personal lives. So, here are a few of the trends I follow, and how I think this “mega-trend” ties them all in.

DevOps and Agile Development

One of the main purposes of Agile Development is delivering customer value. The first of the twelve principles of the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“. Agile development puts the customer on a pedestal, and works to make the customer satisfied. Why? Because the customer pays the bills, that’s why. And not only do they pay the bills, in the world of the Internet users can quickly take their business elsewhere when they are not satisfied. At the end of the day, on the major objectives DevOpsis to push this maniacal focus on delivering customer value all the way into IT operations – where it is has been sorely lacking.

Application Operations and Application Performance Management (APM)

As the less hip and more staid cousin of DevOps, APM has an even easier case to make about the primacy of the end-user. In the past, APM has been primarily about bubbling up complex application performance data from a complex application architecture, and trying to make sense of it. While that kind of deep-dive analysis is important, it can be misleading and distracting. Recent trends in APM, particularly around those same Internet applications driving the DevOps movement, are focusing more and more on the end user. With the “switching costs” so low today, users will leave for the competitor’s site if there is on average a 250 ms or more difference in response time. That is 1/4 of one second. In only 2009, a study Forrester put the acceptable wait time at 2 seconds. Today, in the case of high-performance sites like Google, even 400 ms is too long. Bottom line, if your customers are receiving sub-par response times, you are probably losing them to competitors. It really is that simple. And if an IT department isn’t measuring end-user performance, they are essentially allow their company to stumble blind into a pool of sharks/end-users. Good job IT.

The Business User’s long sojourn in the wilderness of crappy IT support is over

This trend is probably the most disturbing to an IT department and most exhilarating for any IT user. Business IT users are no longer satisfied with flimsy laptops made by do-it-cheaply hardware manufacturers and web applications with appalling user interfaces, seemingly built for Windows 3.1. Apple, Google, Facebook, and others have taught them that technology can beautiful, easy to use, secure, AND effective. The IT departments’ insistence that the need for advanced functionality and security necessitates technology that induces suicidal thoughts and dulls the mind into oblivion, no longer stands. IT users want to be free. They want to bring their iPad, Android phone, and Mac Book to work. Most IT departments don’t really like the stuff they peddle anyway. Now they just need vendors that actually deliver them products that don’t make their users scream in frustration.

Social Media is the tool of User Domination

And how does King or Queen User rule? Through social collaboration tools. Social media is not just about showing pictures of your cute toddler (guilty…) or trying to remove tags from embarrassing photos anymore. Social media is about capturing the best ideas from the people who stand to benefit the most from their realization. It is about encouraging healthy competition and ego-boosting for the sake of information sharing and content creation. And, most of all, it is the platform of user rule – Social IT. And it can’t be ignored. Countries creating “fake internets” and companies with draconian IT policies won’t stop the change. Users always find a way to flaunt the rules, like they have since the dawn of time.

So, is this a good thing? I believe that it is. I think the the essential lesson here is that business has always been about delivering value for the customer. The difference now is that customers actually know how much value companies, organizations, and countries are delivering. Keeping “the man”, the president, and the boss accountable. That is definitely a good thing.