Fire for Effect

I went to college on an ROTC scholarship. When I got my degree, I went into active duty service as a lieutenant. During my time on active duty, I served in a field artillery battalion, as part of the operations staff. That is where I learned how the Army actually delivers fire support

The most important thing to know about artillery is that it can’t win the battle alone. The Army relies on maneuver units (tanks and infantry) to seize or hold the battlefield. Artillery supports them by putting shells, rockets, or missiles on the enemy to suppress or destroy it.

How that support is organized is the interesting part. Artillery units usually belong to a division or a corps, but they do not always work directly for that headquarters. Sometimes they shoot higher-level missions such as SEAD (suppression of enemy air defenses) or counterfire (attacking the other side’s artillery). Sometimes they talk straight to a subordinate unit that is in contact and needs rounds now. And sometimes they have a primary mission and a secondary one stacked underneath it.

The Army classifies those relationships in three habitual categories:

• Direct Support (DS): Artillery’s first job is the maneuver brigade it is assigned to support. Priority of fires belongs to that commander. The typical targets are the tanks and infantry in that brigade’s fight.
• General Support (GS): The unit answers to higher headquarters. The targets are deeper and more often force- or theater-level: the assets behind the front that shape the rest of the battle.
• General Support Reinforcing (GSR): Artillery supports the force as a whole, but it can be called to assist another artillery unit when that unit’s fight gets heavy.

I started thinking about that structure again as I spent more time around data meshes.

When a company accumulates data from more systems and more business units, a single centralized team reporting to the CIO becomes the bottleneck for every model, pipeline, and dashboard. A data mesh tries to break that bottleneck. Instead of sending every request through one warehouse or lake team, it pushes ownership down to the business domains that create and understand the data.

People new to the idea sometimes treat “data mesh” as a product you can buy. Tools can help. But the mesh itself is first and foremost an operating model: who owns the data, how it is published, and how the rest of the company is supposed to use it.

Four principles do the work for building an effective data mesh:

1. Domain Ownership

The people closest to the source produce the analytical data for that domain. A remote central team shouldn’t have to reverse-engineer every source system. Sales owns sales data. Risk management owns risk data. Claims owns claims data. That is domain-driven design applied to data.

2. Data as a Product

Domains do not dump tables into a lake and walk away. They publish data products: datasets (or APIs) that are:

• Discoverable
• Addressable
• Trustworthy (for quality or SLAs)
• Self-describing (schema, lineage, meaning)
• Interoperable
• Securely accessible

A data product has consumers. If those consumers can’t find it, trust it, or join it, the product failed.

3. A self-service data platform

Domains own their data. They shouldn’t have to reinvent the wheel for each ingestion, transformation, test, catalog, and access control process. A platform team provides shared infrastructure as a service: storage/compute, orchestration, catalogs, identity, quality tooling, and templates. Domain teams use those tools; they don’t rebuild the platform.

4. Federated computational governance

Autonomy without standards is just a mess with extra steps. A small central group sets the global rules — security, PII, naming, interoperability, regulatory constraints. Enforcement works better when it is computational, encoded in the platform, than when it is a ticket queue. Domains still own their products; they just operate inside shared guardrails.

The longer I sat with that framework, the more the old fire-support relationships lined up.

• Direct support maps to a domain-aligned data product team. A DS battalion’s first job is that brigade’s fight. A domain team’s first job is that business unit’s data products: the lending book, the claims triangle, the commercial pipeline. The supported commander — brigade or business domain — has priority on what gets built. They do not stand in a company-wide queue for every mission.
• General support maps to the platform team and the enterprise data products. GS units answer to division or corps for force-level missions: counterfire, shaping, deep fires. The platform team answers for shared infrastructure, standards, catalogs, identity, and the products no single domain should own alone — customer master, chart of accounts, regulatory reference data, company-wide security controls.
• General Support Reinforcement (GSR) maps to surge enablement. When a domain is in a hard fight — a system conversion, an exam, a product launch — platform engineers can be pushed forward to reinforce that domain without taking ownership of the product.
• Fire support coordination maps to federated governance. Fire support coordinating measures (FSCMs), attack guidance, and clearance of fires keep DS units from shooting each other or violating higher intent. Naming standards, data contracts, PII rules, and access policy do the same across domains.
• The mission can change. The identity should not. A DS battalion can be rolled to GS for a phase of the operation. A platform team can treat one domain as the main effort for a quarter. That is a change in how scarce technical capacity is allocated, not a change in what a howitzer is.

As a picture of who gets first call on scarce specialists, and who holds the common fire-control system, the analogy holds up.

Of course, like every analogy, sometimes it doesn’t apply:

• Ownership sets at different levels. Artillery can be sliced up to support different units, but at the end of the day, chain of command still matters. In a data mesh, on the other hand, the nerds and geeks who manage the data are often more answerable to the business unit they support than to the IT department.
• Artillery is a single specialty. Domain teams are mixed: business subject matter experts plus enough analytics engineering to run products on a shared platform. The grunts on the battlefield don’t have to become cannon-cockers. In a mesh, the domain does need some organic “gunners.”
• You shouldn’t flip ownership as freely as a fire-support mission. Changing an artillery battery from DS to GS is normal. Changing who owns the “customer” or “policy” data product every quarter destroys accountability.
• Some missions stay centralized. There are some missions (like counterfire and SEAD) that stay GS. Regulatory reporting, enterprise MDM, and security control planes stay GS-like even in a mesh.

The title of this piece is an artillery phrase. After you adjust fire and know you are on the target, you stop tinkering and fire for effect — you mass the guns. The mesh is the same idea. You do not win by owning every tube from the headquarters tent. You win when the unit closest to the fight can put rounds on the target, the platform keeps the fire-control system common, and the rules keep everyone from shooting the same grid twice.

Mission accomplished is still the point. The reliable way to get there is to push responsibility as close to the action as it will go.