– Jon Hoehne, Dovel Technologies
As application architectures and technology stacks continue to evolve to take advantage of cloud hosted environments, organizations now have the ability to increase the rate of feature delivery and fixes. But doing so requires more than just taking advantage of the flexibility of the cloud, it means a new approach to software and application development.
DevOps, a portmanteau of Development and Operations, is an organizational approach that seeks to greatly increase the rate of feature delivery in an application or suite of applications. This combination of development and operations means that there is strong communication between the development team (the people building the technology) and the operations team (the people who will use it). It is an engineering culture as much as it is a technical approach. It advocates automation and monitoring throughout the software development lifecycle pairing development teams with operations throughout the cycle for continuous feedback and improvement. This continuous loop makes DevOps closely tied to agile with its tenants of small increments, production ready code, and close coordination between development and test teams.
DevOps seeks to drive the work in progress down to even smaller, less complex/more manageable workloads without neglecting the needs of the Operations team. Where agile delivery reduced the stage gate barriers implied by waterfall, a successful DevOps implementation further reduces agile overhead, incorporating all stakeholders, providing a constant stream of value added updates.
As with any emerging approach, organizations must evaluate whether it is right for their teams as well as how it can be implemented given existing culture, infrastructure, and protocols.
DevOps in Government
Government adoption of DevOps has been slower than the commercial market adoption. One reason is the DevOps organizational approach does not correlate directly to the nature of government software applications. Government applications tend to be much more regulated in the transactions they process and the data they collect and preserve (e.g., streaming a hit TV show has a much lower cost of failure than the processing of large sets of genomics data or HIPAA safeguarded patient information). The overall mission value grows by increasing the value of applications/services provided, not by reaching more customers. Even though the fundamental missions may be different, delivering more features to the user quickly or reducing technical debt faster is still the goal of many IT organizations. To do this, the barriers to rapid delivery should be examined in the context of the IT organization.
One way to increase software releases without adopting a DevOps approach is to increase headcount on the development team. Government IT budget dynamics being what they are, this is rarely an option. If budget is available, building a larger development team or operations team can provide more overall capacity, but comes at the expense of increased cost and complexity. Additionally, creating larger separate teams fails to address organizational barriers. Development and operations teams are historically driven by different priorities (i.e., developers seek to implement change, while operations must manage the change). The incentives of each organization make sense separately, but as part of a larger IT mission can create friction.
With a combined DevOps team, the IT organization can seek to optimize its processes and investments. DevOps provides an IT organization with an established footprint and the option to get cloud-like flexibility with an internal Infrastructure as a Service (IaaS) style model. The DevOps culture allows the combined team to create virtuous cycles where infrastructure performance is improved and application/service features are added and enhanced.
Another advantage to a DevOps approach is the unique role of user support and help desks in government. Government IT organizations, unlike commercial service providers, are never very far from their end users. As the first line of contact for many users, a user support/service desk team with close ties to development and operations can be a valuable source of data for improvements to user experience and application performance. This data can be quickly triaged by a DevOps organization to determine if application improvements are needed or if environments need to be tuned.
Making the Switch
Transitioning to a DevOps culture is a gateway to rapid delivery, higher availability of services, and creating a team that is responsive to user needs and potential changing requirements. It should not be looked upon as the remedy for a development or operations team that struggles with the basic functions. It is a cultural approach that supports the idea of going from “good to great.”
At its core, DevOps is an organizational approach. To effectively switch, strong technical leadership is required across all three domains: development, operations, and service/help desk. Without deep expertise in all domains, it will be impossible to lead a culture change that delivers the value of DevOps.
A single, strong, technical leadership function operating across all three domains can focus on rapid delivery and user support with a DevOps culture by:
- Decoupling small, low risk features and fast tracking them through the agile delivery lifecycle
- Seeking to automate everything that can and should be automated (e.g., extending the continuous integration and delivery pipeline and environment monitoring)
- Moving to an Infrastructure as a Service (IaaS) posture for a privately hosted data center (e.g., seeking to implement containerization, and create resiliency in services)
- Making the product and service backlog visible to all stakeholders and enabling service/help desk teams to advocate for fixes and updates
The focus on these aspects are a starting point to increasing the pace of delivery and reducing operations overhead that will lead to overall lower cost and higher client user satisfaction.