In 2007 I served as a captain in the U.S. Army during a 15-month tour in support of the “Surge” in Iraq. I deployed with the 4th Stryker Brigade Combat Team to Baqubah, where our unit’s mission was, literally, to neutralize Al Qaeda in Iraq and unseat them from their position of consolidated power, in order to deny them the ability to influence events in the capital of Baghdad. You wear many hats during a combat deployment, but my primary roles were that of lead planner and battalion Fire Support Officer (FSO).
As a planner I formulated the maneuver strategy and led the battle staff’s planning efforts in over a dozen battalion-sized operations, and over 30 company operations. Once the planning was complete, I would switch hats and go out on mission as FSO, responsible for integrating all manner of indirect fires to support the ground commander’s fight. This came mostly in the form of calling in airstrikes on targets ranging from suspected deep-buried improvised explosive devices (IEDs) to high-level meetings of Al Qaeda leadership.
I have since transitioned into the private sector and the world of software, and am constantly amazed by how many shared concepts exist between the military and business, particularly in the areas of strategy, project management, and operations. Having said that, there is one concept I found to be extremely powerful in planning military operations which seems to have no civilian counterpart, and may be useful in the discussion on implementing DevOps in the enterprise. It is the concept of “Task Organization.”
Army doctrine defines task organization as “the process of allocating available assets to subordinate commanders and establishing their command and support relationships.”
I know, I know. Right now you’re sitting in rapt jubilation over reading that statement, thinking to yourself, “What the heck is this goober talking about, and what does any of it have to do with software?!?” Stick with me for a minute – I’ll get you there.
Military operations are mission-oriented, and by their very nature extremely dynamic and fluid situations. Task organization is a construct to assist commanders in choosing the right “tools” to accomplish the mission. Back in the homeland, units are homogeneous to facilitate training and administration. But when deployed, units become heterogeneous as commanders mix and match capabilities, forcing collaboration among disparate skill sets in order to achieve a common goal – in military parlance, this is known as the “combined arms fight.” This is how task organization relates to DevOps.
To illustrate, consider the following real-world example. In 2007 my unit’s area of operations (AO) was nestled right in the Fertile Crescent, dominated by irrigated farmland with villages scattered throughout, and a handful of urban centers. Many of those villages had never seen Coalition Forces before, but it was my commander’s intent to visit each, link up with the leadership, assess the security situation, and provide any help that we could. The gambit was intended to co-opt and partner with the local populace to root out terrorist cells.
However, at the time Al Qaeda was very adept at placing IEDs on highly trafficked routes to disrupt our freedom of maneuver, making it extremely risky for us to conduct vehicle movement. Like Waterfall, it was difficult for us to go anywhere due to the extra time, effort, and resources required to travel safely. We simply would not have been able to reach every village in our AO using this method.
To combat this deadly tactic, we first took a look at our task organization and asked ourselves, “What combination of capabilities will give us the most advantage and the least risk in achieving our stated goals?” Actually, we used a lot more swear words when speaking to each other, but I’m paraphrasing to keep this thing PG. After our analysis, we decided the best course of action was to take to the skies, by requesting and task organizing a unit of Blackhawks under our headquarters. We reverted to old-school air assault tactics, delivering units by helicopter – and completely circumvented the deadly IEDs Al Qaeda had laid out for us. Goal achieved – this method worked wonderfully, and the locals were so appreciative of receiving some support that they partnered with us in the fight against Al Qaeda.
Incidentally, it was during this time that I invented a new method for bomb disposal. Our dismounted patrols would travel with an Explosive Ordnance Disposal team (again, task org), but the EOD guys could only hump so much C-4 in their rucks, and there were more IEDs scattered throughout than they could dispose of. Having acquired a lot of experience dropping JDAMs, I knew how deadly accurate they were, and suggested that when they found a bomb buried in the road, I could detonate it by dropping another bomb on top of it. This method worked so well that I started to joke that I’d figure out how to open a can of soda with a JDAM by the end of the tour – again using a lot of swear words. But I digress…
That’s what DevOps is about – not cussing, but collaboration. By discussing our problems with units who had completely different capabilities, we were able to find new and innovative solutions to our problems together. We were able to turn a perceived weakness into a strength, and gained additional speed and agility by using air assault tactics.
Imagine for a minute that the Blackhawk unit in this example is like IT operations – they were responsible for providing the infrastructure and capability to deliver our “application” to the correct “market segment” in a timely manner, so that the “business” could achieve its desired objectives. The dismounted patrol is like the development organization, translating “business requirements” into tactics on the ground. By collaborating together, we were able to refine our process over multiple iterations so that we could Continuously Deliver combat power anywhere on the battlefield, at any time and place of our choosing. This also enabled a sustainable advantage over our “competitors,” allowing us to beat them to market time and again.
Gene Kim offers two DevOps patterns which dovetail nicely with the concept of task organization – embedding development in operations, and embedding operations in development. By task organizing an individual or team from operations into development, operations becomes aware of proposed changes before they come down the pipe, allowing them to better prepare to support those changes. By task organizing a section from development into operations, developers become more aware of the effects of their changes on downstream environments, and can adjust their code or provide more information to make the lives of operations easier.
For those exploring DevOps in the enterprise, I’d suggest an exercise in task organization before you begin implementation. What capabilities and skill sets do you have available to you? What can you request from “higher?” How can you mix and match these capabilities to achieve your stated objectives with the most expedience and the least amount of waste? After you’ve mixed capabilities, who will report to whom, and how will they be supported?
And don’t forget to use a lot of swear words.
About the Author
Rex Morrow is the Marketing Director at Datical, an enterprise software company whose solution, Datical DB, manages and simplifies database schema change management in support of complex, high velocity application releases across any environment, for any database. Prior to Datical, he co-founded Texas Venture Labs, a startup accelerator at the University of Texas, and received his MBA from the McCombs School of Business. Before graduate school, Rex served as a Company Commander in the U.S. Army in the rank of Captain, and was awarded two bronze stars during combat deployments in Iraq. Website: http://www.datical.com/ Twitter: @Datical Linkedin: https://www.linkedin.com/company/datical