当我们去搜索“架构”，可以受到众多的架构图片，比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。
什么是架构，通常大家说架构一般指硬件架构，架构是指硬件的基础构架，创造这种基础结构的准则，以及对这种结构的表述。在这个定义基础上，我们可以简洁理解为构架往往是对事物主体的结构性表述。
产品架构是对产品的一种结构性表述。一般可以包含前端系统、业务管理、运营管理、基础支撑等子产品或子平台，并描述各个子产品或子平台之间的关联关系。
在公司整体战略之下，需要基于公司战略等多种原因设计组织架构，组织架构影响业务架构，业务架构影响产品架构，产品架构影响技术架构。
从这个链条可以看出产品架构基于业务架构。做产品架构前，需要对业务架构有清晰的知道。
一、业务架构对产品设计的5个影响
业务架构是基于组织构架设计的，业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包含业务的营运方式、流程机制、组织制度、资源分布等内容。
业务架构是一个非常专业的研究课题，技术人员通常对业务架构的关注度相对较低，更加强产品架构、技术构架。这里我们简单例子什么是业务架构，这些架构事实上制约我们的产品架构设计，如下图5-1就是其中一个业务架构设计的框架图。
业务架构图
业务架构对企业的利润模式、支出费用、客户群体、客户关系、需要的资源、关键活动，以及合作伙伴等进行设计说明。
业务架构对产品架构的制约，主要表现在下面几个方面：
1.系统参与角色
业务架构通常会确立用户范围；营销端的参与人员，比如渠道商或代理商，大用户销售团队等；营运端的参与人员，如售后、客户成功等团队；合作伙伴的参加，如第三方合作系统等。每类角色按需设计对应的使用终端。
2.系统运营流程
业务架构对营运流程有较明确的定义，如开户、续费、注销、变更、售前售后工单处理、库存入库入库处理、合同流程、发票流程等。这些构成SaaS平台的运营流程，是产品实现商业价值的重要方法，产品环节通常必须有相应的处理。
3.核心价值
业务架构必须确立SaaS服务对用户带来的价值包装技术协议，这个价值通常必须借助产品端来展现，业务架构的价值描述，很大程度上就是我们产品建设的侧重点。
4.周边系统
业务架构中的合作伙伴、资源一定程度上表现出必须与产品交互的其它平台，这些“其他系统”可能是产品必须的一些基础素养（如文字辨识、计算能力等）、数据（权限数据、业务数据）、流程（管理流程、运营流程）等，而这种能力应该合伙伙伴以及公司的现有资源中提供。这些周围平台会以各类各样的功效支撑着产品的运转。
5.计费方式
业务架构通常会表明收入和费用模型。收入的处理过程影响运营产品的设计，如公司在线下收款，可以产品只应该控制客户账号的只用状态或有效期，如果是线上收款，就必须设计一套开通、续费的线上支付流程。有些SaaS产品都会涉及到利润和成本价格的折旧，以配合财务工作的处理，也或许应该在产品中完成这些计算。
如果所在公司没有清晰的业务架构，或者个别环节缺失怎么办？假如可以鼓励，我们务必引导业务部门建立相关的环节包装技术协议，但有些客观状况是我们能够颠覆的，我们可以尝试根据现有架构，收集梳理信息，做好整体的构架设计，确保具有可扩展能力，能够满足后续需求，再依照业务各环节成熟度设计产品架构，分阶段去谋求。
二、产品架构
SaaS产品架构的设计，可以考量模块化、渐进式设计。
1.模块化设计
所谓模块化是指减少业务间的耦合。低耦合、高内聚是科技架构的重要设计方法，在产品端也十分值得借鉴。
模块式化设计针对系统建模、技术推动、升级迭代、业务推广都有众多帮助。模块化设计也有对最小化画面（MVP）的一种有效支撑。
SaaS产品随着公司的演进，业务范围、功能就会越来越大，而用户或许仅应该部分能力，如果功能间耦合太多，对用户的用途选择会降低限制；销售制度建立起也会得到掣肘，无法灵活组合产品进行销售，对业务推广形成一定制约。
如何做好模块化设计？
模块化设计对于有独立性、可复用的业务或用途进行抽取，包装功能集合构成产品进行推广使用，方便用户按照需要进行产品组合，模块化设计在特色软件中也十分重要。
（1）归类与抽象
需要对相同的用途以及画面进行归类以后抽象出来进行设计。在硬件设计领域，越是底层的东西越容易复用，越是倾向应用端的东西，越无法复用。比如构成一套工具服务，可以有服务器软件、应用服务中间件（例如数据库等）、各种微服务、业务流程、外部入口等，这套工具架构中，服务器软件是进入架构底层，比较基础且通用性很强；应用入口进入架构高层级，形式相对灵活，复用性较低。在产品端也有同理，基础信息如人员、机构等属于基础信息，同一组织在不同平台中的结构大体一样，复用性强，其次是各种业务流程，再其次是业务表单。
我们要做的产品组件化设计，是对于不同客户的意愿，将完成某项业务的场景进行探讨、归类、抽象，抽取共性部分，做成可推动多种组合的产品形态。
（2）数据接口
系统通常由逻辑（算法）和信息两个别组成，信息又分为内容和数据；逻辑是建立工具功能的骨架，内容和数据是血肉，其中以数据尤为重要。
如果要推动工具模块化且模块之间互相独立，必需要先放弃逻辑（实现方式），因为有逻辑就代表这两个模块谁也离不开谁，就不能称之为独立。
如果这两个模块必需要关联在一起，但又不允许它们在逻辑上相互干涉，那么最好的方法就是为他们内部包括的数据进行抽象化，形成标准化接口，以数据读取的方式推动两个模块间的相互协同。
模块化的一个特点是复用，在产品设计上复用意味着必须多种情景的结合，如果只有一个画面，就不是复用，在多个画面都必须使用的状况下，会有数据交互的还要，模块化设计就是要把共性的东西抽取出来后，提供标准接口，进行数据交互，这个共性的东西，可以是字段，也可以是规则。
大家一般理解的SDK，也是模块化设计的一种表现。模块化的产品可以是一个界面、也可以是一个功能，还可以是一个子系统。
2.渐进式设计
SaaS产品是逐渐迭代的，产品设计也不是一蹴而就的，需要有一个不断前行的过程，渐进式设计十分迎合SaaS产品。比如我们公司的产品，有企业用户、集团客户、代理商、平台运营人员、售后人员等参与，在设计平台的过程中，并不是一上来就把所有的工作全部做完，这样周期太长，也不便于迅速验证产品和行业的匹配，所以产品架构自然而然也成为了一种渐进的设计过程。
渐进式设计必须尽量考虑将来产品的全局，以满足后续产品扩展需要。
以我当时做过的一个产品举例，产品的客户可以分为三大类，关系如下图：
产品关系示例
在产品架构的构建过程中，我们在知道有很多基础结构之后，按照优先级排序，逐步发展产品。如图：
产品架构示例图
首先搭建了企业版产品和简单的运营管理平台，让顾客无法使用出来。后来随着代理商力量的不断计入，需要为代理商设计一套管理平台，代理商系统必须依赖于公司营运管理平台（公司运营初期就早已有了代理商加入，运营管理系统只有最简单的代理商管理用途，能够标记用户所属代理商，但并没有去研发一套代理商管理平台，只是预留了扩展能力）。
随着系统的演进，用户群体不断缩减，集团客户也在不断提高，公司又基于企业版产品研发了实业版产品，满足集团企业用户的应该。
整个代理商管理平台和公司营运管理系统也跟随迭代，从最初的企业注册审核，到客户工单管理、结算续费管理、再到降低集团版的开通管理步骤及核算流程，历时用了几年时间。产品整体架构经历了多个版本的迭代，才逐渐成为目前的机制，并且还在持续推进中。
产品架构的渐进式设计和最小化可用产品（MVP）并不是一回事，产品架构渐进式设计是为了产品逐步完善并可扩充，先集中精力解决当前的重要需求和难题，所累积的产品成果，会变成未来产品发展的基础，而不是MVP中表示的每一个过程都可能要重构。
MVP有一个特别生动的举例，用户需求是一辆车，那么车的MVP及产品发展过程需要如下图5-5的第二部分所示：
MVP的演进
产品架构的渐进式设计和产品的MVP有哪些关系，其实是两个维度的事情，产品架构渐进式设计是对这次业务的迅速响应，以及对将来业务扩张的支撑。
MVP是在产品迭代过程中，在不同的阶段，可能必须进行构建，上图的事例，在一些产品论坛上都有体现，这对MVP的解释是很确切的，最小化可行产品必须做到每次迭代都是完整可用的，可用场景闭环是MVP的核心指标，这是产品从0到1的一种有效验证方法，但我觉得那种重构并不必定是需要的.
这些工具产品在迭代的过程中，都是在原有基础上的扩充，实际上产品架构具有韧性和扩展性，这是一名优秀产品经理应该具有的素养，毕竟任何历史投入都是有利润的，优秀的设计需要是在原有基础上的扩展，而不是推倒重来。
B端产品在演进过程中，也非常重视产品和服务的结合，这个服务并不是指产品即服务，而是在初期产品不够健全的状况下，部分环节通过线下服务来补充，这只是SaaS产品发展的一种方式。
产品架构大体无法说知道了平台间的关系，但针对具体的产品流程，产品架构图是能够表达清楚的，还必须辅助平台流程图进行说明。
本文由@原始森林原创发布于人人都是产品经理，未经许可，禁止转载
题图来自，基于CC0协议
