当今时代，数据已成为国家基础性战略资源和企业重要的生产要素之一。用数据说话、用数据决策、用数据管理、用数据创新已成为企业经营管理者的普遍共识。但“企业都有哪些数据、这些数据都在哪里”，成为企业数字化转型的首要问题。
上一篇文章：数据治理系列①|概念篇：数据架构&数据模型&数据目录，你分清楚了吗？，我们已经对数据治理过程中很多抽象、易混淆的概念进行了详细讲解，从中我们知道了“数据架构=数据模型+数据流向”，且数据架构是企业数据的总蓝图，这篇文章我们就来看看如何开展数据架构设计。
数据架构的设计思想
美林数据基于多年的项目实践经验总结形成了『基于IRP的数据架构设计方法』，核心是自顶向下基于业务过程梳理出业务活动的输入输出表单/数据，用于识别与梳理企业数据实体；自底向上主要是理清数据流向关系的过程，体现为数据分布地图和流向地图、实体之间的关系等。
实际操作过程中，主题域模型的设计（主题域的划分）、概念模型的设计（实体的识别与实体关系）、逻辑模型的设计（实体增加属性及关系）、数据流向设计，也是依据业务开展，这也符合企业架构设计的方法论，只不过大部分企业在进行数据架构设计初期就有了一定的信息化建设基础，可以利用已经建设的系统内容，对正向的设计过程进行补充和完善。
说明:
DAMA中也提到，企业的数据模型既可以采用自上而下，也可以采用自下而上的方法构建。自上而下是从主题域开始，先设计主题，再逐步设计下层模型。而自下而上，主题域是基于现有逻辑数据模型向上提炼抽象而成。通常推荐两种方法相结合来共同完成企业数据模型的设计工作。
数据架构的设计步骤
依据这个思路开展企业数据架构设计，我们可以按照主题域划分、数据实体识别、逻辑模型设计、数据流向梳理四个步骤开展工作，如下图所示：
需要说明的是：
1） 数据架构的设计，需要业务架构的业务流程作为输入，通常参考企业的相关体系文件并以开展实际业务流程咨询的方式开始；需要强调的是，以设计企业数据架构为目的的业务了解，并不是为了将企业的业务流程全部梳理一遍，而是识别和理解业务活动环节中输入和输出的数据。所以，企业业务流程手册/流程卡片等不是数据架构设计的关键产出，而是数据架构设计的关键输入。
2） 数据架构的设计，核心包括主题域划分、数据实体及关系、逻辑模型及关系、数据流向梳理4部分产出物。这里的数据流向，其实偏重架构设计层面的数据在主题域之间的流向，如果企业的业务没有变革，业务流转关系没有变革，通常数据架构中数据流向内容也是稳定的，它是一种顶层设计。
3） 而数据在业务系统之间的流向，主要用于后续业务系统的建设与集成打通，是不是必须在数据架构设计阶段产出，这没有标准的定义，可以在数据架构阶段产出，也可以在应用系统建设阶段产出。应用架构层面需要说清楚业务系统间的数据流向，而且这个阶段，因为业务系统的表单字段是明确的，所以需要梳理出表单级别、字段级别的数据流向（直接指导业务系统间的数据集成落地），而不是停留在实体在业务系统中的流向。
4）也有同学会说，客户要求我们输出“数据在业务部门之间的流转关系”，这是项目边界和项目的个性化诉求，也不是企业数据架构设计的核心产出物；其实客户关心这个问题的本质是，希望打通各部门之间的业务贯通与协作，这部分诉求最终也会落到业务系统的集成上解决。
5） 数据架构的设计，不仅仅是信息部门的职责、也不应该依赖于咨询公司完成，一定要组建一支企业业务骨干参与的数据组织来开展此项工作。华为的信息架构包括企业主题域、概念模型、逻辑模型、数据分布（数据流）、数据标准的定义，信息架构是连接业务和IT的桥梁，强调其设计主体是业务人员，而不是IT人员。
“ 第一步：主题域划分 ”
企业的概念数据模型是由主题域模型结合而成。主题域的识别须在整个企业模型中保持一致，基于业务价值链或者基于业务能力形成主题域。
方法:
DAMA中提到：“基于顶级流程（业务价值链）或者基于业务能力（企业架构），考虑数据治理、数据所有权问题，形成主题域”。
通常需要以企业的业务流程规范和体系文件作为输入，在企业没有体系文件或者体系文件比较老旧的情况下，我们通常建议从企业的业务价值链入手。将企业的生产经营活动划分为既相互独立又相互联系的多个有价值的环节，形成从外部/内部需求输入、到企业内部运营活动、到成果交付的一系列价值增值活动和相应流程的核心企业主业务价值链条。基于主价值链及企业各职能支撑板块可提炼得到企业一级主题域，再参照企业组织架构及职能职责、企业各类业务系统功能菜单（目的是相对全面地了解企业业务范围）进行一级主题域的补充及二级主题域的划分。
华为信息架构的5层模型中L1主题域分组、L2主题域直接沿用流程架构的L1流程分类、L2流程组。
要点:
-
大部分的制造企业在进行一级主题域划分时，通常按照战略层、运营层、支撑层三个维度进行总体分层。华为信息架构是按照“价值流程”、“使能流程”、“支撑流程”进行的总体分层，是与华为的业务架构匹配的方式。没有标准的对与错，主要是契合本企业的业务架构现状即可。
-
主题域的划分，通常划分到二级即可。较为复杂的业务板块，可以考虑划分到三级，核心是要能够支撑后续数据实体的识别及归属判断，又便于未来数据的查找及使用。主题域的划分颗粒度要能考虑未来在相对大的业务范围内，使得确定的数据实体、逻辑模型、数据标准等达成一致，并能够服务于未来的企业业务贯通。如果主题域划分得过细，可能出现实体、逻辑模型、标准等各细分领域定义，不能通盘考虑与之关联的业务环节的情况，对业务贯通不利。
-
各主题域识别的原则是不交叉、不重叠、不遗漏，要能说清楚各主题域涵盖的业务范围。
示例:
示例：主业务价值链
示例：某制造业一级主题域划分
“ 第二步：数据实体识别 ”
概念模型是用一系列相关主题域的集合来描述概要数据需求。概念数据模型包括给定的领域和职能中基础和关键的业务实体，同时也给出实体和实体之间关系的描述（DAMA）。概念模型以数据实体及其之间的关系为基本构成单元的模型，是对主题域模型的进一步细化。
方法:
正向的，数据实体识别主要从业务流程卡片的输入、输出数据中提炼，实际落地过程通常采用业务维度和技术维度结合的方法开展，互为补充。
-
业务维度：从业务活动、业务部门的主要职能职责中梳理业务活动办理需要的输入、输出信息，识别出各主题域下的数据实体；
-
技术维度：参考业务系统中正在流转的表单/视图，对系统库表梳理，识别各业务办理相关的数据实体。
要点:
-
实体的概念是实体识别的重要依据。实体是客观存在并可相互区别的事物，实体应包含描述性信息。数据库设计中讲到“一个规范的数据表就是一个实体”，如产品基本信息、产品质检信息、产品退货信息等。
-
实体的关系也是概念模型的内容之一。在两个实体之间的关系中，基数说明了一个实体和其他实体参与建立关系的数量。基数由出现在关系线两端的符号表示，基数只能选择0、1或多（“多”是超过“1”个的意思），方向的每一方都可以有0、1或多的任意组合。
-
值得注意的是，业务流程中使用的表单、系统中办理业务的单据，不能直接等同于实体。如ERP中供应商信息，包括供应商基本信息、供应商银行账户信息、供应商的资质信息、供应商的评价信息等等，此时建议不能只识别一个实体，而需要把供应商基本信息、供应商银行账户信息、供应商的资质信息、供应商的评价信息分别识别为一个实体，而且他们之间存在着一对一、一对多的关联关系。
-
实际落地过程中，还会遇到一种情况是，相似业务的相似表单，是不是应该抽象为一个实体，还是应该穷举各业务分支识别出多个实体。比如，某企业有上千种请购单，是按照物料分类划分的，此种情况下，是否要识别出A物料请购单、B物料请购单……或P部门的请购单、Q部门的请购单……，因为不同物料的请购单信息是不一样的。通常情况下需要分析不同的请购单不同的信息是什么，是不是有共性的信息，比如哪个部门因为哪个令号（任务号）需要什么物料、需要多少、提请日期、提请人、具体物料的描述信息、物料是否有指定的供应商、物料是否需要到货检验、按照哪种标准进行检验等等，我们试着抽象出以下实体：请购单基本信息（日期、人、部门、令号）、物料需求明细信息、物料供应商信息、物料质量检验信息，而且请购单基本信息实体关联了其他三个实体。
-
实体的识别可能存在颗粒度粗细的问题，没有标准的对与错，可以根据实际的业务情况，取相对合适的粒度即可。因为太细有很大的梳理成本和管理成本，太粗又会出现交叉、覆盖的情况。通常来讲，当企业的业务相对一致时，实体数应该相对不变。
示例:
示例：实体清单
示例：实体关系
“ 第三步：逻辑模型设计”
逻辑模型是对概念模型的进一步分解和细化，该步骤需要对实体进行关键数据属性补充，描述更多业务细节。逻辑模型通常包括的关键数据属性，不是全部的实体和全部的属性。关键数据属性，是指如果缺失，企业业务将无法运转。
逻辑数据模型不受任何技术或特定实施条件的约束，它通常是从概念模型扩展而来。
在关系逻辑数据模型中，通过添加属性来扩展概念数据模型。属性通过应用规范化技术被分配给实体，每个属性和它所在的实体的主键都有非常强的关系。维度型逻辑数据模型是维度型概念数据模型的属性透视图。关系型逻辑数据模型捕获业务流程的规则，维度型逻辑数据模型捕获业务流程运行的状况和性能等。
方法:
1、属性识别，也是采用业务分析与IT表单分析相结合的方式。
-
业务维度：结合企业各业务环节创建、流转、使用数据的需求，梳理各实体应具有的属性。通过“如果缺失，企业业务将无法运转”来判断是否有缺失。
-
IT维度：参考线下使用的单据、业务系统中的表单等，辅助模型设计人员（以业务人员为主）识别办理此业务需要的关键属性。
2、指定实体的键
-
键属性有助于从所有实体实例中识别出唯一的实体实例，键可以是单独的一个属性，也可以是多个属性。
-
非键的属性用于描述实体实例，但是无法唯一标识该实例。
示例:
示例：逻辑模型
“ 第四步：数据流向梳理 ”
数据流向用于描述数据如何在业务流程和系统中流动。端到端的数据流向包含了数据起源于哪里，在哪里存储和使用。数据流向的梳理，也需要基于业务活动的流程及信息的流转关系确定。
方法:
梳理数据流向，需要了解和掌握主题域内部各项业务上下游的协作关系\流转关系，最直接的输入仍然是业务流程或者流程卡片，基于业务流，明确数据在哪里产生，在哪里使用，确定数据的流向。
要点:
-
梳理过程中，我们通常会纠结：数据流向梳理应该到哪个颗粒度，是梳理一级域之间的流向还是二级域之间的流向？这个取决于当前梳理数据流向到底要解决什么问题。
-
如果企业已经建设了多个业务系统，主价值链及支撑业务已差不多覆盖，此时的数据流向梳理最直接的价值是解决业务系统集成，打通数据实时流转的问题，通常梳理到一级主题域层面就可以；因为再往二级主题域梳理，多半是某个业务系统内部的业务流程贯通，基本上菜单间数据集成的方式就可以解决后台的数据流转诉求。
-
如果企业主价值链流程待建、本次数据架构设计也是作为企业顶层架构规划，则通常需要梳理出二级主题域之间的流转关系，能为将来某个业务系统的建设提供依据（此时仍然需要关注一级主题域之间的数据流向，因为新建的业务系统仍然需要打通集成；二级主题域之间的数据流向，可以根据实际项目情况定，因为大部分市面上的业务系统是带业务的成熟套件，需要二次开发的数据流向关系需要梳理确定）。
示例:
示例：主题域间流向
示例：系统间流向
以上四个步骤完成后，数据架构设计工作就完成啦。
但，数据治理工作可远不止此，后续还有数据标准制定、数据质量整改、数据指标梳理、物理模型设计、平台落地等工作需持续开展。
下期我们来聊聊如何制定企业数据标准~~~敬请期待~~~
【纯干货分享，10年项目实战经验】