How a DevOps environment transforms organizations

There are key principles that form a DevOps environment. What are these principles and how can organizations build a DevOps practice?

The DevOps revolution is upon us, but why? According to Patrick Debois, one of the masterminds behind the movement, the DevOps environment grew as a reaction against some of the common problems that the IT industry faces, including the siloing of team members and the work they do, the uncertainty of introducing new features or deploying changes, the difficulty of finding and addressing defects and the rise of bottlenecks within the software development lifecycle (SDLC). 

A DevOps environment aims to address these challenges by increasing how well IT operations and development teams collaborate in order to create an environment characterized by a unified team with a multidisciplinary skillset. This structure transforms the way that teams work together and the way that software is built by bridging the gap between “dev” and “ops” and applying effective DevOps tools to mitigate data silos. Overall, a DevOps environment increases visibility to reduce the risk of uncertainty, improves error and bug detection and mitigates bottlenecks and waste in the development process.

Organizations without a DevOps environment often have a team structure based on a division of labor. These teams often work in silos, with developers, testers and IT operation professionals working in separate worlds to achieve their respective goals. This division of labor is an outdated model to structure teams because it creates barriers between them and hinders their communication and the way they work. As a result, this model severely impedes both agility and speed. 

But how? A common scenario, for example, is when the development team reaches out to the operations team with an emergency (e.g. “Help, the server crashed!”). Operations teams already have their own responsibilities they have planned for. When the development team puts unplanned work on their plate, this not only disrupts their workflow process but also leads to waste in the software development process. In fact, more often than not, the operations team has other responsibilities to attend to and is unable to finish this ‘unplanned work’ on time. It is clear that as a result of this division of labor, team members are not aligned and are unable to deliver––hampering agility, speed and overall business goals. 

A DevOps environment seeks to mitigate such challenges and other issues that may emerge as a result of this model. This is done through various practices, including:

• Continuous integration: Integrating code into a shared control repository regularly, preferably daily. 
• Continuous delivery: Deploying and releasing changes and fixes daily in a controlled, rapid manner.
• Automated testing: Testing deployments and deliveries in a continuous, automated fashion.
• Active monitoring: Conducting “health-checks” to ensure platforms, applications and solutions are running appropriately. 

The above practices allow team members to create a DevOps environment based on a collaborative structure. In this environment, team members are aligned in terms of their responsibilities throughout the SDLC and share a unified vision regarding the overall business goals. 

Firstly, a DevOps environment leads to an increase in visibility and a decrease in the risk of uncertainty because development and operations teams are more tightly aligned and have insight into what each team is working on, upcoming projects and more. This means that the next time a member on the development team asks the operations team to fix a crashed server, members of the operations team already have visibility into what is in the pipeline and can strategically incorporate requests and other tasks into their workflow. Similarly, because the development team has visibility into the work that the operations team is conducting, they are able to prioritize accordingly. As a result, the increase in visibility not only improves communication between teams, but also increases time-to-market. 

In addition to improving visibility, a DevOps environment also reduces the risk of uncertainty. But this is not only related to timelines and project delivery, as in the above example. It is also related to the way that teams address issues and generate solutions. This means that the next time an error or bug arises, one team is not pointing fingers at another accusing them of causing the issue or demanding they solve it, a common scenario in a traditional environment. Rather, in a DevOps environment team members already have visibility and can work closely together to solve such an error and pinpoint its source. There are no more divisions or barriers; instead, each issue, bug and business requirement is everyone’s responsibility. 

A DevOps environment not only increases visibility and reduces uncertainty, but also improves the process of detecting and addressing errors, bugs and other issues. As mentioned previously, in a DevOps environment, teams embrace various practices, including continuous integration. This practice involves implementing changes and deploying them in small batch sizes, in addition to checking them on version control on a regular basis. This is unlike a traditional environment in which changes are implemented in large batch sizes, causing uncertainty and making it more difficult for team members to detect errors. 

Through continuous integration, a DevOps environment creates a model based on sustained and instant feedback. Teams can then decode errors or bugs and address them much more easily than in a traditional environment, where large bulk changes complicate the software development process and makes it difficult to know what the problem is, where it is located and who is responsible for it. 

A DevOps environment is key in creating a collaborative environment that increases visibility, reduces uncertainty and improves error detection. However, this environment can also help mitigate bottlenecks and eliminate waste in the development process. As one DevOps head puts it: 

“What tends to happen is this: one day an engineer decides that building servers is a tedious, manual process and that they could write a quick script to make that bit a bit quicker. The next day, they write another one. And another one. Until, over a period of months or even years a whole bunch of scripts have been written automating lots of parts of the process – I like to call this a ‘script monster’.” 

As this DevOps head reveals, eventually, when the “script monster” fails, it is difficult for other members of the team to address the issue. A short-term solution is to call the engineer and ask him or her to save the day. But in the long-term this is an especially troubling approach, especially if the engineer is unavailable or – worse – is no longer part of the team. In this case, the only thing that will remain is a bottleneck that hinders both agility and scalability. 

A DevOps environment seeks to eliminate the emergence of such bottlenecks and the subsequent waste that they may cause. Although the engineer was well intentioned, they did not transform the tedious process of building servers into a team issue. Rather, they created a short-term solution that can only be executed by them. A DevOps environment aims to mitigate such scenarios by encouraging automation and documentation, thereby increasing communication. In this environment, every release is committed in an automated fashion, enabling the rapid building, testing and deployment of every project. In addition, documentation is usually stored alongside code and is revision controlled. This makes it easier for team members to track any changes or updates that occur. Both automation and documentation lead to improved team communication and by increasing communication, a DevOps environment allows members to build, test and deploy as a team. This means that the next time a server crashes, for example, the engineer above along with the rest of the team are well-equipped to address and communicate the issue. 

A DevOps environment is key in increasing visibility, reducing uncertainty, improving error detection and mitigating bottlenecks. It is estimated that by 2019, 1 in 3 organizations could have a DevOps practice. This means that, today, many organizations either have a DevOps practice in place or are in the process of building one. 

One of our customers, Cox Automotive, faced a number of challenges and came to MuleSoft because they needed to improve their DevOps practice. In the span of three years, Cox Automotive acquired over 20 companies, resulting in unprecedented, accelerated growth. Unfortunately, IT had minimal resources and their DevOps practice was unable to create the reusable assets necessary across a number of acquired companies. Cox Automotive realized that it is not enough to create the foundation for DevOps by bringing their developers and operation teams together. They needed to build an environment that encourages the creation and consumption of reusable assets and self-service data; and enable the growing number of companies under their umbrella to leverage these assets effectively and securely. 

Cox Automotive turned to MuleSoft to adopt two key elements: A framework, a Center for Enablement (C4E) and a technology, Anypoint Platform™. A C4E aims to transform IT teams into strategic business enablers, as opposed to traditional technology functions. C4E refers to a cross functional team that operates across central IT and Line of Business (LOB) IT. This team is charged with ensuring that assets are consumable, consumed across the organization and fully leveraged in the process. Once a C4E is established, the model can ensure that teams adopt DevOps best practices and innovate and deliver over their objectives through an agile process and governed manner. With C4E, team members at Cox Automotive were able to shift away from delivering projects to the business to creating reusable assets that enable the various acquired businesses to self-serve and deliver on their own projects. 

Alongside a C4E, Cox Automotive adopted Anypoint Platform™. The platform enabled them to unlock digital assets such as driver history, vehicle records and price comparison data securely via APIs. As a result, these assets were discoverable and reusable across the company, allowing team members to experiment and launch new products quickly. This technology, alongside a C4E operating model, created a foundation for a DevOps environment by improving visibility, reducing uncertainty, enabling self-service and, most importantly, mitigating bottlenecks in the development process. Moreover, this new operations model also allowed Cox Automotive to provision data access to business partners in a matter of seconds. 

With MuleSoft, Cox Automotive was able to build a DevOps environment that transformed the way they delivered new automotive trading as well as the method in which they auctioned, priced and exchanged products. The IT team went from 2-month cycles to 2-week sprints, delivering MVP and enabling iteration with business partners in each sprint. As Andy Lapin, Senior Director of Emerging Platforms at Cox Automotive, reveals: “Anypoint Platform is instrumental for Cox Automotive in building an application network that stitches together disparate systems and enables our team to create innovative new solutions for our dealers.”

Explore how Anypoint Platform™ can help build a successful DevOps environment and read about how the platform has helped many of our customers, including Spotify and Siemens, create a better DevOps practice.