一致性：信息流传递中"客户价值"保持不变的特性

可以把系统建设过程看作一条信息流的传递：起点是客户需求，依次经过企业战略制定、业务架构、应用架构、数据架构、技术架构设计，最后落到代码实现；每个阶段信息以不同形态呈现（企业战略阶段用PEST/SWOT/平衡计分卡，业务架构阶段用价值流/服务蓝图/业务流程图/领域模型，应用架构阶段用应用分层图/交互图，数据架构阶段用数据模型/分布/流转/集成，技术架构阶段用技术栈/部署架构图，代码实现阶段用类图/时序图/代码逻辑）。尽管展示形式各不相同，信息的本质不应该变——这个本质就是满足客户需求、为客户带来价值；一致性指的正是信息流在传递过程中保持这个本质不变的特性。有一个容易被忽视的关键点：保持一致性的检验方向与信息流的传递方向恰好相反——信息流是从客户需求往下游流向代码实现，但验证一致性时要反过来往回看：企业战略的制定要确保与客户价值一致，业务架构设计要确保与企业战略一致，应用/数据/技术架构设计要确保与业务架构一致，代码实现要确保与应用/数据/技术架构设计一致——只有实现了这条反向验证链，客户的价值才可能全部兑现。保障一致性并不容易：按照信息传递理论，每经过一个环节，信息中都会混入噪声导致失真，所以实现一致性本身是有成本的，如何以低成本方式做到一致性，是需要重点考虑的问题。可迁移启发：审视一个已完成的软件系统”是否真正为客户创造了价值”，与其从头（客户需求）往后梳理一遍所有环节，不如直接从代码实现这一端出发，反向一路验证到客户需求——这条反向链路正是一致性验证本该走的方向，也往往更容易发现”某个中间环节已经偏离了最初的客户价值”这类问题。

结构图：

flowchart LR
  C["客户需求"] --> S["企业战略"] --> B["业务架构"] --> A["应用/数据/技术架构"] --> Code["代码实现"]
  Code -.验证一致性(反向).-> A
  A -.验证一致性(反向).-> B
  B -.验证一致性(反向).-> S
  S -.验证一致性(反向).-> C