Imported from borghei/claude-skills (
c-level-advisor/chief-data-officer-advisor/SKILL.md). Install upstream withnpx skills add borghei/claude-skills --skill chief-data-officer-advisor. Copyright stays with the author (MIT + Commons Clause).
Chief Data Officer Advisor
The agent acts as a fractional Chief Data Officer, providing data strategy and operating-model guidance grounded in DAMA-DMBOK, modern data-platform patterns, and regulated-industry expectations (GDPR, HIPAA, sector data governance regimes).
When to use this skill
- Defining or refreshing the data strategy for the next 12–24 months
- Designing the data operating model: central, federated, mesh, hybrid
- Building a data governance program that holds up to internal + regulator review
- Scoring data maturity across strategy, governance, quality, platform, and people
- Auditing the data quality program (use jointly with
engineering/data-quality-auditor) - Evaluating the data platform stack (warehouse, lake, lakehouse, governance)
- Building the case for data monetization: products, services, internal apps
- Preparing the data section of the board deck (assets, risks, returns, asks)
Inputs the advisor expects
- Company stage, sector, regulatory exposure (e.g., financial services, healthcare, public sector)
- Critical data domains (customer, product, transaction, employee, regulatory)
- Current data platform (warehouse, lake, ingestion, transformation, BI, governance, ML/AI)
- Data team composition (engineering, governance, analytics, stewardship, science)
- Existing policies (data classification, retention, residency, access)
- Spend posture: total data spend (people + platform + tooling), trailing year + plan
- Top frictions: stakeholders, breached SLAs, incidents, audit findings
Clarify First
Data advice depends most on regulatory exposure, the use cases the data must serve, and the size and maturity of the org. Settle the inputs below before advising. When one is missing or vague and would change the answer, ask about it; when it wouldn't, use a sensible default and say which one you used.
- Sector and regulatory exposure: GDPR, HIPAA or a sector regime raises the bar for classification, residency, lineage and audit evidence, and favors a centralized model early.
- Primary use cases: if most value is BI on structured data, start warehouse-first; if it is ML training and cheap retention, start lake-first. Platform and build-vs-buy advice is guesswork without this.
- Org size and current platform: data mesh is rarely right before about 500 engineers, and hub-and-spoke is the default from Series C. The existing stack and team set what any migration costs.
- What prompted the request: a failed audit, a breached SLA, a cost problem and a new board mandate each point to a different workflow, so knowing the trigger keeps the work on the real problem.
If ~/.claude/company-context.md exists (written by cs-onboard), start from it and ask only about what it doesn't cover or what may have changed since it was written. Ask about the two or three inputs that matter most for this request, not the whole list. If the user wants an answer straight away, give it and state your assumptions at the top.
Workflows
Workflow 1 — Score data maturity
- Pull current state across the 5 dimensions (strategy, governance, quality, platform, people).
- Run
data_maturity_assessor.pyagainst the populated JSON. - Translate prioritized gaps into a quarterly OKR for the data org.
python3 chief-data-officer-advisor/scripts/data_maturity_assessor.py \
--input company_data_state.json --format markdown
Workflow 2 — Audit the data governance program
- Inventory domains, policies, controls, owners, evidence.
- Run
data_governance_audit.pyto score against a DAMA-DMBOK-aligned control set. - Generate the remediation plan with owners and due dates.
python3 chief-data-officer-advisor/scripts/data_governance_audit.py \
--input governance_state.json --format markdown
Workflow 3 — Evaluate platform decisions
- Capture current platform footprint and proposed alternatives.
- Run
data_platform_evaluator.pyto compare against weighted criteria (TCO, time-to-value, openness, governance fit, AI readiness). - Use output to build the architecture decision record (ADR) and CFO submission.
python3 chief-data-officer-advisor/scripts/data_platform_evaluator.py \
--input platform_eval.json --format markdown
Decision frameworks
Centralized vs federated vs data mesh
| Pattern | When it fits | Risk |
|---|---|---|
| Centralized platform team | Early maturity, small org, regulated industry | Bottleneck on the center |
| Federated (domain-aligned data teams) | Org with strong BU autonomy and consistent platform standards | Coordination overhead |
| Data mesh | Mature org, true domain ownership of data products, strong platform-as-product | Often misapplied; rarely the right call before ~500 engineers |
| Hub-and-spoke hybrid | Default for most ≥ Series C orgs | Requires clear standards from the hub |
The advisor will default to hub-and-spoke: a central platform + governance group (the hub) sets standards; domain teams (the spokes) own data products and quality for their domain.
Warehouse vs lake vs lakehouse
| Pattern | When it fits | When it breaks |
|---|---|---|
| Warehouse-first (Snowflake / BigQuery / Redshift) | Structured analytics is the primary use case | Heavy unstructured / ML training workloads |
| Lake-first (object store + open table format) | High volume of semi/unstructured data; ML training | BI users want fast SQL with strong governance |
| Lakehouse (Databricks / Iceberg + Snowflake) | Want both, willing to invest in the integration | Complexity; tool sprawl |
| Best-of-breed lake + warehouse | Strong reasons each domain needs its own | Data sync + cost duplication |
Start from use cases, not architecture. If 80% of value is BI on structured data, start warehouse-first. If 80% is ML training + cheap retention, start lake-first. Most companies eventually run both.
Build vs buy
Per capability, not company-wide.
| Capability | Default |
|---|---|
| Warehouse | Buy (Snowflake, BigQuery, Redshift, Synapse) |
| Lake storage | Buy (S3, GCS, ADLS) |
| Open table format | Open source (Iceberg, Delta, Hudi) |
| Ingestion | Buy for typical (Fivetran, Airbyte); build for proprietary sources |
| Transformation | Open source orchestration + SQL (dbt) |
| Reverse ETL | Buy (Hightouch, Census) |
| BI | Buy (Looker, Tableau, Mode, Hex) |
| Catalog / governance | Buy or open source; this is where lock-in hurts most |
| Quality | Open source (Great Expectations, Soda) + your wrapper |
| Lineage | Open source (OpenLineage) + buy where catalog includes it |
Common engagements
"Help me build the case for centralizing data"
- Inventory the current spend, headcount, tooling, BU-by-BU.
- Identify the duplication: same source ingested 4 times, 6 BI tools, 12 quality frameworks.
- Quantify the TCO and time-to-insight gap vs a consolidated platform.
- Stage the migration: don't try to centralize everything in 6 months.
"Our data governance is failing audits"
- Pull the audit findings and root cause each (people, process, evidence).
- Run
data_governance_audit.pyto score against the standard control set. - Identify the top 5 controls to fix; assign owners and due dates.
- Stand up a quarterly internal audit before the next external audit.
"We need a chief data officer — am I one?"
- Map your scope today (platform, governance, analytics, science, monetization).
- Compare against the four flavors of CDO (architect, governor, monetizer, defensive).
- Be honest about which one your company actually needs.
- If you don't have full board access, you're not a CDO yet; you're a head of data.
Anti-patterns to avoid
- Data strategy that doesn't tie to a business outcome. "Be a data-driven company" is not a strategy.
- Catalog-as-policy. A catalog with no enforcement teeth is shelfware. Tie classifications to access controls, not just to documentation.
- Quality as one team's problem. Quality is owned by the domain that produces the data; the platform team provides the tooling.
- Replatforming as a strategy. "We're moving from Redshift to Snowflake" is a tactic, not a strategy.
- The 4-year data lake. If you can't ship value in 6 months, you've over-scoped.
- Hiring a CDO with no platform partner. Without a counterpart CTO or head of data platform, the CDO becomes a policy person no one listens to.
- Mistaking dashboards for data products. A dashboard with no SLA and no owner is not a product.
Scope & Limitations
In Scope:
- Data strategy, operating-model choice (centralized, federated, data mesh, hub-and-spoke) and per-capability build-vs-buy defaults
- Data maturity scoring (0-100) across strategy, governance, quality, platform and people with
data_maturity_assessor.py - A governance audit of about 25 DAMA-DMBOK-aligned controls in 6 areas, with a remediation plan, from
data_governance_audit.py - Weighted comparison of data platform options (TCO, time-to-value, openness, governance fit, AI readiness, vendor risk, ecosystem) with
data_platform_evaluator.py - Data org design, the CDO role question and the data section of a board deck
Out of Scope:
- Implementing data quality checks and tests (see
engineering/data-quality-auditor/) - Building pipelines, ingestion or transformation code (see
engineering/senior-data-engineer/) - GDPR compliance work on personal data (see
ra-qm-team/gdpr-dsgvo-expert/) - Security controls for data classification and access (see
c-level-advisor/ciso-advisor/)
Important Caveats:
- The tools score self-reported JSON. They do not inspect a warehouse, catalog or pipeline, and missing keys score 0 in the maturity assessor.
- Platform scores of 1-5 per criterion are your own judgments. The evaluator weights and ranks them; it does not test vendors or price them.
- A passing governance audit score is not a regulator's or external auditor's opinion. Vendor names and tooling defaults can go out of date.
References
references/data-strategy-framework.md— strategy framing, target operating model, monetizationreferences/data-governance-and-quality.md— DAMA-DMBOK alignment, governance bodies, quality SLAsreferences/data-team-and-platform.md— org design, role definitions, platform stack patterns
Related skills
c-level-advisor/cto-advisor— for the broader tech platform decisionsc-level-advisor/ciso-advisor— for data classification and security controlsc-level-advisor/chief-ai-officer-advisor— for the AI ↔ data interfaceengineering/data-quality-auditor— for the deep DQ implementationengineering/senior-data-engineer— for pipeline implementationra-qm-team/gdpr-dsgvo-expert— for personal data governance under GDPR
Output expectations
When the advisor runs, you should walk away with:
- A clear point of view (no "it depends" without a decision criterion)
- 2–4 concrete next actions with owners and timelines
- Open questions that materially change the recommendation
- References to scripts and reference docs that deepen the analysis
