Analyst Roles in IT: A Map Without a Ranking

The title “analyst” reveals very little about the working day. A systems analyst may design APIs in one company and focus on requirements and processes in another. A product analyst may spend most of the week on statistics or work mainly with product teams on definitions and decisions.

A list of titles therefore becomes dated quickly. Four coordinates are more useful:

1. the subject — a need, process, system, dataset, or risk;
2. the outcome — a decision, requirement, model, report, or control;
3. the collaborators — business, product, engineering, or leadership;
4. the depth — domain, technical, mathematical, or regulatory.

The families below are my working grouping, not an industry standard for job titles. Boundaries vary across organisations. IIBA likewise describes business analysis as a practice performed under several titles.

1. Business, product, and process

Business analyst

Studies needs, participants, and business rules. Typical outcomes include a process model, change requirements, solution options, and impact analysis.

The role’s strength is connecting several stakeholder perspectives and checking that the team is solving the right problem rather than automating the current procedure by default.

Business process analyst

Focuses on how work moves across roles and systems: waiting, repeated entry, manual control, and gaps in ownership. BPMN, process measures, and automation programmes are common parts of the work.

Product analyst

Supports product decisions with evidence: defines measures, designs experiments, studies user behaviour, and explains changes in outcomes. Some organisations make this a distinct role; others treat it as a data-analysis specialism.

Marketing or customer analyst

Works with segments, channels, communication, and the customer journey. Causal reasoning and experiment quality matter because a marketing measure is not automatically the same thing as customer value.

2. Systems and interactions

Systems analyst

Translates a need into the behaviour of an information system. The work may include data models, APIs, integration contracts, scenarios, states, and non-functional requirements.

The boundary with architecture and development varies. A systems analyst may propose technical options or record a solution designed with the engineering team.

Functional analyst

Owns the behaviour of a particular product or platform: configuration, rules, user scenarios, and fit with standard capabilities. The title is common in ERP, CRM, and industry-platform implementation.

Integration analyst

Concentrates on interaction between systems: formats, sequence, errors, replay, contract versions, and data ownership. It may be a separate position or part of systems analysis.

3. Data and decisions

Data or BI analyst

Obtains, verifies, and interprets data to produce measures, reports, and investigations. Differences in title often reflect tooling and team structure rather than completely different professions.

Operations analyst

Studies operational work: throughput, lead time, queues, utilisation, and causes of deviation. The domain may be logistics, support, manufacturing, or internal services.

Fraud or risk analyst

Finds suspicious patterns, designs rules and models, and evaluates false positives and missed cases. Data quality, explainability, and regulatory constraints are central to the work.

Data scientist

Builds and evaluates statistical and machine-learning models. The work includes experiment design, metric choice, bias assessment, and explaining where a model should not be used, not only training an algorithm.

Analytics engineer

Works between analytics and data engineering, building transformations, tests, and data models for analytical products. It is a technical role centred on reproducibility and dataset quality, consistent with the account from dbt Labs.

4. Quality, security, and control

QA analyst

The title may describe test analysis and test design or analysis of the quality-assurance process itself. The vacancy content matters more than the label.

Security analyst

Analyses threats, vulnerabilities, security events, and the effectiveness of controls. The family includes SOC, application security, threat intelligence, GRC, and other specialisms with very different skill sets.

Data quality or governance analyst

Works with definitions, ownership, lineage, quality rules, and change. The role connects business meaning, the data platform, and risk management rather than merely inspecting tables.

5. Domain and method as a second layer

Geospatial, graph, financial, and economic analysis often combine a base analytical role with a domain or method rather than forming one universal profession.

Graph methods, for example, may be used by a data scientist, data analyst, or systems analyst. Geospatial work can require statistics, GIS, data engineering, or transport knowledge depending on the problem.

“I want to become a graph analyst” therefore needs another question: which decisions, data, and outputs would define the work?

6. AI roles are still ambiguous

“AI analyst” can refer to several kinds of work:

• a product analyst on an AI-enabled product;
• a data scientist evaluating model behaviour;
• a business analyst selecting processes for automation;
• an AI-governance or risk specialist;
• an analyst assessing LLM outputs and data quality.

ML engineers, data engineers, AI product managers, and domain experts work alongside them. Read the responsibilities and expected artefacts of an AI vacancy rather than relying on a fashionable title.

Hybrid and lead roles

Business systems analyst, analyst-developer, lead analyst, and solution analyst may combine several families. That can be useful when the scope is explicit.

A hybrid role reduces handovers. It becomes a problem when one title quietly accumulates discovery, architecture, development, testing, and support without enough time or authority to own them.

Capabilities shared across strong analysts

Toolkits differ, but several abilities recur:

• framing a question and the boundary of an investigation;
• separating evidence from assumption;
• checking data source and quality;
• explaining a decision to different audiences;
• recording constraints and outcome criteria;
• seeing consequences for adjacent processes and systems;
• revising a conclusion when new evidence appears.

Choosing a direction

Do not begin with a salary ranking or the prestige of a title. Take several real vacancies and note:

1. which verbs repeat in the responsibilities;
2. which artefacts the role produces;
3. who occupies most of the working conversations;
4. how much data, system design, and negotiation the work contains;
5. which domain knowledge is required;
6. what a good result looks like after six months.

Then try a small representative task: model a process, design a contract, investigate a dataset, or analyse a risk. Practice reveals fit faster than another description of the profession.

Analysis roles do not form a ladder from simple to advanced. They solve different parts of a shared problem. Choose the kind of question and outcome you want to work with every day, not the loudest title.

---

The first version of this article was published on vc.ru.

Yours, DPUPP