DevOps is an area of focus for everyone these days. It is expected to be a solution to many problems ranging from IT responsiveness to customer satisfaction. However, one common expectation from DevOps is to reduce the Time-to-Market or increase the Speed at which organizations can change/adapt/deliver new features to their customers. This capability can be defined as “Agility” or “Business Agility” required for a business to meet its goals.
Unfortunately, most of the enterprises that attempt to adopt DevOps are unable to realize tangible business benefits from its adoption. This stems from an assumption that DevOps is primarily about implementing a DevOps toolchain with an eye on increasing automation levels spanning the development and operations lifecycle. However, DevOps is much more than automation and tool-based interventions. Its adoption requires organizational change affecting several dimensions, of which tool usage is just one.
If you aim to avoid wasted investments through half-hearted attempts at DevOps implementation replete with multiple duplicating toolsets, here are 3 top recommendations to make your DevOps implementation a true business success.
# 1 Define and Articulate What Constitutes DevOps Success
It is critical for management to define in business terms what benefit is expected from DevOps adoption. This is the most important prerequisite for DevOps success. For example, a retail bank can have a goal of increasing mobile transactions to 70% in 2 years, an airline can expect the ability to launch digital ancillary within 4 weeks, a health insurance provider can aim for the ability to launch a new micro insurance product within 2 months, or an e-commerce firm’s goal could be to add a new supplier within 5 days on their SaaS platform. Once we have such a goal defined, it needs to be visualized and explained to various teams as to why this is important for the business. Creating such a shared goal across various teams (whether traditional or cross-functional) goes a long way in laying the foundation of a DevOps success story.
# 2 Leverage DevOps Success Criteria to Drive Downstream Goals
Once the overall business agility objective is defined, it can be used to drive downstream agility objectives at the platform, process, or team level. Taking an example of the objective of “Being Able to add a supplier within 5 days”, we can define downstream objectives as:
Platform Level: Being able to have plug-and-play integrations with suppliers so that we can add or remove suppliers without having an impact on other integrations. This capability has implications on the architecture of the integration solution, technology choice, and infrastructure on which it is deployed and subsequently monitored.
Process Level: Being able to have feature-based releases where change to a specific supplier integration or its addition/deletion can be released independent of others.
Team Level: Enable the development teams that are carrying out actual code changes and delivering integrations that are production ready. This requires Developers to take full ownership of the code they deliver right into Production.
In reality, what most organizations adopting DevOps do is simply identify areas where automation is lacking. Mostly, this happens to be in various forms of functional & non-functional testing, environment provisioning, deployment, and release management and organizations straightaway start adopting toolsets that address these gaps. On the process side, they implement various forms of Agile processes and start delivering iteratively. This bottom-up approach may or may not meet the business objective defined initially, or worse, it may end up being an overkill.
# 3 Establish a Clear Roadmap Spanning Process, People, Automation, Infrastructure, and Architecture
What is really required is to not rush into various tool implementations. A DevOps success always needs holistic change across the dimensions of Process, People, Automation (or Tools), Infrastructure, and Architecture. The extent of change required across these will be determined by what are your end objectives. For example, changes required to enable a release cycle of 3 days will be very different from those for a release cycle of 4 hours.
Dimension
Examples
Difficulty/Resistance to Change
Process
Kanban adoption Feature based releases Limit work in progress Easy if organization has already embraced agile. If not, then things can be challenging due to cultural elements mentioned below
People/Culture
Remove silos of Dev/Test/Operations Teams have ownership of delivering code to Production and managing it Organize by products instead of projects Cloud (lift-and-shift) Extremely difficult and may need training, reskilling, and even changes in people and structure of organization
Automation (Tools)
Full lifecycle automation with Application Lifecycle Management integration Continuous integration, testing, deployment and monitoring Easy as compared to other dimensions and primarily requires investments in tools and effort
Infrastructure
Self-service infrastructure Infrastructure-as-a-code Cloud (lift-and-shift) Easy as compared to other dimensions
Architecture
Loosely coupled and discoverable components Microservices Cloud Native and serverless Difficult as it may need huge investments in re-engineering of monolithic architectures
Organizations should identify gaps across all these five dimensions and prioritize them based on business need, investment requirement, and appetite and then move ahead with adoption. During the journey, continuous inspection and adaptation of the roadmap is required depending upon what is working and what is not.
Anti-Patterns to watch out for
Starting on the DevOps journey without having a business-linked success criterion Consider DevOps as being limited to implementation of tools and rushing into their implementation Ignoring the people aspects in terms of skills and aspirations. This is one of the most difficult dimensions to address. Ignoring the architectural limitations of the application(s) in scope. If the architecture is monolithic, then tools, process, and automation can only get you so far. Attempting a big bang approach. DevOps is a journey and not a project.
