CIO Insider

CIOInsider India Magazine

Separator

Leveraging DevOps For Business Benefit

Separator
Puneet Sachdev, Corporate Vice President, WNS Global Services

Puneet Sachdev is technology business partner for travel, shipping and logistics, utilities, DMRT domains and CIS.

DevOps is an area of focus for everyone these days. DevOps 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 Time to Market or increase Speed at which organizations can change/adapt/deliver new features to their customers. This capability can be defined as “Agility” or “Business Agility” that is required for a business to meet its goals. However, most who attempt to adopt DevOps are unable to realize tangible business benefits or “Agility” from its adoption.

As agility needs of every business will be different, so will be its DevOps adoption. However, many organizations ignore this fact and jump into DevOps with the assumption that it involves primarily tool implementations with the objective of increasing levels of automation across the development and operations lifecycle. There are many tool vendors out there with competing offerings for the DevOps toolchain. DevOps, however, is much more than tools and automation. Its adoption requires organizational change across multiple dimensions, of which tool usage is just one of them. Ignoring the others will result in a lot of wasted investments and a landscape being saddled with multiple duplicate toolsets, half-hearted implementations and blame game. Following are some of the recommendations on how to make the DevOps implementation a success for the business.

Recommendation 1: Always define a success criterion for DevOps in business agility terms
Explicitly define what benefit we want from DevOps in business terms and make it measurable. We may be starting DevOps journey small, but defining what benefit to expect in business terms from its adoption will go a long way in ensuring its success and expansion. Some examples of such criterion as per my experience are as follows:

Once we have such a goal defined, it needs to be visualized, 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 foundations of a DevOps success story.

Recommendation 2: Translate the DevOps success criterion into downstream objectives
Once the overall business agility objective is defined, it can then 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-n-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 do 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 who are doing the actual code changes, deliver integrations that are production ready. This requires developers to take full ownership of the code they deliver right up into production.

A DevOps success (meeting of business agility objectives) always needs change across the dimensions of process, people, automation (or tools), infrastructure and architecture


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 and non-functional testing, environment provisioning, deployment, release management and straightaway start adopting tool sets which 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.

Recommendation 3: Create a roadmap across the dimensions of Process, Automation, Infrastructure, Architecture and People to really succeed with DevOps
What is really required is to not rush into various tool implementations, as tools are only one dimension. A DevOps success (meeting of business agility objectives) always needs 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 your end objectives are. For example, changes required to enable a release cycle of 3 days will be very different from say, a release cycle of 4 hours.

Organizations should identify gaps across all these five dimensions and prioritize them based on the business need, investment requirement and appetite and then move ahead with the adoption. During the journey, continuous inspection and adaptation of the roadmap is required, depending upon what is working and what isn't.

Anti-Patterns To Watch Out For
• Starting on DevOps journey without 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

Current Issue
VKRAFT Software Services: Pioneering Innovation In Integration & Beyond