Business Analysis Roles and Organizational Context

Who Performs Business Analysis

The Business Analysis Standard and the BABOK Guide both make a foundational point: business analysis is a set of activities and competencies, not a fixed job title. Organizations assign this work to people carrying many different titles, and the ECBA exam expects candidates to recognize business analysis work wherever it appears, regardless of the label on someone's business card.

According to the BABOK Guide, business analysis is commonly performed by people whose job title actually is "business analyst," but it is equally performed by people with titles such as:

• Business systems analyst
• Business architect
• Business process analyst
• Data analyst
• Enterprise analyst
• Management consultant
• Product manager
• Product owner
• Requirements engineer
• Systems analyst

A product owner on a Scrum team writing and prioritizing a backlog is doing business analysis. A management consultant facilitating a strategic assessment is doing business analysis. A data analyst translating a reporting need into a defined dataset is doing business analysis. The activities -- eliciting needs, analyzing information, defining requirements, recommending solutions -- are what matter, not the title on the org chart.

How Responsibilities Vary by Context

Because the role is defined by activity rather than title, the specific responsibilities a business analysis practitioner carries shift with context. Several factors drive that variation:

Methodology. In a predictive (plan-driven) initiative, a BA typically spends more time up front producing detailed, signed-off requirements documentation before development begins. In an adaptive (Agile) initiative, the same practitioner -- often filling a product owner or team-embedded BA role -- spends more time in ongoing backlog refinement, just-in-time elaboration of user stories, and continuous stakeholder conversation throughout each iteration.

Organizational maturity and size. In a small organization, one generalist may perform the full range of business analysis activities across strategy, requirements, and solution evaluation. In a large enterprise, the work is often split across specialized roles -- for example, a business architect working at the enterprise level, a business systems analyst working at the project level, and a data analyst focused on reporting requirements -- each contributing a slice of business analysis to the same initiative.

Industry and regulatory environment. Regulated industries such as financial services, healthcare, and government often require more rigorous documentation, traceability, and formal sign-off, expanding the BA's responsibility for requirements management and audit-ready artifacts. Less regulated, fast-moving environments may emphasize speed and continuous validation over exhaustive documentation.

Scope of the initiative. A BA supporting an enterprise-wide transformation is more likely to work with strategic-level concerns -- business architecture, capability analysis, organizational change -- while a BA supporting a single system enhancement focuses on solution-level requirements and detailed acceptance criteria.

Organizational Considerations

Where the business analysis function sits inside an organization's structure meaningfully shapes how the role operates:

1. Centralized (Center of Excellence). BAs report into a shared business analysis practice and are assigned out to initiatives as needed. This supports consistent standards, mentoring, and career progression, but can create friction if BAs feel disconnected from the delivery teams they support.
2. Decentralized / embedded. BAs report directly into the business unit, product team, or project they support, and belong to that team full time. This builds deep domain knowledge and close stakeholder relationships but can make consistent practice and knowledge-sharing across the organization harder to sustain.
3. Matrixed. BAs have a functional reporting line, for standards and skill development, and a separate project or product reporting line, for day-to-day work assignment and prioritization. This is common in larger organizations and requires the BA to balance sometimes-competing priorities from two managers.

The organizational structure also affects the BA's authority and influence. A BA is rarely a formal decision-maker with sign-off authority over budget or scope; the role's influence typically comes from facilitation skill, subject-matter credibility, and the quality of the analysis produced, not positional power. Recognizing this distinction is itself part of the underlying competency of Organization Knowledge: understanding how an organization is structured, how decisions get made, and where the BA's recommendations need to be routed to become effective.

Stakeholder Roles the BA Works Alongside

The BABOK Guide also defines a common set of stakeholder roles that appear across virtually every business analysis initiative, regardless of methodology or industry: customer, domain subject matter expert, end user, implementation subject matter expert, operational support, project manager, regulator, sponsor, supplier, and tester. A single individual may occupy more than one of these roles at once -- a sponsor might also be a domain subject matter expert, for instance -- and the same person may shift roles across different initiatives. Recognizing which stakeholder role a person is playing in a given conversation, rather than assuming their job title defines their contribution, helps the BA elicit the right information from the right perspective.

Exam Takeaway

For the ECBA exam, remember that business analysis work is defined by what is done -- eliciting, analyzing, specifying, validating, recommending -- not by the title of the person doing it. Expect situational questions that describe someone performing business analysis activities under an unfamiliar title, or that ask how a BA's responsibilities should shift given a described organizational structure or methodology; the correct answer is almost always the one that matches responsibility to context rather than assuming a single "standard" BA job description.