DevOps As Design

The DevOps movement has encountered a certain amount of criticism for not being more prescriptive. “The principles sound nice,” critics say, “but how do we actually do it?” They get even more frustrated when proponents answer, “you have to figure it out for yourself.”

What if we practice DevOps as a design activity rather than as a set of implementation guidelines? Instead of looking to it for instructions on what we should do, we would use it as a unified method for changing and improving systems, processes, and organizations. We would use the CAMSmodel to guide and calibrate our design efforts:

• Culture: continually look for ways to increase empathy, respect, trust, and collaboration across organizational silos, whether they be between dev and ops, ops and security, or any other set of IT-relevant groups. Having developers carry pagers, for example, is a great way to give them empathy for system administrators. It’s just one technique, though, and might or might not be appropriate for any given organization.
• Automation: continually look for ways to automate repetitive, error-prone processes that impact engineers’ ability to focus on higher-level activities requiring human intelligence and decision-making. Whether automation uses Chef vs. Puppet, or open-source vs. commercial tools, or whether it starts with comprehensive infrastructure-as-code vs. simply automating application deployments, is not the essential point.
• Measurement: as Etsy puts it, “if it moves, graph it. If it doesn’t move, graph it anyway.” Adaptive processes require feedback. DevOps as design continually thinks about what kinds of feedback could be useful, and experiments with new ones.
• Sharing: continually seek ways to share tools, approaches, measurements, and lessons across teams. Sharing doesn’t insist that dev and ops always use the same task management tool. It does, though, encourage them to learn from each others’ experiences, and to smooth out unnecessary differences.

DevOps as design is a creative process of moving a digital service organization’s culture, automation, measurement, and sharing from where they are to where you want them to be next. It is continous and circular in nature:

• Identify possible places to go next
• Experiment with ways to get there
• Propagate changes that work
• Identify the next set of possible places to go

DevOps is a creative design method because it doesn’t bring about provablycorrect solutions or “best practices”. Instead, it lets organizations explore possibilities and discover solutions with “good” or “better” outcomes. If we practice it in this way, we can use it to connect industry-level goals and principles with implementations that match individual organizations’ practical needs and constraints. By doing so, we can transform “you have to figure it out for yourself” into “here’s how you figure it out for yourself.”