Your Status Quo is Status Stuck

Any IT professional can tell you that company brass rarely sees a need to increase IT budgets while systems are up-and-running. It is undeniable that in today’s business world, uptime is money, yet business leaders still view IT as just a cost center.

The unfortunate effect of this view is that there’s little appetite for taking measured approaches to broader changes, like moving from waterfall software development to fully embrace Agile and DevOps. Business leaders may think that equipping IT teams with DevOps-ready tools will result in faster application releases and fewer issues, but without making significant cultural changes to break down work silos, DevOps’ business impact can’t be fully realized. This lack of commitment to see through the major cultural changes required for DevOps is a widespread issue evidenced by reports that about 80% of organizations trying to “do” DevOps still can’t be considered “advanced” or even full adopters.

However, thanks to the many vocal supporters of the DevOps movement who have spent years saying “it’s about more than tools,” even those organizations that haven’t fully implemented DevOps still understand the need to break down work silos and encourage systems-wide thinking from employees. The reason so many organizations fail to fully implement DevOps is that too few break down all the walls between IT teams and end up focusing too heavily on individual parts of the software delivery lifecycle (SDLC).

Once IT teams have started bringing down their work silos in earnest, it can be harder to recognize the ones that are still standing (or perhaps too easy to justify leaving them in place). The symptom to watch for is disproportionate increases in efficiency. If the SDLC is accelerating, but businesses aren’t releasing application updates faster and more frequently, then it’s likely that there are still complex processes in place that can be simplified.

Too often, IT leaders focus on helping developers build and test code more quickly. but overlook the many time-consuming processes between code delivery and production deployments. Developers might be able to push code updates daily, but can database administrators (DBAs) work fast enough to check that code for problematic database changes in a day too? Probably not: four out of five application changes require a corresponding database change, so you can bet DBA workloads are piling up. Potentially even worse for organizations that invested more heavily in code delivery, QA and security teams might fall behind looking for vulnerabilities, putting business and customer data at risk.

Continuous improvement plays a big part in the quest to break down organizational silos. If IT leaders encourage systems-wide thinking from employees, then they should be making efforts towards systems-wide problem solving. If DBAs can’t keep up with database changes coming from accelerated development cycles, that should signal to IT leaders that the feedback loop between DBAs and developers isn’t flowing smoothly enough – a work silo still exists there. To break that wall down with an eye on continuous improvement, smart IT leaders should do two things: ask the organization if certain tools can help accelerate processes, and work with both DBAs and developers to simplify complexities on either side. Perhaps developers don’t understand the impact some updates have on the database, and more feedback from DBAs can help developers understand the difference between a good database change and a bad one.

People and processes are the real heart of DevOps because breaking down work silos increases a business’ ability to innovate in response to customer needs or market forces and continuously stay ahead of their competition. When organizations fail to fully invest in the culture of continuous improvement DevOps depends on, the unbroken walls between developers, operations, QA and database teams dilute the business impact an advanced DevOps implementation can have.

For more tips on what it takes to run a successful DevOps program check out this white paper: 9 Metrics DevOps Teams Should be Tracking