Data team: centralised or federated — a decision frame

When the fork appears

The operator invests in data capability. Two architectural patterns:

A) Centralised — all data engineers, scientists, analysts in one function under the CDO. The central team serves everyone.

B) Federated — small data pods embedded in each business domain (marketing data team, network data team, finance data team), with a dotted line to the CDO.

Eighteen months later these models produce different operating realities.

Symptoms of the centralised model

Backlog of requests from business — weeks/months.

Data team does not know domain context, delivers generic solutions.

Business teams build shadow data capabilities (Excel on steroids) around it.

Technical discipline is strong — common standards, single source of truth.

Symptoms of the federated model

Per-domain speed is high — the pod is next to the business.

Standards differ per domain — taxonomy conflicts, dashboards inconsistent.

Talent is fragmented — specialist in marketing does not know what specialist in network is doing.

Cross-domain analytics are difficult — each team protects its own data.

Where decisions usually go wrong

“Build one big data org” without understanding domain depth. A year later the business says “this team does not understand us”.

“Every domain its own data team” without central standards. Two years later 12 different definitions of “active customer”.

Hybrid without clear accountabilities. Nobody knows who is responsible for what.

Hybrid pattern (often optimal)

Centre of Excellence (CoE) under CDO: standards, platform engineering, governance, ML platform, MDM. 30-50% of talent.

Domain pods, dotted line to CDO: data analysts and domain scientists embedded in the business. 50-70% of talent.

CoE owns standards and infrastructure. Domain pods own delivery in their domain. Career path is supported through CoE (rotation possible).

When centralised

Small-to-mid operator (<3M customers).

Data discipline not yet mature — needs strong central control.

Business teams are not ready to own data outputs.

CDO has strong leadership and political capital.

When federated

Large operator with mature domains.

Data discipline is mature — common standards already exist.

Business teams ready to own decisions, not just consume reports.

Data leadership distributed.

What to discuss at the committee

Current operating pain — where it is slow, where it is inconsistent.

Talent availability — are there data leaders in domains for federation, or does the CDO hold all talent.

Standards readiness — does existing discipline exist.

Governance maturity — who resolves conflicts.

3-year talent roadmap — where we grow, where we hire.

How SamaraliSoft helps

Data Org Decision Workshop — 4 weeks. Diagnostic of the current model, target operating model design, transition roadmap, capability gap assessment.

Related

• /en/architecture/telecom-cdp-architecture/ — CDP ownership
• /en/architecture/telecom-master-data-management/ — MDM
• /en/architecture/telecom-mlops-architecture/ — MLOps
• /en/insights/telecom-data-discipline/ — data discipline