❓ Who Manages Data in Your Organization? (Spoiler: It’s Not Just the Data Management Office)

In the past few months, I’ve been managing a project cataloguing data 🗃️ for our organization, helping the Data Management Office. I noticed an interesting problem:

⚠️ As IT management (focused on software) and data management diverge, a grey zone between them emerges – and that’s a problem.

At this point, every serious organization assigns:

1. 👔 Application Managers (System Owners)
2. 🧩 Software Architects (who see the bigger picture).

❓ But who owns data management for these systems?

From my view:

• ✅ Unless you designate data stewards alongside system owners, application owners are de facto data owners (aligning with DAMA-DMBOK).
• 🔀 Then, the responsibility for cataloguing data/integrations is distributed among three parties: 🛡️ Data Management Office (DMO), 🧩 Architects, and 👔 Application Managers.

I propose a ⚙️ Shared Ownership Model. In the model 👔 Application Owners:

1. 📖 Define data domains, business glossaries, and validate metadata accuracy as they know the context, understand the business meaning, quality, and usage of data within their specific applications;
2. 📝 Document source systems: including data schemas, field definitions, and changes in their systems (e.g., “What are the possible values of `customer_status`?”);
3. 🛡️ Steward data: ensure data is catalogued upon creation/modification and adheres to governance policies.

🧩 Architects, at the same time:

1. 🗺️ Map data lineage, integrations, and APIs, documenting how data flows between systems (APIs, ETL pipelines, events), including transformations and dependencies;
2. ⚙️ Enforce technical standards (e.g., naming conventions);
3. 🚀 Design scalable data flows.

🛡️ Data Management Office all the while:

1. 🏛️ Defines org-wide policies, taxonomies, and tooling;
2. 🔍 Audits compliance & quality against governance rules;
3. ⚖️ Resolves cross-domain conflicts.

🏦 Real-World Example: A bank’s 👔 loan app owner catalogues `loan_status` codes → 🧩 architect maps flow to risk analytics → 🛡️ DMO monitors via unified catalogue.

🚀 To help build effective data management process that would enhance operational efficiency, strengthen security & compliance, and help optimize costs in your IT management work:

1. ✅ Clarify responsibilities with a RACI matrix (e.g., Owners provide data details; Architects map flows; Data Stewards oversee compliance).
2. 🤖 Automate when necessary. Use automated scanners to ingest metadata from databases, APIs, and code (e.g., via OpenMetadata), reducing manual effort.
3. 🌐 Establish a Centralized Catalog (e.g., in a data mesh/mesh catalog) where: 👔 Owners tag business context, 🧩 Architects add technical lineage.

⚙️ Shared ownership approach works because:

1. 👔 Owners lack visibility into cross-system flows → 🧩 Architects fill gaps.
2. 🧩 Architects lack business context for domain-specific data → 👔 Owners provide it
3. 🛡️ Data Management office provides mandate to enforce standards, tooling to manage metadata, and culture for data management. Without 🛡️ DMO catalogues become 💀 “data graveyards”.

⚡ Some of the useful (and digital) techniques you can employ to bring technology management and data management back together are:

1. 📥 Embed Cataloging in Workflows by requiring metadata updates during SDLC (e.g., Jira integrations).
2. 🤖 Automatically capture pipeline metadata (e.g., from Airflow/DBT) to keep it relevant.
3. 🤝 Assign Data Stewards to bridge gaps between technical and business teams.

✨ In the end, the proposed model ensures catalogs remain accurate, actionable, and aligned with both business needs and technical reality. In the end shared ownership turns data management into a useful tool for both IT and Data teams while the organization gains ⚔️ competitive advantage. When IT and Data people collaborate, data becomes 🔍 findable, 🔐 trustworthy, and 🚀 actionable; accelerating AI, analytics, and innovation.