In my last post, I introduced DevOps and briefly explained its history and benefits. An organization cannot merely change the name of its IT department to DevOps and expect to immediately realized outsize rewards. On the contrary, firms often face considerable challenges on both the technology and people fronts as they embark upon the DevOps path.
Perhaps the key tenet of DevOps is continuous deployment/delivery. Few intelligent business and tech folks would argue that it’s never been more critical to anticipate and respond quickly to emerging trends. Still, no firm can do this merely by fiat. CXOs can implore their underlings to work hard as much as they want, but the simple truth is that aging infrastructure prevents many employees, groups, teams, and even entire organizations from quickly releasing new features and services. (For an example of how this recently hindered the airline industry, click here.)
Aging infrastructure hinders more than a few organizations’ attempts to embrace DevOps.
Put differently, consider XYZ, a fictitious mature organization that runs a bevy of self-hosted legacy applications stitched together with a patchwork of extract, transform, and load (ETL) routines. The term spaghetti architecture comes to mind. As a result, key systems fail on a relatively frequent basis. New features to existing applications take months to launch, never mind brand-new applications. Basic reporting remains a challenge and many systems ought to be at least refactored if not retired. Finally, all testing is manual.
A few years ago, XYZ management cautiously embraced cloud computing and ported a few applications over. This only meant more complexity and increased cost; think of it as addition by addition.
If you think that DevOps is a silver bullet here, think again. Unless and until XYZ cleans up its act and thinks about upgrading its infrastructure, cycle times will remain long. In short, DevOps is unlikely to make a bit of difference.
Even the “best” or “most current” tech, however, does not guarantee by itself that DevOps succeeds in any given enterprise. As I’ve said many times before, organizations’ muscle memory tends to be strong.
Plenty of old-school IT folks remain stuck in their ways and don’t easily accept new ways of doing things. For instance, some reject the very idea that core DevOps tenets such as automated testing frameworks can bear fruit. Deploying several times per day is anathema to them, as are Kanban Boards, burndown charts, and other Agile artifacts.
As powerful as DevOps is, it is no elixir. Without the right infrastructure, people, and culture, efforts to adopt it will likely die on the vine.
What say you?
In part three of this series, I’ll offer a few thoughts on the future of DevOps.