跳到主要内容

谁来干活 — 数据发现团队、归属之争与七级角色梯

这一章讲三件事: 目录为什么需要一支专职团队、这支团队的名字为什么叫「数据发现团队」; 团队挂在公司哪个部门的三种方案与各自的坑;以及所有用目录的人如何排成一张角色梯。 它回答的是第 01 章留的欠账:地图画好了,谁来看守、谁往里填、谁签字放你进门。

1. 先看现象:目录失败,很少败在软件上​

企业软件里有一类著名的失败:东西买回来了,装上了,演示很漂亮,一年后没人用了。 数据目录是重灾区。书里没有回避这一点——前言里甚至把「静态预设元模型导致灾难性实施、 成本飙升、没有回报」当作第一版要纠正的核心错误1。

失败的原因不在软件,在于目录是活的:数据源天天变、人员天天动、元数据要持续补。 没有一支团队把它当回事,它就会退化成一份过期的地图——比没有地图更糟, 因为它让人误以为「这里就是全部了」。

2. 团队与它的图纸:数据发现团队和元模型​

为什么不叫「目录团队」​

作者的建议很具体:这支团队应该叫数据发现团队, 而不是「数据目录团队」——因为名字应该说的是你交付的能力(让人发现数据), 不是你使用的工具(目录)2。

他还建议把摊子铺大一点:这支团队最好不只管目录,而是接管公司里所有描述 IT 版图的 元数据库——比如 CMDB(配置管理数据库,IT 部门记录每台机器、每个系统台账的库)、 数据共享协议系统等。理由:数据发现的完整体验取决于所有能描述数据的地方, 散落在几个团队手里,每个地方都是一道断点3。

元模型:团队的图纸​

这支团队维护着目录的顶层设计,书里叫元模型(metamodel)。注意这个词与 AI 无关: 这里的「模型」取「图纸、样板」的本义——元模型就是「目录里允许出现哪几类东西、 它们之间允许有哪几种关系」的那张总图4。

书里举的最小例子只有两类实体:部门和域。它们不是一回事:一个部门有人、执行流程、 被技术支撑,还拥有能力;而能力定义域,域把技术里的数据归拢起来5。 也就是说,元模型规定的不只是「有哪些框」,还有「框和框之间用哪种动词相连」。

判断(我们的,不是书里的): 元模型是目录版图里最被低估的一层。 它决定后面所有章的天花板——域怎么划(第 04 章)、描述往哪挂(第 05 章)、 标签贴在哪(第 06 章)、搜索能按什么栏目搜(第 08–09 章),全都踩在元模型画的框里。 作者说第一眼看到元模型「容易头晕」6,但头晕的解法不是跳过它,是把它画小: 书里强调 KG 式目录的元模型通常小而极珍贵(第 05 章会回到这句)。 如果错,会错在: 如果元模型照抄大厂模板、抄出一堆用不上的实体类型, 后面每一层都要为这些空框填数,目录会变成填报负担——这恰是前言里「灾难性实施」的一种成因。

3. 归属之争:这支团队该挂在哪​

元模型之外,还有一个组织问题:数据发现团队向谁汇报? 书里给了三个选项,并逐一标出利弊7。

挂在哪得到什么付出什么代价
数据治理部门合规稳:机密与敏感数据有人盯着,流程质量高目录被当成一笔合规开支,创新潜力被埋没
分析业务部门直接落在价值最大处:创新失控风险:没治理兜底,可能泄密、可能牺牲数据质量换速度
CDO(首席数据官,统管公司数据战略的高管)理想解:团队的参谋职能,高管的数据战略建立在实际数据上,结果可度量罕见:多数公司还没有这么一个角色8

书里的排序很明确:治理路线安全但保守,分析路线有活力但危险,CDO 参谋模式是最优解9。 把这张表和第 02 章连起来看会更有意思:AI 让目录的收益(演示、上手)更容易被高管看见10, 这恰好改变了归属之争的天平——过去目录只有治理部门愿意收留,现在分析侧和高管层也有理由要它了。

4. 三类用户:谁在用,谁交房租​

团队与归属定了,再来看使用目录的人。书里把终端用户分三类,并且直言不讳地排了座次11:

分析类用户(数据分析、数据科学、AI 工程师)。他们在目录里搜数据源,找到之后 再去数据里干活。书里称他们是最重要的用户,因为目录的回报(ROI)靠他们交付: 他们基于搜到、找到、分析过的数据做出新业务,目录的投资才有账可算12。

治理类用户(合规、安全、隐私)。他们搜目录是为了找机密数据和敏感数据,然后保护它—— 新增数据源时要过一遍,日常风险评估时也要过一遍。价值真实存在, 但书里承认:这类用户的回报很难度量,没有创新故事好讲13。

日常类用户。所有其他员工:搜一份报表、找一份战略文档、查一个 SOP(标准作业程序)、 申请某个系统的入口。书里判断这将是未来最大的用户群体——当目录真正长成 「公司搜索引擎」,人人都会来搜14。

书里补了一句组织层面的观察,值得单独记:这三类用户合起来构成一张社交网络; 当他们不需要数据发现团队居中协调、就能彼此配合时,目录的价值最大15。

5. 主走查:一次数据访问请求,沿七级角色梯走完全程​

前几章的积木(资产、域、元数据)到这一章全部有了主人。书里给目录配了一套角色梯, 我们拿一个具体场景把整条梯走一遍。

场景:你是 H&M(第 02 章那家木构建筑公司)新来的分析员,想用「需求趋势」数据产品 (它落在分析能力域下,数据源是一个具体的 Power BI 实例)做季度分析。

  第 1 步  你在目录里搜到这份资产。资产页面上挂着一份「人员名册」:
          域负责人、域管家、数据源负责人、数据负责人、数据管家、
          术语负责人、术语管家——每份资产都应有这些角色[^16]
              │
  第 2 步  你发起访问申请。注意目录的规矩:日常维护归管家,
          但「批准访问」归资产负责人——数据在谁名下,谁说了算[^17]
              │
  第 3 步  资产负责人(数据的实际所有者,可能同时管着几个数据源的数据)审批[^18]
              │
  第 4 步  域管家执行落地:他管域架构、面谈新任数据源负责人、开权限——
          琐碎但承重的活都在这一层[^19]
              │
  第 5 步  用起来之后你发现某个列名看不懂。术语管家维护着术语的生命周期
          (新增、修订、废弃),术语负责人对术语的内容负责[^20]
              │
  第 6 步  三个月后原负责人转岗。资产管家(对某一批资产最熟的人)接手补齐描述,
          访问链路换人——书里说这类交接正是目录要接管的场景之一

这张梯子有一个容易被忽略的特点:负责人(owner)和管家(steward)是成对出现的—— 负责人管「决定」(归属、审批、定义),管家管「日常」(维护、执行、修订)16。 书里把「负责人+管家」称作强制元数据:一份资产可以没有华丽的描述, 但不能没有这两类人,否则出了事没人认账17。

6. 作者的判断与证据​

书里当作经验给出的:

  • 三种归属方案的利弊表,是作者在多家企业实施目录的经验总结;他没有给出每种的失败率, 但给出了失败机理(治理路线→无人创新;分析路线→无人兜底)7;
  • 「分析类用户交付 ROI」——这是书里少有的把话说死的地方:治理用户的价值「难以记录」, 日常用户「目前还不是大群体」18。

作者的推测:

  • 「日常用户将成为最大的群体」——建立在「目录会变成公司搜索引擎」这个愿景上, 而那条愿景的展开(第 5–6 章)不在试读版里,属于未兑现的预测;
  • 「终端用户构成社交网络、自组织时价值最大」——是观察式的判断,没有附组织案例。

判断(我们的,不是书里的): 这张角色梯真正的进入门槛在第 3 步——「资产负责人审批」。 它把数据访问的决定权从 IT 部门移回了业务侧,这是目录区别于「数据申请工单系统」的根本处, 也是实施时最容易卡住的地方:很多公司能画出角色梯,却找不到愿意在资产页上署名的人。 实施目录时,先解决「谁来当负责人」再谈工具,顺序不能反。 如果错,会错在: 如果一家组织用行政命令强行指派负责人,署名会沦为形式, 审批退化为盖章——目录重新变回「IT 的库」,治理类用户之外的三类人都会离开。

7. 边界与局限​

  • 「CDO 参谋模式」罕见,书里也承认;多数读者的现实选择是在治理与分析之间摇摆, 本书没有给出折中方案的讨论。
  • 角色名称不统一。 书里提醒:各家目录产品对角色的叫法不一样(比如「数据源负责人」 在传统数据管理里叫 system owner 或 data custodian)19,换一家供应商就要对一次词典。
  • 术语生命周期、访问流程的细节被书推给了不在试读版里的章节(第 7 章、第 10 章), 本章只有骨架没有细则。
  • 日常用户场景(报表、文档、SOP 搜索)在试读版里只有展望,没有展开。

8. 可带走的​

  1. 目录是团队经营出来的,不是采购来的;失败几乎都败在运营,不在软件;
  2. 团队叫「数据发现团队」——卖能力,不卖工具;能接管全部元数据库(CMDB 等)更好;
  3. 元模型是目录的总图:允许哪些实体、允许哪种关系;它小而珍贵,照抄大厂模板必死;
  4. 归属三选一:治理(稳但保守)、分析(活但险)、CDO 参谋(理想但罕见);
  5. 三类用户座次:分析类交房租,治理类保平安,日常类是未来;
  6. 角色梯口诀:负责人管决定,管家管日常,两者成对出现、缺一不可;
  7. 实施顺序:先找到愿意署名的负责人,再谈工具——顺序反了,目录会退化成盖章系统。

9. 原文地图​

主题原书章原文位置
「灾难性实施、无回报」前言text/05-fm-preface.txt:72(搜「catastrophic implementations」)
团队命名:能力而非工具第 1 章text/09-fm-the-data-discovery-team.txt:5(搜「your data discovery team」)
接管全部元数据库、CMDB第 1 章text/09-fm-the-data-discovery-team.txt:12(搜「CMDB」)
元模型定义第 1 章text/09-fm-the-data-discovery-team.txt:19(搜「high level overview」)
部门≠域、能力定义域第 1 章text/09-fm-the-data-discovery-team.txt:30(搜「defines a domain」)
元模型令人头晕第 1 章text/09-fm-the-data-discovery-team.txt:31(搜「dizziness」)
KG 式元模型灵活、赢市场第 1 章text/09-fm-the-data-discovery-team.txt:36(搜「flexible metamodels」)
归属三选项第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:2(搜「Chief data officer」)
治理路线=合规开支第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:11(搜「expense to ensure」)
CDO 路线理想但罕见第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:14(搜「ideal, but also a rare」)
分析路线的风险第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:19(搜「risk of this」)
CDO 参谋模式最优第 1 章小结text/11-fm-summary.txt:52(搜「staff function for a CDO」)
三类终端用户第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:29(搜「Everyday (efficiency)」)
分析用户交付 ROI第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:34(搜「return on investment」)
治理用户找机密、ROI 难记第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:39(搜「Governance end users primarily search」)
日常用户是未来最大群体第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:51(搜「everyday end users become」)
报表、战略文件、SOP第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:49(搜「strategy papers」)
用户=社交网络第 1 章text/11-fm-summary.txt:14(搜「constitute a social」)
人员名册七角色第 2 章text/14-fm-organizing-data-in-the-domains.txt:89(搜「relevant persons who should be listed」)
管家日常维护与访问请求第 2 章text/14-fm-organizing-data-in-the-domains.txt:50(搜「data steward who maintains」)
数据源负责人=系统负责人第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:57(搜「system owner or data」)
域负责人定归属第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:60(搜「Domain owner manages」)
域管家面谈、开权限第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:64(搜「conducting interviews」)
资产负责人批访问第 1 章text/10-fm-end-user-roles-and-responsibilities.txt:71(搜「grants access」)
资产管家第 1 章text/11-fm-summary.txt:2(搜「Asset steward」)
术语负责人与管家第 1 章text/11-fm-summary.txt:5(搜「Term owners typically own」) · text/11-fm-summary.txt:8(搜「term lifecycles」)
负责人+管家是强制元数据第 2 章text/14-fm-organizing-data-in-the-domains.txt:42(搜「mandatory metadata」)

Footnotes​

  1. 出处:「Preface」第 72 段(text/05-fm-preface.txt:72,搜「catastrophic implementations」)。 ↩

  2. 出处:「The Data Discovery Team」第 5 段(text/09-fm-the-data-discovery-team.txt:5,搜「your data discovery team」)。原文:这告诉所有人「你交付的是能力,不是技术」。 ↩

  3. 出处:「The Data Discovery Team」第 12 段(text/09-fm-the-data-discovery-team.txt:12,搜「CMDB」)。作者建议团队接管 CMDB、数据共享协议系统等所有元数据库,并提到他的另一本书《Fundamentals of Metadata Management》(O'Reilly, 2025)。 ↩

  4. 出处:「The Data Discovery Team」第 19 段(text/09-fm-the-data-discovery-team.txt:19,搜「high level overview」):元模型是「提供目录中所有实体类型总览」的模型,并包含实体之间的全部关系。 ↩

  5. 出处:「The Data Discovery Team」第 30 段(text/09-fm-the-data-discovery-team.txt:30,搜「defines a domain」)。 ↩

  6. 出处:「The Data Discovery Team」第 31 段(text/09-fm-the-data-discovery-team.txt:31,搜「dizziness」)。 ↩

  7. 出处:「End-User Roles and Responsibilities」第 2 段(text/10-fm-end-user-roles-and-responsibilities.txt:2,搜「Chief data officer」)与第 11 段(text/10-fm-end-user-roles-and-responsibilities.txt:11,搜「expense to ensure」)。 ↩ ↩2

  8. 出处:「End-User Roles and Responsibilities」第 14 段(text/10-fm-end-user-roles-and-responsibilities.txt:14,搜「ideal, but also a rare」):CDO 模式下,高管的数据战略「建立在实证事实上,结果可衡量」。 ↩

  9. 出处:「Summary」第 47 段(text/11-fm-summary.txt:47,搜「three possible setups」)与第 52 段(text/11-fm-summary.txt:52,搜「staff function for a CDO」)。 ↩

  10. 出处:「The AI Data Catalog and as Source for AI」第 30 段(text/06-fm-the-ai-data-catalog-and-as-source-for-ai.txt:30,搜「decision makers on board」)。 ↩

  11. 出处:「End-User Roles and Responsibilities」第 25 段(text/10-fm-end-user-roles-and-responsibilities.txt:25,搜「three categories」)。 ↩

  12. 出处:「End-User Roles and Responsibilities」第 34 段(text/10-fm-end-user-roles-and-responsibilities.txt:34,搜「return on investment」)。 ↩

  13. 出处:「End-User Roles and Responsibilities」第 39 段(text/10-fm-end-user-roles-and-responsibilities.txt:39,搜「Governance end users primarily search」):「与数据分析类用户相比,治理用户的 ROI 更难记录」。 ↩

  14. 出处:「End-User Roles and Responsibilities」第 45 段(text/10-fm-end-user-roles-and-responsibilities.txt:45,搜「most substantial group」)与第 51 段(text/10-fm-end-user-roles-and-responsibilities.txt:51,搜「everyday end users become」)。 ↩

  15. 出处:「Summary」第 14 段(text/11-fm-summary.txt:14,搜「constitute a social」)。 ↩

  16. 出处:「End-User Roles and Responsibilities」第 56 段(text/10-fm-end-user-roles-and-responsibilities.txt:56,搜「Data source owner」)至第 71 段;负责人定义与管家定义并列给出。 ↩

  17. 出处:「Organizing Data in the Domains」第 42 段(text/14-fm-organizing-data-in-the-domains.txt:42,搜「mandatory metadata」)。 ↩

  18. 出处:「End-User Roles and Responsibilities」第 43 段(text/10-fm-end-user-roles-and-responsibilities.txt:43,搜「more difficult to document」)与第 50 段(text/10-fm-end-user-roles-and-responsibilities.txt:50,搜「not a very big group」)。 ↩

  19. 出处:「End-User Roles and Responsibilities」第 57 段(text/10-fm-end-user-roles-and-responsibilities.txt:57,搜「system owner」):数据源负责人在传统数据管理中「也被称为 system owner 或 data custodian」;第 43 段(text/07-fm-the-core-functionality-of-a-data-catalog.txt:43,搜「different role type names」)提醒各家目录的角色名称不同。 ↩