You can divide most IT departments into two groups, the development people and the operations people. (Yes, we’re oversimplifying, but bear with us.) The development folk are focused on innovation; they’re responsible for creating the applications that give their companies a competitive edge. The operations people, on the other hand, prefer stability, because it’s their job to keep all the cool applications the developers create up and running at peak performance. If you’re charged with maintaining functionality and your beat is your company’s infrastructure, change usually means either disruption at best or catastrophe at worst. Out of these separate focuses emerges two different cultures. But these days many businesses are working to break down the barriers between development and operations—that’s how you get DevOps.
The Agile Revolution
Going back to the days of Henry Ford and Frederick Taylor, business managers in all kinds of industries have operated on the same basic principles that made the assembly line such an efficient production tool for factories. Following these principles, workers build products in sequential stages, and each stage is handled by a worker specializing in the requisite tasks. This is the same logic that underlies the waterfall method of custom software development. You begin with requirements-gathering, move on to design, then development, then testing, with each stage taken on by specialized experts, much as they would be on an assembly line.
One of the main benefits of assembly lines is product standardization, but in the realm of business computing the focus is on customizing, not standardizing solutions. If you’re trying to create a custom solution to complex business challenges in a dynamic and rapidly evolving environment, principles designed to ensure standardization probably won’t be your best bet. In the rare situations where you can actually know all the requirements upfront with a high degree of certainty, waterfall may be the most efficient approach. But more often than not the requirements for a business application end up changing—or only gradually become clear—over the course of development, and this is one of the main reasons for high rates of failure when it comes to custom development projects.
The increasing popularity of agile methodologies is just one of the IT industry’s responses to the difficulty of upfront requirements-gathering and the need to keep apace of innovations in business computing. Alongside a rethinking of the rigid sequencing of the phases of development projects is an ongoing erosion of the barriers separating workers with various specialties.
The central premise of agile development methodologies like scrum is that big, complex projects are best tackled by breaking them into smaller parts. You still have sequential stages, but instead of one overall push to build the application you take it on a piece at a time, and hence you end up going through all the stages multiple times. This piecemeal approach makes it possible to deliver a subcomponent of the application at the end of each project iteration. And this type of iterated delivery gives stakeholders and end-users multiple opportunities to provide feedback and reassess project priorities. But there’s another important premise built in to this method: development projects are most likely to succeed when stakeholders and workers in all the different roles keep in close communication.
DevOps and the Rise of Never-ending Development
Alongside this rethinking of development methodologies has come rapid innovation in areas like mobile devices, analytics, cloud hosting, and virtualization. Business workflows are tied ever more closely to an increasing range of technologies, and this means that the edge in competition will go to the companies with the most efficient processes for developing quality applications. It’s no longer enough for developers to create a great app and hand it over to operations to be kept optimally functional for a few years. Now the operations people are monitoring usage patterns and setting up virtualized environments for testing, and developers are incorporating the usage data into their designs. Replacing the old linear sequence of development stages is an ongoing back-and-forth. And one of the potential outcomes will be an ever more rapid pace of innovation.
DevOps isn’t any one technology. It’s more of a guiding philosophy for how workers tasked with different aspects of development should interact with each other. And, as with agile methodologies more generally, the approach has its detractors. Stopping and restarting projects multiple times is inefficient. And forcing workers to learn several specialties so they can communicate with experts in other areas might result in teams consisting solely of jacks, with no masters. But the trend is to view the added flexibility and communication that come with the new approaches as necessary responses to the complexity of modern business computing.
Also check out: