数据架构与应用架构：大而全与小而美的天然矛盾

数据架构常见两个理解误区。误区一是没厘清数据架构和业务架构的关系——传统观点认为业务架构直接承载企业战略目标、直接提供业务价值，而数据架构（和应用架构一样）只是间接为企业提供业务价值的支撑角色，因此传统数据架构工作主要集中在数据建模、采集、处理、报表开发、数据仓库建设这类偏后端支撑的工作；但随着大数据和数据中台的深入，数据正逐步从”支撑角色”变成”驱动要素”，甚至能直接驱动企业业务流程再造和业务转型——这意味着数据架构设计应该尽可能提前，最好在企业战略和业务架构建模阶段就同步规划，而不是等应用架构定型之后才补做。误区二正是把数据架构当成应用架构的附带设计（根据应用架构成果去做数据架构）——这种理解忽略了[[数据架构的核心是数据编排：定归属、控流转、促聚合|数据编排]]与应用编排之间天然的矛盾：数据架构倾向于把数据聚集起来以发挥更大效应，应用架构则倾向于分工（分工带来更高效率），一个追求”大而全”、一个追求”小而美”，二者存在结构性张力。但二者又相互影响：应用拆分时，”数据聚类”本应是判断哪些功能该放进同一个应用的重要规则之一（现实中很多人做应用拆分时仍只依靠业务流程功能聚类这一条规则，忽略了数据聚类维度）；反过来，数据流转和交换的设计也是基于应用中已经存在的数据分布去做的——所以数据架构影响应用架构，应用架构也影响数据架构，设计时必须兼顾双方，而不能把二者当成前后接力的两个独立环节。可迁移启发：应用拆分方案评审时，除了检查业务流程聚类是否合理，还应该单独追问一句”这些数据的天然聚合关系是不是被这次拆分打散了”——很多后期棘手的跨应用数据一致性问题，根源就在拆分阶段只考虑了业务功能聚类、漏掉了数据聚类这条规则。

结构图：

flowchart LR
  D["数据架构<br/>倾向:聚集数据(大而全)"]
  A["应用架构<br/>倾向:分工(小而美)"]
  D <-.天然矛盾,需要权衡.-> A
  D -->|数据流转基于应用中的数据分布设计| A
  A -->|数据聚类应是拆分的重要规则,常被忽视| D