First cohort Winter 2026/27
Learn to write specs engineers can build from.
Eight instructor-led sessions with labs, a final exam and a portfolio review, taught by someone who does this work inside banks and enterprise programmes every week. You leave with the artifacts you built, not a slide deck.
Dates and price aren't published yet. Leave your email and I'll write to you when they're set. Right now that list is my inbox, so the email you get will be from me.
Who teaches it
Theodor Istratescu, and the work the material comes from.
I've been a business analyst since well before this firm existed, and a contracting technical BA since 2022, mostly inside banks, capital markets and one UN programme. The course is built out of that work: the specs that came back, the integrations that failed at the boundary nobody modelled, and the acceptance criteria that were fine until UAT.
Universal Music Group (UK)
Jul 2025 – present
Technical Business Analyst (contract)
Decommissioning a legacy rights-management system and migrating onto a modern stack. Business, legal and operational requirements written as technical specifications, plus the integration requirements and data flows between the systems on both sides of the migration.
Raiffeisen Bank Romania
Jul 2023 – Oct 2025
Business Systems Analyst · Lead BA · Proxy Product Owner (contract)
Lending and insurance flows for existing customers, integrating the national tax authority, the credit bureau, a qualified digital-signature provider and an insurance carrier. Also a tablet advisory tool that replaced a paper process in branches.
UNFCCC (Germany)
Oct 2023 – Jun 2024
IT Business Analyst · Proxy Product Owner (contract)
A carbon-accounting portal supporting Article 6 of the Paris Agreement. Regulatory requirements turned into backlog items and workflows, with stakeholder alignment across multiple countries.
LSEG (USA)
Apr 2023 – Dec 2023
IT Business Analyst & Scrum Master (contract)
A collaboration platform letting analysts work together on real-time market data. User stories, functional and technical specifications, and the integration and non-functional constraints agreed with the engineering teams.
Finstro (Australia)
Aug 2022 – Mar 2023
Solutions Designer · Technical Business Analyst (contract)
Enhancements to a digital lending platform across web and mobile, including SOAP-based integrations. Technical solutions designed with the solution architect, and API contracts defined for both clients.
Earlier
ING Hubs Romania
Mar 2020 – Aug 2022
Senior IT Business Analyst
Alior Bank
Nov 2018 – Mar 2020
IT Business Analyst
Those are contract engagements I delivered as a technical BA. They are my record, not the Academy's client list. The Academy hasn't run yet, so it has no graduates and no references, and I'm not going to borrow anyone else's.
At Raiffeisen I also ran the technical interviews that hire technical business analysts, and mentored BAs at Qualitance. So this course is built from both sides of the table: the work, and the bar someone has to clear to get the offer.
Who this is for
Three specific people.
A business analyst who writes good documentation and keeps getting asked technical questions in the room they can't answer.
You know the process better than anyone. You don't want to be dependent on an engineer to tell you what's possible.
A PM, PO or delivery manager who owns a backlog and inherited the analysis with it.
Nobody trained you for the technical half; you're doing it anyway.
An engineer moving into analysis.
You can read the system. You haven't had to run a workshop full of stakeholders who disagree with each other, and that's the harder half than it looks.
Don't enrol if
You want letters after your name.
This is not an IIBA certification and doesn't lead to one. The material is aligned to IIBA, BABOK and Scrum; the Academy is not accredited by them and does not claim to be.
You want a job guarantee.
There isn't one, and I'd be suspicious of anyone offering you one for a course.
You can't make the sessions.
Sessions three to seven build on each other and your work is reviewed in front of the group. Missing two of them means missing most of it.
You want theory and nothing else.
Most of the time is spent on your artifacts, and they get critiqued out loud. Some people hate that. It's the part that works.
What changes
What you'll be able to do that you can't do now.
Six things. If you can already do all six, this course is not worth your money.
Read an API contract and challenge it.
Open an OpenAPI spec, find the field your feature needs that the response doesn't return, and write the change request to the team that owns that API. In refinement, not in integration testing four weeks later.
Write acceptance criteria that survive UAT.
The happy path is the easy half and everyone writes it. The half that costs sprints is the timeout, the retry, the partial failure, the empty state, the duplicate submission and the permission the user turns out not to have. That's the half you'll practise.
Draw a data flow an engineer will actually build from.
Which system owns the record, which one holds a copy, what happens when the two disagree, and where the flow crosses a boundary you don't control. You'll also write enough SQL to check a claim yourself instead of waiting three days for someone to run a report.
Model a process in BPMN so it can be implemented, not just presented.
Most process models stop at the happy path and get admired in a steering committee. Yours will carry the exception paths, which is the only part engineering needs from you.
Specify an integration end to end, including what it does when it fails.
Request, response, the error cases, the retry behaviour, whether it's synchronous and what that costs the user standing at a counter waiting for it.
Run a requirements workshop without losing the room.
Get a disagreement resolved in the meeting rather than in an email chain afterwards, and leave with a decision somebody has agreed to own.
This is the ordinary working competence of a technical BA. Almost nobody is taught it. People pick up whichever three of the six their last project happened to need.
The difference in practice
Traditional BA vs technical BA
Seven places where the two roles diverge. Every row is a moment that happens in a normal delivery week.
| Traditional business analyst | Technical business analyst |
|---|---|
| Writes down what the stakeholders said | Writes down what the system will have to do about it |
| Asks engineering what the API returns | Reads the API contract and says what's missing from it |
| Documents the happy path | Documents the timeout, the retry and the partial failure |
| Reports what the data shows | Queries the data and checks before writing the requirement |
| Draws a diagram for the steering committee | Draws a diagram engineering builds from |
| Raises a risk | Names the tradeoff and what each option costs |
| Finds out in UAT | Finds out in refinement |
Format, price and dates
What's decided, and what isn't.
- When
- First cohort Winter 2026/27.
- Sessions
- Eight, live, instructor-led.
- Taught by
- Theodor Istratescu, every session.
Anything not listed here is genuinely undecided. When it is decided, the list gets it by email before this table does.
Questions
The things people ask before they sign up.
Waitlist
Get the dates and the price before this page does.
The first cohort is Winter 2026/27. When the dates, the format and the price are set, I email the list first and update this page afterwards.
What joining now gets you
- The dates, the price and the format, emailed to you before they go on this page.
- The full session-by-session syllabus when it's signed off, not the summary above.