I came across this twisted version of an old saying while reading on my travels to Santa Clara, CA for EMC’s first (hopefully annual) IT Transformation Week. As I met with customers to explore Environment/Platform-as-a-Service (EaaS/PaaS) and hybrid clouds, I began to see just how true this revised version is in most enterprises.
DevOps is a fairly simple set of concepts and guidelines, namely:
- Collaborate more
- Automate and version everything
- Eliminate waste
These concepts and guidelines are all focused around a single objective, namely reduce cycle time by improving consistency and minimizing repetitive manual tasks.
In conversation after conversation, at IT Transformation Week, a common thread prevailed. In general, everyone agreed that following the above guidelines would improve their ability to rapidly deploy software and that devops was a better way to operate. However, nearly all struggled with visualizing what that would look like in their organization. Without a vision of what this could be, it is very difficult to create a path through the organizational obstacle course. The challenge often seems too big to solve and organizational inertia is too difficult to overcome. Although the need is present, the invention is hidden in the weeds of doubt, departmental “protectionism”, and organizational inertia.
Change is risky business; and big change is often equated with professional suicide. So rather than leaping head first into the innovation abyss, start small with a low risk project to implement an integrated, automated tool chain (devops tool chain). Then, use your “invention” to demonstrate the possibilities of transformation. By leveraging the work completed in this pilot, you can illustrate how this small, first step, a.k.a. the devops tool chain, can address the needs of an organization to deploy faster, improve stability, and/or reduce operating cost, the necessity
BTW, small does not equal skunk-works. Rather, I am suggesting a fully sanctioned project with clearly defined metrics, sponsors, and target returns that can provide the evidence needed to justify future investments. This means creating a baseline of current practices and processes with measures like cycle time, lead time, process efficiency, and devops maturity and then re-measuring these metrics at project completion. Capturing these metrics and illustrating how the “needled moved” will increase confidence and buy-in from other stakeholders.
By starting small, you are able to establish a win and use that win to build momentum both tactically in the form of new tools and practices and politically in the form of driving IT performance improvements. It the “snowball” effect. The initial win is the snowball at the top of the hill (our invention). As we incrementally extend the tool set, refactor SDLC processes, and align our people and skills to the new operating model, the snow ball rolls down the gaining momentum and mass. In essense, it is creating a greater necessity to act. Use success to feed future successes.
So let’s flip the old adage on it head and let invention be the mother of necessity in the enterprise.
