Open the sprint board of almost any data team and you'll find user stories for three different jobs, all sitting in one backlog.
There's always a new ingestion pipeline being designed, a failed refresh from this morning that needs chasing, a schema change from an upstream vendor and a service retirement notice that has been sitting in the backlog for six weeks.
It's the same group of engineers. Same board. Same sprint. Three completely different kinds of work, and almost nobody names the difference.
That is what this article is about. Data engineering runs in three modes: build, maintain and business as usual. Each one needs different people, different planning and a different budget. When they blur together, issues fall through the cracks.
Three modes, three different jobs
Build is creating capability that did not exist before: a new pipeline, a new source, a new model, new infrastructure. It is project-shaped, with a start and an end, and is full of ambiguity. Success is measured by delivery. Did it ship, and does it do what was agreed?
Maintain is deliberately changing what already exists so that it stays fit for purpose. Runtime and dependency upgrades, schema drift from upstream systems, retiring services, paying down technical debt, tuning cost and performance. It's planned and proactive, and often the first thing cut when a deadline gets close.
Business as usual (BAU) is keeping the platform running today: watching the overnight runs, triaging failures, answering access requests, supporting users, and producing the evidence that all of this happened. This is reactive by nature and driven by the clock rather than a plan.
| Build | Maintain | Business as usual | |
|---|---|---|---|
| Purpose | Create new capability | Keep the platform fit for purpose | Keep it running today |
| Rhythm | Project, with an end date | Planned and recurring | Daily, driven by the clock |
| Success looks like | Delivered, accepted, adopted | Changes land without surprises | Reliable, fast recovery, evidence kept |
| Typical failure | Late or over scope | Quiet decay | Silent failure nobody notices |
| Usually funded as | Project budget | Retainer or reserved capacity | Run budget or managed service |
What goes wrong when the modes blur
The failures follow three recognizable patterns.
1. Build eats business as usual
A new feature is exciting, visible and has a sponsor, so it gets the best engineers. BAU becomes whatever capacity is left over. Overnight failures wait until someone notices a dashboard looks off, which is the failure category I wrote about in Real-World Azure Data Architecture: not a system that is down, but numbers that are quietly wrong.
2. Maintain never gets scheduled
Maintenance has no launch date, no demo and no sponsor, so it loses every prioritization argument against build work. Nothing breaks on any given day. Runtimes age, retiring services stay provisioned, upstream schema changes pile up, and access that was granted for a one-off investigation never gets revoked. Each item is small. Together they are the platform slowly becoming something nobody fully understands. I covered the zombie resource version of this in How to Build a Secure Azure Data Platform from Day One.
3. The handover cliff
Go-live gets celebrated. The project team rolls off to the next build. Then, a week later, someone asks who owns the platform on a random weekday morning when a pipeline fails, and the honest answer is nobody. Build mode ended and BAU mode never started. The first production incident leads to the discovery of there being no runbook.
Each mode needs different things
Treating the three as one stream of tickets hides the fact that they differ on almost every dimension that matters.
- Skills and temperament. Build rewards design thinking and a tolerance for ambiguity. Maintain rewards patience, discipline and risk management. BAU rewards calm, fast triage and clear communication under pressure. Some engineers are strong at two of these. Very few are strong at all three at the same time.
- Metrics. Build is judged on delivery against scope and date. Maintain is judged on how whether changes land safely or not and how the current the platform is. BAU is judged on how quickly problems are detected and recovered from.
- Planning rhythm. Build runs on sprints and milestones. Maintain runs on a recurring calendar, like a quarterly access review. BAU runs on the daily clock and on-call rota.
- Commercial model. Build is typically a project fee. Maintain suits a retainer or reserved capacity. BAU suits a run budget or managed service. Whichever model you choose, the three should be scoped and funded separately, not hidden inside the build budget.
Why this matters more in regulated environments
In defense, aviation, healthcare and financial services, each mode produces a different kind of assurance, and an auditor will ask about all three.
- Build creates the design assurance. Identity, networking, data classification and environment separation are decided here, and they are far cheaper to get right now than to retrofit.
- Maintain provides change control. Every upgrade, schema change and promotion between environments is a controlled change with a review, an approval and a way back. This is the territory of Deploying Synapse to Synapse, where the gates between stages are what keep a failure contained.
- BAU generates the audit evidence. The question "can you show us it was being watched?" is a BAU question. It is the governed rung of the pipeline monitoring maturity ladder, and it is why I built Vigil to produce a timestamped record of every run.
A team that only budgets for build can pass a design review and still fail an audit. The design was sound, but nobody was funded to change it safely or to prove it was being operated.
Making the modes visible
None of this needs new tooling. It needs a few habits.
Label every piece of work
Ask three questions of any ticket:
- Does it create something that did not exist before? That is build.
- Does it deliberately change something that already exists, to keep it healthy? That is maintain.
- Is it a response to something happening today, or a task that recurs on the daily clock? That is BAU.
Once every ticket carries one of the three labels, the blurring becomes visible on the board within a sprint.
Ring-fence capacity for each mode
There is no universal ratio, but there should be a number, written down. A team might start with 60 percent build, 20 percent maintain and 20 percent BAU, then adjust as the platform matures. The exact split matters less than the fact that it is explicit and that build cannot quietly borrow from the other two.
Treat handover as a deliverable
Build is not finished at go-live. It is finished when the platform can be run without the people who built it. Before declaring a build complete, check that:
- A named owner exists for BAU, with an on-call arrangement.
- Runbooks cover the failure modes you already know about.
- Monitoring reports on every run (not just the failures) and keep a retained log.
- Access, secrets and service dependencies are documented.
- Recurring maintenance (upgrades, access reviews, retirement checks) is on the calendar.
- Run and maintain each have a budget line that does not depend on the build project.
Final thoughts
Most data platforms do not fail during the build. They fail in the months afterwards, when the people who designed them have moved on and nobody has been funded to maintain or run them. The technology is rarely the problem. The problem is not having proper separation of concerns.
Naming the modes is not a fix, but it provides the shared vocabulary required for prioritization and capacity management.
If you lead a data team, put the three modes on your board as three lanes and see which one is thinnest.
If you are an engineer, notice which mode you are in when you start a task. It changes how you should work, and how you should be measured.
If you are scoping a build with a partner, ask who owns maintain and BAU after go-live, and what that costs. A good answer is specific. A vague one usually means nobody has thought about it yet.
I work across all three modes building data and AI platforms in Azure for regulated industries, including defense and aviation. If you are working out how to structure your team, or what a proper handover should include, let's talk.