DevOps Requires an Optimized Application Delivery Tool Chain

Part 2 -- Part 3 of Component Management Strategy and DevOps -- Part 4 Up Next

Ok, I need a "blog post delivery tool chain" because part 3 in my DevOps series of blog posts is woefully behind my expected delivery date. It's like a broken development process - I'm missing oversight and guidance to make sure things stay on track! And to think, I don't even have to manage collaboration between multiple developers, or deal with IT Ops, etc.., which brings me to the point of this post…

While DevOps is about culture, people and process; technology and automation are necessary to provide repeatability, improve efficiencies, and free human resources to do high value work. It's also the thing that technologists tend to focus on - I found it interesting at the DevOpsDays that I've attended in Atlanta and Portland, there was great promise about culture, people and process, but the discussions invariable came back to tools. People wanted to discuss what tools to use and what tools not to use. It's like they wanted to move the discussion to a higher ground, but they couldn't resist talking about technology. This reflects that DevOps is new, its immature, and people are focused on optimizing the release process through automation, which means tools and technology. So while there is an appreciation for the non-technical topics, the reality is that people are still making technology and tool choices at this point.

It makes sense too, automation is critical given the scope of what organizations have to deal with. They have lots of applications, they have lots of new functionality they want to deliver, they have tons of servers to manage, they have lots of deployment environments to choose from. And finally, they have lots of components to manage. They simply can't manage the the volume, complexity, diversity and release cadence of components (many open source) with all of these other factors manually. DevOps needs to provide and support an automated, efficient tool chain – this tool chain will form the foundation for accelerating application delivery.

While part of the tool discussion will focus on what tools to use - for example, what Continuous Delivery and Continuous Integration tool you should select, it's important to step back and to think about the challenge more strategically. Even if you plan to build the tool chain and involve different constituents in the process in a phased manner, think about the critical design factors up front - it's analogous to taking an enterprise architecture approach to building applications and infrastructure. Since I want to get this blog post published soon :-) I can't address every strategic design aspect, but I'll throw out some thoughts that can serve as a starting point.

• Lifecycle Support: Think about a comprehensive tool chain that supports all aspects of the software lifecycle. Think about how your software development process works today, or better yet, think about how it should be optimized for the future. Then identify support for each aspect of the lifecycle. Since applications are dominated by components, make sure you factor in how applications are constructed today. Visibility, guidance and enforcement is needed throughout the entire application lifecycle, it shouldn't be introduced as a single gating factor, especially if that gate is at the end of the process. Think about the information and process that you can implement in an automated way that will shift activity to the left, which will speed development and reduce downstream rework.
• Personalized Support: Design your toolchain so that it supports the needs of the individual constituents directly in the tools that they use. This is critical for multiple reasons - if the support is not designed for each constituent, it will slow them down, and they'll look for work-arounds, which will force activity outside of your managed application delivery tool chain. It's also key for effective collaboration. At the DevOps show in Portland, Ben Hughes (@benjammingh) provided an example of this when he gave an ignite talk on how security needs to "stop sucking". He talked about how security needs to stop being so negative, and that security needs to understand what IT Ops and Development does. I think this illustrates my personalization point - if security can provide information to the developers in a language that they understand, delivered when they need it and where they need it, security will be more effective.
• Heterogeneous Support: Heterogeneity is a reality in mid-to-large size organizations. From programming languages, to databases, to operating systems, to deployment environments… even organizations that say they standardize on one particular aspect typically have exceptions. So while I'm not implying that you should provide multiple options for every tool in the chain, your tool chain should address heterogeneity. And along these lines, your toolchain should be flexible - while it can't be completely plug-and-play given the integration necessary between the tools, if you can take a service based approach, you'll have more flexibility if you need to switch a tool out at some point.

Hopefully this will help you identify the design factors you should consider as you think about our automation approach. Let me know what else we should add to the list!

And for those of you in London, join us at the DevOpsDays on 11 & 12 of November 2013.