Stop Reaction-Based IT — Adopt a DevOps Workflow

Historically, IT departments have tended to operate reactively, responding to their organizations’ immediate needs and delivering solutions to each problem and request with a unique process generally created from scratch. The traditional siloed nature of large IT departments compounds this reaction; generally, one silo is waiting for another to provide them the services needed to fulfill the request or fix the problem. Without an established workflow, the IT department struggles internally with how to deliver a solution or product with consistent results, often doing just what is needed to accomplish a project or solve an issue. This often leads to unrealistic deadlines, an abundance of confusion among IT employees, lead times that are unacceptable to end users, and a final product that is not quite what the IT department wants to deliver — often one deemed deficient by the end user. Sometimes it just feels like a “hail Mary” football pass; everyone just hopes it will all work out as the IT department then moves on to react to the next problem or request with the same amount of confusion and inconsistent results.

Today’s technology is moving too fast for the reaction-based IT model to be sustainable. More accessible and faster bandwidth has caused an exponential growth of IoT devices, digital media and data analytics, which is driving a need for more agile and complex solutions to an organization’s IT needs. Furthermore, end-user expectations are higher than ever, and tolerance to service disruption is very low. As a number of business-critical and safety systems have moved to the IT department, a reaction-based response cannot keep up with demand and is not likely to deliver a consistent product that meets needs and expectations. We need to rethink how IT departments operate and deliver services to end users, and to do so we can take a page from software development: DevOps.

DevOps: Not just for software development anymore

What is DevOps exactly? Bringing together “development” and “operations” to speed delivery, the DevOps process is a workflow that outlines the way an organization delivers its IT services and products. Think about what the purpose of an IT department is — at its very core, is to deliver a service or product to end users, be it customers, employees, or an entire organization. This type of customer service/product relationship is not much different than any other type of service product relationship — think of an automaker, for example, that builds cars and then sells them to customers. The automaker needs a process to build cars efficiently and ensure they are functional and safe. Automakers utilize a well-planned workflow to ensure that this can be done in a manner that is cost-effective, follows government safety regulations, and most importantly, delivers a product that meets customers’ needs and expectations.

It wouldn’t be much of a stretch, then,  to say continuous integration/continuous delivery (CI/CD) is to IT what is an assembly line is to an automaker. In software development, CI is the process of developing a service or product and evolving it to the next version. It starts with version control, which should be iterative, employ many small changes and avoid large-scale changes and revamps. This approach has two great benefits: An IT department’s changes are now documented and thoughtful, and many small and ongoing changes address the end user’s needs quickly, rather than asking them to wait for a large change (and of course, troubleshooting a large change is more difficult than a small one).

CD is the processes involved in testing and deploying these changes. The CD approach takes into account all the steps needed to deploy these changes and deliver them seamlessly to the customer with little or no disruption of service. Ultimately CI/CD should be ongoing and can quickly meet the needs of the end user, while not compromising the stability and functionality of the service.

The idea of treating IT operations like a factory assembly line is well documented (“The Phoenix Project” by Kim, Behr, and Spafford does a great job of this) and is especially effective in large organizations that have a very siloed IT environment. In these environments, without a thoughtful and well-planned workflow or process, each silo will only do what is needed to satisfy their internal needs rather than delivering a product/service that meets end-user needs. A well-run IT department that adopts a DevOps process will be able to deliver their services/products effectively and deliver IT efficiently.

So if you’ve found yourself looking for a workflow that will smooth the processes of your IT department, you do not need to reinvent the wheel. What is important is that you start having these discussions now. Change will not happen overnight, so it’s important to start with a plan to develop workflow, and then implement and stand behind the policy. Don’t simply react to your organization’s IT needs — adopt a DevOps workflow for your entire IT department and deliver the IT services and products in an efficient and thoughtful manner.

The following two tabs change content below.
Barry Weiss

Barry Weiss

Barry Weiss is a network engineer with more than 15 years of experience in the IT field. His certifications include CCDP, CCNP, CCDA, CCNA Security, CCNA Cloud, CCNA, Google Cloud Certified Associate Cloud Engineer, IPv6 Forum Certified Gold Engineer and CompTIA Network+. He was recently named a 2020 Cisco Champion.
Barry Weiss

Latest posts by Barry Weiss (see all)