下面这篇文章是笔者整理分享的关于自身的产品和项目及面试经历，其中内容包含了爱企查/舆情/情报分析/风险预警等系统所解决的业务问题、各系统的共通之处及差异分析以及关于“架构”的一些思考的相关内容，对此感兴趣的同学接着往下看看了解更多叭！
个人从事2B/G产品工作3年半，期间个人直接或间接负责建设的系统包括：【智慧城管系统】、【政务热线分析系统】、【人体/车辆异常行为告警系统】、【舆情分析系统】、【开源情报分析及侦察系统】、【公共安全防控与预警系统】、【自训练平台】、【OA系统】等。
今天就来聊一聊，这些系统以及诸如“爱企查”、“企查查”、“千里马招投标”，还有面向KOLMCN提供运营/营销服务工具的如“飞瓜数据”、“蝉妈妈”系统，有什么共通之处？又有什么差异？
做了这么多产品/系统，我发现，这些系统（城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…，包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等），它们本质上就是一类东西：【（大）数据处理与分析系统】。
即，都是对采集或获取到的各种数据（有仅开源的，有仅闭源的，有开源+闭环的），利用各类AI算法（有只用CV的，有只用NLP的，有多种技术结合的）进行治理和分析，最终给到业务侧去应用，而且业务应用功能多为：预警、分析。作为为业务发现风险的一个“上报源”。
——这是从数据流转层面来看的，上述各个系统的【共通之处】（即产品架构基本类似）。抽象来看，上述各个系统的业务流程都如下，且与OA系统的关系如下：
OA系统，可以负责上述【数据处理与分析系统】提供的风险数据的后续业务操作与处置，使得业务能够流转（如生成告警工单，案件处置表单等，进行多部门的协同）。
——从对外提供的产品服务模式来看，厂商一般也会优先提供基于互联网的PaaS服务或SaaS形式。
这是因为服务升级、运维均在厂商自己侧，维护和管理成本低。而私有化部署交付这种服务形式，对厂商侧的运维成本很高。
（1）从产品面向的客户类型来看，这些系统（城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…，包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等），其是有差异的。
A. 客户类型不同，导致的交付模式差异
B. 客户业务场景不同，导致的业务功能差异
由于这些系统（本文开头提到的系统）面向的行业、客户有所不同，这就导致具体的业务场景不同，业务场景不同，就会衍生出差异化的产品功能，也会根据业务需求，确定选择用哪些技术实现。
（2）若产品是专门提供数据服务的，从数据的开、闭源角度来看，这些系统（城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…，包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等）的对外服务模式也是有差异的。
为什么会写到这个内容，之前在面试过程中，几次被问到了产品架构相关的问题，遂有了下述思考，小伙伴们可有自己的见解哈~
我们经常会在什么短语中听到这个词？组织架构，对吧？每行每业都会有架构师。建筑行业的架构师：建筑设计师，再细分开来：有土木结构设计师、钢结构设计师、住宅建筑设计师、室内家装设计…
我们互联网这行，提到架构，经常会听到：解决方案架构、业务架构、技术架构、产品架构、功能架构、信息架构…对吧？
那到底什么是架构呢？先放几张图感受一下：
图来自网络（如有侵权，联系删除）
图来自于百度云官网-智能客服产品架构（仅作交流学习使用，如有侵权，联系删除）
图来自于网络-标签体系架构（仅作交流学习使用，如有侵权，联系删除）
图来某项目-个人设计的产品架构
图来自于阿里云官网-某数据需求场景解决方案架构图（仅作交流学习使用，如有侵权，联系删除）
我理解架构的本质，就是一个东西的内核，是其核心框架/骨架，并按一定的逻辑顺序，将支撑这个系统的核心骨架串起来，并给出各个模块间的交互关系，在每个骨架层同时加以“血肉”使其稍微“具象化”。至于最终的呈现形式可以是上面那些常见的规规整整的架构图，也可以是流程图，也可以是脑图、表格…等多种展现形式。
那业务架构、产品架构、技术架构、信息架构之间的关系是怎样的？
根据我相关产品/项目工作实践经验，我总结了几个有效的设计产品架构的方法：
（1）从数据流向来设计。即从数据怎么来的->怎么加工处理的->到怎么给到业务去应用的这样的顺序去设计。
（2）参照OSI框架来设计。
（3）按Iaas、PaaS、SaaS，从底到顶逐层来设计。
其实，上面这几种方法的本质是一样的，我认为都是根据数据流向来设计的。那什么是好的产品架构设计？
——类比于房子等建筑的架构，其好与坏，可以用一些实际应用情况来评估，比如抗风程度、抗地震程度…软件产品架构（软硬件结合产品的架构），一般要求：其稳定性、健壮性、鲁棒性均较强。
——但软件产品与房子建筑架构（结构）又不太相似的地方在于：软件产品一般更新迭代速度较快，而实体房子不会推倒重建（除非地震坍塌、建筑主体损坏，需要翻修等等），这就要求软件产品架构还需具备很重要的复用性和可扩展性。
产品经理，一般从产品助理做起，从一开始接触简单的功能需求（如设计一个简单的功能模块：这里面可能会包含业务流程的调研/梳理/设计、功能输入输出的制定、原型界面设计等内容）、到负责一个产品核心模块的建设、到负责一整个产品线的建设，并为产品商业化负责。
在整个产品经理打怪升级过程中，不论是功能型的产品经理，还是策略型的产品经理，还是软硬（硬件产品经理）结合的产品经理，其架构能力要求，肯定是逐渐升高的。
图来自Boss直聘（如有侵权，联系删除~）
图来自我的某个offer
图来自Boss直聘（如有侵权，联系删除~）
所以，我们1-3年或3-5年的产品经理平时在进行产品工作时，要多去了解公司的组织结构以及业务情况，以及市场上的其它优秀产品，才能据此设计出适合于部门或团队的产品架构。架构能力的提升，我认为本质在于模块化、抽象化思维的不断锻炼。
本文主要基于个人此前的产品和项目及面试经历，首先梳理了每个产品所解决的业务问题，然后介绍了这些产品在架构层面、在对外服务形态等层面的共通之处和差异点。最后介绍了关于“架构思考”的内容。文章中，如有不正确之处，欢迎小伙伴们指出，我们一同探讨，共同成长~
本文由 @南方碟道 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。