Data Governance / Target Operating Model (TOM) Lead

The Role:

Our challenge

The Role

Responsibilities:

•  Agree the taxonomy normalisation method and the metadata standard (ISO/IEC 11179)

• Establish the four boundary tests as the documented decision method: business capability rather than schema; origination beats usage; change cadence and cohesion; accountability for the business decision the data supports.

• Normalise the inventory into a canonical, FIBO-informed taxonomy with explicit boundary definitions, collapsing variants such as "Reference" / "Market Data" / "Reference / Market Data", "Equities Front Office" versus "Equity Front Office", and the several spellings of "Derivatives Operations (Reg Ops)".

• Assign exactly one accountable producing domain to every item and produce the domain-assignment matrix with written rationale (DDD context mapping).

• Resolve multi-domain and contested items through DACI. Contested artefacts, typically cross-domain stored procedures — are decomposed into origination logic held by the producer and derivation logic held as a consumer-side product; they are not shared.

• Convert the dependency and lineage map into named consuming domains and contract obligations for every UI, extract feed and downstream application.

• Draft provisional producer-consumer data contracts to ODCS, each specifying all six mandatory elements: schema and semantics; quality SLOs; freshness and availability; access and entitlement; versioning; change and deprecation.

• Define the target operating model across the four roles: Domain Owner (accountable), Data Product Owner (responsible), Data Steward (quality and metadata), Platform team (enablement, never ownership) — with a stewardship RACI that names real people or real positions

• Supply the governance plane definition into the target-state architecture: taxonomy conformance, contract registry, policy-as-code, quality SLOs and access entitlement enforced at the point of publish.

• Advise on adoption sequencing, which domains are ready to hold accountability on day one and which need an interim arrangement. 

Requirements:

• 10+ years in data governance within banking or capital markets; 5+ leading governance or TOM design at enterprise scale.

• Federated governance design experience, evidence of a model that was adopted by domain teams, not a policy set that was published and ignored. Ask for the adoption evidence.

• Domain-Driven Design context mapping applied to data domains, and working familiarity with FIBO and BIAN service domains as sources of canonical boundaries.

• Data contract standards (ODCS or equivalent) and metadata registry standards (ISO/IEC 11179).

• Regulatory grounding that makes the governance defensible under examination: BCBS 239 principles, critical data element definition and coverage, Dodd-Frank, MiFID II

• Practical facility with catalogue, lineage and data-quality tooling: Unity Catalog, Microsoft Purview, Collibra, Alation, Solidatus, Securiti.ai, Anomalo.

• Ability to write a decision rationale that will still be defensible to an internal auditor two years from now.

Preferred, but not required:

• Domain-assignment matrix with rationale (Excel; DDD context mapping)

• Refined domain taxonomy and boundary definitions (Word; DDD + FIBO)

• Target operating model for ownership and stewardship (Word + RACI)

• Provisional producer-consumer data contracts (YAML/Excel; ODCS)

•