devopsy.kinsta.cloud

Category: Enterprise DevOps

DevOps with purpose: ACT-ing with greater agility

This is Part Four in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications. In Part Two, I provided four tips to fostering a DevOps culture in your organization. In Part Three, I discussed the role of tools and how they can amplify (or constrain) individual and team abilities as well as work across teams.

In this final fourth part of the series, I’m going to weave the three previous topics of (A)pplications, (C)ulture, and (T)ools together and will show how you can ACT with purpose to start your own DevOps transformation. Your DevOps strategy should incorporate all three aspects of applications, culture, and tools. Given the breadth of those three areas, it’s easy to feel overwhelmed from the start. Here’s a tip I learned from a mentor a few years ago. Whether you are a CEO, VP, or team leader, smart leaders set a vision (often at least two or three years out) and then they make small decisions every week with the goal of generally moving the organization or team in the direction of the vision over time.

I recommend first that you set a vision for DevOps as it relates to your Applications, your Culture, and your Tools. Let’s begin with Applications. In the first article, I shared the concept of the pace-layering model developed by Gartner. To set a DevOps vision for your applications, place each of your current applications into one of the three layers – system of record, system of differentiation, or system of innovation. Then, do the same thing for any applications you are planning to add to your portfolio.

With that context, specific to your organization, formulate a strategic vision for how DevOps will apply to your systems in each layer. Will you seek to have DevOps principles for continuous integration and continuous delivery in place for all of your systems of innovation, and if so, by when? How about for systems of differentiation? Will DevOps be the norm for each of those applications or just some, and by when? Then ask yourself the same questions about your systems of record.

Next, turn to your culture. In Part two, I discussed the importance of baselining the degree of collaboration you have between the business, dev, and ops as well as how you view work (in workstations or in end-to-end flow terms). Then I challenged you to incentivize people to modify their behavior both with respect to their roles and as individuals. With this as context, define your DevOps cultural vision. What does collaboration between the business and development look like in the future? What does collaboration look like between development and operations? How about between dev, QA, and ops? And let’s not forget security.

How will you recognize when your culture is optimized for flow? For example, I recommend documenting a set of indicators that you can measure at regular intervals (e.g. quarterly). Here are three good ones. How much work-in-process (WIP) do we have for Application X today vs. how much was there a quarter ago? What is the average time it takes from the definition of a requirement to its deployment in production today vs. a quarter ago? How often did we make updates to Application X in production this quarter vs. last quarter?

Now, let’s consider tools. Take a baseline of the tools you are using today for each step of the typical DevOps tool chain from requirements management to source code control and bug tracking through to build management, automated testing, configuration management and deployment. And don’t forget project management tools too. What is the state of your tool investment in each of these areas? Do you have gaps? Do you have multiple tools in the same area, and, if so, is that okay or do you want to standardize on one? Do your tools vary based on the applications they are used with (see pace-layering discussion above)?

Then take an inventory of your collaboration tools across dev and ops. Are you still mostly using email and sharepoint sites? What role does instant messaging play in your dev and ops teams today? What about conference calls and meetings? Once you’ve baselined where you are today, set a vision for where you want to be in the future. Are you looking to reduce the need for conference calls and meetings, and if so by how much (time or average number of participants)? What issues are you running into around email and IM communications that need to be addressed and also for SharePoint? Have you looked at the emerging class of DevOps collaboration tools and concepts such as ITinvolve and ChatOps? What role can they play in streamlining communications, keeping people informed, and presenting information to staff so they don’t have to go hunting around for it in dozens of systems or call more meetings?

With this as background, define your DevOps tools vision by setting priorities for filling identified gaps and rationalizing existing investments, then set a general target time frame for each area.

Now that you’ve set a vision in each area – (A)pplications, (C)ulture, and (T)ools, it’s time to ACT. I recommend you first pick one or two applications to begin your DevOps journey. Ideally, they should be applications that are visible to the business and where you can lay claim to the impact DevOps can have on business goals like time-to-market and responsiveness to customer needs.

Once those applications are identified, take an inventory of all the people across your organization (including the business), those responsible for the development and delivery of the applications. Develop a specific plan for how you will educate those individuals on DevOps principles (e.g. attend DevOpsDays, read The Phoenix Project, read a sets of articles and watch a set of seminar or demo recordings), and also develop a specific plan for how you will incentivize behavior changes for their roles as well as what is expected of first line managers to take individual personalities, skills, and experiences into account.

Let me also stress that you shouldn’t ignore the people who aren’t participating in this first DevOps effort as part of your communications. Educate them as well, for example through an all-hands meeting and an email from leadership. Explain why the company is investing in DevOps transformation, why these applications have been chosen, and your long-term vision across Applications, Culture, and Tools to realize the transformation. Help them understand where the organization is going and why, and how it may impact them in the future. Avoid the perception that “the best people were picked for this and you are not among them” or that this group of people is being given license to do things that others can’t (e.g. make changes outside of the standard change management process) – otherwise, you risk reducing morale, good people leaving, and even sabotage of your DevOps efforts.

Once you’ve completed the above, map the relevant tools you have in place today for managing the development and delivery of these applications as well as the tools on your vision roadmap defined above that will be added or rationalized in the next six months.

By following the above recommendations, you will now have an action plan for the near term and a long-term vision you can use to guide daily decisions to move you closer to that vision. Lastly, don’t be rigid about your short-term plan or long-term vision, recognize that everyone is learning, including you, and that one of the key principles behind DevOps is the feedback loop!

Thank you for reading this series. I hope it’s been useful to you on your DevOps journey. If you have a question or just want to share a comment, you can do so here on devopsy.kinsta.cloud or send me an email at matthew@itinvolve.com.

Best wishes on your DevOps journey!

November 12, 2014
Time-Sharing to Unicorns: The DevOps Problem Facing Enterprise IT

How did we in Enterprise IT get to this point? There’s a lot of talking and writing about the value of adopting DevOps but very little analyzing the problem domain we’re trying to correct. There are some schools that will say we can move forward without looking back, but I believe a key element of the dysfunction that faces many enterprise IT organizations can directly be attributed to their history and how they were formed.

One of the clear lessons we can learn from businesses that we call “unicorns”–termed this because of their mythical capabilities as an IT organization that can deliver high quality software very quickly–is that they have very little friction in the process from ideation to operation. Startups and greenfield initiatives are practically operating in a vacuum relative to the amount of friction they encounter compared to operations around entrenched decade-old legacy mission-critical applications. In retrospect, this should not be surprising given frictionless delivery is a mandate for many of these efforts and has been from the start.

You create what you focus on!

Some will say we don’t require the capability to deliver to production ten times a day (or even a year) for our SAP Enterprise Resource Planning (ERP) system. So they will conclude that perhaps DevOps isn’t right for our needs. This shows the skewed thinking that current literature on DevOps is fostering. It is not the need to deploy changes quickly into production that is at issue, but the ability to deliver business capabilities when they are required as quickly and with little impact as possible. Current processes around changes to the ERP are usually so fraught with friction that when the time comes to fulfill a need for the business so that the business can continue to compete effectively, it takes weeks or months instead of days or hours.

I researched how the division between development and operations was formed and interestingly, there’s very little history about this division of work. We can trace this division back to the early days of time-sharing systems in which the division of work actually represented the exact advice DevOps prescribes today. Deliver and operate a platform on which developers can build and deliver their applications. In the days of time-sharing systems, operations was not responsible for what developers put into the box, just ensuring that the box was available, secure, and backed up. If developers applications had bugs or crashed, it was the developers that were responsible for repair.

Then came the era of client/server. Application pieces ended up distributed across application infrastructure like a kid that dumped their Legos all over the floor. Managing these applications became as painful as stepping barefoot on a Lego as well. Developers didn’t work on the complete application, but instead worked on modules and these modules were split across various services each requiring their own levels of expertise to keep running in an optimal manner. The DBA was responsible for ensuring the database could meet transactional requirements and support data design and management, the network professionals dealt with protocols and traffic issues caused by these modules communicating with one another. Each layer of the application had it’s own capacity management and operational concerns. The only chance we had to keep the ship from sinking was to put it all in the hands of the one team that had access to all the components — IT Operations.

Things have not progressed much since this divergence away from time-sharing to client/server either. Today’s applications are more complex and more distributed than ever before. We have clusters of the same server working in unison to handle scalability exponentially increasing the complexity and difficulty for operations. A single application may now require anywhere from 5 to 25 servers to deliver the required capacity.

On top of all this we’ve never modified the division of work from the days of time-sharing and continue to push the burden for monitoring and uptime to the operations staff. We have turned IT operations into the Jigsawyer’s–someone who does jigsaw puzzles–and developers into the puzzle makers. Moreover, the puzzle is never the same; the puzzle makers change the picture all the time as they add new piece forcing the Jigsawyers to figure out how to retrofit the new piece into the whole.

While researching the history of IT operations and trying to figure out the path from computing’s earliest organization until now, I came across a great piece that really helps identify the problem we have created. So What Is A Deployment Really? by Robert van Loghem illustrates what it takes to move from ideation to operation with today’s application platforms. What I really like about this piece is the illustration that even if we want to go back to earliest division of work, it may not be possible. IT operations cannot simply provide a black box for developers to deliver their applications on and expect them to work as planned. Firewalls need updating, web servers need configuration changes to support the new domain requests and the security architecture must now allow these new requests to be routed appropriately based on rights and source.

Deployment is a team activity!

So, what have most of us in enterprise IT done? We broke down the tasks of deployment further into divisions of work so that we can apply the necessary level of specialization to ensure the application can be delivered to the end user at the cost of adding a ton of friction into the process slowing things down by a logarithmic factor when compared to our unicorn friends.

What is surprising is the number of pundits that put forth that the answer to this problem domain is empathy and culture change. Clearly, we have organizationally written ourselves into a corner because this is how large enterprises solve problems. Here’s a simplification of how this decision was most likely made:

Question: There’s a lot of issues attempting to monitor and operate these distributed applications and the developers don’t have the means or transparency into all the components.

Retort: Then who does have access and insight into all these components?

Answer: IT operations can see what’s running and has the tools to monitor the health, let’s give them the task.

At a time when IT was viewed as an expense versus a strategic advantage, there was no offsite planning to assess what the impact to this answer means to the business ten or twenty years hence. It’s solve the problem and keep moving because that’s what enterprises need to do in non-strategic areas. At the time this answer was formulated most businesses equated this decision with “which office supply vendor should we use?” Moreover, the leaders in client/server barely had any experience with IT operations, they were primarily comprised of application developers. Hence, there was no experience to guide businesses away from this decision. IBM, Unisys, Honeywell, etc. the vendors that were a prime source of guidance at the time were still leading with a time-sharing mentality.

This entire trip down memory lane was with one purpose in mind, figure out what we created and how it was created so we can consider the means to unwind it and provide a path for enterprise IT to move forward in an agile manner. The history provides the answer. We need to move away from the traditional time-sharing division of work that was formulated before the age of the Internet and realign along frictionless surfaces. What does that mean? Well, that, my friend, is an entire book that happens to be in the works! 😉

November 11, 2014
Why “Enterprise DevOps” Doesn’t Make Sense
Recently, some folks have been suggesting that we need a new form of DevOps, something called “Enterprise DevOps” or “Big DevOps.”

DevOps is great, the argument goes, but large enterprises don’t operate the same way as the agile web startups where DevOps was birthed, and thus they can’t implement the same DevOps methodologies as those startups. Large enterprises have bigger teams, more inherent operational complexity, and greater governance controls (both self-imposed and externally-imposed); therefore, they need a different type of DevOps that caters to their sensibilities and not those of agile web startups.

While it’s true that large enterprises do operate in a different environment than agile web startups, none of that makes a difference from the point of view of adopting DevOps.

In short, if you’re advocating for Enterprise DevOps as something different than Plain Ol’ DevOps, then you’re missing the fundamental essence of DevOps.

Here’s why.

Early Thinking: DevOps = Tools + Culture

To best understand DevOps, we need to understand where it came from.

DevOps started as a bottom-up collection of best practices with few formal underpinnings. System administrators and developers were looking at the successes of agile development practices and trying to apply some of the same ideas to the whole development-to-operations process. Practitioners in the trenches stepped forward and said, “This is what we’re doing and it seems to work for us.”

One of the earliest and most visible examples of that was John Allspaw’s and Paul Hammond’s presentation at Velocity in 2009, titled “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.”

[youtube http://www.youtube.com/watch?v=LdOe18KhtT4]The video is well worth your time, as is the presentation on Slideshare:

[slideshare id=1628368&doc=allspawhammondvelocity2009-090623161942-phpapp01]

Note that this presentation predates the actual creation of the name “DevOps.” Allspaw and Hammond talk about how Dev and Ops teams can work productively together, but they never say “DevOps.” Patrick DeBois would coin the term later that year when he created the first DevOpsDays.

In the presentation, Allspaw and Hammond discussed the success they were able to achieve at Flickr and provided a set of recommendations that they think are important, separated into two buckets:
1. Tools
2. Culture
In the Tools category, they provided six recommendations:
1. Automated infrastructure
2. Shared version control
3. One step build and deploy
4. Feature flags
5. Shared metrics
6. IRC and IM robots
Along the way, they mentioned that Flickr used:
- Chef, Puppet, CFEngine, and other automation tools
- SVN for version control
- Hudson for builds
- Ganglia for monitoring
Finally, in the Culture category, they listed four additional recommendations:
1. Respect
2. Trust
3. Healthy attitude about failure
4. Avoiding blame
Unfortunately, most people missed Hammond’s remark ahead of the Tools section of the presentation (timecode 7:40):

These are some of the tools that work for us. They are not necessarily going to work for everyone, and throughout we’re going to give examples of the specific tools that we use, but the important thing that we’re trying to get across is the concepts that are important.

In the years following, many self-proclaimed “DevOps engineers” (a bit of an nonsensical title if you understand that DevOps is about bringing Dev and Ops engineers together, not creating new types of engineers focused on nothing but DevOps) insisted that if you were automating your releases using Jenkins and Chef and treating the other members of your team with respect, you were “doing DevOps.”

While Allspaw’s and Hammond’s presentation was excellent (seriously, spend the time watching it) and the advice was practical and valuable, many people walked away with only a vague notion of what would later be called DevOps.

For instance, in the “One step build and deploy” recommendation, Allspaw and Hammond describe their automated system that moves code into production. Developers can click a single button to make a build live. The button is jokingly labeled “I’m feeling lucky” (in homage to Google, I’m sure).

If you’re an agile web startup, that’s par for the course.

But if you’re a large financial services company, you’re likely to think, “No! Our governance folks will never let developers push code straight to production with a single click, never mind the ‘I’m feeling lucky’ labeling. No way. Not gonna happen.”

When people suggest that we need “Enterprise DevOps,” they’re typically reacting negatively to the choices that others have made. They recognize that those solutions won’t work for them for any number of reasons, and they say, “I can’t use that. I need something different.”

But here’s the thing — DevOps isn’t about the specific implementation choices. Those are all optional. You can make a completely different set of choices than Allspaw and Hammond and still be “doing DevOps.”

Unfortunately, subsequent conferences were filled with DevOps presentations that just reiterated the “DevOps = Tools + Culture” mantra and provided similar sets of recommendations that were often drawn from agile startups rather than from large enterprises.

So, does that mean Tools and Culture aren’t important for DevOps?

No, not at all. Both Tools and Culture are critical for DevOps in the long run.

The problem that DevOps seeks to solve, however, is not a Tools problem or a Culture problem but rather something more fundamental.

In order to understand DevOps, you need to focus on the ultimate goal.

The Firm Foundation: The Toyota Production System and Lean Manufacturing

In 2013, Gene Kim, Kevin Behr, and George Spafford wrote The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.

The trio’s contribution to the DevOps movement was in recognizing that enterprises had confronted a similar set of issues previously, but in a different domain — manufacturing — and that similar solutions could be applied to software engineering and application operations. (The group took another cue from the manufacturing world, copying the novelization technique from Goldratt’s The Goal to create a fictional case study where the characters were allowed to wrestle with the fundamental DevOps truths being discussed.)

The key takeaway from The Phoenix Project is that DevOps seeks to create a smooth and increasingly speedy flow of change from development into production, with as little waste along the way as possible.

The models here were the Toyota Production System (TPS), Lean Manufacturing, and Goldratt’s Theory of Constraints.

In the world of manufacturing, we have a physical product that moves through a factory, either on a formal assembly line, or from processing step to processing step, as part of a value stream. Each step along the path is supposed to “add value” to the product until it completes its journey and exits the factory to be shipped to customers.

If you’re a manufacturing engineer, you need to do everything possible to create a smooth flow through the value stream by identifying constraints in the system and eliminating waste of time or resources.

In the software world, application artifacts and changes move through the software development and operations value stream, with each step designed to “add value” and get the changes into production.

If you’re a development or ops engineer, you need to do everything possible to smooth the flow through to production. The techniques you use are similar to a manufacturing engineer — you identify constraints in the system and go about eliminating waste of time and resources.

The Kata is the Key

Following Toyota’s success, the TPS and Lean Manufacturing were all the rage in the manufacturing world.

Consequently, many western manufacturing engineers studied Toyota’s systems in great detail. They noticed a variety of tools and solutions that Toyota used to optimize manufacturing flow, and they recommended their use to their employers and clients. Toyota’s Kanban, for instance, was heavily promoted in the manufacturing world, and later made the jump to software engineering.

Interestingly, the manufacturing world has suffered much of the same confusion that’s now happening in the DevOps world. When they tried to employ the tools and techniques they had learned from studying Toyota, things didn’t work as expected.

Mike Rother, author of Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results, described the situation in the manufacturing world this way:

Looking back, we naturally put Toyota’s visible tools in focus first. That is where we started— the “door” through which we entered the Toyota topic. It was a step in the learning process (which will also, of course, continue after this book). Since then I went back to the research lab–several factories–to experiment further, and present what I learned in this book. The visible elements, tools, techniques, and even the principles of Toyota’s production system have been benchmarked and described many times in great detail. But just copying these visible elements does not seem to work. Why? What is missing?

Later, Rother continues:

Toyota opens its factory doors to us again and again, but I imagine Toyota’s leaders may also be shaking their heads and thinking, “Sure, come have a look. But why are you so interested in the solutions we develop for our specific problems? Why do you never study how we go about developing those solutions?” Since the future lies beyond what we can see, the solutions we employ today may not continue to be effective. The competitive advantage of an organization lies not so much in the solutions themselves—whether lean techniques, today’s profitable product, or any other— but in the ability of the organization to understand conditions and create fitting, smart solutions.

Focusing on solutions does not make an organization adaptive. For example, several years ago a friend of mine visited a Toyota factory in Japan and observed that parts were presented to production-line operators in “flow racks.” Wherever possible the different part configurations for different vehicle types were all in the flow racks. This way an operator could simply pick the appropriate part to fit the particular vehicle passing down the assembly line in front of him or her, which allows mixed-model assembly without the necessity of changing parts in the racks. Many of us have been copying this idea for several years now.

When my friend recently returned to the same factory, he found that many of the flow racks along that Toyota assembly line were gone and had been replaced with a different approach. Many of the parts for a vehicle are now put into a “kit” that travels along with the vehicle as it moves down the assembly line. When the vehicle is in an operator’s workstation, the operator only sees those parts , and she always reaches to the same position to get the part.

My friend was a little upset and asked his Toyota hosts, “So tell me, what is the right approach? Which is better , flow racks or kitting?” The Toyota hosts did not understand his question, and their response was, “When you were in our factory a few years ago we produced four different models on this assembly line. Today we produce eight different models on the same line, and keeping all those different part variations in the flow racks was no longer workable. Besides, we try to keep moving closer to a one-by-one flow. Whenever you visit us, you are simply looking at a solution we developed for a particular situation at a particular point in time.”

As we conducted benchmarking studies in the 1980’s and 90’s and tried to explain the reasons for the manufacturing performance gap between Toyota and other automobile companies, we saw at Toyota the now familiar “lean” techniques such as kanban, cellular manufacturing, short changeovers, andon lights, and so on. Many concluded— and I initially did too— that these new production techniques and the fact that Western industry was still relying on old techniques were the primary reasons for Toyota’s superior performance.

Rother concludes that the secret to the Toyota Production System and Toyota’s success was not any one particular tool or technique, but rather the Toyota Improvement Kata, which focused on continuous improvement of everything at Toyota, seeking to establish flow and eliminate waste.

Toyota Kata is a great book and if you want to understand DevOps, I encourage you to get a copy and read it for yourself. Kevin Behr recommended it to me and I was pleased to see Jez Humble reference Rother’s story, above, in his recent QCon talk on DevOps.

What is DevOps?

So, after all that, what are we left with?

What is DevOps?

Cue the trumpet fanfare…

Fundamentally, DevOps is the activity of optimizing the development-to-operations value stream by creating an increasingly smooth, fast flow of application changes from development into operations, with little waste. Optimization of the value stream takes place continuously using various continuous improvement techniques like the Toyota Kata.

“Is that it?!” I hear you cry.

Yes, that’s it.

“No way!”

Way.

“But what about Tools and Culture?! What about continuous delivery and Jenkins?! What about automation? What about mutual respect?!”

Yes, those are all in there, too. But those are the equivalents of Rother’s “kanban, cellular manufacturing, short changeovers, andon lights, and so on.” They are solutions to particular problems that you might be faced with.

If, during the course of trying to optimize your value stream, you’re faced with the problems that those tools and techniques solve, then you might try them out as solutions. Or you might not, if your situation dictates differently.

The key is to understand that simply deploying a tool or even a broad solution without thinking through your unique situation and the current state of your value stream and its current constraints is foolish. After all, the specific solutions that are applicable to an agile web startup have a high likelihood of being inapplicable to a large enterprise. And vice-versa.

Why “Enterprise DevOps” Doesn’t Make Sense

So, that brings us right back to where we started.

Enterprise DevOps doesn’t make sense because it confuses the forest for the trees. Those advocating for Enterprise DevOps make the mistake of focusing on specific tools and solutions (Jenkins, Kanban, etc.), then find them wanting for various (extremely valid) reasons in an enterprise context, and then reject DevOps in favor of Enterprise DevOps, which they suggest is somehow different.

But DevOps is about flow and continuous improvement, not about specific solutions. Flow and continuous improvement are equally applicable to a large enterprise as they are to an agile web startup. And if you miss that, you’re lost, regardless of the tools and solutions you choose.

To implement DevOps, you need to learn how to map your value stream, identify the constraints in it, and then use a continuous improvement kata to develop specific solutions for your particular problems at this point in time in your particular organization.

If you’re a large enterprise, the problems and constraints that you face will undoubtedly be different than those of an agile web startup. So, you’ll necessarily need to select different solutions.

That doesn’t mean you “aren’t doing DevOps!”

Rather, it means that you’re doing DevOps correctly.

And remember that whatever solutions you come up with to your particular problems and bottlenecks, they are likely to be temporary. As Toyota said to Rother’s colleague, solutions are only applicable to a particular problem at a particular point in time.

Epilogue: A Bitter Irony

Some of the earliest work on what would become DevOps grew out of some ideas that Andrew Shafer was kicking around in late 2008.

At the Agile 2008 Conference in Toronto, Shafer proposed a birds-of-a-feather session about “Agile Infrastructure.” Only a single person showed up — Patrick DeBois. He found an empty room. It turned out that Shafer skipped his own session because he received such poor feedback about it and thought nobody was interested. Shafer and DeBois later discussed Agile Infrastructure and many ideas that would later become DevOps in the hallways at the Agile 2008 Conference.

Shafer also presented on Agile Infrastructure at Velocity 2009:

[slideshare id=1637386&doc=velo09-agile-inf-090625020850-phpapp01]

Note slides 92 through 97. The key points from this sequence are:
- Dogma Sucks
- “Do not seek to follow in the footsteps of the wise. Seek what they sought.” This is a quote from Japanese poet, Matsuo Bashō.
- The Tao that can be spoken is not the eternal Tao.
- You are a special snowflake, just like everybody else.
Even from the start, Shafer was on to the point that a binding set of rules is self-defeating. DevOps cannot be codified in a set of rules. Because it’s bigger than that.

Note the Matsuo Bashō quote:

Do not seek to follow in the footsteps of the wise. Seek what they sought.

The wise DevOps practitioners do not seek to implement any given tool or technique out of adherence to DevOps dogma. Rather, they seek to create a smooth, quick flow of changes through the value stream. Do not try to follow in their footsteps using the exact same set of tools or techniques, but rather seek the same thing that they seek and find your own way to the same destination.

So, the bitter irony here is that we’ve been warned all along, by Shafer, Allspaw, Hammond, and others, to focus on the foundational problems, not the specific solutions they have employed. Yes, we can learn something from their experiences, but every situation is unique.

(Unfortunately, I haven’t been able to find video of Shafer’s Velocity 2009 presentation. If you find it, let me know. But you can see a later version of Shafer’s ideas, mixed with those of Paul Nasrat, in a presentation from Agile 2009, made available on InfoQ.)

Other Resources

I’ve hopefully salted this post with enough links to key presentations and resources, but there’s one more that should be included. If you’re at all interested in the history of DevOps, and you should be if you really want to understand it better, then you need to view Damon Edwards’ “The (Short) History of DevOps”on YouTube:
[youtube http://www.youtube.com/watch?v=o7-IuYS0iSE]

Connect With Me

Think I’ve left something out or put too much in, got it totally wrong or completely nailed it? Let me know! Continue the conversation by commenting on this post and following me on Twitter.

About the Author

Dave Roberts brings 25 years of technology experience to his role of Executive Advisor at BMC Software. A thought leader in agile IT and digital transformation, Dave routinely speaks at conferences around the world. Dave is a member of the Twitter #clouderati and blogs at BMC.com and Leverhawk.com. He holds nine patents and has written three books on computer programming and data communications technology.
November 10, 2014
SDN has a lot to offer to DevOps

When discussing DevOps it’s natural to focus the attention on the one operations team that focuses on application infrastructure. But when you start digging in to DevOps and its applicability to all four operations groups you’ll find that technological shifts in the network – like software-defined networks (SDN) – are just as important to the overall success of DevOps-related initiatives as the spread of software-defined operations going on across the application infrastructure.

One of the intersections of network and app infrastructure operations is around speed. Not just speed of deployment of services supporting applications, which is critical, but also the resulting speed of the application itself. Application performance management (APM) is a less often mentioned concern of those looking at DevOps but it is one with which developers and app infrastructure operations alike are very interested in not just monitoring and measuring but improving.

But here’s the thing: the relationship between the app infrastructure and the network are intertwined when it comes to application performance. Measuring and monitoring in the app infrastructure is all well and good, but it is impacted by network performance. And vice versa. Technically speaking, the app infrastructure folks are going to end up tweaking things like TCP; changing window sizes and timeouts in order to improve poorly performing apps. And they should, as TCP is highly tunable and one of the primary means of changing the performance behavior of an application.

But tweaking TCP has an impact on network performance. TCP is a reliable transport protocol, meaning its particular about thinks like packet order and its very responsible about making sure each and every packet is received. When one isn’t, it resends it. And resends it. And resends it. Retransmit storms contribute to the congestion of the network, which in turn contributes to the need to retransmit, which in turn… well, I think you see the Catch-22 here. While the app infrastructure team is pointing fingers at network operations, the network operations team is pointing fingers at the app infrastructure team.

Both are equally responsible for the problem.

SDN promises, in part, to address the problems associated with speed. Both speed of service deployment (through operationalization) as well as speed of delivery, i.e. application performance. SDN will, ostensibly, provide the means to both recognize application specific performance requirements and adjust, as necessary, the delivery of application data through the network in order to meet those requirements. But what it also implies is the ability to provide visibility into the reason why new routes were necessary. There are plenty of reasons an application might initiate a retransmission storm and some of them are related to the application platform (TCP problems), others to the client or the Internet itself, and still others to the network. Being able to quickly identify what is causing a degradation in application performance gives everyone the ability to react and resolve the problem faster.

That goes to MTTR (mean-time to resolution), a key DevOps-related metric.

But for all that to happen, there has to be some collaboration (sharing) going on between network and app infrastructure operations. There has to be less finger pointing and more question asking going on between the two, and the sharing of collected performance data across the entire application delivery chain – from network to platform to the app itself. SDN provides a means through which such measurements can be obtained and shared with other systems – and teams. This ability is important. Puppet Labs 2014 State of DevOps Report named it a “top practice” correlated with MTTR, and CA’s latest report indicated 19% of organizations adopting DevOps have experienced “Improved quality and performance of our deployed applications.”

Monitoring and measuring application performance is a key component of DevOps, and yet a significant portion of that performance is dependent on and related to the network. Which means app infrastructure operations can’t measure or address poor performance without understanding the network’s contribution to the whole.

SDN “apps” can be one way in which app infrastructure and network operations can gain insight into how apps are performing and how the network is impacting that performance – for good or bad. Whether it’s simply having the data to share or providing an interface into the network to gather the data, SDN has the potential to enable greater collaboration across network and app infrastructure teams.

That makes it an excellent player in the wider ecosystem of tools and frameworks that support the need for monitoring and measurement associated with DevOps initiatives.

November 6, 2014
Cloud-Based Documentation at the Speed of DevOps

Welcome back to this (semi-)regular column where I attempt to answer questions about DevOps, especially in larger enterprises. This time I address a vexing issue facing many large enterprises – how to make sure downstream processes move as fast as development and operations:

Q. In my enterprise we are getting faster at releasing code, but we are still slow to update and translate downstream product documentation. How can documentation and technical writing be optimized as part of a DevOps approach?

As I have said before, you can ask me any question you want (in the comments below, via e-mail, or on Twitter), but that doesn’t mean I know all the answers. If (when) I don’t know, I have promised to try to find someone who does – and this is one of those times.

This question stumped me, so I asked around to find some insight into this issue. As it turns out, my company (a large enterprise, building out our DevOps capabilities, developing and operating new software every day, in many different languages, across about 40 countries worldwide) is working with what we think is an answer to this question. So I asked my colleague Jim Turcotte to explain what we are doing to address this problem. Here is what he said:

The problem – serial downstream processing

I know exactly the problem that this writer is facing! We have been wrestling with this ourselves. The problem is that with current industry practice, a team of technical writers shadow developers to document the latest product functionality. By the time product is delivered, it’s a mad dash to publish the PDF/HTML. Then, to make matters worse for international customers [our software users], it may be days or weeks before localized [translated] versions of content follow. It’s a slow, tedious, serial process that ends up being a rush to the content finish line every time.

To make matters worse, both documentation and code are typically “thrown over the wall” for Support to discover and address bugs. Documentation bugs are often handled by Support engineers writing dozens of knowledge docs. The end result is that skilled Support engineers are often diverted from addressing customer issues, to updating documentation. We then expect users of our software – our customers – to search through the product documentation and sometimes hundreds of Support knowledge documents to find answers to their questions—not exactly an optimal self-service experience!

Introducing a cloud-based collaborative approach

Something we have started doing to address this concern is by applying what we call ‘DocOps.’ It is a continuous content supply chain that connects all the stakeholders, and which is agile and collaborative. In this way, our approach mirrors many of the characteristics and culture of DevOps.

Instead of waiting until code is complete before starting on documentation, multiple writers “curate” content throughout the product lifecycle. Instead of producing static, standalone knowledge documents in PDF (or even HTML), we use cloud-based documentation, wikis, forums and chat groups. Instead of a single one-time effort, original content topics are matured continuously in a collaborative effort. Instead of channeling documentation through a single technical writer, we allow developers, operations, support, and even technical field staff [pre-sales] to curate documentation.

On-demand translation is performed as needed using local cloud-based translation services. Highly automated workflows determine which vendors will be used for each product and language. The platform senses the customer’s language preference and automatically pulls up the content in the language they prefer.

Then there’s online help. With the approach, we provide contextual help by linking content directly to product UIs. This allows customers to access additional sources of information like education courses and discussion threads all from the same source. Customers no longer have to log into multiple systems or sites to find the information they need to be successful.

Benefits of the new approach for end-users – and for us

For end-users, collaborative curation ensures documentation is always crisp and relevant, reducing the age-old problem of large quantities of duplicated knowledge/content. Customers who need help using a product are always able to find and use the latest curated content – in their language, relevant to their experience. Customers can also now access not only the developer’s original instructions, but also knowledge from other product experts, colleagues and peers.

For us, we can use its analytics to provide real-time operational feedback, so technical writers can make updates on the fly to further improve the customer experience. The new approach also enables us to close the feedback loop, connecting end user questions with engagement and lead generation tools such as Marketo, marking the first time product documentation can also be leveraged as a serious sales tool.

The old school Content Supply Chain cannot support the business agility that DevOps requires to be successful. The new documentation approach solves that. It was conceived and built around the need for an improved customer experience with product information. Do you really want to maximize your DevOps platform? Support the content with the new approach for the ultimate agile experience.

Jim Turcotte is a Senior Vice President with CA Technologies and the Business Unit Executive for its Information Services team. For more information about DocOps, follow him on LinkedIn Pulse.

October 26, 2014
Mobility Means Enterprises Need to Get Lean with DevOps

When people say “mobile” most folks think “devices.” Phones. Tablets. Phablets. Smart things. Wearables.

But what we really ought to be talking about in most cases is apps.

A McKinsey & Company survey noted, “When we recently surveyed 250 CIOs on their mobility strategies, 56 percent reported strong demand from employees to support a wide range of mobile devices.” With no direct mention of applications you might think CIOs are reporting just that employees be allowed to use mobile devices, but dig deeper into this and similar surveys and you’ll find what CIOs and employees mean by “support a wide range of mobile devices” is really this: make applications available across all the myriad devices we might want to use.

When we say “mobility” is a driving factor for the adoption of a technology or an emerging methodology like DevOps, we don’t mean just the insatiable demand consumers have for engaging with you through mobile apps. We also mean your employees, who have an increasing appetite for engaging with business applications and tools through mobile apps.

For enterprises, mobile means apps as much as devices – and lots of them. If there is one area of enterprise concern that aligns well with the startup mentality of measuring the success of a DevOps approach by the number of deploys per , it is around mobile applications.

That’s because mobile apps change a lot. According to an Oracle-sponsored survey, “35 percent of midsize and large enterprise organizations update their application portfolio monthly, while an additional 34 percent update their applications quarterly. More than four-fifths (82 percent) of respondents expect those rates to increase over the next two years.”

That rate may seem trivial to organizations seeking to achieve “X deploys per day” but traditionally enterprises plan for a single change window a month, and if you can’t fit in that window, you’ll just have to wait. There’s only so much time – and so many cans of Mountain Dew one can drink – in a single Saturday night change window and these numbers don’t take into account existing applications – both new and updates to existing – that are being pushed out on a monthly basis.

A 2012 survey from VersionOne found 37% of organizations push 6-25 net new applications per year. Nearly half (46%) push 11-50 upgrades during the same time period. That’s atop an existing base of apps that must be managed, scaled and secured.

One of the ways DevOps is able to assist is through the optimization of deployment processes that take that app or app update to production. Whether it’s through value-stream mapping or Six Sigma or automation – or all of the above- the precepts of “lean” that underpin many DevOps concepts are invaluable to enterprises looking to up their number of deploys – even if it is just per window.

If you can automate and optimize deployment processes to fit 2 or 3 more applications into each window, you gain ground. And gain ground you must, because mobile isn’t going away and neither is cloud and neither is the application economy we’re running headlong into.

There is certainly room for operational improvement – and DevOps – in the enterprise to accommodate the increasing number of applications (mobile and otherwise) that need to get to market faster and with greater assurance of availability and competitive performance.

October 23, 2014
Enterprise DevOps and the Project Management Office

Welcome back to this occasional devopsy.kinsta.cloud series on Enterprise DevOps Q&A. Remember, if you have questions about DevOps in the enterprise, let me know and I will try to answer them (or find someone who can). E-mail me at andi.mann@ca.com, tweet me at @AndiMann, or leave a comment below.

This week brings a question about DevOps that could only come from a large enterprise:

Q. For software development and IT operations, the picture is quite clear. But in my company the PMO has so much control over what projects we take on, what their scope is, when they are due, etc. How can I encourage and enable DevOps in our PMO?

Startups and ‘DevOps unicorns’ likely have never worried about dealing with a Project Management Office (PMO), but this is a very common process gate for enterprise-scale organizations. The PMO provides essential capabilities to plan application strategy, gather requirements, prioritize projects, allocate resources and budgets, manage project risk, and report on delivery, especially across complex organizations. However, as with many uniquely ‘enterprise’ departments, the PMO often seems like a significant bottleneck too.

That means enterprise DevOps initiatives must bring the PMO along too. After all, you cannot deliver business-critical software faster if you have no idea of your business priorities or requirements. You cannot claim a successful release without measuring how (or if) it has delivered on business goals. While this will often happen organically in small businesses, in large enterprises this is the remit of the PMO.

Unfortunately I have not seen a lot of ‘best practice’ (or even ‘good practice’) advice on this yet, as DevOps discussions have focused mainly on smaller organizations. However, what I have seen working in large enterprises to foster a closer relationship between the PMO and the DevOps teams is a shared approach to agile Project and Portfolio Management (PPM).

I have seen this shared, agile PPM working in three key ways:

Align development with business priorities

First, a shared, agile approach to PPM helps the PMO and DevOps teams come together and collaborate to prioritize development of capabilities that matter to the business. The PMO shares portfolio priorities and project plans with dev, ops and other stakeholders; dev and ops share development estimates and operational requirements to enable accurate planning with realistic timelines. DevOps teams can help foster this collaboration by bringing PMO stakeholders into requirement gathering and agile planning, even into standup meetings as part of the scrum methodology. This benefits DevOps teams too, by ensuring immediate feedback and shared alignment against business goals.

Manage agile parallel development and continuous operations

Second, encouraging DevOps teams to track and report on timelines, resources, and deliverables helps the PMO to report back to business leaders on progress across multiple parallel projects. In large distributed enterprises, DevOps teams can assist by sharing granular project status (e.g. burndown, commits, etc.) with PMO stakeholders, so they can measure delivery against business objectives. Shared project reporting also helps DevOps teams to measure themselves, and assign responsibilities appropriately too. This shared commitment to business deliverables is itself a key objective of DevOps in any size organization.

Measure and iterate the SDLC

Third, a shared, agile PPM approach can help drive iteration back into development. After new features have been released, shared reporting means the PMO can immediately measure the impact of new releases on business priorities. This also allows them to ensure DevOps teams have delivered against the prior plan before they reassess the current portfolio and start on the next plan. With shared project reporting, the PMO can adjust project plans to reflect achievements, prioritize the new set of macro and micro gaps, and close the feedback loop back by driving requirements into the next development cycle.

Shared, agile PPM tools and solutions

Much of this change – as with all DevOps change – is primarily cultural; it is not necessary to use specific PPM tools to enable an agile, shared approach to PPM. However, as with many activities in DevOps, automation and tooling can certainly help. Especially in large enterprises with complex portfolios and geographically dispersed teams, a shared PPM toolset may be essential.

As you mature and move from waterfall to agile development and DevOps, all stakeholders will appreciate a shared PPM solution that allows a business view of the current application portfolio, a shared view of planning and priorities, common management for both waterfall and agile projects, and roll-up reporting of application delivery and portfolio value. You may find your current PPM solution already fits; or you may need to consider supplementing or replacing it.

Where agile and DevOps aim (at least in part) to accelerate time-to-market for new business ideas by bringing business closer to service delivery, a formal Project Management Office can seem like a brake on productivity. However, as the whole business needs to go faster, IT teams can help bring the PMO onboard the DevOps train with a shared, agile approach to Project and Portfolio Management.

October 7, 2014
The Divisiveness Of The Term “DevOps Culture”

If the term DevOps has caught your ear of late and its caused you to start researching what it is and how it can benefit you, you’ve probably come across a number of dissenting pieces on the term “DevOps culture.” A recent tweet by Lori Macvittie of F5 (@lmacvittie) reiterated my thinking, “wow, this issue has some strong opinions surround it it!”

I’d be remiss if I didn’t mention that I have on numerous occasions stated my own issues with the notion of culture being an instrumental component of DevOps adoption. Having been an executive in a few startup tech companies in my past, I remember, and still smart from, the various executive team discussions about company culture. We spent hours–wasted hours???–discussing what kind of company we will be and how to build a culture that would turn us into a market leader only to have all that work undone by underhanded backstabbing and small company politics within the executive team itself.

Hence, I’m skeptical about the ability to truly foster culture anywhere. Culture is something that takes holds as a factor of the individuals involved and how they treat each other, which is a direct result of many other corporate led initiatives, such as opportunity to be recognized for their work, stability, compensation, etc. So, if it’s that difficult to foster a culture in a small startup, what is likelihood of fostering culture in a large enterprise, where so many in IT struggle everyday with great frustrations and an inability to progress through backlogs and fragility?

There’s a great Twitter discussion that includes Damon Edwards, CEO of DTO Solutions (@damonedwards), John Willis (@botchagalupe), Matt Stratton (@mattstratton) and myself on the topic in which Damon discusses how he and John Willis came up with the CAMS acronym–Culture, Automation, Measurement & Sharing–as a means of avoiding partial solutions.

In this thread, I specify that enterprises thrive on tangible, repeatable efforts. For me, attempting to explain the benefits of DevOps to the business to an IT executive needs to be rife with tangible and measurable efforts so that the IT executive can have a high threshold of confidence that if followed will lead to the expected results. In my opinion, culture does not belong in this conversation for the sole purpose that if the culture cannot be changed, the entire effort will be suspect and, thus, most likely not attempted.

In response to one of the tweets in this thread, Damon states:

Damon has been working with many large enterprises now on delivering benefits of DevOps, so I believe this statement is reinforcement of my earlier theory that culture is a big turn off for getting IT executives to invest in adopting DevOps approaches. Organizational dynamics is something that is a bullet point within the roadmap that must be dealt with and the IT executive will recognize that no transformational efforts can ever be successful without possible need to shift people and roles.

In speaking with Edwin Miller (@edwinmiller), CEO of 9Lenses, a company that provides a platform for analyzing organizational dynamics, there was agreement that culture is important, but it is very much a leadership issue. Without strong leaders that can admit fault, don’t fear not having all the answers and can incite the passion of workers any attempt at culture is a folly. The opportunity to have real transformation in IT will start with hiring IT executives that understand the changing landscape of the digital economy and realize, just like the automotive companies did in the 80’s, that middle-tier executives may have no perspective on issues where line workers have great insight into how to change things. That is, in order for things to really change in enterprise IT, it will require leaders that recognize that the aggregate knowledge of all in IT will be required to identify problems and eliminate them.

With regard to the perspective of those in favor of DevOps culture, it seems there are various perspectives on what is meant by the word culture. This blog entry by Jeff Sussna, “Empathy: The Essence of DevOps” has become a beacon for many on how to proceed by focusing on fostering change through shared experiences. This article, “DevOps Culture,” by John Willis discusses culture from the perspective of behavior modification, where behaviors are essentially how the organization responds to a given stimulus. This latter piece really is about problems caused by the overlap of people and process, which is an interesting point given that we talk about IT being about people, process and technology as if they were independent silos when what we really are talking about is the need to fix the points where these three elements overlap.

Frankly, stepping back from the fray for a moment, I find it odd that opposition to the term DevOps culture causes such fierce debate and in some cases mob-like responses in various forums. For me, I’ve presented a logical reason why the term can be seen as negative or at a minimum offer no value to entice investment or gain traction for taking action to work on the changes that are often discussed around companies practicing DevOps. Other than “it’s critical to DevOps success” messages, I’ve seen little from those pro-culture advocates as to why we should expect businesses will change something as esoteric and intangible as culture in order to succeed in fixing what we should all view as ineffective practices. Without meaningful changes in IT management to hire leaders with the aforementioned attributes, talking about culture change is akin to changing the oil filter in your car when the spark plugs are shot.

October 2, 2014
Four key vectors for closing the DevOps feedback loop
A question I am asked frequently about DevOps – and a perennial challenge to all DevOps slide artists – is what exactly we mean by the idea of ‘closing the feedback loop’

Q. What do you mean when you mention ‘closing the feedback loop’? Ops monitor our systems today, and alert devs when they are needed (next step, devs carrying pagers!). Is this the same Ac?

Yes, this is definitely part of the equation. Feedback from operations (and more) to development (and more) – through alerts, monitoring, log entries, service tickets, or verbally – is essential. Good fast feedback helps, for example, to:
- connect dev and ops more closely to user experiences
- establish shared insight to replace fragile tribal knowledge
- foster ownership from both teams in the entire service
- provide rapid response to problems or new requirements
- encourage faster experimentation and a tolerance for failure
Feedback loops in smaller organizations tend to be relatively simple – just lean over the cubicle and tell your counterpart what is going on, or program the monitoring system to send you an alert. However for larger organizations the multiplicity of teams, volume of events, separation of duties, and variety of feedback can make this harder to handle.

In larger organizations then, I see four key vectors used in closing the DevOps feedback loop:
- Machine to Person (M2P)
- Person to Person (P2P)
- Machine to Machine (M2M)
- Person to Machine (P2M)
I have tried to illustrate these 4 vectors below (and not being any kind of graphic artist, I would love any feedback on this image):

Machine to Person (M2P)

This is more or less the alert cycle the original question posed – a machine process (performance monitoring, for example) picks up an error situation that it cannot identify it as a ‘known resolvable’ issue, so forwards it to a person to take charge. Machines can resolve many problems automatically with intelligent orchestration – rollback a release, increase capacity, modify a configuration, migrate a workload, restart a service – but sometimes a person needs to fix hard and/or infrequent problems.

Person to Person (P2P)

This is just the classic ‘hot line’ feedback, where application users (internal or external) talk directly to someone in IT (e.g. help desk staff). This can be the most powerful feedback of all. Not only can it help identify defects, but it can also identify opportunities for improvement – from new features to entirely new services. However, to be useful this personal feedback must be transferred into development or operations process – e.g. to update configuration scripts, or as input to future release planning.

Machine to Machine (M2M)

This includes automated problem resolution (e.g. monitoring detects a performance bottleneck, triggers a provisioning engine to add additional capacity), but also includes data mining that feeds back ‘real-world’ production data to build more realistic test and QA environments, or to inform more accurate capacity plans. This feedback makes prod more stable, makes QA and test more realistic, reduces human and process errors, and helps to build scalability into applications from the start of the SDLC.

Person to Machine (P2M)

This can take many forms, such as end-users logging problems into a self-service portal or Service Desk, or rating a mobile app, or complaining online. Automation can trigger resolution for known problems, so end users can address problems automatically; or feedback can reach product owners to resolve common user complaints. However, P2M feedback may waste resources and increase technical debt, as solvable problems are fixed repeatedly rather than permanently; or user complaints are ignored.

Final Tips

These four vectors of active feedback are just a starting point, but describe a framework that enterprises can work to when looking to close and accelerate your feedback loops. Remember too that in a DevOps mode, feedback needs to be faster, it needs to be more accurate, and especially in a large organization it needs to connect not just with dev and ops, but with other stakeholders too – business owners, test and QA teams, security teams, and of course end users.

What are your feedback loops? Do you cover all four vectors? Do you have more that I am missing? Please let me know in the comments below – as always, I would love to hear from you.
September 29, 2014
Right-Picking the First Project to Go DevOps On

One of the hardest things to do when starting a new initiative is picking the right project to work on. Should I start with App A? App B? Does it really matter as long as I get started on this DevOps thing and prove its value to management?

Yes, actually, it might.

If you think about it, one of the reasons you’re doing DevOps in the first place is not just because it’s cool (it is, of course, but that rarely flies with the business guys) but because it’s going to add value in one or more ways by improving time to market, reducing risk and lowering operating costs. If the project you choose to go DevOps on isn’t capable of showing those benefits (or isn’t capable of showing those benefits in a reasonable time frame) then you might just be choosing the wrong one to start with.

So how do you choose? Well, how about starting with an app that’s being developed using agile methodologies?

According to the “8th Annual State of Agile” survey from VersionOne 88% of respondents were practicing agile development, which means you shouldn’t have a hard time finding one.

Except, you might if you aren’t paying attention. A high adoption rate doesn’t necessarily mean a high saturation rate, however.

Dig a bit deeper into the survey and you’ll find that agile isn’t used for every project. On the contrary, there’s a good distribution of agile and traditional (waterfall ) methodologies being used. While over half of the respondents are using agile to manage more than 50% of projects, the other 48% are using some other methodology.

Which offers some interesting strategies for how to get started with DevOps on the other side of the wall (that’s you, in operations land).

On the one hand, the projects most in need of improved velocity in deployment (time to market) are likely those being developed using agile methodologies. The aforementioned survey validates that approach, with the top reason cited for adopting agile being “accelerate time to market.” The general premise of agile is fast, frequent updates, making the need to deploy into production a more pressing priority. Choosing an app that’s being developed using agile methodologies means you’ll be able to practice, refine, and optimize the processes as you work to automate the deployment. Because of the frequency with which agile-developed projects tend to need deployment, this gives you the opportunity to practice similar techniques on your automation and optimization.

You’ll be able to automate individual tasks and test them thoroughly before moving on to the next one and the next one and the next one, until you’ve got the process orchestrated (yes, Virginia, there is a difference). You’ll then have ample opportunity to optimize the process, finding redundancies or inefficiencies in the way information is gathered and disseminated into the process. Optimization of the process means greater efficiency, especially if you can knock out those all important wait times between tasks.

The key here is that you have to know which projects are being developed using agile methodologies, and which aren’t. That means communicating with developers. And not just by sending an e-mail and asking for a list, but really talking to them to understand which projects the business would benefit from improving time to market. Getting an app that is the vehicle for competitive advantage to market faster seems a bigger return on investment than the app used by just a few people for non-critical purposes. You’ve got to dig in and determine which agile projects need agile deployment the most, and then decide where to dig in.

This is not to imply that less frequently deployed apps will not benefit from agile. They most certainly will, though the benefits that DevOps brings to those apps are more about stability and consistency than they are those derived from improving time to market.

What’s important is to decide what your goals are with DevOps and what benefits will be worth the most bang for the buck (cause it ain’t going to be cheap in terms of time investment). Getting DevOps on an infrequently but mission-critical app can reduce the risks associated with rusty processes and improve stability in general. Automating the deployment of such applications can certainly save time and resources that can be redirected to agile projects in need of greater deployment velocity.

But if you’re looking to show value and return on investment, you’ll likely want to choose one of the agile-developed projects that already exists and needs some attention. Not only because it’ll show value faster, but because it’s releasing frequently enough that you’ll actually get the opportunity to refine (and one hopes optimize) your automation and orchestration.

September 25, 2014