记一下关于B端产品设计领域,2B互产品中台设计的精要
主题范围
组织中台
研究的是企业内部的组织结构设计，如何通过合理的权责划分，以及管理架构搭建，提高业务部门的经营能力，迅速响应市场变化，并且能够让企业提升整体跨部门跨业务线协作效率，降低运营成本，实现标准化管理。所谓组织中台的设计思路，实际上已经存在了很多年了，在集团企业中，往往采取事业部制的组织形态，再配合各种共享服务中心的建设，实现前后端业务分离，前端业务保持机动性，后端业务提供火力支援。类似于财务共享服务中心FSSC（Financial Shared Service Center），人力资源共享服务中心HRSSC（Human Rersources Shared Service Center）
产品中台
研究的是企业内部的软件系统如何进行抽象和设计，从而让企业的软件系统就像搭建积木一样灵活，可以重复高效利用现成的软件组件，快速组装开发出新的软件系统，从而节约软件开发成本，并能够快速支持新业务开展。很多文章也把这类中台产品称作业务中台，或业务中台产品。目前被广泛讨论的产品中台包括电商交易中台、账号中心中台等，其中电商交易线又被更加广泛的探讨，包括了订单中台、支付中台、商品中台、促销中台等。产品中台还有另一层含义，即能够给全公司全企业提供一致服务的管理软件产品，也可以纳入产品中台的范畴，例如呼叫中心、项目管理软件。从某种程度上来讲，这些标准化软件产品也是中台产品
数据中台
研究的是企业内部的数据管理、治理问题，以及数据产品体系和数据底层结构的搭建问题。数据中台研究的范畴，包括企业统一的数据安全、数据规范、元数据管理、数据编码管理，以及数据仓库、数据集市的拓扑架构，也包括大数据底层和运算能力建设和复用。要注意的是，数据中台更多的关心从业务和产品层面对数据的治理、管理、应用，而非技术层面问题
技术中台
研究的是软件产品的技术实现过程中，哪些技术上的处理能力和架构可以进行抽象复用，例如消息中间件MQ，分布式计算框架Hadoop，分布式服务框架HSF，各种Open API等等。技术中台是纯粹从技术实现底层来思考基础服务和基础模块的复用能力，其设计思路和产品中台一脉相承，是技术人员需要深度思考的问题
产品中台在企业应用架构设计中的公认关键要点
企业应用架构设计
指企业内部的各个软件系统，应该以什么样的形式建设、组合，从而高效的支持企业的经营运作
关键要点
- 企业级
- 抽象
- 下沉
- 复用
抽象复用
明显具备共性的模块尽早抽象
- B端产品的体系化设计中，很多形态的产品是具备明显共性的，可以尽早的进行抽象设计，这样在系统架构建设的早期，就能做出正确的设计方案，而且并不会增加多少研发工作量，但会让未来的系统扩展更加轻松。例如，业务系统的统一权限管理系统、单点登录系统、组织架构系统、公告系统、短信系统，这些系统都应该尽早抽象建设。
不确定共性的模块事后抽象
- 例如统一客户视图、订单中心、商品系统，这些软件模块，很难判断在多业务线场景下能够完全复用，如果对于是否抽象拿不准主意，完全可以先不做抽象，等业务渐渐明确后，有足够的信息作出充分的分析和判断，再决定是否合并抽象。
避免人力外包中台
- 中台的建设一定要有合理的原因，如果只是为了中台而中台，会让系统的架构混乱，工作效率反而降低。而且很容易产生“人力外包中台”现象，即下游业务团队把中台团队当做乙方来合作，“反正你们要帮我们打理好这些模块，不管是否合理，需求提交给你就必须得高优支持，否则就是不支持业务一线”，这样会让中台产品和中台团队失去该有的气质，形成团队间的敌意和隔阂。
架构合理性
- 可以允许不合理的架构存在
- 产品设计人员、架构师、产研负责人，在面临这些问题时，必须谨慎思考，基于对业务、市场、系统、代码、架构、人员、团队，各方面进行综合判断后，做出决策，牺牲部分合理性来保证公司和业务的长远利益上的正确
业务统一管理
- 不要过多考虑未来不一定发生的事情
- 集中管控是不一定发生的需求，产品设计初期和中期，没有必要为未来不确定的事情提前做过多的布局，因为很有可能未来根本用不到，却会产生过度设计，造成开发资源的浪费，甚至也会让系统架构看起来非常奇怪
- 通过业务价值和业务诉求驱动系统迭代抽象
- 没有明确的收益和价值，却采用了这种集中控制调度的软件架构设计，这会让各个事业部的核心销售系统被割裂，被控制，被牵制。没有业务价值和业务诉求的系统迭代抽象工作，是很难推动落地的。
- 项目必须有高管介入确保推进
- 架构调整，集中管控会打破原有的利益格局，想成功落地，必须有集团层面的，超越了各个下游业务线的非常高级别的管理人员牵头挂帅，管理团队必须有统一的认识，通过强有力的项目管理手段，才能保证在项目执行过程中化解任何困难，成功落地。
总结
