云计算·大数据 频道

大型 SaaS 平台产品架构设计思路

当我们去搜索“架构”,可以得到很多的架构图片,比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。

什么是架构,通常大家说架构一般指软件架构,架构是指软件的基础结构,创造这些基础结构的准则,以及对这些结构的描述。在这个定义基础上,我们可以简单理解为架构往往是对事物主体的结构性描述。

产品架构是对产品的一种结构性描述。一般可以包括前端系统、业务管理、运营管理、基础支撑等子产品或子系统,并描述各个子产品或子系统之间的关联关系。

在公司整体战略之下,需要基于公司战略等多种因素设计组织架构,组织架构影响业务架构,业务架构影响产品架构,产品架构影响技术架构。

从这个链条可以看出产品架构基于业务架构。做产品架构前,需要对业务架构有清晰的了解。

一、业务架构对产品设计的5个影响

业务架构是基于组织架构设计的,业务架构是把企业的业务战略转化为日常运作的渠道,业务战略决定业务架构,它包括业务的运营模式、流程体系、组织体系、资源分布等内容。

业务架构是一个比较专业的研究课题,技术人员一般对业务架构的关注度相对较低,更重视产品架构、技术架构。这里我们简单示例什么是业务架构,这些架构事实上影响我们的产品架构设计,如下图5-1就是其中一个业务架构设计的框架图。

业务架构图

业务架构对企业的收入模式、支出成本、客户群体、客户关系、需要的资源、关键活动,以及合作伙伴等进行设计说明。

业务架构对产品架构的影响,主要体现在以下几个方面:

1. 系统参与角色

业务架构一般会明确用户范围;营销端的参与人员,比如渠道商或代理商,大客户销售团队等;运营端的参与人员,如售后、客户成功等团队;合作伙伴的参与,如第三方合作平台等。每类角色按需设计对应的使用终端。

2. 系统运营流程

业务架构对运营流程有较明确的定义,如开户、续费、注销、变更、售前售后工单处理、库存入库出库处理、合同流程、发票流程等。这些构成SaaS平台的运营流程,是产品实现商业价值的重要手段,产品环节一般需要有相应的处理。

3. 核心价值

业务架构需要明确SaaS服务对客户带来的价值,这个价值往往需要通过产品端来呈现,业务架构的价值描述,很大程度上就是我们产品建设的侧重点。

4. 周边系统

业务架构中的合作伙伴、资源一定程度上体现出需要与产品交互的其他系统,这些“其他系统”可能是产品需要的一些基础能力(如文字识别、计算能力等)、数据(权限数据、业务数据)、流程(管理流程、运营流程)等 ,而这些能力需要合伙伙伴或者公司的现有资源中提供。这些周边系统会以各种各样的作用支撑着产品的运转。

5. 计费模式

业务架构一般会说明收入和成本模型。收入的处理过程影响运营产品的设计,如公司在线下收款,可以产品只需要控制用户账号的可用状态或有效期,如果是线上收款,就需要设计一套开通、续费的线上支付流程。有些SaaS产品还会涉及到收入和成本费用的摊销,以配合财务工作的处理,也可能需要在产品中完成此类计算。

假如所在公司没有清晰的业务架构,或者部分环节缺失怎么办?如果可以引导,我们尽量引导业务部门完善相关的环节,但有些客观情况是我们无法改变的,我们可以尝试按照现有架构,收集梳理信息,做好整体的结构设计,确保具备可扩充能力,能够满足后续需求,再根据业务各环节成熟度设计产品架构,分阶段去实现。

二、产品架构

SaaS产品架构的设计,可以考虑模块化、渐进式设计。

2.1 模块化设计

所谓模块化是指降低业务间的耦合。低耦合、高内聚是技术架构的重要设计原则,在产品端也非常值得借鉴。

模块式化设计对于系统建模、技术实现、升级迭代、业务推广都有很多帮助。模块化设计也是对最小化场景(MVP)的一种有效支撑。

SaaS产品随着公司的发展,业务范围、功能都会越来越大,而客户可能仅需要部分能力,如果功能间耦合太多,对客户的功能选择会增加限制;销售政策制定起也会受到掣肘,无法灵活组合产品进行销售,对业务推广产生一定影响。

如何做好模块化设计?

模块化设计针对有独立性、可复用的业务或功能进行抽取,包装功能集合构成产品进行推广使用,方便客户根据需要进行产品组合,模块化设计在传统软件中也非常重要。

(1)归类与抽象

需要对相似的功能或者场景进行归类然后抽象出来进行设计。在软件设计领域,越是底层的东西越容易复用,越是偏向应用端的东西,越难以复用。比如构成一套软件服务,可以有服务器硬件、应用服务中间件(比如数据库等)、各种微服务、业务流程、外部入口等,这套软件架构中,服务器硬件是处于架构底层,比较基础且通用性很强;应用入口处于架构高层级,形式相对灵活,复用性较低。在产品端也是同理,基础信息如人员、机构等属于基础信息,同一组织在不同系统中的结构大体一样,复用性强,其次是各类业务流程,再其次是业务表单。

我们要做的产品模块化设计,是针对不同用户的需求,将完成某项业务的场景进行分析、归类、抽象,抽取共性部分,做成可实现多种组合的产品形态。

(2)数据接口

系统一般由逻辑(算法)和信息两部分构成,信息又分为内容和数据;逻辑是构建软件功能的骨架,内容和数据是血肉,其中以数据尤为重要。

假如要实现软件模块化且模块之间相互独立,必须要先抛弃逻辑(实现方法),因为有逻辑就代表这两个模块谁也离不开谁,就不能称之为独立。

如果这两个模块必须要关联在一起,但又不允许它们在逻辑上互相干涉,那么最好的办法就是为它们内部包含的数据进行抽象化,形成标准化接口,以数据调用的形式实现两个模块间的互相协作。

模块化的一个特征是复用,在产品设计上复用意味着需要多种场景的结合,如果只有一个场景,就不是复用,在多个场景都需要使用的情况下,会有数据交互的需要,模块化设计就是要把共性的东西抽取出来后,提供标准接口,进行数据交互,这个共性的东西,可以是字段,也可以是规则。

大家通常理解的SDK,也是模块化设计的一种体现。模块化的产品可以是一个界面、也可以是一个功能,还可以是一个子系统。

2.2 渐进式设计

SaaS产品是逐步迭代的,产品设计也不是一蹴而就的,需要有一个不断前进的过程,渐进式设计非常契合SaaS产品。比如我们公司的产品,有企业客户、集团客户、代理商、平台运营人员、售后人员等参与,在设计系统的过程中,并不是一上来就把所有的工作全部做完, 这样周期太长,也不利于快速验证产品和市场的匹配,所以产品架构自然而然也变成了一种渐进的设计过程。

渐进式设计需要尽量考虑未来产品的全局,以满足后续产品扩展需要。

以我曾经做过的一个产品举例,产品的用户可以分为三大类,关系如下图:

图片

产品关系示例

在产品架构的搭建过程中,我们在清楚有这些基础结构以后,按照优先级顺序,逐步发展产品。如图:

图片

产品架构示例图

首先搭建了企业版产品和简单的运营管理系统,让用户能够使用起来。后来随着代理商力量的不断计入,需要为代理商设计一套管理系统,代理商系统需要依赖于公司运营管理系统(公司运营早期就已经有了代理商加入,运营管理平台只有最简单的代理商管理功能,能够标记客户所属代理商,但并没有去开发一套代理商管理系统,只是预留了扩展能力)。

随着平台的发展,用户群体不断扩大,集团客户也在不断增加,公司又基于企业版产品开发了集团版产品,满足集团企业客户的需要。

整个代理商管理系统和公司运营管理系统也跟随迭代,从最初的企业注册审核,到用户工单管理、结算续费管理、再到增加集团版的开通管理流程及结算流程,历时用了几年时间。产品整体架构经历了多个版本的迭代,才逐步变成现在的体系,并且还在持续完善中。

产品架构的渐进式设计和最小化可用产品(MVP)并不是一回事,产品架构渐进式设计是为了产品稳步推进并可扩展,先集中精力解决当前的重要需求和问题,所积累的产品成果,会成为将来产品发展的基础,而不是MVP中表示的每一个过程都可能要重构。

MVP有一个非常生动的例子,用户需求是一辆车,那么车的MVP及产品演进过程应该如下图5-5的第二部分所示:

图片

MVP的演进

产品架构的渐进式设计和产品的MVP有什么关系,其实是两个维度的事情,产品架构渐进式设计是对现在业务的快速响应,以及对未来业务扩张的支撑。

MVP是在产品迭代过程中,在不同的阶段,可能需要进行重构,上图的例子,在一些产品论坛上都有阐述,这对MVP的解释是很准确的,最小化可行产品需要做到每次迭代都是完整可用的,可用场景闭环是MVP的核心指标,这是产品从0到1的一种有效验证方式,但我认为这种重构并不一定是必须的.

很多软件产品在迭代的过程中,都是在原有基础上的扩展,实际上产品架构具备弹性和扩展性,这是一名优秀产品经理需要具备的能力,毕竟任何历史投入都是有成本的,优秀的设计应该是在原有基础上的扩展,而不是推倒重来。

B端产品在发展过程中,也比较注重产品和服务的结合,这个服务并不是指产品即服务,而是在早期产品不够完善的情况下,部分环节通过线下服务来补充,这也是SaaS产品发展的一种形式。

产品架构大体能够说清楚了系统间的关系,但对于具体的产品流程,产品架构图是无法表达清楚的,还需要辅助系统流程图进行说明。

0
相关文章