业务架构 – 跨领域的统一语言

作者：朱如梦

领域驱动设计的起点一般是企业启动了一个软件项目，该项目对应的整个业务范围就是领域（Domain）。在战略设计阶段，设计人员需要识别核心域/子域，并进一步识别限界上下文以及上下文之间的关系，然后进行领域建模。业务架构设计的起点一般是企业战略。例如：某个以直销为主的企业提出“渠道优先”战略，目标是用3年时间将渠道销售收入的占比从当前的20%提升到80%。业务架构人员需要对这一战略目标进行影响评估，即评估新战略对企业究竟意味着什么。在这一过程中，业务架构人员需要评估哪些价值流会受到影响，支撑这些价值流的业务能力中有哪些存在差距。通过分析找到对战略实现最重要且差距最大的价值流和业务能力，并在此基础上规划项目或项目组合。

战略目标-价值流-能力-项目组合/项目-领域-核心领域/子领域-限界上下文（bounded context）-领域建模

不难发现，业务架构的重点恰好是DDD战略设计的起点，二者之间必然存在某种联系。然而，探讨业务架构与领域驱动设计的关系有何意义呢？在众多的DDD实践中，由于领域专家参与不足等原因，设计人员在战略设计上投入的精力要远远小于他们在战术设计上投入的精力，这可能导致辛辛苦苦开发出来的软件无法支撑企业战略，很快被弃用。而在为数不多的业务架构实践中，由于缺乏与IT有效衔接的方法和机制，业务架构的输出只能停留在PPT上，无法落地。如果能够把业务架构和领域驱动设计结合起来，一方面强化DDD实践与战略的衔接，另一方面为业务架构找到落地的方法和途径，应该是一件很有价值的事情。

1. 业务架构有什么用？

首先，让我们通过一个虚拟的案例来了解下业务架构有什么用。

Taste Coffee是一家传统咖啡店（后简称TC），从创立至今已有接近50年历史。这个月TC刚刚启动了一个软件项目，希望实现产品的线上销售。该项目团队采用领域驱动设计方法。为了更好地理解TC成立“实现线上销售”软件项目的背景，让我们回到半年前，也就是TC的管理团队刚刚启动新一轮战略规划的时间点。

TC作为咖啡店中的“百年老店”，一直以有竞争力的选址和优雅的环境吸引消费者。但是，随着人们消费习惯的改变，越来越多的年轻人不愿意在分秒必争的早上抽出10分钟去店里买咖啡，而是希望在地铁上就能够通过手机下单，到公司楼下时外卖员就已经把咖啡送到自己面前了。为了满足消费者“在线下单外卖”的诉求，TC管理团队决定拓展线上销售业务。他们给自己设定了一个小目标，就是在一年内实现线上订单金额占总订单金额的比例达到50%。起初他们有2个选择，一是开发自己的APP，二是跟互联网平台企业（如饿了吗、美团等）合作。经过反复权衡，TC管理团队决定选择后一种方式，即跟互联网平台合作拓展线上销售业务。

消费者述求：在线下单+外卖
战略目标：线上订单金额占总订单金额的比例达到50%
战略举措：跟互联网平台企业合作，实现线上销售

战略一经确定，就轮到TC的业务架构师登场了，他的工作就是对这项新战略进行影响评估，也就是要搞清楚跟互联网平台合作拓展线上销售对整个TC来说意味着什么？哪些方面存在不足？哪些方面必须调整？等等。
如何理解“影响评估”呢？打个比方，有人想在自家楼顶修建一个游泳池，为了把这个想法变成现实，通常他需要找一名建筑设计师，基于最初的建筑图纸进行全面、专业的评估，包括整个建筑的结构、承重、管线布局等等，并给出结论：能不能在顶楼修建游泳池，具体建在哪个位置，是否要对整个建筑进行加固，相应的管线布局是否需要调整，等等。如果没有这样的评估结论，恐怕没有哪个施工队敢接这个活儿。

同样，任何战略都是对企业这个运行中的复杂系统进行变更，如果认为线上销售只对销售业务有影响，就好像以为在楼顶修建游泳池只要做好防水就行了，这样的想法是非常危险的！

现在我们了解了对战略进行影响评估的重要性，那么业务架构师要如何进行影响评估呢？就好像建筑设计师做评估需要建筑图纸，业务架构师也需要一套业务架构资产，或者叫业务架构蓝图。假设TC已经有一套基线版本的业务架构资产了（这些资产是如何设计出来的，将在“2. 什么是业务架构”中进行阐述），业务架构师将在此基础上进行影响评估。他发现，与互联网平台合作拓展线上销售主要影响3条价值流：

销售产品：以前客户在店里买咖啡，一手交钱一手交货，不需要派送；现在仍有一部分客户在店里下单，但另一部分客户会通过互联网平台下单，后者代收货款并负责派送。因此，需要进一步分析新战略对渠道管理和派送管理两个业务能力的影响。
生产产品：以前像是三明治、蛋糕这类产品都是装在盘子里或纸袋里提供给客户的，现在则需要在生产环节就进行包装、保鲜等处理，待收到客户订单时才能直接派送。因此，需要进一步分析新战略对产品包装能力的影响。
财务结算：以前TC只需要付款给供应商，而现在TC还需要从互联网平台收款，同时给互联网平台支付服务费，财务结算业务变得更复杂了。

在进一步分析支撑财务结算价值流的业务能力时，TC的业务架构师遇到一些困难。一开始他把收款、付款作为两个业务能力，正好对应应收（AR）和应付（AP）两个业务部门，将来可以规划为2个方案包，分别实现应收和应付的自动化。但有人对此提出了挑战，认为收款和付款之间本来就有很多共性，如果规划两个方案报分别实现自动化，可能会导致重复建设。

经过讨论，双方都认可“收款”和“付款”是2个行为，行为一定能归结到对象上，因此应该先找到收款和付款行为背后的对象，才能设计出与之匹配的业务能力。经过与相关领域专家反复讨论，他们最终达成一致：财务交易（Financial Transaction）、款项（Payment）和财务科目（Financial Account）才是收款和付款背后的对象：

TC跟互联网平台收款，意味着一笔款项（如：20万）被计入收入科目；
TC向互联网平台支付服务费，意味着另一笔款项（如：2万）被计入费用科目；
对应上述2笔会计分录，却只发生了1笔财务交易，即互联网平台从20万的货款中扣住了2万的服务费，将剩余的18万转账给TC。

这样，财务交易管理、款项管理和财务科目管理就是财务结算价值流下的3个业务能力了。他们不仅能够支撑TC与互联网公司之间的双向结算，还可以用在销售产品价值流中，支撑TC跟客户之间的收款或退款业务。通过上述分析，TC的业务架构师给出了“实现线上销售”的项目规划，其中包括3个子项目：实现客户在线获得产品、优化部分产品的生产流程，以及实现财务结算自动化。其中，实现财务结算自动化子项目又可以分为3个方案包，即财务交易方案包、款项方案包和财务科目方案包，分别实现3个业务能力的自动化。

可见，在将战略转化为项目的过程中，业务架构师站在整个企业层面进行设计，不局限于部门或项目的边界，有助于合理地规划项目，确保项目对准战略，同时减少项目间可能存在的重复建设。

业务架构的作用在于衔接战略与执行，合理规划项目，确保项目对准战略，同时减少项目间可能存在的重复建设。

2. 什么是业务架构？

在上面的案例里，我们了解到业务架构师是如何将战略转化为项目的，但并没有解释什么是业务架构、如何开发业务架构资产。事实上，很多人对业务架构都有一种说不清、道不明的感觉。因此，在讨论业务架构与领域驱动设计的关系之前，有必要澄清一下业务架构的一些基本概念。

简单地说，业务架构就是对业务的结构化表达。至于什么样才算“结构化表达”，BIZBOK给出了一个更加具象化的定义，即“业务架构呈现全面的、多维度的业务视角，包括：业务能力、端到端的价值交付、信息和组织结构，以及这些业务视角之间的关系，以及它们与战略、产品、政策、项目和Stakeholder之间的关系。” 下图是BIZBOK的业务架构模型，其中内环四个是核心元素，即Capability（业务能力）、Value Stream（价值流）、Information（业务概念）和Organization（组织）；外环是六个扩展元素，即Strategies（战略）、Initiatives（项目）、Metrics（指标）、Products（产品）、Policies（政策）和Stakeholder（干系人）。

本文重点介绍四个核心元素。

2.1 Information（业务概念）

业务概念是将现实世界中的人、事、物进行抽象，并映射到数字世界的一种载体，核心是“抽象”。这里的抽象不是过程抽象，而是本质抽象。例如：产品需求要评审，合同条款也要评审，但“评审”不是业务概念（而是一个操作），“产品”和“合同”才是业务概念。

业务概念的作用在于确保语义的一致性。例如，不同业务领域都存在“需求”这个术语。销售人员所说的需求与开发人员所说的需求可能非常不一样，前者一般是指客户面临的问题或挑战（wants and needs），对象是客户；而后者一般是指产品需求（requirement），对象是产品。在一个需求管理相关的软件项目中，如果设计人员不能准确区分这两个概念，可能导致大量无效需求进入开发环节。而这恰恰是业务概念要解决的问题。

2.2 Capability（业务能力）

把一个业务概念和与之相关的操作（或行为）封装起来，就成了业务能力。这里的操作不是指增、删、改、查之类的数据库操作，而是真实业务中对业务概念的操作。例如：员工（Human Resource）是一个业务概念，与之相关的操作包括员工权限管理、员工绩效管理、员工薪酬管理、员工风险管理、员工偏好管理，等等。业务能力的作用在于模块化。它描述业务“做什么”，同时屏蔽了业务要“怎么做、什么时候做、谁来做”等细节，从而大大提高了共性、稳定性、可复用性。

正如前面案例中提到的，无论是TC给互联网平台付款，还是反过来互联网平台给TC付款，其本质都是对款项、财务科目和财务交易这3个业务概念的操作。最常见到的对业务能力的误解，就是把业务能力等同于“技能”。例如，可以说面试是招聘人员的技能，但不能说面试是一个业务能力，因为面试过程中涉及到很多业务概念，以及围绕这些业务概念的很多操作（即业务能力）：

面试的候选人是一类员工，对应Human Resource Management能力；
候选人具备某种技能，对应CompetencyManagement能力；
候选人面试的是某个岗位，对应Job Management能力；
面试是以面对面或电话会议的方式进行的，对应Conference Management能力；
面试前需要发送信息给候选人，告知对方面试的时间、地点等，对应Message Management能力；
安排面试本身是一个任务，对应Work Management能力；
面试过程中需要遵从一些公司内外部的政策，对应Policy Management能力；
……

2.3 Value Stream（价值流）

价值流描述企业为谁（即Stakeholder）提供什么价值，相当于企业级的业务用例。价值流把企业当黑盒，屏蔽了如何提供价值、有哪些场景、内部如何分工协作等细节，聚焦为谁、提供什么价值。例如，当我们分析TC有哪些价值流时，就要把TC当作一个整体（黑盒），客户希望从TC获得产品，那么客户就是Stakeholder，获得产品（Acquire Product）就是一条价值流。相对来说，“线上下单”就不是一条价值流，因为无论是线上下单还是面对面下单，客户的诉求是获得产品，如果可以不下单就获得产品，客户也会很开心。除了“获得产品”，开发产品（Develop Product）、获取原材料（Acquire Materials and Assets）、生产产品（ManufactureProduct）、优化库存（Optimize Inventory）、执行营销活动（Execute Campaign）等等都是价值流。与执行层面的业务流程相比，业务流程会随着时间的推移发生变化，但价值流非常稳定，无论是50年前还是今天，“获得产品”作为一条价值流都不存在任何变化。一条价值流可以细分为几个价值流阶段。以“获得产品”价值流为例，可以细分为生成订单、确认订单、交付订单、客户接收产品这几个阶段，每个阶段交付明确的价值项，这些价值项汇总起来，最终交付一个完整的价值，即“获得产品”。无论客户获得产品的方式发生了多么大的变化，这条价值流以及每个价值流阶段所交付的价值项是不会改变的。

价值流的作用在于分离关注点。企业是一个运行中的复杂系统，分析复杂系统的关键在于能不能将其“切片”，即把一个复杂系统切分成若干个简单系统。价值流就是把不同Stakeholder的关注点（Concern）梳理出来，就好像把一堆杂乱无章的电线梳理成一条一条的电线，这样就方便于找出问题到底出在哪条电线上。

2.4 价值流与业务能力的CrossMapping

看完业务能力和价值流，我们再来看看二者之间的关系。如果说价值流描述了“动态的”业务，那业务能力就是描述“静态的”业务，二者体现了业务的不同维度，它们之间没有因果关系，只有相关关系。例如，不能说“客户管理”能力是由“获得产品”价值流决定的，因为“财务结算”价值流以及其他很多价值流都会用到“客户管理”能力。

价值流和业务能力之间的相关关系体现为，在每个价值流阶段下匹配业务能力，业务能力使能价值流实现价值。以TC的“获得产品”价值流为例，客户提出需求阶段，肯定需要客户管理、产品管理能力。如果客户是通过互联网平台提出需求，则还会涉及伙伴管理能力。为及时通知客户订单处理的进度，还需要消息管理的能力。通常，价值流阶段需要匹配到L2甚至L3的业务能力，这里为了简单起见，仅仅匹配了L1的业务能力。

2.5 价值流对应子域，业务能力对应限界上下文

看到这里，可能您已经发现，价值流与业务能力的关系与领域驱动设计中的子域与限界上下文的关系非常相似。如果从问题域和解决方案域的角度来审视，可以认为价值流体现的是问题域，即实现线上销售涉及哪几个方面的问题；而业务能力体现的是解决方案域，即哪些业务能力才能支撑价值流实现上述价值。同样，在领域驱动设计中，子域体现的是问题域，限界上下文体现的是解决方案域，那么能否认为价值流就相当于子域、业务能力就相当于限界上下文呢？我们尝试用领域驱动设计的方式重新表述一下前面的业务架构分析结论：

获得产品、生产产品、财务结算三条价值流分别对应三个子域，其中获得产品子域是核心域，生产产品和财务结算是支撑域；
获得产品子域包含客户管理、产品管理、消息管理、伙伴管理等限界上下文；
生产产品子域包含订单管理、产品管理、原材料管理等限界上下文；
财务结算子域包含订单管理、财务管理等限界上下文。

可见，价值流对应子域，业务能力对应限界上下文，将业务架构的分析结论匹配到领域驱动设计的战略设计阶段中也是完全成立的。

2.6 Organization（组织）

组织作为业务架构四个核心元素之一，与通常意义上的组织结构类似，只是业务架构不局限于企业内部的组织结构，而是着眼于企业所处的生态，把企业内部组织和外部伙伴在一个模型上呈现出来。组织在业务架构中的作用恰恰在于，时刻提醒我们，组织只是业务架构中的一个维度，不是全部！

业务概念、价值流、业务能力等其他业务架构元素必须以独立于组织的方式描述业务，跨越组织壁垒往往是业务架构人员面临的最大挑战。在过去三年笔者从事业务架构工作的过程中，不止一次地遇到这样的场景：业务架构师向某业务部门领导汇报能力框架，领导发现某部门没有体现在业务能力框架上，于是要求业务架构师修改，最终汇报通过的业务能力框架与组织结构一一对应。不仅如此，将来一旦组织结构发生调整，业务能力框架必然要跟着调整。整个过程完美印证了“康威定律”！这样的业务能力看似每一个都有明确的业务Owner，实际上已经丧失了独立性，完全违背了业务架构所强调的“全面的、多维度的业务视角”，也不可能在战略到项目的转换过程中发挥任何作用。因此，在开发业务架构资产时，应该尽可能地避免受到组织结构的影响。

2.7 小结

用一张图总结业务架构核心元素之间的关系：

业务能力使用并修改业务概念
组织拥有业务能力
业务能力产出Outcome
业务能力使能价值流阶段
价值流细化为价值流阶段
价值流交付价值主张
价值流阶段交付价值项
价值项汇聚为价值主张
Outcome实现价值项

医生在诊断患者的病因时，脑子里一定有一套“人体结构图”，包括血液循环系统、消化系统、神经系统等等。头痛可能是因为呼吸系统感染引起的，也可能是因为神经系统出了问题。在制订解决方案前，医生必须要做出全面的评估，才能确认问题出在哪里，避免“头痛医头，脚痛医脚”。同样，企业面临各种内外部变化，要快速响应这些变化，这就必须有一套“企业结构图”，从业务概念、业务能力、价值流、组织等不同维度描述企业的业务，以及各维度之间的关联关系。相当于为物理世界中的企业在数字世界建立模型，从而帮助企业在此基础上进行变化的影响评估。这就是业务架构。

业务架构资产是一套企业级的统一语言，它从不同维度为企业建模，并描述各维度之间的关联关系。

3. 业务架构与DDD战略设计的关系

当我们说业务架构时，其实隐含了两个层面的意思：一是把业务架构当名词，即业务架构资产，或者叫业务架构蓝图，它把企业当作一个运行中的复杂系统，从不同维度对企业进行建模；二是把业务架构当动词，即基于业务架构资产进行战略影响评估，正如前面TC案例中所描述的，任何战略的调整都可能对企业产生整体的影响，业务架构有助于全面地评估战略带来的影响，从而合理地规划项目，避免不必要的重复建设。下图描述了作为动词的业务架构是如何在企业战略制订到实施的过程中发挥作用的，业务架构主要在What阶段发挥作用：