The term “DevOps” is a contraction of “software development” and “IT operations.” This is a philosophy that gets new software up and running. The key feature of DevOps is a pipeline that times the delivery of elements – this is a little like the Bill of Materials scheduling used for factory production. Another notable factor in the DevOps philosophy is that is it very similar to the Agile development concept.
The DevOps system looks at the lifecycle of software from concept to operations and support. Unlike Agile and other development strategies, there is no set framework for DevOps. Also, there are no legal obligations or SLA standards involved in the methodology.
Lean thinking
The concept of lean thinking arises from the pursuit of cost optimization. The discipline arises from the practices pioneered in manufacturing by Toyota. The principal tries to eliminate waste and relies on the advice of shop floor workers rather than the intuition of management.
Lean thinking methods result in the elimination of management layers and the merger of shop floor assembly teams.
DevOps is the IT implementation of lean thinking. It pulls the management practices of IT departments away from the tendency to segment IT functions into separate responsibilities and departments. The IT skills deployed in operations are just as qualified to perform software and service development. Thus the development and operations teams can be merged, providing a skills pool that could be used for either requirement.
Coincidentally, the removal of departmental divisions also removes the need for two management structures. The expertise needed for development is enhanced by the system knowledge of the operations team. The ability of the Help Desk staff is also useful for reaping feedback from the user community during the installation phase.
DevOps goals
The key aim of DevOps is to improve profitability. That profitability comes from improved efficiency. Unifying teams removes management layers and saves staffing costs. Creating a talent pool that can be deployed in a range of roles also removes the possibility of having one set of specialists being under-occupied while other technicians with equal skills are overworked.
Creating a more efficient use of highly-paid technical staff saves money. Reducing the time each project takes lowers staff costs further and produces greater efficiency and improves profits.
An external consultancy will always need to start a project by getting to know the business and its existing practices; staff onsite performing day-to-day system management already have that knowledge. A team that works both on maintenance and innovation is better able to spot the root cause of current problems and propose system enhancements to resolve those shortfalls.
By removing the divisions between IT responsibilities, which are often referred to as “silos,” DevOps removes the need for agreements between departments. Thus, time is saved and time is money.
- DevOps aims to satisfy the following goals:
- Speed up deployment frequency
- Shorten requirement definition time
- Speed up system testing
- Reduce lead time between fixes
- Propose composite solutions that exploit existing resources
- Reduce mean time to recovery
- Build on existing working relationships
DevOps staff already know the user community and the users have experience in dealing with the team, thus reducing trepidation when communicating requirements. Cutting down suspicion of the development team by relying on established business relationships shortens project investigation times and reduces the likelihood of an unacceptable solution being proposed repeatedly until the analysts discover the true needs of the users.
DevOps vs ITIL
DevOps is the opposite of ITIL. In fact, many see the DevOps movement as a reaction against the ITIL framework. While ITIL segments IT functions into different roles, responsibilities, and departments, DevOps merges separate team specializations into one group.
With ITIL, the people who identify a requirement, those who define that requirement, those that manage a development project, those that introduce the new system, and those that run the software from day to day are separated out into different teams. DevOps sees the definition, creation, introduction, and operation of a piece of software as a continuum, like a production line.
The DevOps strategy argues that the tools needed to manage software and the knowledge needed to support the software users are all closely linked to the design and creation of the package. This argument arises from the typical problems faced by businesses that bring in a development consultancy to create and introduce new systems while the in-house staff gets on with managing existing systems. Once the new system is ready to use, the developers walk-off, collect their payment, and are never seen again. This leaves the employees of the IT department no idea about the intricacies of the new software.
Although it is expected that the development team will leave behind extensive documentation on the new system, those document libraries can often be too large for anyone to study meaningfully. Operations technicians are not given time to read through all of the documentation before they are put on the spot to answer questions about it as though they were experts. Similarly, training programs given during handover can be staged by a development consultancy to skim over any defects in the system and only present a limited number of usage cases. It is only once the product is in operation that its full capabilities get thoroughly tested and any weaknesses in its design get identified.
The structured path of ITIL relies on precisely drawn-up contracts with limits on the scope of the project. Problems in operations are not foreseen before that new piece of software exists. Getting a consultancy to come back and fix problems is almost impossible to achieve once they have been paid for the job. That results in bug fixing being defined as a new contract with extra payments.
The DevOps concept requires continuity between the development and operations processes. The team that is going to be responsible for supporting the new system needs to be involved in its development so that they can fully understand the service with which they will be expected to be expertly familiar when it goes live.
DevOps vs Agile development
There are many similarities between the Agile development framework and the DevOps concept. Both believe that there needs to be a strong link between development and operations and both realize that feedback from operations needs to be channeled back to the development team. In reality, the development of new systems doesn’t have a cut-off date – the development dribbles on into user complaints, revised requirements, and bug fixing. The development team needs to participate in those long-term revisions.
Every software developer knows that end users aren’t very good at defining requirements. They don’t know what they want until they are presented with something that they don’t like. No amount of training on the part of a systems analyst can overcome the problem of users not turning up to meetings because they are “too busy” or constantly answering the phone during interviews because they are “too important.”
There are two ways to approach the problem of ill-defined requirements. One is to give the users a deadline and tell them they have to pay for whatever is delivered, so if they don’t cooperate, they will just have to put up with what they are given. That is the approach of structured development strategies, such as ITIL. Independent development consultancies like that method because it clearly defines the scope of the project. They know that they will be able to make more money after the project is over by charging all over again to replace the parts of the delivered system that the users decide that they don’t like.
The other approach to coaxing a requirement out of users is to give them part of the system that looks like what they asked for. The users will complain very quickly about a new system and this leads the development team to a better understanding of what the users thought they asked for. Delivering a partial system heads off the tragedy of going all the way down the wrong path and only discovering that error when the finished product is presented to the user community.
Agile development uses the practice of a partial delivery to gather comments and complete the software requirement definition. This gives the development process a recursive shape. However, Agile development has an end date when the new system is signed off and handed over to operations. DevOps sees operations as a continuation of the development effort, so there is no end date.
In the DevOps strategy, the support technicians provide feedback into the development process; the development team provides monitoring tools and feedback messages within the software to guide support staff in day-to-day operations.
CI/CD
CI/CD (also known as CICD) is the closest DevOps has to a framework. CI stands for “Continuous Integration.” CD has two possible meanings: “continuous delivery” and “continuous deployment.” Continuous delivery involves preparing new software releases; continuous deployment involves flowing source code updates to production. That is, every little change goes live in continuous deployment, while a number of changes are collected for release in continuous delivery.
The continuous delivery method is more frequently encountered in software developed by an independent producer. Continuous deployment is more likely with in-house development.
Continuous integration is a method of managing software development projects that have a number of programmers working on each module. The CI strategy merges all development code at a number of points in the day. This doesn’t mean half-finished lines of code get merged into a central repository. Rather, a stage of development is bundled in with the output of other programmers.
The CI part of CI/CD is not an essential part of DevOps. It is important for Agile development. Continuous deployment is an important part of the DevOps process. This is particularly important in the in-house development model that uses continuous deployment. It accounts for the likelihood that operations will highlight the need for small adjustments to a piece of software that is ostensibly regarded as being completed.
Operations technicians are adept at spotting system problems before the users notice them. They are also the first point of contact for dissatisfied users. Thus, the operations team can quickly feed requests for adjustments to new software and bug fixes to the development team and clearly define requirements. As trained IT professionals, operations staff are better able to define technical requirements than the user community.
The continuous deployment strategy solves the communication problem between analysts and users. The developers supply what the users asked for but don’t walk away. The operations team is involved in acceptance testing and then monitors the performance of the code. Once the software is operational, technicians suggest improvements for the developers to implement. The operations team also translates user complaints into technical specifications. The new piece of software is not considered to be completed until the new system has run and the number of support calls it creates has died down to a minimum, meaning that the new system is stable.
Another advantage of the DevOps approach is that the production or purchase of appropriate monitoring tools to manage the new system can also be considered as part of the development process. In some cases, tools can be used for monitoring a project and for continued monitoring. For example, the project library will be built up during the development phase. This can be structured in a way that makes it a useful guide and reference source for system managers and support staff.
DevOps suitability
The DevOps strategy is easier to implement where both the development team and the system management team are managed in-house. The entire development team does not need to be made up of employees – it is common to supplement the development team with specialists on short-term contracts.
DevOps can also be applied by software producers who integrate their product support staff into the development process. This enables the Help Desk technicians to have a better chance of understanding the software on which they have to advise customers. The use of DevOps in a software house is also useful for identifying security exploits that arise once the product is in use in the real world. The development team can quickly create patches and updates to problems identified by the front-of-house support staff.
Businesses that outsource their operations and support functions to MSPs will find it difficult to implement a DevOps approach. Outsourcing is more suited to the ITIL formula of separating out IT functions.
The Agile development model is more frequently applied where the developers are supplied and managed by a consultancy or software house but the project is tailored to one client. Bespoke development is becoming increasingly rare in business environments, thanks to the development of off-the-shelf solutions, such as ERP systems.
The field of web development is a more likely source of work for Agile development teams. The structure of a website means that the consultancy can put up a home page very quickly and then add on pages as soon as they are developed. In the DevOps model, a new page on a site should be managed by the client’s own operations team. This scenario places the in-house technicians in the role of providing feedback for software refinement.
ArchOps
The lean thinking drive behind DevOps can be applied to other aspects of IT services. Infrastructure also needs to be defined, put in place, and then managed. So, the initial design of an office system or the expansion of an existing system needs to be defined, provisioned, and installed. The operations team can manage and staff that process along with optional extra consultants added to the team but under departmental management.
As with DevOps, there are no specific standards or closed-loop platforms for ArchOps. However, the same management and technicians can be used for software development, hardware configuration, and system installation that also perform ongoing monitoring and management of the implemented system.
The merger of hardware and software expertise has obvious benefits. The overall infrastructure design requires both elements. Knowledge of software solutions can cut the cost of hardware and vice versa. As with Agile development, when the system is finally all in place, ongoing monitoring and user feedback can be used to identify necessary adjustments that will bring the new system in line with user expectations.
DataOps
The field of data management is a cutting-edge source of profit for IT systems that is still not fully exploited. The lean thinking management strategy of letting those operators on the shop floor suggest improvements can also be applied to the use of the data that the business manages every day and often ignores.
An example of this field is the use of sales data for marketing analysis or the use of transaction data to identify bottlenecks in the business’s processes or points in the buyer’s journey where customers commonly pull out.
Operators of the IT system are more familiar with the types of data that the system handles and how it is stored. Once again, merging operators with analysts gives the DevOps team a head start on any external development or data analysis consultancies because the in-house staff doesn’t need to waste time investigating the business’s operations.
DevOps toolchains
As DevOps has no specific framework, there aren’t any platforms that cater to the entire continuum from development to operations. However, there are tools that support each aspect of DevOps, and managers of the strategy tend to assemble a collection of support software to assist their efforts.
The collection of tools used in DevOps is commonly known as a “toolchain.” Each DevOps department works out which combination of tools best supports efficiency drives in the development and operations continuum. For more information on toolchain components, take a look at The 8 Best DevOps Automation tools.
DevOps staff
The DevOps concept offers better prospects for IT professionals than the segmented strategy of ITIL. The separation of development and operations creates two tribes of IT professionals.
In this divided scenario, development specialists are valued for their ability to understand and manage new and innovative technology. These specialists tend to work for consultancies or software houses, moving from client to client, introducing change with each commission. Thus, development consultants are always up-to-the-minute with technology but they never get to understand the mindset of any company’s workforce.
The transitory nature of development consultancy work means that consultants are seen as outsiders by the staff of the businesses that they are deployed to improve. This image breeds resentment from the operations staff of the client company and mistrust from the users that the consultants need to interview. These attitudes raise barriers to cooperation and increase the time it takes to implement change.
Operations staff gain their value through experience with the system of one company. So, these IT professionals are more anchored but they don’t get to work with new technology. They are committed to working with one system as it ages and they actually gain an appreciation for their ability to work with outdated systems, finding workarounds to make up for the old system’s shortcoming.
Lack of experience with cutting-edge technology makes the skills of operations staff less valued in the employment market. Thus, an IT professional working in development and management consultancies can command higher wages than operations staff.
Using the DevOps model gives in-house operations staff more contact with new technology. A DevOps technician is going to get more variety of tasks, being able to participate in high-value projects, such as requirements analysis and software evaluations. The DevOps strategy provides better opportunities for operators and more stability for developers. A DevOps technician gains experience and contacts within the business while also keeping up with new innovations in the industry.
Choosing a management strategy
Many IT managers don’t have any choice over whether to go with the segmented strategy of ITIL or the unified approach of DevOps. The requirements for the use of ITIL may already have been settled by the executives of the business. However, there are many DevOps departments out there. So, if you want to switch from the ITIL model to a DevOps environment, you should find plenty of opportunities in the job market.
