Business Analysis Overview

Business analysis is a discipline focused on identifying and describing solutions that address the needs of an enterprise. As mentioned in the previous chapter, there is no fixed rule defining how detailed a solution description should be. However, the boundary is typically established by the technical design, which falls under the scope of systems analysis rather than business analysis.

The entire discipline is standardized by the International Institute of Business Analysis (IIBA) through the BABOK Guide BABOK (Business Analysis Body of Knowledge). The official BABOK definition of BA is:

"Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change and to design and describe solutions that can deliver value.

Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. It can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future state."

Based on the BABOK description, the core of business analysis lies in identifying business needs and determining their solutions. A need is any problem an organization must or wants to solve, or an opportunity that would be beneficial to seize. Addressing these needs is done through solutions, which represent specific ways of solving problems or enabling the organization to take advantage of an opportunity. A solution can be a single change, such as a new IT system, or it can be composed of multiple components, including people, infrastructure, hardware, software, equipment, facilities, and process assets, or any combination of these. Although introducing a new system or modifying a legacy one is part of most solutions, the solution space is much broader; focusing solely on systems carries the risk of developing an incomplete solution.

The person who performs business analysis activities is called a business analyst. A business analyst plays a key role in discovering the goals an organization wants to achieve, as identifying what truly needs to be changed is not always an easy task. Stakeholders often state what solution they want, and it is the business analyst's responsibility to elicit the actual needs behind those desires. Furthermore, because information is often gathered from many people, the analyst must synthesize data from multiple sources. Since different groups may have varying opinions on what is needed or how to achieve it, business analysts often play a central role in aligning the needs of different business units, facilitating communication, and serving as a "translator" between these groups.

Sometimes, business analysts are referred to as requirements engineers. Even though requirements analysis and management are essential components of business analysis, simply eliciting requirements is not enough. True business analysts are strategic: they ask why a change is needed, not just what the requirements are. To help you understand the actual responsibilities of a business analyst, we provide the following list of activities as defined in BABOK:

According to BABOK, a business analyst is responsible for

understanding enterprise problems and goals
analyzing needs and solutions,
devising strategies,
driving change, and
facilitating stakeholder collaboration.

"If the business analysts are in IT with the purpose of writing requirements, it's a missed opportunity."

– @RogerBurlton

Business analysts are typically among the first to be presented with an identified business need and tasked with analyzing it to propose potential solutions. To achieve this, it is often necessary to gather information from various stakeholders (both internal and external), challenge their perspectives through organized meetings and workshops, and outline possible solutions.

EXAMPLE

The Board of Directors at Effecta Bank has decided that the primary strategy for the upcoming year is to streamline the bank's product portfolio. The first step is to merge the Current Account (the account where a client's salary is deposited) with the Overdraft facility (a product that allows clients to withdraw more money than they have in their account). This means that when opening a current account, the client will automatically gain access to an overdraft without having to apply for it as a separate product.

This is a large-scale project that impacts nearly all departments within the bank. It involves redesigning the account opening process at branch offices and across all digital channels, updating contract templates, altering internal methodologies, and modifying numerous reports to reflect the new regulations. All these changes will have a direct impact on IT infrastructure; specifically, the front-office systems, internet and mobile banking platforms, and reporting systems will require modifications. Additionally, a new marketing campaign and employee training programs must be developed. While the business analyst does not execute every task, they are responsible for recommending the overall solution, identifying its components and necessary activities, and driving the initiative forward to ensure its success.

From the example above, it is clear that a business analyst's daily work is no walk in the park. A business analyst must have a solid understanding of the organization's business domain, both from a business perspective (products, processes, and operations) and an IT perspective (systems, applications, architecture, and processes). On the one hand, a business analyst must be able to "suit up" and facilitate meetings with top management to capture high-level business goals and discuss potential solutions. On the other hand, the role requires the ability to discuss the technical side of problems with IT specialists who may not always be easy to deal with. Often, these experts are focused on their own technical constraints and might be frustrated by budget delays or shifting business priorities.

Being a Subject Matter Expert (SME) and a "tech person" at the same time—switching contexts, memorizing vast amounts of information from different areas, negotiating with diverse personalities, and de-escalating tense meetings—is the essence of the BA world. It requires the ability to stay high-level and prepare simplified presentations for executives while simultaneously modeling detailed IT scenarios for technical gurus.

AND YOU ASK...

Regarding the example from the bank, is it really the business analyst who should be analyzing the impacts of implementing the new regulatory requirement? Business representatives know the processes better; shouldn't it be them who analyze the impacts?

The problem is that in large organizations, there is usually nobody who knows the entire organization and all of its processes. Each business representative knows only a small portion and cannot foresee the impacts of implementing a requirement at the enterprise level. This is when the business analyst steps in and why it is such a crucial role.

Unfortunately, it is not always the business analyst who is asked to define the needs or set the project boundaries. In our experience, to build a solution on solid foundations and reduce the risk of implementing something that is not truly aligned with business goals, an experienced BA should be involved right from the start. Neither business stakeholders nor project managers typically possess the specific skills required to analyze a business problem thoroughly, evaluate all alternatives, and account for existing constraints. What may initially seem like a "piece of cake" can quickly turn into a nightmare. Allowing business representatives or project managers to analyze the problem alone may come back to haunt you; as you realize that ambiguous requirements, feature gaps, and vague language require significantly more time to build the solution than was originally expected.

Systems analysts and project managers excel at ensuring that things are being done right, but it is the business analyst who ensures that the project is doing the right thing.

Becoming a Business Analysts

Business analysis is a discipline that sits at the intersection of business and IT, which largely dictates the professional backgrounds from which analysts emerge. In most cases, a business analyst is either a former technical professional who has become a Subject Matter Expert (SME) in a specific business domain and invested time in acquiring soft skills, or conversely, an SME who decided to gain the necessary technical background. It is impossible to say which path is superior; ultimately, no one cares about a BA's previous career as long as their work results in high-quality solutions that deliver genuine value to stakeholders

From a Developer or Systems Analyst

(+) Analytical and structured thinking: Strong ability to break down complex problems into logical components.
(+) Technical proficiency: Deep understanding of technology and software engineering principles.
(+) Feasibility assessment: Ability to evaluate technical feasibility even during the early stages of a project.
(-) Domain knowledge gap: Need to invest significant effort into learning the specific business domain.
(-) Soft skills development: May initially lack the communication and negotiation skills required for stakeholder management.
(-) Technical bias: A tendency to focus exclusively on technical implementation rather than business value.

From a Business Representative

(+) Domain expertise: Deep knowledge of the business domain, organizational capabilities, and internal processes.
(+) User-centric perspective: Practical understanding of how information systems and applications are used in daily operations.
(-) Abstract modeling gap: May struggle with the high level of abstraction required for formal modeling and technical decomposition.
(-) Technical skill gap: Limited understanding of underlying IT architectures and software constraints.
(-) Lack of technical detail: Proposed solutions often lack the granularity required to assess technical feasibility or effort.

Each path has its pros and cons. Regardless of their former role, neither a talented developer nor a subject matter expert (SME) can automatically become an effective business analyst without proper training. In practice, more business analysts transition from IT than from business departments, and the reason is straightforward. Solutions outlined by business analysts almost always involve IT modifications, which must be technically feasible. The constant need to "roundtrip" every requirement with an IT specialist for validation significantly slows down the process. Consequently, it is often more efficient for an IT professional to acquire soft skills, learn the business domain, and develop strategic thinking than it is to teach business representatives structured modeling or the fundamental principles of software engineering.

Need: A problem or opportunity to be addressed.
Business need: Business needs are the problems and opportunities of strategic importance faced by the enterprise. An issue encountered in the organization, such as a customer complaint, a loss of revenue, or a new market opportunity, usually triggers the evaluation of a business need.
Solution: A specific way of satisfying one or more needs in a context.
Stakeholder: A group or individual with a relationship to the change, the need, or the solution.
SME: A subject-matter expert (SME) or domain expert is a person who is an authority in a particular area or topic.