Analytics & BI Tools · Chapter 5 of 18
Alteryx and the preparation layer
Where analysts build pipelines without calling them pipelines — and what that means five years later.
Alteryx occupies a specific and often misunderstood position: a visual, drag-and-drop preparation tool aimed at analysts rather than engineers. Understanding why organisations buy it, and what happens afterwards, is more useful than a feature list.
Why it gets bought
- It unblocks analysts who cannot write code. A finance analyst who needs to join six sources and clean them can do it themselves, in a day, without a ticket to the data team. That is genuine value and it is why it spreads.
- It is auditable in a way scripts often are not — the workflow is visible, which regulated functions like.
- Strong at spatial and fuzzy matching, which are awkward in SQL.
- It reduces the data team's queue immediately, which makes it popular with everyone at first.
What happens next, which is the part to plan for
Workflows become production without anyone deciding. Something built for one analysis ends up feeding a board report, running on a laptop or a single server, owned by one person who then leaves.
Version control and testing are weak. Visual workflows are hard to diff, review or test, so the usual engineering safeguards do not apply.
Logic duplicates. The same cleaning happens in eleven workflows, each slightly different — which is the metric-definition problem again, one layer down.
Licensing is expensive per seat, and seats proliferate because the tool is useful.
The position to take on prep tools
They are legitimately valuable for exploration and one-off analysis, and they are a poor place for anything that feeds a recurring, consequential report.
So the policy that works is not banning them — that fails, as it does everywhere — but having a promotion path: when a workflow starts feeding something that matters, it gets rebuilt in the governed pipeline with tests and ownership. Naming that path explicitly is what prevents a shadow data platform, and it is a genuinely good answer in an interview about self-service.
What the preparation layer really is
Visual data-preparation tools let an analyst build a multi-step transformation by dragging boxes: join these, filter that, pivot, output. What has actually been built is a data pipeline — and because nobody called it one, none of the practices that keep pipelines alive get applied to it.
| Property | A pipeline built by engineering | A workflow built in the prep layer |
|---|---|---|
| Version control | Git, with review | A file on a share, named final_v3_USE_THIS |
| Tests | Assertions that fail the run | None. It either errors or produces something |
| Scheduling | An orchestrator with retries and alerting | A scheduler on a server, or somebody's desktop |
| Lineage | Traceable to the source | Inside the tool, if at all — invisible to the warehouse and to everything downstream |
| Ownership | A team | One person, who may have left |
The five-year problem, and it is very consistent across organisations.
A tool like this genuinely delivers early. An analyst who was blocked on engineering for months solves their own problem in an afternoon, and that is real value, not a mistake.
Then it accumulates. Forty workflows, feeding reports the business depends on, built by people who have since moved teams, with logic that exists nowhere else and is documented nowhere.
And the moment anyone wants to migrate — to a warehouse, to a different tool, to anything — the cost is not the tool licence. It is reverse-engineering hundreds of undocumented business rules from a visual graph, which is slow, error-prone and impossible to verify.
The mitigations are cheap and almost never applied: put the workflow files in version control even if the tool does not encourage it; require a named owner per workflow and review it annually; push anything that has become load-bearing into the warehouse where it can be tested; and keep an inventory of what feeds what.
The one that matters most is the inventory, because the first question in any migration is ‘what exists?’ and most organisations cannot answer it.
The fair verdict: the preparation layer is not a mistake, and treating it as shadow IT to be eliminated misreads why it was adopted — it exists because the governed path was too slow. Fix the speed of the governed path and the prep layer shrinks on its own. Ban it while the governed path is still slow and the work simply moves to spreadsheets, where you have even less visibility.
Check yourself