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

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

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

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

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

一、业务架构对产品设计的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产品发展的一种形式。

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