Failure of IT projects has cost many people their jobs, not to mention lost weekend days spent working. Handoffs between different functional groups within IT sometimes (often?) results in finger pointing and a round of laying blame for problems.
New methodologies for development are nothing new. Developers and IT operations teams have long tried to work together but are often stymied by organizations’ barriers and differences in perspective. Recent years have seen a proliferation of development and deployment philosophies that seek to break down those barriers. Concepts such as lean development or Agile are some. DevOps is another. Ultimately, faster delivery of new applications and new functions to business units is the goal.
Just looking at the name DevOps gives you a sense of the thinking—DEVelopment and OPerations. Putting together people from the two different parts of IT should speed delivery and increase quality.
DevOps to Speed Deployment
DevOps practitioners typically break projects into sets of steps or tools referred to as toolchains. In the most basic descriptions, the toolchain starts with coding and building, moves to testing and packaging, and then ends with release and monitoring ongoing usage. Designing and managing projects that take all of these steps into account during the process minimizes the problems of handoffs between functional areas. Those functional areas should be working together from the start to deliver better quality code that interoperates with existing applications and infrastructure.
Focus
Good DevOps practices do produce better code and faster deployment. IT departments sometimes lose sight of a prior step: Why is the project being done in the first place?
At the beginning of projects, a good definition of the business problem and needed solution anchor any project. DevOps teams run with that definition. Common sense says development and IT operations teams need to continually refer back to the end user needs. Many times, the original definition of the solution worked out with the business users changes based on the development. Strategies like agile development try to involve the end users to make the needed changes quickly.
A disconnect frequently happens to DevOps-focused teams that—not purposefully or maliciously—leads to problems. Too often, DevOps teams follow the initial problem definition and solution description without checking back in with the business users. Minimizing communications, meetings, and changes means the project takes less time, which is good. Too much scope and design change during the project cause delays and failures.
Unfortunately, delivering unusable or ill-suited functionality is not good either. Even if a project happens on time and meets the quality indicators initially laid out, the end result can be failure.
This happens when the DevOps team is laser focused on delivering stable code that interoperates with existing systems in the shortest amount of time. Without consideration of the true business needs, the DevOps team can fail while succeeding.
History
Few developers or IT operations people start in the business functions of organizations. In my past experience, there used to be more. Maybe my perspective is wrong, but with the complexity of technology increasing over time, specialist developers and IT personnel have decreasing experience in business functions.
Not having a business-focused resource inside the technical DevOps team leads to problems.
Add a Business Tool to the DevOps Team
Some DevOps teams bring the business users in during the testing phase. It needs to be done earlier.
Amongst all the talk of having different parts of the development and IT teams working together, the business users must be brought in early to the toolchain of DevOps. During coding and building, business users need direct involvement. This will slow down projects from the nice, neat project plan agreed on in the beginning. The end result, however, is a much better deliverable product.
Involving business resources also relieves the DevOps team from some liability. With continual business-side involvement, business executives will have a much harder time blaming IT for project failures. This isn’t just a cynical reason—this is reality.
And, if a culture of working together between DevOps teams and business users is created, it might lead to more funding and more cool projects for the IT department.