Short answer: no, and the closest tracked occupation is one of the faster growing in the economy. The US Bureau of Labor Statistics projects management analysts to grow 10 percent between 2025 and 2035, adding about 109,200 positions to a 2025 base of 1,077,100, with 2025 median pay of $101,860. That is close to three times the 3.5 percent projected for total US employment. What is changing is the composition of the role. Documentation, requirements write-ups, process maps and first-pass analysis are being produced far faster. Eliciting what people actually need, when they disagree with each other, is not.
The Two Jobs Hiding Inside One Title
Business analyst covers two quite different roles, and their exposure differs enormously.
The documentation analyst turns decisions other people made into artefacts: requirements documents, user stories, process maps, test cases, status reports. This version of the role is heavily exposed, because every one of those outputs is a structured document generated from known inputs.
The elicitation analyst works out what the business actually needs. That means sitting with people who describe the problem inaccurately, noticing that two departments have contradictory definitions of the same term, discovering the undocumented workaround that everything depends on, and getting a decision out of a group that would prefer not to make one. This version is barely exposed at all.
Most real jobs are a mixture, and the ratio is the single best predictor of how the next few years will go for an individual analyst. The uncomfortable part is that many organisations hired for the first version and pay for the second.
Where the Compression Is Actually Happening
| Activity | Change | What remains |
|---|---|---|
| Requirements documentation | Drafted from notes in minutes | Deciding what is actually required |
| Process mapping | Generated from descriptions or logs | Recognising that the documented process is not the real one |
| User story writing | Largely automated | Judging whether the story solves the right problem |
| Acceptance criteria | Drafted automatically | Knowing which edge cases will actually occur |
| Data analysis and summaries | Fast and cheap | Framing the question and challenging the answer |
| Stakeholder workshops | Not automated | Everything |
| Conflict resolution between teams | Not automated | Everything |
| Impact assessment for a change | Partly automated | Political and operational judgement |
Read the two blank cells in the right-hand column as the actual job. When the artefacts get cheap, the meetings become the deliverable, and the analyst who was valued for tidy documentation has to become the analyst who is valued for getting a decision made.
BLS also published AI exposure categories with the 2025-35 projections, sorting occupations into Low, Moderate, High and Very high relative exposure using five external datasets including observed usage. It states plainly that exposure “does not imply job loss, productivity gains, automation probability, or wage effects.” Analyst work is language-heavy, so it registers strongly. The occupation is still projected to grow 10 percent, and both statements are correct.
Why demand is rising rather than falling
Three forces push the other way, and they are stronger than the documentation compression.
Every AI deployment needs an analyst. Organisations adopting these systems have to decide which processes to change, what the new process looks like, where the human review sits, how exceptions are handled, and what the measurable outcome should be. That is business analysis, and there is now a great deal more of it than there was.
Failed deployments create work. A significant share of automation projects underdeliver, and the usual cause is that nobody mapped the real process before automating the documented one. Diagnosing that is analyst work.
Faster artefacts mean more projects. When the cost of specifying a change falls, organisations attempt more changes. More changes require more people to work out whether each one is a good idea.
The projections release notes that professional, scientific and technical services is projected to be the third fastest growing sector at 8.6 percent, adding 926,700 jobs, with demand driven partly by AI-based systems and associated consulting services. Analysts sit directly inside that.
A discovery session no model could have run
A finance team asks for a report that reconciles two systems, and the stated requirement is clear: match the transactions, flag the differences, run it nightly. A generated specification from that description would be entirely reasonable and entirely wrong.
What an analyst finds by sitting with the team for two days is that the reconciliation already exists, in a spreadsheet maintained by one person who has worked there eleven years. That spreadsheet contains fourteen manual adjustments that are not in either system, each of which encodes a real business rule nobody documented: a customer whose invoices are always posted late, a subsidiary whose currency conversion uses a different date, a legacy product where revenue is recognised differently.
The actual requirement is not a reconciliation report. It is to get those fourteen rules out of one person’s head and into a system before that person retires. Nobody in the room said that, because nobody in the room knew it, including the person with the spreadsheet, who considers it obvious.
Finding that out required watching, asking naive questions, and having enough standing to say the stated requirement was wrong. That is the whole profession in one example, and it is the part that will still exist in ten years.
What to Know Before You Draw Conclusions
The documented process is almost never the real process. This is the most reliable finding in the whole discipline. Systems trained on documentation inherit the fiction. Discovering the difference requires watching people work and asking uncomfortable questions.
Requirements are political. What gets built reflects whose interests prevail. An analyst is often the person who surfaces that trade-off and makes it explicit. No amount of language capability substitutes for a person in the room with standing to ask.
Speed exposes weak analysis faster. When a specification takes two hours instead of two weeks, a bad specification reaches build sooner. The value of getting it right went up, not down.
Junior roles are genuinely squeezed. Documentation work was how analysts learned the domain. That entry path is narrowing, which is a real problem for the profession’s pipeline even though the occupation grows.
Domain knowledge is the durable asset. An analyst who understands insurance claims, clinical workflows or supply chain operations deeply is difficult to substitute. A generic analyst is much easier.
Where the Work Is Moving
- Process discovery and redesign. Working out what actually happens, then designing what should happen. The most valuable and least automatable part of the role.
- AI implementation analysis. Deciding which steps to automate, where the human check goes, and what happens to exceptions.
- Data and measurement design. Defining what success means before the build, and building the measurement into the change.
- Vendor and build evaluation. Assessing whether a product actually solves the problem, which requires understanding both the problem and the claim.
- Change and adoption. The gap between a working system and a used system is where most value is lost, and closing it is a human job.
A Decision Framework for Analysts
- Mostly writing documentation. The most exposed position. Move deliberately toward elicitation and facilitation within the year: run the workshop instead of writing it up, and take the stakeholder nobody wants to deal with.
- Mixed role in a delivery team. Reasonably secure. Your growth move is measurement, because analysts who can define and evidence outcomes are scarce.
- Domain specialist analyst. Strongest position. Your risk is tooling fluency rather than relevance, and it is cheap to fix.
- Entering the profession. Choose a domain and go deep rather than learning the artefacts. The artefacts are now the cheap part; the domain is not.
The test that separates the two versions of the job: in the last month, how many hours went to writing things down versus finding things out? If the first number dominates, that is the number to change.
Common mistakes right now
- Producing more documentation because it is now cheaper, rather than less.
- Accepting a generated process map without validating it against observed behaviour.
- Letting the specification get faster without making the discovery more thorough.
- Treating stakeholder disagreement as a documentation problem rather than a decision problem.
Building the Fluency That Makes You the Implementation Analyst
Organisations deploying these systems need someone who can hold two things simultaneously: a real understanding of what the technology does and does not do, and a real understanding of how the business actually works. That combination is unusual and currently very well paid, and it is much easier for an analyst to acquire the first than for a technologist to acquire the second.
Concretely it means being able to judge which parts of a process are suitable for automation, design the review step that catches the predictable failures, specify what should happen when the system is uncertain, and define how anyone would know whether the change worked. Learning that in a structured sequence is far faster than assembling it from vendor material, and a certificate alongside a real project makes the capability visible when a programme is choosing its lead analyst. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
FAQ
Is business analysis a dying career?
Which analyst tasks are most automated?
What should I learn to stay relevant?
Does this change which certifications matter?
Are junior analyst roles disappearing?
Your Next Step
Take your most recent requirements document and ask what would have been different if you had spent those hours watching the process instead of writing it up. In most cases the answer is that you would have found the workaround, the exception, or the disagreement that later caused a change request. That is the work worth protecting, and the fastest way to protect it is to start spending the hours the tooling gives back on discovery rather than on producing more documents.