业务架构关注的不是找到“正确的答案”，而是确保提出的是“正确的问题”。业务架构通过结构化或模型化的方式来理解和组织业务问题，从而为目标客户创造价值。
“对齐”是业务架构最基本也是最重要的作用。对齐就是业务架构能够准确体现战略意图，确保所构建的业务能力与战略目标保持一致。
企业战略相当于是业务架构的“指南针”，而价值流则相当于是业务架构的“主动脉”。
业务架构在企业中最终构建了一个“业务与技术共同的语义空间”：既能够向上承接战略方向，又能够向下对接业务条线的垂直执行，起到承上启下、协同聚力的作用。
业务架构的目的是为业务和技术人员提供统一的理解和指导，如果让人“看不懂”，自然也就“落不了地”。
在现实中，业务架构的应用很不理想，很多时候并不是因为架构师缺乏企业级视角，或者不具备跨条线设计的能力，更多是因为方法论层面过于复杂、难以落地。
智能原生企业架构（IEAF）重点优化了业务架构的建模过程，将业务架构划分为三个层次，每一层对应着不同的抽象级别和设计视角。
一、价值层
包含业务领域和价值流。这是业务架构的顶层设计，聚焦于价值交付，回答的核心问题是：“应该为用户创造什么价值？”价值层设计了两个元素，也就是业务领域（及子领域）和价值流。
1、业务领域 / 子领域划分
业务领域 / 子领域与价值流这两个元素的设计往往是交叉进行的，没有绝对的先后顺序，但最终目标是价值流设计。
业务领域是企业某类核心能力的集中体现，通常对应一个独立的产品或服务。业务子领域则是对业务领域进一步细化的结果，通常按照关键业务环节或职能部门维度进行划分。
子领域不建议拆得太细。一是因为“领域”或“条线”这个词是业务与技术共用的术语，划分时要考虑业务的理解，粒度越小越容易不一致；二是如果子领域拆分过细，微服务粒度也容易拆得过小。
2、价值流分析
价值流是一系列能够为客户创造价值的活动集合，涵盖了从用户产生原始需求，到最终产品或服务实现的全过程中的增值环节。
价值必须由目标用户来定义，而不是以生产者为核心。“面向价值流”设计，实质上就是“以用户为中心”的设计。
价值流中的“流”字，意味着各个活动之间要能够流动起来。
价值流的本质，可以概括为两个核心要素：价值流 = 用户导向 + 价值流动。
业务架构设计中通常以产品或服务为单位来构建价值流。
二、能力层
包含业务能力和业务流程两个元素。这一层会细化价值流，明确支撑价值交付的服务能力及其业务流程，回答的核心问题是：“我们需要哪些能力来实现价值交付？”
1、业务能力设计
业务能力是对价值流中具体活动的进一步细化和展开。为了实现价值流中每一个活动的“价值输出”，需要明确支撑这些活动的业务能力有哪些。
业务能力的呈现方式，通常可以采用“服务蓝图”来表达。每一个业务能力的背后都对应着一个业务流程。
在服务蓝图中，只需要将该流程的发起者（即流程的触发来源）作为利益攸关方（Stakeholder）列出来即可。通常还会标注该业务能力所依赖的系统现状，以便后续评估系统关系和边界等。
2、业务流程创建
业务流程图是对服务蓝图中业务能力的进一步细化和展开。从业务视角来看，业务能力其实是业务流程运行起来之后的一种外在表现，而流程图则揭示了这个能力背后的具体执行过程。
在服务蓝图中，我们强调利益攸关方应是业务流程的发起者，而业务流程图的作用，正是清晰地展示出服务蓝图中每一个发起主体所对应的具体操作路径。它通常由一系列任务和流转关系组成，呈现出业务是如何一步步被推进和完成的。
业务流程图，是后续进行应用架构和数据架构设计的重要基础模型。在绘制业务流程图的过程中，有三个关键点值得关注：数据流要清晰标注、避免过度细化流程、端到端流程要分层展示。
三、组件层
包含业务组件和业务实体。这一层对业务流程进行原子化拆解，定义支撑业务逻辑的服务组件及其关联的业务实体。回答的核心问题是：“我们需哪些组件与实体来实现服务能力？”。
业务组件和业务实体是后续应用架构和数据架构的重要输入。业务组件涉及微服务的模块化拆分，业务实体是从业务视角出发得到的实体模型。
以上图中的“基金产品设计”业务流程为例，从中可以分析出来的业务实体主要包括产品需求、产品模版和产品信息等。
上面这个业务架构的设计过程就是目前实践中最常用的一种方法，采用自上而下的设计过程：从业务领域、价值流设计出发，到业务能力、业务流程的设计，最终识别出业务组件和业务实体。这种方法的抓手其实是流程。实际上价值流也可看作是一种高阶的流程。微服务的划分通常基于业务流程中的操作“断点”进行切分，中台能力的提炼也依赖于在流程中识别并抽象出可复用的公共业务能力。
