▼

       易奇科技导读：软件工程是一项复杂的项目工程，架构设计的好坏往往决定着项目的成功或失败。To B的产品人在设计一款产品时，学会搭建产品架构是一项必备的能力。这里我们来聊聊To B的产品架构如何去搭建，能让你的产品生命周期更长，更稳定。

　　“产品架构犹如房屋地基、人体骨骼、车辆核心部件。”

　　“架构”一词 早来源于建筑，其核心是通过一系列构件的组合来承载上层传递的压力。经过漫长的演变，架构设计的理念已经深入多个行业和场景，成为了必不可少的活动。

　　01 架构认知

　　1. 架构的含义

　　架构一词，从韦伯词典中定义为“一种意识过程结果的形态或框架;一种统一或有条理的形式或结构”。这里的关键部分是具有特定结构的，有条理的，这个定义很抽象，很不好理解，说人话核心我们要把握住“框架”、“结构”、“有条理”这几个关键词就好了。

　　我们来看一个例子：

　　车的骨架由车身、车架、发动机、制动设备、轮胎和电器设备等构成，这些组件构成了一款完整的车，提供驾驶服务，这些组件的好坏决定着车的使用寿命和服务体验;组件数量的多少决定着车所能提供的服务边界在哪，不是越多功能越多好，也不是只有一个车身就行，组件的 低数量是起码保证一款车能够正常使用。

　　同理，软件产品是不是也需要具备同样的逻辑，保证一款软件产品能够正常使用，满足用户诉求，解决用户的问题。

　　我们有一个不容忽视的问题，软件领域发展到今天，延伸出了企业架构、业务架构、应用架构、数据架构、产品架构、技术架构等一堆的名词。是不是有点晕了，这些架构都是用来干什么，它们之间有什么区别?不搞清楚它们之间的关系，产品架构从何谈起。

　　2. 架构之间的区别和联系

　　这么多名词，它们是如何定义的?相互之间如何区分和联系?这里做一些简单的说明，详细的解释和案例还望各位童鞋翻阅架构相关书籍。我们来看下面这张图。

　　1)业务架构

　　业务架构是指企业通过分析自身所处的外界环境，自身面临的机遇和挑战，同时剖析自身的结构特点和资源情况，明确自身优劣势，从而选择和制定企业发展目标，制定具体的实施方案和计划。

　　核心要素主要包括业务目标、资源能力、业务流程和组织结构;放在企业层面是企业业务目标，放在部门层面是部门业务目标。

　　对业务架构我们要思考一下的问题：

　　达成的目标是什么;

　　做什么业务;

　　资源和能力在哪里;

　　什么样方式在什么样的组织里做;

　　举例来说：企业采购业务的业务架构

　　业务目标：合理、合规、高效、节约的方式为集团各部门提供寻源、合同签订、订单执行等服务，保障和保本各运营业务线的运行。

　　资源能力：品类丰富、规模优势、采购模式多样，具备一定的市场话语权。

　　业务流程：以集团统管的方式，实现供应商交付，需求部门验收的上下游流程一体化的格局。

　　组织结构：建立集采、分采等采购团队，集中管控+授权自购的组织体系。

　　2)数据架构

　　数据架构是基于数据管理领域知识经验的总结，提炼指导未来数据管理的过程。

　　主要包括数据治理和数据管理，数据治理包括数据管理政策，原则，规范和标准等;数据管理包括数据总体视图和数据结构，数据库设计等。

　　下图是一张总体视图：

　　3)技术架构

　　技术架构是将数据架构和应用架构落实下去，通过技术的手段实现出来。主要包括架构规划和技术选型等事项。架构规划包括网络、平台、语言、中台、微服务等概念规划;技术选型主要是具体到某个产品时技术方案的选型，包括开源框架、语言、架构风格、数据库、中间件等。

　　我们来参考一个单个产品的技术架构方案，如下图：

　　图片来源：百度图片

　　4)应用架构

　　应用架构是描述一个企业各个相互独立的应用系统的部署以及核心业务流程之间的关系，目的是建立业务架构与数据架构和其他架构之间的关联;它能连接业务架构的流程，功能，人员，也能够连接数据架构中的数据管理和使用，还能提出对技术架构的要求。主要分为表现层、应用层和数据层来表示

　　产品架构是产品的结构，是对某一块具体业务的进行抽象，并用可视化的方式呈现出来，它划分了功能模块、数据流向，包括现有的，以及未来规划的。其目的不仅是为了架构设计的简洁性，更是为了整个业务的完整性，把离散的业务过程场景化。

　　产品架构和应用架构的关系?

　　产品架构是应用架构的一部分，当应用架构只有一个产品时，也就是产品架构。多个产品组合一起形成了企业应用架构全景图。

　　这里主要阐述如何规划产品架构图。

　　02 为什么产品架构图

　　画产品架构图目的是为了将业务架构拆解并梳理出产品思路，整体上把握产品的发展方向，把控产品的核心功能，决定了产品功能的实现路径和大体规划。当然，架构本身也是需要随业务的发展逐步的演进，具备一定的扩展性。这里阐述几条做架构的好处：

　　1)梳理产品方向和规划路径

　　这种图本身就体现了整个产品的结构，包括已实现的和未实现的，为产品的迭代指明方向，判断产品之间的依赖和关系。

　　2)为团队提供明确的目标

　　团队成员，包括，研发、测试、运营、市场和销售，能够根据这张图了解产品的规划，相应的团队可采取对应的策略。比如，研发可思考技术方案，市场和销售可制定产品的推销策略等。

　　3)建立业务全景图

　　产品规划是从业务架构中抽象出来的，反过来，可以帮助业务部门完善业务制度、和管理标准化，实现整个链条上的闭环。

　　03 构建产品架构图

　　构建产品架构图是需要产品人具备较高的综合能力，包括不限于：

　　相关的业务知识;

　　对相关成熟的商业产品了如指掌;

　　一定的技术知识储备;

　　产品战略和规划的能力;

　　抽象、归纳和结构化思维能力;

　　这里提供一个方法：6步构建To B产品架构图

　　1. 梳理用户故事，全面认识业务需求，形成业务闭环

　　不管是从0到1构建一款产品，还是1到N迭代一款产品，当新的业务场景进来时，我们先要进行用户分析和需求调研，全面的认识需求，从组织 ，用户 ，开发 三个层面考虑不同类型的功能需求、质量需求和约束条件。比如，我们看一个企业采购需求到合同签订的场景。

　　这里用户提交需求，中间经过招投标， 后才签订合同，涉及多个角色，多个业务场景，我们在分析的时候，就要全面的调研整个业务环节的用户，并记录其相应的业务诉求和现状。

　　2. 识别业务链条的业务领域以及问题域

　　用户的需求陈述可能是模糊，可能是清晰的，我们在获取用户需求后，先要判断业务领域，再识别该领域内的问题。

　　1)业务领域，是一个组织所做的事情以及其中所包含的一切。狭义上，如采购领域、生产领域、销售领域等。这里领域是采购领域，子领域是采购里的细分领域。

　　我们将上面的例子进行领域划分后，分为需求领域、招投标领域和合同领域，如下：

　　2)问题域，是指产品能够解决的所有问题的集合。架构设计是没有时间对所有需求进行深入分析，也没必要对所有的需求进行深入分析，只要抓住关键需求即可。

　　关键需求决定架构，将核心需求当前要解决的，以及未来要解决的问题归集起来，作为问题域。

　　比如，上面的例子包括不限于以下问题：

　　怎么识别该需求需要招投标;

　　招投标需求是否需要策略;

　　招投标如何制定比价模板;

　　招投标如何进行比价;

　　招投标如何进行定标;

　　合同签订有多方吗;

　　建立问题域是需要产品人具备一定的业务知识和结构化思维，可阅读相关业务书籍，比如采购，财务书籍等，提问过程可基于实际业务操作流来积累每个环节可能会出现的问题。

　　3. 画出业务闭环流程图，并拆分出初步的解决方案域

　　通过前面的调研和领域划分，基本上能够确定业务场景现有的或将来的业务流程图。业务流程图的画法，可参考相应的书籍或后续文章会单独进行分享如何画好业务流程图。

　　基于业务流程图和需求，我们需要抽象和归纳同类型事物，用更高层次来表达;比如，苹果和梨子都是水果。

　　上述案例我们基本可以得出整个流程上的初步解决方案功能。

　　4. 明确产品定位，划分好范围

　　回到定位，不要走错了路。可参考：《战略(4)：TO B产品定位，千万不要忽略这两层!》。

　　梳理完需求和业务流程以及初步的解决方案域，我们能够评估那些是当前产品或待规划产品的范围，不是当前产品定位内的需求，要果断的让另一个产品承接;比如，审批流的需求，当前产品内只能是部门内审批，涉及到外部门的审批，审批流的功能必须放在企业OA系统完成。

　　5. 架构分层

　　清晰的产品架构图至少包括这三层：

　　表现层：用户接触产品的途径;产品展示给用户的界面、风格;

　　应用层：产品的功能模块划分、数据流向、接口集成;

　　数据层：产品的数据存储方式;

　　在进行产品架构分层时，我们可以采用自上而下的方法分别对展示层、业务逻辑层和数据层进行信息分类和排版。在信息分类时可以使用金字塔原理将每层核心信息尽量完全穷尽，相互独立。

　　分层之前需注意以下几项：

　　明确不同信息层 的边界：架构的层 表达有一定的信息流转逻辑，同一层 的上下信息流转要一致

　　明确同一层 的子模块边界：同一层 不同模块的边界要清晰，模块之间要做到可独立开发和部署

　　明确产品边界：产品边界要清晰，明确区分不同产品的颜色

　　1)表现层

　　主要是用户的接触渠道，用户通过这个登录使用产品功能，获取相应的服务，一般可分为PC端和APP端。

　　2)应用层

　　这个层将具体的功能进行分类组合成模块单元，先将大的模块填充，再将大模块下的功能点填充。

　　模块和功能的颗粒度如何界定?

　　模块的划分颗粒度可参照业务领域模型来划分，比如招投标领域的业务功能点归类到招投标模块，合同领域的功能点归类到合同模块;

　　功能点划分颗粒度可采用面向对象方法的实体颗粒度或者按完成某一项业务工作事项，比如，立项这个功能点，就是按采购员要完成发标前立项要做的工作任务来划分。

　　颗粒度大小没有明确标准，只要能表述一项工作任务即可。

　　另外，一些主数据，用户，组织架构，消息组件，日志管理、接口服务等服务能力可单独放在支撑层或者作为应用层的一些基础数据也是可以。

　　3)数据层

　　这里主要是描述产品主要的数据存储数据库和存储方式。比如，涉及到结构化数据一般存储在Mysql，sql server等关系型数据库;涉及到文件，可能一般存储在对象存储。

　　图中的1、2、3对应的是表现层，应用层和数据层的功能和逻辑划分，大家可以参考;这里就没有把技术架构相关的内容放上来了，特别是涉及到中台、微服务划分，均没有体现，比如，IAAS层，PASS层，SaaS层等。

　　5. 信息流转和产品规划

　　产品架构图除了表达核心功能之外，还需将信息流转的路径标识清楚，比如图中的标识4;

　　另外，我们需将产品功能的实现情况通过不同颜色标识出来，比如，绿色代表功能已上线，黄色代表功能需优化，灰色代表功能是规划中。

　　如果你的产品是0到1，那么也可以标识出1.0版本做那些功能，2.0版本做那些功能，3.0版本做那些功能，有一个相对清晰的展示，这才是 终的产品架构图。

　　如下图：

　　 后，构建产品架构图是产品经理一项必备的能力，To B的产品结构相对较为复杂，除了考虑产品本身功能场景外，还需考虑集成系统之间的数据交互和接口交互。

　　这里给大家分享了架构是什么，为什么要做产品架构，以及6步法构建一款B端产品架构图，接下来我们就是要找机会去练习，去感悟。

　　知道的是知识，做到的是能力，能够构建自己的体系才是大咖!

　　你认为好的产品架构图是什么样的?