DISCUSSION PAPER
THE ROLE OF THE BUSINESS ANALYST
IN A DEVOPS ENVIRONMENT
Contents
The Dev Challenge 3
The Problem 3
The Birth of the Business Analyst 3
The BA Challenge 3
Industry Perception 3
The advent of DevOps 4
DevOps Culture 4
Agile and the DevOps toolchain 4
The Business Analyst in the DevOps environment 5
What can the BA oer? 5
Service to the business stakeholders 5
Service to the DevOps toolchain 6
• ‘Planning’ stage 6
• ‘Create’ and ‘Verify’ stage 6
• ‘Monitoring’ stage 6
Is the Business Analyst always needed? 7
Embracing the new culture 7
The Dev Challenge
The Problem
In the 1970’s technology was cheap enough to allow businesses to invest more in IT solutions.
The common way of working in this fledgling environment was for the software engineers
and the business to collaborate directly to define and craft the solutions.
A common problem that projects experienced was with the quality and accuracy of the
product being developed. The requirements that were discussed between the engineers
and the business were often misinterpreted leading to costly re-writes, negative impacts to
budget and project schedule and a product that did not realise all the original benefits.
The Birth of the Business Analyst
A solution to this problem was to create a role that bridged the gap between the business
and the technical teams. An eective Business Analyst (BA) was able to understand the scope
of the project, build solid relationships with the project stakeholders to eectively elicit the
requirements, model the current and target processes and communicate the business and
system needs. This all needs to be done in a language that the business can understand and
that the technical teams can use to develop.
This set of skills fed into methodologies that allowed the project to help monitor the progress
and success of the project by allowing it to track its completion within the allotted timeframe
and budget. It also mitigated the risk of expensive rework by providing a distinct period of
time to fully elaborate the full breadth of work that addressed the project scope.
The BA Challenge
Industry Perception
As the role became more established so did common methodologies for delivery. To this
day models such as Waterfall and the Unified Process have become standard ways of
delivering a project and fit well with hierarchical command and control frameworks that IT
departments and organisations often work in. The analyst is given a distinct period to define
their requirements, during which time they deploy a myriad of skills to allow for the accurate
definition of the requirements and assessment of the most suitable solution. They present
the options, give the pros and cons of each and define the requirements in a way that allows
the business to have confidence that what’s been documented defines their needs and allows
the project to move to the next distinct phases, namely solution design and implementation.
Even though Business Analysts have firmly demonstrated their value to the IT profession
the focus on defining the requirements up-front may have caused the role to be type-cast.
Other disciplines may see the analyst as a ‘non-technical’ role that works with the business
stakeholders in a silo or one that works well with the business but less well with the many
technical parties in the project. In addition, because a Waterfall project often requires a period
of many months to fully document the requirements the analyst may also be seen as a role
that works slowly and focuses on writing long, exhaustive documents to define the solution.
Even worse is the risk that some analysts themselves may perceive their job beginning and
ending with the definition and sign-o of the requirements.
The advent of DevOps
DevOps Culture
DevOps has been adopted by many organisations as a way to break down the silos that are
naturally caused by the distinct phases of a more linear, sequential approach. It encourages
close collaboration and transparency between the whole project team by developing a
shared culture of change. This helps the organisation, who naturally gravitates to the side
of stability, understand and adopt rapid, continual change and also helps the technical
members understand the importance of helping to embed and support the changes that
they are developing. Empowerment of the team is key to this culture with the hierarchical
command and control project structure is replaced with self-organisation of the team.
Agile and the DevOps toolchain
A DevOps team will often use Agile techniques to develop a product in short iterations. The
emphasis is put on performing quick periods of analysis followed by a fast development
cycle. This allows working software to be provided to the business leading to faster time-to-
market and enables the end-users to feed into an eective feedback loop be established to
help feed into further requirements.
In the DevOps world, each stage of the Agile lifecycle is supported by a series of technical
tools to allow for the eective planning, development (Create), testing (Verify), deployment,
configuration and monitoring of the product. This toolchain helps the team have predictability
when working in this fast-moving iterative way.
To allow this to take place the role of a developer has had to evolve. To support both the
development and deployment of code the DevOps developer needs to be able to understand
how to deploy and maintain this toolchain. In addition, they are able to work eectively with
the business to interpret the business requirement and accurately develop the most relevant
solution.with agile projects.
PLAN
CREATE
VERIFY
PACKAGERELEASE
CONFIG
-URE
MONITOR
The Business Analyst in the DevOps environment
What can the BA oer?
With the focus being on bringing the technical teams closer to the operational and business
processes and with an antiquated perception of the Business Analyst to address the analyst
may question where they fit in in this evolving world. One way of seeking to understand their
place is to look again at the reasons that the Business Analyst role was created in the first
place.
Service to the business stakeholders
Agile methodologies put more emphasis on a single business stakeholder to act as the
ultimate owner of the product. The Product Owner’s role is one of executive decision maker
of what requirements are developed and makes the business directly accountable for the
success (and failure) of the product. They are expected to accurately define and prioritise
each User Story so that the product is built in a way that allows the highest value items to be
produced first whilst crafting an eective Minimum Viable Product to allow for test and learn.
This may be a daunting prospect for the most adaptable of people; however, if partnered
with a Business Analyst the PO has the ideal person who can help them navigate this new
landscape.
Service to the DevOps toolchain
The Business Analyst can use their skills to help support key processes maintained by the
DevOps toolchain. By examining key stages it is clear what kind of support the analyst can
provide:
• ‘Planning’ stage: Managing multiple stakeholders and eliciting the concise definition
of need should be a core skill of any analyst. Typically they will have an excellent
understanding of the entire scope of work to be delivered via the requirements. This
experience will help them to maintain a holistic view of what has been developed,
what still needs to be delivered and the dependencies and risks associated with each
requirement at any point in time . If they achieve this they can eectively question the
value of each requirement and can therefore help to ensure that the highest value stories
are delivered iteratively.
• ‘Create’ and ‘Verify’ stage: The key to developing in parallel the correct features
and supporting tests is in the unambiguous definition of the requirements and the
supporting central artefacts. With their experience in eliciting and documenting quality
requirements, the business analyst can play a very eective role in the process. They can
work alongside the PO, the developers and the testers to create and split as needed the
requirements and define unambiguous acceptance criteria if needed using techniques
such as Behaviour Driven Development (BDD).
The analyst can also expedite the essential process of ensuring the stories are fully
tested and accepted within a Sprint by reviewing the developed requirements against
the acceptance criteria prior to being passed to the Product Owner. This can lead to a
quicker turnaround to ensure any remediation work is done against the Story in order to
be accurately delivered and marked as ‘Done’.
• ‘Monitoring’ stage: It is essential that feedback is continuously gathered as new features
are introduced and the analyst can use their experience of doing this to elicit this
information in the 2 main ways. They can use elicitation techniques to most eectively
collate feedback directly from the users and can eectively analyse production metrics
to understand how the users are using the system. This can then be channeled into
subsequent planning stages to help the Product Owner’s decision-making, showing
which features are popular and should be developed further and which are not.
Service to the project team
The analyst like no other member of the team is most comfortable playing out-of-position in
order to contribute where needed to the success of the end product. Because the analyst seeks
to maintain the understanding of the bigger picture it is a current occurrence for Business
Analysts to spend periods of their career performing analysis work which is not categorised
as ‘pure’ business analysis. Many analysts will have occupied roles such as system analyst,
data analyst or taken on responsibility for areas such as modelling and UI & UX design. This
experience provides the analyst with the ability to temporarily fill crucial roles that may
emerge during the lifetime of the project to allow the team to continue to deliver eectively
and maintain the same level of productivity. For instance, if a project requires an emphasis
on data modelling, extraction process, profiling and cleansing the analyst can move into this
void to coordinate and support the team’s goals.
As previously mentioned, because the analyst has a solid understanding of the requirements
and the features currently in development they are able to move into other occupied roles in
the team as needed.
For instance, because they have a relationship with the Stakeholders who contributed to
the requirements they can eectively fill a role of Scrum Master because they know who
to liaise with to unblock issues. Because of their knowledge of the requirements and the
business stakeholder’s ongoing vision they can act as a proxy for the business (at risk) to
make informed decisions when they are unavailable. Their understanding of how low-level
requirements contribute to the bigger picture means that they can help suggest and define
any further in-depth testing that is needed prior to the release of critical features.
Is the Business Analyst always needed?
The short answer is probably not. For example, a DevOps team can be used to support Lean
Start-Ups where requirements are quickly written and developed to facilitate an environment
of continual experimentation using customer feedback to test-and-learn. In this environment
failing-fast is a positive outcome and the analyst may not be required to contribute to the
project’s success.
In addition, some projects may be of small enough size that it is clear what the vision and
outcomes should be. Others may have a Product Owner who is proficient or experienced
enough to be able to manage their own product backlog and elaborate their own requirements
to the right quality and detail.
In general, a named Business Analyst may not be required in less complex projects , but the
business analysis processes are still relevant. The more complicated a project is, e.g. with
complex database infrastructure, multiple suppliers, dispersed project teams or with limited
business stakeholder availability, the more Business Analysts may be of value to a team.
Embracing the new culture
It is worth noting that most organisations with a heavy digital focus, for example, will
have established continuous build, test, deployment and monitoring practices even before
the advent of the term ‘DevOps’. A lot of these companies, especially with complex needs
routinely use Business Analysts as key members of the project team and these analysts will
have already embraced the DevOps culture and Agile ways of working.
For the rest of the Business Analyst discipline to be truly relevant in the evolving IT landscape,
the analyst community must take responsibility for proving the value that the Business
Analyst can bring. They must be prepared to leave behind the silos that act as a comfort
blanket and embrace a culture of collaboration and transparency.
Wordy documents can be replaced with highly visual ways of communicating the desired
requirements and potential solutions which reinforce collaboration and shared understanding.
Above all, they must be prepared to be flexible in their approach when supporting the evolving
Product Backlog and must only maintain artefacts that provide clarity and accuracy for the
development and operational teams.
Due to the need for the analyst to integrate much closer with the technical teams they will need
to be prepared to be open to learning new common languages and ways of communicating
eectively with technical parties. One of the most rewarding areas of transitioning to the
DevOps/Agile world is being able to draw on their creativity to help discuss problems, craft
solutions and take a front seat when collaborating in such areas as wireframing and process
modelling more ecient processes, all done in a matter of hours, not months. This closer
collaboration can turn a good business analyst contributing what’s needed to the project into
an excellent business analyst contributing tangible value directly to the success and quality
of the end product.
BCS The Chartered Institute for IT
First Floor Block D, North Star House, North Star Avenue, Swindon, SN2 1FA United Kingdom
T +44 (0) 1793 417 417 | www.bcs.org
© BCS, The Chartered Institute for IT is the business name of The British Computer Society (Registered charity no. 292786) 2016
International Institute of Business Analysis
701 Rossland Road East, Suite 356 Whitby, ON L1N 9K3 Canada
www.iiba.org
IIBA® and the IIBA logo are trademarks owned by International Institute of Business Analysis. This trademark is used with express permission of International Institute of Business Analysis.
If you require this document in accessible format please call +44 (0) 1793 417 600
(TM) (IIBA(R))
About the authors:
Alex Cottrell has spent his career working in the fields of business analysis and
business change and has a genuine passion for Agile delivery methods. He has
successfully delivered projects using Agile methodologies for high profile companies
over multiple industries including insurance, media, telecoms, government
agencies and finance and is a true believer in the value that the evolving Business
Analyst can bring in this area.
Przemyslaw (James) Ciesluk is an accomplished Senior Business Analyst with
over 15 years of experience in Business Analysis and software development.
James started his career as a software designer working for consumer electronics
companies and quickly moving into the field of Business Analysis. In his time as a
Business Analyst James has worked in a number of business sectors including
airlines industry, public services sector and Financial Services sector.
Zurich’s Digital Innovation Journey
Zurich’s BA team is a highly engaged community with a passion for combining new
ideas and ways of working with tried and trusted analysis techniques. Zurich has
an increasing focus on innovation in areas such as the digital space and the use of
technology to benefit its customers, so it’s essential that its BAs are also able to
adapt to new ways of working. At Zurich, our IT professionals are empowered to try
new things and we believe that “agile” is a mindset, not just a methodology.
