当产品经理升职后，一般都会要求负责系统架构的设计。之前没有接触过这种，如何快速处理？本文写给已负责或即将独立负责系统，为系统架构设计苦恼的产品人&曾经的自己：
系统架构系列目录：
我所在的大部门内部是乐于分享的，此前能听到很多产品对自己负责的业务&系统进行分享，有幸看过了很多系统架构图，有意思的是，不同产品经理负责分享时的系统架构图都不太一样，举2个明显差异化的例子：
催收系统架构图如下
认证中心架构图如下
可以看到上述2个系统架构图有明显差异：
从2021年到现在，期间有过几次困惑：系统架构图是非标的吗，为什么每个人的系统架构图都，各有千秋呢？随着主导各类系统从0到1或系统重构的项目经历不断丰富，对于系统架构的理解才有了自己的答案；
在互联网中，公司商业模式的主营业务流往往需要多个系统支撑串联，而支撑业务的系统都有自己的侧重，不同侧重类型的系统，其架构表达形式自然有差异；
从众多系统全盘看，系统可以分为3类，每一类都有各自的特点；
名词解释：
核心能力：指系统中提供可直接使用的功能；以各类系统的核心能力举例
名词拆解：
在此补充2个新的名词，本质上是对系统核心能力的拆解细分；
在笔者所接触的风控业务系统中，基本没有区分应用能力和基础能力，而工具&服务系统则重点对基础能力和应用能力进行区分；其差异化的原因下文会详细说明。
系统架构是产品经理梳理出来，面向人员（其他相关产品经理、开发人员、测试人员），让其能够清晰的明白系统的定位和能力以及系统边界（其与上下游外部系统的关系）；
通过明确系统架构的价值，反向推断一个系统架构图中应当具备的元素和内容，这样系统架构需要做什么，就很明确了：
而系统功能点的来源，是将线下的执行事件，转化到线上系统进行支持体现；系统关联关系，则可以明确系统内部能力的同时，按照上下游外部业务接入方进行划分。
因此要想无遗漏的梳理功能点，同时明确系统内外部关联关系的前提，需要对调用系统能力的多条业务线，在实际调用的相关业务环节进行全盘梳理；
为此，我将整个系统架构设计分5步：
明定位（敲定基础能力）→抽线盘点定标准（梳理多条业务线流程各阶段执行事件，定义对接标准）→抽象（提炼功能点）→分层（服务拆分）→划分边界（区分上层调用方&依赖的下游系统能力）。
系统定位是什么？本质上定位是核心能力的极简体现，它约束了后续的迭代方向。
没有明确定位的系统，在系统迭代过程中没有方向，往往会越做越乱，变成一个大而全甚至与外部系统耦合的功能集合体，比如系统会做一些定制化功能，违背通用特性。
举个有趣的实际案例：
几年前我负责贷后催收系统时主导一个催收先还款后返现的需求中，就曾任性的要求支付系统的产品经理，在提供的退款接口中，需要对催收请求的返现金额按照一定逻辑进行拆分后在进行对应订单进行原路退款，最后被对方直接了当的拒绝了，拒绝理由清晰明了：支付系统的定位就是提供通用的支付应用能力，返现金额拆分属于仅催收特定场景，属于不通用的定制化业务逻辑，其不该由服务系统承接。
这就是清晰的系统定位，为产品经理在需求对接和设计过程中带来的判断依据。我现在想起来还记忆深刻。
所以“工具系统”&“服务系统”在未确定系统定位之前，不要想系统架构设计，先明确一个清晰的系统定位，才能保证系统规划设计不会跑偏。
明确系统定位：除了约束后续的迭代方向，最重要的是敲定核心能力的地基-基础能力，即系统最基本的原子能力，它是核心应用能力的组成部分或前置条件。
分别以笔者主导0~1建设的呼叫中心，参与重构设计的订单中心举例：
工具系统-呼叫中心：
外呼中心相对比较特殊，需要由特定的硬件去实现基础能力的支撑，所以相对常规系统多了一个硬件层体现信息流；由于软交互机在通讯领域是一个很复杂且相对成熟的硬件，这里就不做展开说明。在整个系统架构设计之前，首要了解的就是呼叫中心最底层能提供什么样的基础能力。否则，上层应用的建设就是没有支撑的空谈。
服务系统-订单中心
敲定基础能力的重点在于：上层应用能力的建设无法脱离底层基础能力。因此明确定位后，就需要产品经理将定位转化为具象的底层基础能力，这是为什么定位能约束系统后续迭代方向，实际产生约束作用的，还是具体的基础能力。
抽线：是指抽出本系统服务外部业务线的局部环节（流程）；
盘点：是指抽线后的流程中，按照阶段性拆分，找到多条业务都有哪些事件需要支持，最终基于事件挖掘出对用系统需要提供的功能点；
定标准：定义外部接入层对接标准。
其中工具类系统&服务类系统在这一步存在明显差异：
工具系统：先盘点→再定对接标准
在工具类系统架构设计步骤中，抽线盘点可以简化为对外部涉及工具的应用场景进行重点挖掘即可确定清楚功能点。
当然除了功能点以外，还需要针对工具对接流程也是需要制定一套标准：
服务系统：先抽线→再盘点
在服务类系统架构设计步骤中，则需要先抽线：完成环节内部流程梳理。再盘点：通过各条业务线的各阶段性事件来找出对应功能点；以订单中心举例
抽象：是指从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。
抽象的价值在于避免系统中出现很多同质化的功能，这样系统就越轻量，系统建设的总人力投入成本越少；
举例：
这2个事件最终实现为2个功能点，总计投入4人日;
当我们将A&B前置抽象为一类条件，将这2类事件合并为1个事件：（A或B前置条件）执行M事件，其中开发执行M事件仅需投入1人日，总计投入3人日，即可完成1人日的人力节省。
投入的对比可以直观的体现出抽象精炼功能点的重要性，那么具体应该怎么抽象呢？
当工具类&服务类系统经过抽线盘点后，通过比对各业务线是否需要相同的功能点，若功能在系统服务流程或场景中，被2+业务线应用且功能不会导致系统与业务耦合，就可以考虑将功能统一纳入到工具&服务系统范围实现；
例如：订单中心的闭单的后置动作：恢复优惠券&恢复额度
常规上来看，订单中心只需要关注订单状态，数据变更，至于被闭单后请求优惠券恢复，请求已被扣减的额度恢复，理应由业务线自己发起请求执行闭单后的动作。
但由于闭单后3条业务线都存在恢复优惠券、恢复额度的逻辑，此时这2项后置动作可以统一做成闭单组件，由订单中心闭单后，对外触发，这样一来就避免多个外部接入系统重复造轮子。
分层：是指将系统内部服务拆分不同层级（可理解为不同区域的服务）
通常来说工具类/服务类系统可以拆分为2层：
最终实现应用与基础拆分的解耦合方案，这样后续上层业务线有变化，通用应用层针对调整即可，基础服务层无需变动。
不同类系统分层的差异性
在我接触的所有系统中，无论是业务系统、工具系统还是服务系统，底层服务都是进行了分层，只不过分层的考虑维度不同，差异性在于系统服务范围不同：
以催收&呼叫中心&订单中心，对比业务系统 & 工具系统 & 服务系统 的分层维度侧重：
1）业务类-催收系统-底层技术服务主要分为2套：服务分层侧重于性能稳定，保障系统易用性。
2）工具类-呼叫中心-底层技术服务分为2套：服务分层侧重于解耦，保障快速响应业务变化的同时避免高耦合导致后期复杂的维护成本；详见下方图例
3）服务类-订单中心-底层技术服务分2套，分层侧重同上呼叫中心，详见下方图例
工具类–呼叫中心分层图例如下
服务类-订单中心分层图例如下
划分边界：是指将工具&服务系统的上下游关联关系体现；
当系统完成服务分层后，通过接入层体现上游接入业务线或调用系统，通过外部依赖层链接下游提供能力支持的系统即可完成系统关联关系的表达。
最终呼叫中心的完整系统架构表达如下：
工具系统与服务系统虽然都具备通用性，但两者在细分服务类型上存在差异
工具系统和服务系统设计区别在于是否需要盘点业务流程，其他思路一致
1）先明确系统定位：通过定位敲定系统基础能力
2）抽线→盘点→定标准：
3）抽象：比对接入业务线的功能点，若功能在系统服务流程或场景中，被2+业务线应用且功能不会导致系统与业务耦合，就可以考虑将功能统一纳入系统实现为公用组件。
4）分层：不同维度进行服务分层，通常以基础服务、通用应用拆分，保证低耦合度的同时可以快速响应多方业务变化。
5）划分边界：链接上游接入层，下游外部依赖层。
作者：橙言，互金风控产品经理；公众号：橙言（ChenYan_515）
本文由 @橙言 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。