Technology is fond of acronyms and fads, and information technology (IT) in particular always has a new technology or methodology to learn. The latest new-fangled thing to emerge from the overworked laboratories of IT methodology rework is DevOps. The term “DevOps” is a portmanteau of “Development” and “Operations”, and it means what it looks like: an amalgamation in tools, methodologies and cultures between the development and the operations teams in an IT environment.
“Development” in the DevOps definition is not just software developers – it is everyone within an organisation – or department – involved in developing a product or service. This includes the traditional software developers, but can also include product development teams, quality analysis, testers, marketers, control, and research and development in both IT and non-IT scenarios. “Operations” in this context means all those personnel and departments that keep the lights on – they are in charge of operating, managing and monitoring systems or applications.
In a self-contained environment, Development and Operations are almost always opposed in approach. Developers want fast and frequent deployments of products, or services, or of software code. This allows them to rapidly achieve whatever targets they have, and is also excellent for error management and tracking: it is easier to find an error if you are doing many small deployments discretely, than if you gather all your changes into one huge deployment and then release it: in case of an error in the latter approach, finding where the error originated from is a massive undertaking. In a marketing scenario, for example, rapid deployments would take the form of many different marketing campaigns, each targeting one product and one audience. Finding out the effectiveness of the marketing campaign is relatively easy in such a case, and errors can be corrected and rapidly remedied. This is in contrast to bundling several marketing campaigns together and releasing all of them simultaneously across various target audiences: impact is virtually impossible to measure for individual items.
DevOps is an outcome of process failure. Traditional systems development relies on the well-documented Waterfall Systems Development Life Cycle, a systematic and fairly rigid way of developing information systems by breaking the process into several phases that each lead to the next: requirements gathering and analysis, system design, system development, testing, implementation, and post-implementation review. Each phase expects input from the one before it, and the review at the end can send its input to a new requirements gathering phase. The key, though, is that there is a sign-off and handover at the end of each phase, so once you arrive at system design there’s no going back to requirements gathering; and once you begin implementation there’s no going back to development, and so on.
The inherent rigidity of this methodology means that the end product is not what the user wanted – it is how IT interpreted the user’s requirements. To fix this common problem, a new way of developing products and services was invented. It’s called “Agile” development, and as the name suggests it’s all about agility – the ability to change direction easily and quickly. This is done by embedding the customer in the development process, and ensuring that frequent consultation with the customer is done for every small change and development. The method therefore emphasises collaboration: meetings are held daily, with product or service developers defining exactly what they did yesterday, what they are doing today, and what impediments – if any – they are running into. The Project Manager is technically the customer representative, and her job is to clear these impediments so that the developers can get on with their work. The business owner or user will also be in the meeting to ensure that each of those little bits of development are exactly what is needed – if not, a change is made on the spot. This method is most commonly used in software development, but can also be used in product development, marketing ideas and campaigns generation, or product engineering. By ensuring that intervention can be had at every stage, agile development avoids costly reworks later.
DevOps refines agile development by roping in all the teams in the product lifecycle, so that both Development and Operations are responsible for supporting the product development process, with the combined expertise, skills and experience helping to improve the product – rather than the old method of Operations “sitting on their hands” waiting for Development to complete the product and hand it over. With Operations involved in the lifecycle from the planning stage and giving their feedback and inputs throughout, the process is transparent to everyone involved, errors are identified and fixed early on, and most processes can thus be automated right away: common Operations methodologies like configuration management are built into the development lifecycle, and the small deployments and deliveries of changes mean that integration also becomes a continuous task. In IT, this means such tasks can be automated using various tools, so that any software code written can be tested immediately it is completed – and given that each development is a small step every day, this is easy to achieve.
DevOps is a complete change in the way systems development is done. It requires continuous collaboration and back-and-forth feedback between the Development and Operations teams, which in turn requires a complete culture change in the way organisations work and are structured. Whether it leads to better outcomes remains to be seen.
