转载

中台之上（十二）：如何快速设计业务架构？

之前介绍过，应用业务架构模型可以快速对新需求进行企业级分析，那就讲一个实际发生过的例子供大家参考。

以前做企业级项目的时候，曾经接到一个紧急设计业务架构方案的通知。由于当时公司还处于企业级转型项目的施工期间，所有业务需求都要经过业务架构分析，出具业务架构方案，再落实到具体项目组。鉴于当时有 50 多个项目组同时施工，这样的企业级分析过程是非常必要的。

该需求是与某宝合作的实物贵金属在线销售业务，当时，另一家竞争对手与某互联网巨头刚刚合作了此类项目，受市场形势所迫，必须快马加鞭，紧急施工。所幸业务部门已经连夜写出了业务需求，需求共计 15 页，将近 9000 字，涉及 11 个大的需求项，要马上根据业务需求文档形成业务架构方案。

需求的主要内容包括：为客户建立虚拟账户，用于记录客户买卖交易、持仓等；支持使用某宝黄金发送红包（黄金份额）；红包的账务性处理、红包资金的支付结算及划转；支持黄金实物兑换；支持黄金转赠；销售数据提取、报表统计、实物提取配送数据交互以及相应的核算规则等。

当时公司早已经完成了企业级的业务架构和业务模型建设，并使用模型驱动企业级开发近四年时间，工具使用已经没有问题。公司的企业级业务模型包含上百个组件和数十个大型应用，其中，该需求所属的业务领域自己包含十余个应用，业务活动近三十个，任务超过一百多个，涉及多个核心组件及公共类支持组件，需求牵涉的只是其中一个应用。在有业务架构和业务模型的情况下，业务架构人员的工作就是识别新业务流程与原有业务流程的差异，以判断涉及的模型范围，包括识别出需要使用的活动、任务、涉及的组件，以及需要新增那些内容，新增的应该归属给哪个任务和组件，进而，应用架构人员会根据分析结果给项目组指派具体承接的需求。当然，这不是简单的对号入座，架构设计最重要的就是理清结构和关系，要说清楚各部分的具体分工和协作，给出明确的设计理由，否则，项目组会质疑任务分工。

经过对文档的仔细研读，最终理出了“签约”、“产品查询”、“交易（含红包）”、“对账”、“结算费用”这几个主要工作流程，涉及 9 个现有业务组件，现有业务模型基本支持该需求的实现，部分任务需增加业务规则。

业务架构关系图如下：

大致流程和组件分工描述如下：

签约。客户向某宝提出建立购买我司贵金属的合约申请，某宝将相关信息及客户在某宝的 PID（客户在某宝的身份标识）传给我司，由于一个客户可能有多个 PID，因此需要分别为其建立账户，该过程的处理，由我司与某宝新增的渠道负责信息传输，客户信息及客户关系组件负责识别是否应为我司新增客户，记录客户在某宝的 PID 信息，并与我司客户信息进行关联；XX 交易组件则负责为每个 PID 建立单独的交易合约和账户。考虑到未来可能与某宝有更多产品合作，因此，PID 应该在客户信息组件作为企业级信息管理，方便各组件查询并保持唯一性。
产品查询。产品信息由产品目录的统一管理平台——产品研发组件负责提供；报价涉及 7*24 小时实时人民币黄金报价，并允许在账户金报价、金交所报价、交易对手报价等各个报价来源之间切换，允许买入价、卖出价、中间价等多种形式报出，因此，由投 X 与 XX 交易组件支持的企业级定报价平台负责。
交易。交易涉及贵金属买卖和对红包转账的支持，由 XX 资金交易组件负责账户金交易、贵金 XX 组件负责实物金交易、运营 XX 组件负责库存和配送管理，核算由财会组件完成，都有现有业务活动和任务可以支持。
对账清算和手续费扣收。这两项都由 XX 资金交易组件基于交易记录发起，清算结果和扣收都是在某宝在我司的存款账户和内部账户之间转账完成，也有基础的业务活动可以支持。
报表。报表由于都是基于该组件的交易记录，因此可以由该组件负责提供支持。

上述方案从阅读需求到设计，再到跟领导请示汇报，发出方案，总共花了四个多小时。因为会议紧急，所以方案出的也比较简要，只搞了一页 PPT，其实，这样也不错，如果一页 PPT 能说清楚问题，干嘛非得搞上一大堆文稿呢？这方面敏捷宣言非常值得赞赏。

这个方案的制作过程体现了以下几点：

对原有业务架构和模型的充分复用。方案最终只是在原有的业务模型中增加了部分步骤和规则，就一个抽象业务模型而言，不需要再增加活动、任务这些较大的元素了。
模型化的业务架构工具对企业级需求分析的加速作用。该方案涉及的客户信息管理、交易、核算、运营配送等，都是由不同业务条线负责管理的，是典型的企业级方案，由于有模型化的架构分析工具，就能够快速识别需求的归属，并为跨条线的协调提供客观依据。
业务架构师必须经常熟悉项目情况。该方案能够快速形成也得益于刚刚完成的产品设计重检工作，设计者对模型与实施之间的实际映射情况非常了解，方案设计乃至后续项目组对分工的接受都很顺利。由于分工的原因，企业级业务架构师可能会与项目之间有一定的“距离”，因此务必时刻注意补充自身对项目的了解，防止“距离”变成“疏离”。

由于之前业务上已经准备了较为详细的需求文档，因此业务架构设计工作少去了一些了解过程，但是，从上面的例子可以看出，如果业务架构人员从需求梳理就开始介入，也可能会进一步提高需求分析的效率，推动一种基于业务模型的敏捷过程。所以，一开始建立企业级业务模型一定会是一个漫长的过程，因为要处理大量的标准化整合，也会触动一些深刻的利益关系，一旦完成了这个过程，建立了企业级业务架构，就可以向敏捷过程看齐，这种有企业级参照的敏捷过程，好于没有“篱笆”的快速开发，有清晰的边界总是开发人员愿意看到的。看似“笨重”的业务模型方法，其实提供了一个“扎实”的下盘，如同练武术一样，没有扎实的马步，怎么能够“飞檐走壁”呢？

中台和组件化一样，都是通向快速响应的方式，单就快速响应而言不能简单比较孰优孰劣，基于企业级业务架构的组件化设计，其实优势还是在于有效连接战略与开发，实现上下贯通的一体化设计，这方面不是单纯追求中台的技术实现可以获得的。

中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”

中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？

中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素

中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路

中台之上（五）：业务架构和中台的难点，都是需要反复锤炼出标准模型

中台之上（六）：如何为一个商业银行设计业务架构？

中台之上（七）：不神秘但很麻烦的业务架构落地过程

中台之上（八）：企业级业务架构的实现需要不断沟通和调整

中台之上（九）：如何基于企业级业务架构管理业务需求？

中台之上（十）：业务架构设计“笨重”，它能跟敏捷沾边吗？

中台之上（十一）：企业级业务架构设计的“五难”