Again!? You wanna build another new system?

If you are a data scientist working closely with IT team, you have probably heard this complaint. “Why does everyone in the house want to build their own new system?” — an IT manager said this to me.

He wanted to persuade us — a data-facing team that already runs many surveillance systems alongside IT — to build on an existing platform instead. The claim is fair: a new system means a new vendor, long procurement, contract management, compliance review, architecture rework, and a lot of new things to maintain.

And yet we still had a hundred reasons to build our own. To be clear, that never meant skipping IT — the real question was never whether to involve them, but who drives the system.

This got me thinking. In the age of agentic AI, where the number of applications can skyrocket, this conflict will only show up more often. So rather than take a side, I want to ask where the tension between a business unit and IT comes from — starting with the argument I was having myself.

Why does every department want its own system?

In short: we recently secured funding to build an AI agent system for monitoring international outbreaks. IT’s reasonable question was: why can’t you add these functions to an existing system and avoid duplication? Our answers were:

1. Proven mission with a mandate. We have monitored international outbreaks manually for nearly two decades — work of real value to the agency, now formally approved in the next five-year national strategy.
2. A genuinely different function. Our existing systems watch local cases and are mostly indicator-based. The new one is event-based: the diseases it captures and the sources it draws on are far wider.
3. A technology-readiness gap. AI adoption is an international trend we need to follow — and the legacy systems simply aren’t AI-ready.
4. An accountability indicator. “An event management system is established” is itself a monitoring-and-evaluation indicator we’re measured against.
5. The honest one — politics. Extending someone else’s system means negotiating their roadmap, inheriting their debt, and waiting for their priorities. Building together means shared budgets and endless coordination. Starting fresh looks cheaper for the department — at the cost of the organisation’s coherence.
6. Expertise we don’t have in-house. Our team knows the domain, but with limited staff we cannot build and run everything ourselves. A new system lets us hire that capability from a vendor: often a system integrator (SI) team that builds a customized system to our specification.
7. A sustainability path. This is not an ad hoc build. We are committing to maintain it, with a long-term roadmap and dedicated funding behind it.

The seven reasons settle one question: a new system deserves to exist. But they leave the harder one my IT manager was really asking — who drives it? A justified system could still be IT-led, yet departments everywhere want the wheel, pulled by three forces:

• Speed: you stop waiting in someone else’s queue.
• Fit: the people closest to the work know the requirements best.
• Autonomy: clear ownership, your own budget, no negotiating access rights every time you need a new field.

Look at these forces, and at reasons 5 and 6: every one is a cost of communication. IT’s queue is paid in time. Translating requirements to outsiders is paid in accuracy — something is always lost. Negotiating budgets, roadmaps, and access rights is paid in political capital. Even hiring a vendor buys your way out of one conversation at the price of another: procurement, contracts, lock-in. A department building its own system is not really buying software — it is buying its way out of talking. And that instinct has a name; someone described the mechanism sixty years ago.

Systems are the outcome of communication structures

Melvin E. Conway made this observation back in 1968:

Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.

When departments don’t talk much, they build silo systems that avoid sharing functions, data, or access rights. The architecture simply reveals the organisation chart.

This is the IT department’s nightmare: everybody owns a customized system and the system count keeps climbing. But Conway’s Law tells us the sprawl is a symptom, not the disease. The disease is how the organisation communicates.

When every department has its own system — each reaching out to its own vendor, all loosely orbiting a stretched-thin IT core — the architecture ends up looking like this:

Govern the conversation, not the systems

So the real problem was never the number of systems — it was the communication that shaped them. That reframes the fix: optimize the communication structure first. Fix the talking and the architecture follows; fix the architecture without the talking and you just get a well-documented copy of the same silos.

In practice, that means starting with the organisation, not the software. Put cross-functional teams in charge of the missions that must not fail, then give them a federated paved road: IT supplies shared standards, common data definitions, security guardrails, and an approved vendor list; business units build freely on top.

So, should you build a new one?

If you’re about to propose yet another system, the seven reasons above double as a checklist: a real mandate, a genuinely different function, a technology gap the legacy stack can’t reach, an accountability hook, an honest read on the politics, the capacity to build and run it, and a plan to sustain it once the launch budget is gone. If you can answer most of these, you probably have a real case.

If you can’t, you’re likely better off building on what already exists — and saving your IT manager from asking “again?”

Views expressed here are my own and do not represent the views of my employer, Taiwan Centers for Disease Control. This post was collobrated with Claude.