第1部分 写在开篇前的话（碎碎念）

作为一名有不多经验的产品经理，回顾所经历的产品设计内容，大多数时候是基于团队已建好的系统模型框架来进行产品设计，产品工作也主要以原型设计和体验设计为主。
我记得第一次负责一个0到1产品项目，当时直接用团队已有的用户角色和权限架构（简称组织树），产品1期也因为工期短、用户需求90%及以上实现，受到了业务一致好评。但在产品2期时，由于有不同层级、同一个层级不同的用户（多以B端用户为主）需要访问系统，组织树已有的菜单级账号权限已不太能满足普遍性的使用场景，也使我意识到自己在产品设计上还存在很多不足，有更多的知识需要我去学习、更多的经验需要我不断的去摸索。
刚好最近又一次踏上了找工作的旅程，在招聘岗位中有要求到懂B端产品架构、数据流转逻辑等。借助本次“空闲”时光完善下自己的产品基本功，有利于找工作，也有利于今后自己的职业专业性。
本篇文章主要以产品架构设计为主，后续会不断学习和整理数据流转相关内容。
产品设计的三个阶段：架构设计（建立产品骨架、确定内在元素）、原型设计（描绘产品轮廓，定义功能逻辑）、体验设计（打扮产品形象、优化使用流程）[1]。

第2部分 架构设计

通常情况下，在开始准备做产品设计之前，我们需要或者已经知道“做什么样”的产品，在职场上产品的来源大致有以下3个渠道：（1）老板（leader）想做的产品，idea来自老板；（2）甲乙方项目类产品，idea来自甲方提的需求；（3）你是老板、或者阅历很丰富的产品总监，idea来自自己的经验、市场调研分析等。
所以，接下来讨论的架构设计思考维度是在已有“做什么样”的产品基础上进行的讨论与总结，如有描述或引用不当的地方，也欢迎各位产品前辈多指正。

1. 架构设计4个思考维度

产品的架构设计主要有4个思考维度，依次为：范围、分层、框架、数据/流程，通过该逻辑可以不断锻炼自己从宏观到微观的产品架构思考能力，也是先收敛再不断发散的过程。

1.1.范围

范围维度主要思考一个产品主要涉及哪些系统，从而界定产品“是什么”、“不是什么”的问题[2]。
举个例子：
假设有如下市场背景：X市政府为更好地关爱儿童健康成长，通过早期筛查、健康干预关注儿童高质量成长，特联合市内各幼小中学校、健康管理第三方机构为X门店搭建儿童健康管理系统。
我们需要做的产品是：设计一套为3-17岁幼儿及青少年提供即时的健康监测和报告解读服务的产品。
服务的用户有：X市政府相关监管人员（监管）、各幼小中学校负责人（运营）、健康管理第三方机构对接人（运营）、X门店运营人员（运营）、儿童和家长（实际消费用户）。
所以基于以上分析，我们可以先确定需要什么样的系统，是B端、还是C端，若是B端是需要BS模式还是CS模式；若是C端是需要APP、小程序还是H5链接。如，对于监管人员和运营人员，我们通常会为其设计PC端系统（关于是采用BS模式还是CS模式，会在第2个思考维度“分层”中进行详细描述），通过侧重功能和数据可视化展示来满足业务需求；对于实际消费用户，我们需要考虑到用户操作的便捷性、页面交互的友好性，则通常会考虑C端APP或小程序设计（关于APP和小程序的优缺点，相关产品面经上会有很多详细的介绍，大家可以按需搜索查阅）。
其次，在已确定的系统方向上，明确需要哪些具体的系统。如，对于监管人员登录的系统则除了看到自己的信息外，还需要看到自己所管控的运营平台数据，即需要监管平台系统；对于运营人员只需要看到运营相关功能，即需要运营平台系统，在运营平台系统的设计中，由于我们还需要对接第三方机构，则需要考虑双方数据对接问题，常见的对接方式有H5链接、API对接等；同时，需要对所有系统的数据、账号权限负责，则需要超级管理平台系统。

1.2.分层

在确定组成产品架构的的系统有哪些之后，需进一步思考每一个系统的组成。
思考每个系统如何组成时，先不要思考具体功能和技术是什么，而是对系统进行分层。系统的分层通常分为五层：系统层、数据层、业务层、框架层、表现层（这里可以结合用户体验的五个层面进行交叉了解）[3]。其中，各层主要做的事项如下：

• 系统层（产品的系统层次结构）：产品模式（BS模式/CS模式，用户角色、权限）、产品形态（功能、场景）；
• 数据层：数据元素、数据关系（集合、线性、图形、树形）、数据结构、数据字典；
• 业务层：业务模型、算法公式、功能流程；
• 框架层（原型）：导航、频道、页面、模块；
• 表现层：交互体现、视觉界面。
  分层的意义在于每一层由不同人员负责，如业务层产品经理负责、技术层技术架构师负责，各人员协调沟通。

1.3.框架

在我们对系统进行分层思考后，需要思考系统具体是由哪些功能模块组成，在该层面中需要明确每个系统模块之间如何通过不同的数据进行连接。
这里常常我们会通过产品框架图、技术框架图、数据框架图进行展示。
在实际的工作中，产品框架图由产品经理负责，技术框架图一般由架构师或者后端开发人员负责，数据框架图产品和技术均可。

1.4.数据/流程

在思考每个框架图之后，需要对每个模块进行进一步的拆解，这个层面的拆解主要从流程上进行深入的思考。
按照流程思考是最接近现实中的场景，也是最容易理解的部分。
通过对产品流程的思考，来思考具体产品时怎样使用和运行。

基于以上4个架构设计思考维度，作为产品经理，通常我会在PRD中确定的是：（1）本次上线涉及到的系统有哪些；（2）用户角色及每个角色对应权限（可看到哪些菜单、哪些数据、哪些按钮等）；（3）各系统的适用场景和功能模块，大多数情况下以业务流程图和系统功能框架图进行展示；（4）设计原型、交互规则，以及重要或复杂页面的字段取值规则；（5）对于表现层，通常通过讲述使用场景和交互规则，有UI进行完成。
在这个过程中，我一直忽略了各功能模块间、各系统间数据流转相关问题，也是通过本次求职和学习使我意识到自己所欠缺的知识。

2.架构设计常见理论

本部分内容主要介绍Zachman、TOGCF、4+1视图3个架构理论，每个架构理论网上都有很多很详细的阅读资料，因此该部分以简介核心内容为主，同时也会附上自己认为比较好的参考链接共大家参考。

2.1.Zachman架构理论

Zachman架构理论，全称为企业架构和企业信息系统结构架构（Zachman Framework for Enterprise Architecture and Information Systems Architecture）。
Zachman架构的核心理念是同一个事物可以用不同的方式、基于不同的目的、从不同维度进行描述。其最具有代表性的是通过6行6列共36个元素表示的矩阵表格（如下图），以最简便的形式刻画了构成所有内在关系的设计元素以及这些元素在设计中的功能和作用，构成了一个完整的理论和模型[4]。

Zachman框架图

2.2.TOGAF

TOGAF（The Open Group Architecture Framework）是众多企业架构框架理论中的一种，它为一个企业或组织对于企业架构的接受、创建、使用和维护提供了一系列辅助方法和工具。同时它还是基于一个迭代的过程模型（分阶段实现的架构分析方法），支持最佳实践和一套可重用的现有架构资产。
TOGAF旨在支持4种常见的架构，这些架构归为企业架构的子集，具体的架构内容见下图（图中列表部分表示每个模块主要交付内容）：

• 业务架构：定义了企业战略，管理，组织和主要的业务流程，其包括战略、企业业务流程（价值链）、当前能力、未来能力、商业能力、IT能力。
• 数据架构：描述一个组织的物理和逻辑数据资产，以及数据资源的结构。
• 应用架构：提供了一个蓝图，各个应用程序部署，它们之间的相互作用，以及它们的关系，该组织的核心业务流程。
• 技术架构：描述了需要支持的业务，数据和应用服务部署的逻辑软件和硬件的能力; 这包括 IT 基础设施、中间件、网络、通信、处理、标准等。[5]
  
  TOGAF框架图
  
  在引用文章[5]中，关于业务架构有描述一个优化方法，我认为该方法在实际的产品工作中也会有所涉及，所以将该部分的描述帖了出来，内容如下
  万般需求皆业务，万般业务皆流程；管理无止境，流程出效益；
  在流程优化上，有著名的ESAI理论，目标业务流程设计方法：
• Eliminate-删除无附加价值的步骤，该部分涉及到过度控制、重叠环节、等待时间、反复校验、部门协调方面。
• Simply-简化所有过于复杂的环节，该部分涉及到简化所有复杂的步骤、表格、程序、沟通渠道方面。
• Integrate-集成功能 ，理顺流程过程，该部分涉及到离散到整合、无序到有序、职责、部门、客户、供应商方面。
• Automate-运用先进的信息技术自动化，该部分涉及到数据收集、数据传输、数据分析、自动化方面。

2.3.4+1视图

“4+1视图”分别为场景视图、逻辑视图、物理视图、处理/流程视图和开发视图。

4+1视图内容

3.架构设计案例（引用7）

（1）供应链系统架构

供应链系统架构

（2）供应链系统功能模块

供应链系统功能模块

有赞基础生态架构

（4）客服平台逻辑架构图

客服平台逻辑架构图

Oracle CRM产品功能架构

支付公司产品架构

参考链接：
1.1-产品设计的三个阶段介绍《产品架构设计入门指南》
2.产品经理思考产品架构的四个维度
3.5-产品架构的五个层面《产品架构设计入门指南》
4.业界企业架构方法（二）-Zachman框架
5.企业架构设计方法论-TOGAF
6.架构蓝图--软件架构的“4+1”视图模型 - 涛哥 架构和产品的文章 - 知乎
7.15张B端产品业务架构图，产品经理快速成长通道
8.一文读懂产品架构(已2更) - 产品经理大群的文章 - 知乎