关于产品架构设计方法与核心设计原则,你需要知道这些

2 评论 3047 浏览 27 收藏 15 分钟

编辑导读:产品架构是对商业模式中核心业务场景的抽象,是整个产品的“骨架”,体现了商业模式的运作和实现方式。而对产品架构的设计是通过业务规则来建立产品的内在逻辑,是产品工作中重要的一环。本文作者根据自身工作经验,分享了一些产品架构设计方法与核心设计原则,希望对你有帮助。

一、什么是产品架构

产品架构是对商业模式中核心业务场景的抽象,体现了商业模式的运作和实现方式,产品架构设计是抽象业务场景,通过业务规则建立产品内在逻辑的过程。

二、以X产品为例介绍产品架构分层

如下图所示,首先对X产品做一个背景介绍,现在要设计一个电商平台X,目前只支持自营业务,而且一部分系统已存在(支撑后台及其服务)。

图中总共包含4部分: 应用层、服务层、技术架构层、支撑后台。其中,产品架构主要涉及的是应用层、服务层、支撑后台,技术架构层是一个简化的技术架构,添加其目的是为了展示一个全景,让大家了解一下与产品架构与技术架构的关系。

应用层和服务层体现了“小前台、大中台”的战略思想,是产品架构的核心。当然,并不是说没有中台就没有产品架构,只是这是当前主流的产品架构。如果没有中台,服务层就是单纯的API,就需要把这部分的服务能力提到应用层里,在此不做介绍。

产品架构与技术架构层的关系:

应用层、服务层、逻辑层、数据层,4层体现了技术上MVC框架的设计思想,是一个逻辑递进关系,越往底层走越偏向技术实现。

技术架构可以划分的很细,在此不做详细说明,主要介绍技术实现原理:应用层通过一次用户操作获取数据,然后通过服务层把数据传输到逻辑层,逻辑层通过代码实现的规则对数据层数据进行处理,处理完之后再反向通知到应用层,反馈给用户,这样也就实现了一次用户交互。

三、详细介绍X产品的产品架构组成

先解释下“应用层(小前台)”和“服务层(大中台)”中“大小”的意思,“小前台”其实并不是真的小,只是相对中台小而已,因为中台包含的服务特别多(如果不理解服务的意思,可以把“服务”改成“能力”),承载的业务也丰富,而不同前台产品都是有不同定位的,可能一个中台服务于十几甚至几十个产品,所以就是小前台、大中台。

那么前台到底是什么?大家应该对阿里中台战略有所了解,如果用阿里的产品矩阵来距离的话,就包含了天猫、淘宝、菜鸟物流、1688等等,但是这部分只是面向前台用户的产品,其实还有对应产品的后台,可能面向各类商家,也可能面向内部管理,这些后台对中台来说也都是前台。说白了,只要是由中台提供服务的产品或系统,对中台来说都是它的前台。

这里存在一个误区,就是很多人认为中台在前台和后台之间,那就要分清“后台”到底是名字上有“后台”,实际是一个由中台提供服务的前台,还是产品线上用于支撑该产品的后台产品。这也就是为什么“平台后台”会出现在“小前台”的原因了。

应用层包含了各种各样的前台,不同形态的产品,可能是App端、Web/PC端、H5、小程序,这些不同形态的产品可能面向2C也可能面向2B。

服务层主要包含两部分:基础服务(或者叫内部服务)和外部服务。

基础服务就是要完成X产品需要设计的服务,外部服务就是已经存在于其他产品,可以直接使用的服务(该图的内外服务不代表实际设计时的划分,要根据实际情况划分,数据中台也不是必须的,在这里占了个坑)。

服务中心提供的基础服务可以单独对应用层提供服务,也可以跟外部服务进行组合,形成一个新的服务,对应用层提供服务。

对服务本身的设计不属于产品设计范畴,但是为了能够理解产品内在的逻辑,都要对服务有所了解,这是中后台产品经理的核心能力之一,我会在后面做简单介绍。

支撑后台分为两部分:可直接提供外部服务的后台系统和支撑X产品数据流转的后台系统。

在此解释两个概念:

  • 服务产品化:当服务层的能力越来越强时,就可以把不同的服务组合,打包成一个新的产品提供给愿意为其买单的用户。图中CRM就是服务产品化的结果。
  • 产品服务化:当自身的产品做到极致,而且很多其他企业也想要拥有这种能力时,就需要把自身的能力开放出去,然后就出现了“开放平台”,这是一个典型的开放能力的产品。在开放平台里,有企业内各种各样的产品能力,其他企业可以通过对应的API获取到对应的能力,比如支付、地图,这就是把支付产品和地图产品服务化了。

四、产品架构设计方法

X产品的产品架构图可以简化成下面这样(服务中心内的内容体现了其可支撑的业务能力,在画整体架构图时可以简化掉):

根据上图来分析产品架构的设计方法(以下为一步步细化的过程):

1)确定当前产品与其他产品的关系

该产品与哪些前台产品有关系?是否涉及到建设中台服务?哪些服务是可以直接用的?哪些是需要新建的?数据是否流转到其他系统?

也就是把三层涉及的产品关系梳理出来

2)梳理涉及的业务场景与功能模块

分析产品在各个业务场景下需要什么功能支撑,此处不需要像做前台产品详细设计时分析的那么细致。

3)抽象化服务中心的边界,确认其可提供的业务能力

根据第二步中涉及的实际业务划分服务中心(也有称呼叫“子系统”或“服务领域”之类的),并把能提供的核心业务能力填充到服务中心(划分的原则后面介绍)。

4)将业务能力抽象出业务实体,转化为支持前台功能的服务

其实把前三步梳理清楚,整体的产品架构也就出来了,这一步主要是为了详细设计单个服务中心内部的架构,这一步既体现出了你对业务的理解力,也体现出了你对产品真正的设计能力。

以下以促销中心为例做分析:

先把各种方式的促销业务流程画出来,如下图所示,可以看出,前五种促销的整体流程都是一致的,只是促销的方式和条件不同。而优惠券却跟促销不同,而且流程上并不兼容,所以促销中心抽象出两个业务实体:促销活动、优惠券。

有了实体以后,最标准的基础服务就是对实体的“增删改查”,以下为促销中心的产品架构图(包含了跟其他服务中心的服务关系) ,如下图所示,什么“满减、满赠、立减”已经消失了。

通过这几步细化下来,也就对服务与服务的关系,服务与产品的关系比较明确了。这样在做产品设计时,根据实际的业务设计前台功能就行了,端到端考虑每个产品应该如何设计。

五、因产品增加导致架构变化示例

按上面的思路来分析,现在X要支持其他商家入驻到平台销售商品,而且要做一个CRM产品,就形成了如图所示的X产品体系的产品架构图:

通过图中添加的绿色字体部分可以看出,因为业务范围扩大了,所以补充了对应的商家中心,而且平台后台变成了商家后台,虽然新增了一个CRM,但是服务层并没有变化。中台在新的业务到来时在进化(增加了商家中心),而在支撑一个新的产品时中台却可以不变,因为在整体架构设计上中台已经支持了多前台,除非新的前台有特殊需求,这就体现了“小前台、大中台”的灵活性。

在此,解释另外一个概念:

SaaS(软件即服务): X产品刚开始用户量很小,但用户量大增后需要做一个新产品“CRM”用于管理用户。如果这个CRM是给平台管理全部2C用户的产品,就是一个平台级“CRM”,如果这个CRM是给所有2B客户单独管理自己的2C用户,那么这就是一个“SaaS CRM”。SaaS的关键特点是数据隔离,虽然各个商家用的同一个产品,但是不同商家的数据不共享。钉钉、企业微信都是典型的SaaS产品。

六、服务划分和核心设计原则

最后回顾一下整体架构图,来看一下服务的划分和设计原则:

1)服务重在定边界,遵循高内聚、低耦合原则

高内聚是从服务中心的业务来说的,在一个服务中心内的业务应该是相关性和依赖性很高的;而服务中心之间应该是业务隔离性比较大的,即追求尽可能的低耦合。

2)服务抽象化,尽量通用

抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。将业务能力转化成对应的业务实体就是抽象的过程,即对相同或相似的业务能力提取出共性的特征,抽象出可以提供给不同前台的公共服务,尽量做到服务通用,个性化需求由不同的前台实现。

3)可扩展性

在服务的设计时不能只满足当前业务需求,还要考虑服务对未来业务的支撑,这样可以减少未来对服务的修改。比如说对商品品类层级的设计,理论上来说可以无限层级扩展,但是考虑到前台的易用性和实际应用,不会设计很多层级也不会只有一层,而三级就能满足绝大部分业务场景了。所以在设计时也要注意另外一个原则:不过度设计。

4)可复用性

即服务可以多次重复使用,服务的抽象化程度高,可复用性也会越强。在支撑新的业务能力时,优先看是否存在可以复用的服务,如果没有,再考虑现有服务是否可以通过改造(再次抽象服务或扩展服务能力)达到这一目标,最后才考虑设计新的服务。

5)渐进性建设

渐进性的建设原则是从降低风险和实施难度这个角度出发,推荐小步快跑的方式逐步推进,而不是轰轰烈烈地推翻重来,试错的成本更低。

 

本文由 @Zurl 原创发布于人人都是产品经理,未经允许,禁止转载

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
2人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 这个图用什么工具画的呢?

    回复
  2. 如果用阿里的产品矩阵来“距离”(举例)的话

    回复