Skip to main content

The DevOps Business Analyst Conundrum

Written by Raji Pillay on . Posted in Articles.

Them: What do you do?

Me: I am a Business Analyst with DevOps

Them: Huh?

Them: How does that work? Who are your stakeholders? What exactly do you do?

 

This is a typical conversation I end up having every time I mention my role.

Let me start by answering a few questions that I have been posed with over my term as a “Business Analyst in DevOps”.

What is the role of DevOps in Delivery?

DevOps is anything but a buzzword. The term has picked up a lot of attention in technology and for the right reasons.

DevOps bridges the gap between teams that have worked in silos in the SDLC. Continuous Integration and Continuous Delivery enhances Agile delivery model. This allows delivery to ship code in smaller chunks continuously. It accelerates the shipment of code to production.

Some examples that I have worked with in DevOps:

  • Architecture changes/upgrades as part of delivery (eg: upgrading your out of support SMTP server)
  • Implementation of new tools to aid in delivery (eg: monitoring tools like Splunk, appdynamics, use of jenkins)
  • Supporting the non-prod environment
  • Designing deployment pipelines
  • Integrating early testing in the pipeline
  • Delivering robust features

And most importantly cultivating the DevOps mindset across delivery and operations!

Yes, tools are important to achieve the end goal, but we cannot progress without an inherent cultural shift.

Who are the stakeholders for a BA in DevOps and What does a Business Analyst need to consider?

Higher management, delivery team, testing team, operations, and your own self: they are all your stakeholders. The idea or requirement to improve the development, delivery, testing or operation of the application can come from anyone.

The essential core role of a Business Analyst doesn’t change with projects or genre of requirements. The same applies to a Business Analyst in DevOps. The below examples will shed light on projects that BA’s have to work with where the DevOps tools and mindset is required.

a) One-click deployment: This requirement came out of the extensively manual deployments we had to perform as a team. This meant constant monitoring and having someone manually go from one step to the other. Like any other process, the less the manual intervention the less the chances of human mistakes.

Stakeholders:

  • Operations team (Actual Deployment team)
  • DevOps Team (Creating the one-click pipeline0
  • Delivery team (to provide inputs)
  • Senior Management

Things to consider as a Business Analyst:

  • Understand the issues in current state that the operations team are facing.
  • The ripple effects and the issues this creates for the releases.
  • The advantage delivery team will have going forward.
  • How can this be built to add automated testing and blue/green deployment as an iterative approach?
  • What tools will be required to deliver
Advertisement

b) Migration to cloud: With the sweep of infrastructure migration to cloud, this is a prevalent project in many organizations. Rightly so! The migration can be small-scale lift and shift with only the APIs or queue endpoints in the cloud, or it can be a large-scale migration.

Stakeholders:

  • Management (the directive and timelines come from them)
  • Solution Architects ( The solution and design will come from this group)
  • Project Managers
  • Performance Team
  • Functional Testing
  • Security Team
  • Database Administrators
  • DevOps
  • Delivery
  • Operations
  • Third Party Vendors if any

Things to consider as a Business Analyst:

  • Work with the solution designers and business to understand the use cases
  • Start creating epics to manage scope and prioritize
  • Break down the high-level design or epic into smaller chunks of work with the delivery teams
  • Incorporate security and Non-Functional Requirements as part of the use cases being delivered
  • Work on data migration strategy
  • Work with Testing teams to create functional and regression testing plan
  • Engage relevant stakeholders to work out operational readiness, DR strategy, and final cut-over strategy

c) Business Requirement (feature/functional driven work): Delivery of a business functional requirement. This piece of work involves as much a DevOps mindset as the above-mentioned work. In the delivery of features, we need to consider the BAU support required for the non-prod environments, the work involving the deployment of the code, the delivery of non-functional requirements. All this done with the “I am not working in silo” mindset makes it as much DevOps as any other work.

This is a snapshot of the things that a Business Analyst needs to consider. It is not an exhaustive list.

What skills does a BA need to be a part of DevOps?

A Business Analyst needs all the tools from his/her toolkit and experience gained over the past to navigate the DevOps world. However the most important is the mindset for continuous delivery, integration, continuous deployment and a keen understanding and importance for the non-functional requirements.

Whether it is in a titled “DevOps” team or a feature delivery team, this mindset will ensure we consider “Reliability” “Performance” “Security” and “Stability” as a feature instead of nice-to-haves.

The role of a BA is then to help deliver world-class platforms, as always.

The core of being a Business Analyst doesn’t change weather we work with a traditional waterfall methodology, an Agile framework or an Agile DevOps framework. In fact, a DevOps mindset is required in any of the frameworks that we work with. It is essentially considering NFRs as a feature and delivering them continuously in collaboration and continuously along with the functional business requirements.

I hope this helps answer the Business Analyst in DevOps conundrum.

Views: 536