从活动能力层建设看业务架构

一、引言

很多技术同学看到业务架构这个概念时，会觉得既熟悉又陌生。如果把业务架构一分为二，先看架构这部分，大部分人可以联想到技术架构，系统架构，分布式架构等等，这些概念对于技术同学来说都不陌生，甚至有些亲切感。但如果目光前移，落在业务上时，就可能有一种陌生感，虽然很多人在写业务代码，虽然很多人在解决产品的业务需求，但是当面对什么是业务架构时，好像有种无从下手的感觉，对其含义和作用会有很多疑问。 本文会用 Qunar 活动能力层建设的实际案例，来为大家介绍业务架构，以及揭示业务架构对于技术同学的重要性，同时案例本身也是大家在进行业务架构设计是可以参考的对象。

二、业务架构的起源和含义

业务架构(BA)概念的提出，是 TOGAF（The Open Group Archtecher Framework）方法中描述企业架构(EA)时作为企业架构的一部分出现的。企业架构(EA)之下由四部分组成：

• 业务架构(BA) 定义商业模式，业务功能，业务流程，相关利益方以及组织结构

• 应用架构(AA) 定义应用系统和各自对应的业务功能，以及它们之间的组织关系

• 技术架构(TA) 定义开发，部署，运行，运维应用系统所需要的技术选型，基础组件以及相关基础设施

• 数据架构(DA) 定义数据资产的记录方式，存储方式，使用方式，以及相关的数据管理资源

而通常我们技术同学主要工作的部分集中在应用架构和技术架构，以至于提到架构时，大家都会第一时间想到应用架构和技术架构的相关内容，也就形成了思维定式，也就是技术同学可以通过合理拆分应用，优化调用链路，改进技术方案，保持技术先进性来促进业务提升。但实际结果真的总能如人所愿吗？

三、Qunar 活动业务的现状和痛点

Qunar 作为互联网 OTA 企业，对获取新客，市场推广，维持活跃度和转化率有强烈的需求，伴随着这些需求，各种各样的活动也就应运而生，同时为了保持活动对用户的吸引力，在活动的玩法设计，交互体验，奖励丰富度和吸引力方面也要精心设计。

以机票盲盒为例，其整体交互效果和流程如下图

参照上图，活动的详细玩法如下:

1. 用户购买机票盲盒商品，成为活动的发起者，发起者可以进行发起活动来邀请好友帮忙助力来解锁盲盒可以兑换的航线

2. 收到发起者发来的活动助力分享页面的用户，可以选择成为活动的助力者，打开分享页面进行助力活动

3. 助力者在完成对发起者的活动的助力后，活动系统也会为助力者发放助力奖励，同时引导助力者购买盲盒

4. 当有足够数量的助力者给发起者助力后，发起者可以得到发起奖励，解锁更多航线，完成活动流程

如果我们抽象一下，类似盲盒活动的这类助力分享裂变类的活动流程可以如下图：

针对上面的业务需求和功能，实际采用的架构设计如下：

这套架构设计的优点如下：

• 入口层适配不同的活动入口，充分发挥门面模式的作用，起到不同入口、不同端的适配和防腐的作用，当接入新入口或者入口需求发生变化时，最大程度降低对核心运行模型的影响

• 运行层采用中台化设计，提炼抽象出了活动中台，提高内聚程度，提升代码模块复用度，提升开发效率，避免烟囱式开发，统一接入方式

• 配置层提供了实时热配置能力，实时修改活动相关配置，实时生效，提升配置效率和时效性，同时提供了活动后台配置系统，通过该系统可以实现活动免开发上线，组合复用现成的中台组件

从以上架构介绍可以看到，在已知活动玩法和流程的前提下，技术团队在架构设计上花了很多心思，分层架构风格，门面模式的运用，中台化设计思想，热发配置的基础能力，从技术工作的角度来看，技术团队做到了优秀的设计和交付，自然也期望这套技术方案能够很好地支持活动业务的运行和发展，助力活动业务达成目标。

但就像文章开头提出的疑问，上面这套技术方案设计能真正达到助力活动业务的目标吗？我们可以看下在这套技术方案落地上线之后，活动业务面对的问题和痛点。

• 痛点 1 活动业务的技术方案变更率很高，同时对于新上活动的技术工时很高

• 痛点 2 活动配置的碎片化严重，产品运用进行配置时学习成本高，配置耗时很大

• 痛点 3 活动中台对接公司各业务线活动时，对接一个活动的周期很长，出现需求堆积

• 
  

上面这三个典型痛点，对于活动业务的影响是巨大的，具体表现在：

• 每次活动类需求的整体技术成本增加，使得活动的整体收益预期降低甚至出现不能覆盖开发成本的情况，活动效果大打折扣

• 活动线上配置的风险很大，产品运营出现配置遗漏的可能性很高，影响活动效果甚至是出现故障，造成损失，同时由于高昂的配置学习成本，导致产品运营的配置时间有时比开发时间还要长，活动上线速度下降

• 活动需求堆积在活动中台，中台成为研发链路上的瓶颈，很多活动都有自身的时效性和活动窗口期，由于堆积导致活动错过最佳时机上线运行，效果大打折扣，甚至有些活动由于迟迟排不上期而不了了之

这些痛点和影响不仅使得相关的活动业务受到影响，也深深困扰着活动的技术团队，为什么我们的架构设计看起来非常合理，每部分拿出来都可以在技术层面禁得起深入剖析并不乏亮点，但为什么对于活动业务的支持仍然达不到活动业务的最佳目标。作为技术团队，我们的下一步该何去何从，从哪里入手改变现状呢？

我们首先是分析一波痛点，将问题逐一解析，找到其背后的产生原因，并思考获得架构启发，将问题变为改进的机会，这是我们不断精进的思路。

先来看痛点 1——活动业务的技术方案变更率很高，同时对于新上活动的技术工时很高

要找到解决技术方案变更率高的原因，我们需要先看下在 Qunar 产品需求到技术方案的研发流程

产品方案的来源是产品经理通过分析拆解业务诉求，形成的以达到业务目的预期的产品方案描述，内容一般包含本次产品需求的背景，目标，业务流程以及相关数据需求，开发同学基于现有活动中台的能力以及支持的更新模式，给出对应的技术方案，以满足实现产品方案的要求。经过分析技术方案变更的案例，我们发现，发生变更的案例往往是技术方案描述和产品的业务需求和业务流程相差较大，导致开发进行到一定阶段被这两者之间的差异而造成的不可解决的矛盾阻塞了，不得不重新从业务需求的角度出发，设计技术方案，并调整中台能力预期。

接下来分析痛点的另一部分，上线新活动成本高。

对于一个新活动上线，主要涉及到的角色以及各角色在过程中需要做的事情可以参考下图

从上图可以看到，在活动上线的业务流程上，存在四个环节，每个环节都需要对应的角色做相关的工作，因此一个活动上线的整体成本是包含四环节成本的总和，而在实际新活动上线的过程总，技术开发和线上运营这两个环节的成本又是占比重最大的。上面已经分析过技术变更产生的原因，但对于那些未发生变更的新活动开发案例，工时就符合预期吗？当然也不是，技术开发是基于活动中台能力制定方案和进行开发的，因此中台能力的设计是否符合新活动的上线流程以及产品的活动设计思路，会对技术方案和开发效率造成很大的影响，我们理想中的情况应该是，对于一个新活动，其上线业务流程应该如下

上面的流程的改进点在于，在原有红色的输入流程基础之上，新增了加一条绿色路径，该路径代表了另外一种更符合业务预期的流程，产品产生了活动诉求之后，通过活动中台提供的配置能力完成活动设计，然后直接进入运营配置阶段，同时当活动中台提供的活动配置能力（比如活动能力市场）不足以支持本次活动需求时，才需要开发介入，同时开发设计的技术方案也不仅仅是针对本次活动设计，而是从完善活动中台能力建设的角度进行，从而将本次活动需求当作提升活动中台能力的机会。

如果我们把痛点一的分析结果进行总结，我们可以将产生原因提炼成如下结论：

• 目前中台的复用能力不满足需求，活动需要技术接入的案例占比较大

• 活动需求相关的技术方案标准不一，面向单次活动的方案居多

• 目前中台沉淀的能力不能向上传递到产品方案层面，即技术能力不能转化成对业务需求的支持

如果我们把这次分析出来的原因当作一次架构改进的机会，那么可以给我们如下启发：

• 技术视角的中台能力不等于业务功能

• 可通过标准化方案来控制可变因素

• 技术能力向业务能力传递需要通过适配

按照上面分析痛点 1 的思路和过程，我们针对痛点 2 和痛点 3 的分析结果整理如下

行文至此，是时候引出企业架构中业务架构对于架构设计的价值了，我们上面做的事情，其实就是在填补原有架构方案中，对于企业架构中业务架构缺失的部分。

如上图所示，在企业的战略和远景的驱使之下，在技术团队可用的 IT 方案和基础设施之间，是存在 GAP 的，这个 GAP 的作用是将业务目标和期望导向落地解决方案，同时使得落地解决方案能更好助力业务目标和期望的达成。填补这块空缺的，就是企业架构，而进行业务分析和业务架构设计是落地企业架构的首要任务。

再回顾下之前的技术方案设计以及遇到的痛点，其实就是因为没有解决业务架构的空缺问题，在底层 IT 架构中再怎么下功夫，做优化，对于业务的目标达成的助力依然有限。只有意识到业务架构填补空缺的意义，并按照一定方法进行业务架构设计，才是走在了正确的解决问题的道路上。

那么，该如何进行架构架构设计呢？接下来介绍活动能力层建设的设计过程，大家可以作为一个进行业务架构设计过程的参考。

四、活动能力层建设

1、明确活动业务目标和业务逻辑

对于活动类业务，其明确的业务目标和业务逻辑可以如下图表示

解释下上图，活动业务是以用户社交链路为基础，通过为用户提供趣味性玩法，基于用户厌恶损失的心理，为用户提供额外权益，从而吸引用户参与，达到裂变拉新，拉升日活，提高转化的业务。其底层商业逻辑为，将新用户、睡眠用户和低活跃用户，通过活动重新引入 Qunar 用户池，并刺激用户池中用户的浏览行为、分享行为和消费行为，以达到业务增长的目的。

2、梳理业务流程和利益相关方

我们重新分析了活动业务的产品研发运营流程，识别出了活动的业务流程以及活动的生命周期。

一个活动诞生于基于业务目标和可行性评估的活动评估阶段，通过产品基于现有活动业务模板和本次活动的需求，完成活动的方案设计，对于通过现有活动业务模板就可以完成活动配置的活动，在进入活动研发阶段时，只需要产品的参与，若当前活动模板不能支持本次活动，则有产品和开发共同进入活动研发阶段，开发基于本次活动的特有业务需求，开发具备复用能力的新模板组件。当活动研发完毕后，进入以运营为主导的活动运营阶段，此阶段运营关注在线活动运行情况，根据业务目标和需要随时在线调整活动状态。当活动窗口期结束后，将活动数据进行归档，按需求生成相关报表，供管理层和相关业务方评估本次活动效果，进入下一个循环。

在上面的活动业务流程中，各利益相关方和关注点也就自然被识别了出来。

对于活动业务流程中涉及到的不同利益相关方，其关注点也各不相同，而我们做业务架构，就需要把这些利益相关方以及他们最关注的核心问题识别出来，设计对应的业务能力来满足要求，给下游的 IT 架构设计落地解决方案提供输入资料。

3、业务能力识别

基于上面整理出来的业务流程和各利益相关方的关注点，我们可以把业务需求进行分类，并针对每一类业务需求设计对应的业务能力。这个阶段的产出如下表：

将需求进行分类，是指导我们进行组织结构划分和边界划分的规则之一。通过对于不同类需求的优先级，重要程度以及和战略目标的关联程度，可以针对性的制定资源投入方案，目的是将最强的战斗力资源投入到最有价值的事情上。同时，可以识别出哪些需求可以采用现有方案或者现有系统支持，避免重复开发，造成资源浪费。

4、制定落地方案

识别出来业务能力之后，我们就可以基于现有团队的知识、方法、技术资源、人力资源、可利用基础设施等因素设计对应的能力落地方案了。

有了满足各项业务能力对应的落地方案之后，技术同学就可以进入开头提到的大家熟悉的环节了，做应用架构设计，进行技术方案选型，确定架构风格，选择合适的编码风格和代码规范，组织具体技术同学进行进入编码开发了。

针对这一部分整理一下，当我们要做某个业务的业务架构时，可以参考如下步骤：

1. 明确业务目标

2. 理解业务底层商业逻辑

3. 设计业务流程

4. 识别利益相关方

5. 识别业务能力

6. 确定各能力对应落地方案

以上是我们在进行活动业务架构设计过程中使用的步骤，如果大家对官方的标准过程感兴趣，可以看下 TOGAF 的 ADM 文档规范，学习了解更加完整的过程。不过就像任何其它的架构方法一样，从规范到具体落地执行，基于团队现状和业务现状进行本地化适配是避免不了的，这一点大家一定要有所认识。

五、总结

本次为以活动能力层建设设计过程为例，介绍了业务架构缺失被识别出来的过程以及如何进行业务架构设计。在总结的部分，让我们一起看下业务架构以及相关的应用架构、技术架构、数据架构的概念和在战略落地当中的位置和作用。

上面的图非常清晰地阐明了业务架构的重要位置和核心作用。同时，也展示了业务架构过程中的五要素：组织结构、业务能力、商业模式、业务流程、业务数据。大家可以回顾下活动业务架构设计过程的部分，看下我们在落地过程中围绕五要素做了哪些事情。

同时业务架构也是需要随着业务的发展和战略目标的变化而不断改进的，在 TOGAF 给出了架构开发方法(ADM)中，给出了完整的架构开发的周期过程，在这里也提供给大家作为参考。

(上图引用自 TOGAF® Series Guide Using the TOGAF® Framework to Define and Govern Service-Oriented Architectures)

这里要特别关注到中间的核心节点——业务需求。我们架构的发展要永远贴合业务需求的要求，同时当业务需求变化时，不管我们的架构工作处于周期内的哪个环节，都应该重新审视是否应该重新进入之前的环节进行架构的重新设计和改进。

本文引用了不少 TOGAF 相关的资料，也推荐大家去官网上学习一下官方文档。如果大家有在自己的团队中落地业务架构的想法，希望本文介绍的案例能为大家带来参考。