严选在19年年底开始体系性的建设业务中台,也是从那时候开始,我们在工作中会经常提及「边界治理」。 什么是「边界治理」?为什么「边界治理」在严选变成了一个高频词? 本文是严选业务中台系列文章的实践篇之一,主要向大家介绍「边界治理」的基本思路及实施策略。严选在19年年底发布了「严选业务中台白皮书」,开始体系性的建设业务中台,也是从那时候开始,我们在工作中会经常提及「边界治理」。什么是「边界治理」?为什么从20年开始「边界治理」今年在严选变成了一个高频词?很多同学对此有不解,也经常会有同学讨论这些问题。本文是严选业务中台系列文章的实践篇之一,主要向大家介绍「边界治理」的基本思路及实施策略,后续我们也将推出一些具体的案例来展开说明「边界问题」的识别与解决方法。斯坦福大学的教授、 Raft和Tcl的发明者John Ousterhout在2018年出版了一本书『A Philosophy of Software Design(软件设计的哲学)』引起了巨大的反响,其中有一个很重要的思想是:软件设计的核心目标,就是降低复杂性。所谓复杂性,就是任何使得软件难于理解和修改的因素,主要有三个来源:理解了这三个复杂性,也就可以理解为什么我们设计的软件总是那么容易进入到一种混乱和无序的状态,本质上是因为我们不能控制变化发生:业务不断在发生变化,技术不断在发生变化,组织不断在发生变化,人的认知也不断在发生变化。因此,John Ousterhout教授认为,降低软件复杂性的基本方法是「对复杂性进行隔离」,通过将复杂度隔离在用户看不见的地方,进而实现控制变化、隔离变化,减缓熵增。在工程实践方面,我们遵循两个核心原则,即水平架构分层及垂直领域拆分:- 水平架构分层:水平架构分层的本质是专业化分工、隔离关注点。通过合理的水平分层,使层与层之间的关系保持稳定,可以快速扩展,比如业务前台、业务中台、技术平台、基础设施层的划分就是基于这一原则。
- 垂直领域拆分:垂直领域拆分的本质是对专业领域进行精细化分工。通过领域分析的方法对问题域进行分解和抽象,使领域之间的关联更少、职责更清晰,从而尽可能将变化隔离在单一领域,比如交易、商品、用户等业务板块的划分、微服务边界的划分以及系统模块的划分都是基于这一原则。
严选引入「边界治理」的根本原因是通过水平架构分层及垂直领域拆分来隔离复杂性,避免复杂性蔓延。「边界」包括水平层与层之间的边界、领域与领域之间的边界、系统与系统之间的边界以及与之对应的组织边界,而对边界的治理过程则是我们对业务的一次系统性的梳理、审视与重构过程,将组织、领域、系统从一种「无序」「不可控」的状态变成一种「有序」「可控」的状态,而由于「熵增」不可避免,因此「治理」也将会是一个长期存在且持续发生的过程。3 怎么做现阶段严选「边界治理」的重点是领域边界治理,包括针对业务域、业务板块、产品及服务边界的治理,进而优化组织分工。另一方面,在业务板块内部,我们也会采用水平架构分层的思想,分离出能力层和运营平台层。不难理解,「边界治理」的核心挑战在于组织中各个角色能够共识业务边界。共识是一个非常复杂的分析与沟通场景,因此,我们需要统一「领域分析」的方法和「边界表达」的方法来提升共识的效率。领域驱动设计(DDD)是一种处理高度复杂问题域的设计方法,分离了业务需求和技术实现的复杂性,我们将DDD作为「领域分析」的方法论,指导业务边界划分,同时其输出物也是下一阶段工程实施的重要输入。「边界表达」方法决定了业务边界共识过程的沟通效率以及对业务边界共识成果的认知效率与认知质量,可以有效减缓腐化速度,从而让「边界治理」的价值更容易被认同。「边界表达」需要考虑完整性、准确性和可视性,有局部和全局两种表达方式:- 局部:通过结构化的信息来标识某个系统、领域的边界,如目标用户、要解决的核心问题、核心能力等等。
- 全局:通过业务架构分层及业务全景可视标识横向和纵深的边界。
这两种表达方式都已经被固化到了中台治理平台,本文对此不进行专门论述。为了更加有序的在推动「边界治理」,我们将「边界治理」划分为「理」和「治」两个阶段,确保每个阶段的策略和成果可以落地,并在这个过程中逐步培养并唤醒边界意识:在这个阶段,主要有三个核心策略:梳理业务边界、识别边界问题、识别业务能力3.1.1 梳理业务边界
梳理业务边界包含三个关键步骤「规划业务板块」、「梳理板块及产品边界」及「持续保鲜」3.1.2 规划业务板块
这部分工作主要由架构师团队(虚拟组织,覆盖所有业务研发团队)根据电商领域的专家经验,通过「自顶向下」的方式对各个业务域需要解决的核心问题进行分解,最后划分为交易、用户、营销、客服、财务、商品、库存、供应商、采购、品控、仓储、配送共计12个业务板块。这部分工作成果是严选「边界治理」以及组织分工的最基础输入,在19年底基本确定,并在后续梳理阶段进行了必要的调整。3.1.3 梳理板块及产品边界
这部分工作是边界梳理的核心,由研发团队(包括产品经理、技术人员等各个角色)根据中台团队提供的「领域分析」方法和「边界表达」方法进行边界梳理,产出业务架构图,完善板块信息、产品信息,并在梳理过程中识别「边界问题」。- 重视目标用户及问题域:梳理过程中应首先明确目标用户及要解决的核心问题,然后通过自顶向下的方法梳理核心功能或者能力;当然在实践过程中,我们也发现很多同学习惯采用逆向的方法,即先梳理核心功能再归纳要解决的核心问题,这种方法对于已经成型的产品比较有效,可以加快梳理速度,但我们依然建议,采用逆向梳理方法产出的成果,最后仍需要通过正向方法进行一次复核,避免出现拿着榔头找钉子的情况。
- 重视参与度:边界梳理过程中各个角色的参与程度对于边界准出具有非常重要的意义。虽然由于各种历史和现实原因,不少业务板块在边界梳理的第一阶段往往由核心技术人员来主导,但产品经理往往又是最贴近业务、最懂业务的人,直接影响业务板块和产品的未来演进方向,因此,边界梳理更适合由产品经理进行主导,准出环节也必须由产品经理参与
- 重视准出过程:我们为业务板块的边界梳理设置了准出环节。在梳理的第一阶段,主要由负责业务板块的研发团队进行内部准出;在第二阶段,由中台团队组织跨部门的评审会,一般由关联业务板块的架构师参加,所有原则性的评审意见都得到确认才能被准出。
经过一年的边界梳理,我们也发现有部分业务板块所需要解决的问题域还是过于复杂、不够内聚,产生了一些不必要的协同成本,因此,在梳理过程中,我们会重新审视业务板块的粒度,并进行必要的拆分与重组。比如我们将仓配板块拆分成了仓储和配送2个业务板块,确保每个板块要解决的问题域足够内聚,同时这样的划分粒度也与我们的组织分工一一对应,确保每个板块都可以由一个小型的研发团队进行维护、独立推动演进。3.1.4 持续保鲜
正如前文所述,我们并不能控制变化的发生,随着业务、技术、组织与人的认知的不断变化,这些被准出的业务板块仍然需要不断的演进才能适应业务的发展,为此,我们需要建立有效的流程和机制来减缓腐化速度:- 产品经理在需求分析阶段需要关注需求的边界,在方案设计阶段确认及修订边界
- 架构师团队对板块边界进行定期复核,板块的负责人也需要定期对板块的整体规划进行复核
3.1.5 识别边界问题
「边界问题」是指组织、领域、系统的职责处于一种不合理的形态,与理想中的完美设计存在差距。- 重复建设:这类问题在实践中可以通过审视各个领域的核心能力或者功能进行识别,如果存在重合,一般都会存在边界问题,这类问题往往都会造成极大的资源浪费和低水平的临时工程。
- 能力错位:这类问题在实践中可以通过审视各个领域需要解决的核心问题域与现有能力或者功能之间的契合度进行识别,如果存在不契合的能力或者功能,一般都会存在边界问题,出现这类问题,往往都会造成依赖链路复杂化、协同效率低下。
由于「边界问题」有极大的危害,因此我们需要在梳理过程中将这些问题识别出来,避免问题持续恶化。比如我们在梳理供应商板块边界的时候,识别了供应商与仓储、配送板块存在外仓边界问题、与采购板块存在履约和报价边界问题,这些识别出来的关键问题为下一阶段的边界问题治理提供了方向,下文也将对这个案例进行重点介绍。3.1.6 识别业务能力
基于领域分析的方法划分的业务边界,相比于功能拆分的方法,可以使边界之间的关联更少,能力更加内聚。我们建议,业务边界梳理在进入到比较深度的阶段后,应该尝试将能力层从运营平台层分离出来,从而将业务的复杂性下沉,抽象出该领域中可复用的业务能力。这部分工作也是「中台化」架构演进的重点,本文不做展开。针对第一阶段我们已经识别的边界问题,我们需结合「组织+技术+业务」现状(如业务重点发展方向、业务痛点、交付瓶颈等)选择合理的治理方案,并在业务演进、架构演进过程中稳步推进治理。- 项目制:依托于目前严选已经成熟运转的项目制,通过横向的业务项目或者技术演进项目解决这些边界问题,但需要强调的是,「并不是所有识别的边界问题都需要被治理」,在决策是否治理的时候,我们需要综合考虑长期收益和短期收益,一方面避免短视,另一方面也要避免冒进;针对边界问题治理的价值,可以从「规划的整体性」、「系统的稳定性」、「系统的可维护性与可扩展性」等方向进行挖掘
- 共识&共赢:有些人对边界治理有误解,认为对边界问题进行治理的本质是工作量转移,而事实上,完成边界治理后,往往可以形成共赢的局面,挖掘到「共赢点」可以极大地提升治理的效果、加快推进的节奏。
- 前瞻性:边界问题治理需要跨团队跨领域的协同,有时候也需要投入比较多的研发资源,但如果问题已经恶化到了必须治理的阶段,治理的成本又会成倍增加,因此,对于边界问题治理我们需要有足够的前瞻性,提前做好共识与规划,这也是第一阶段「识别边界问题」的核心价值。
2020年,严选开启了「边界治理」元年,过去两年,我们已经沉淀了11个业务板块,识别了数十个边界问题,涉及80%以上的业务板块,其中60%以上被识别的问题已经得到治理,为「中台化」架构演进夯实了基础。
但我们也要认识到,「边界治理」是一个持续的过程,我们需要将「边界」的意识融入到我们的产品研发流程中、融入到我们的日常工作方式中,希望这种转变,可以提升我们的沟通协作效率,让我们有更多的时间去思考业务、思考技术,也为用户创造更多的价值。