零件标准化，构件模块化，产品配置化 ｜ 从物理产品到企业系统的思考

fuhe

最近这些年，为了使得企业IT系统快速适应变化，企业软件的微服务化、基于API集成，业务领域设计驱动的架构等等，成为企业级软件工程的变革主流。我觉得这些企业软件“微服务化”的道理，和物理产品，例如电子、机械、汽车的部件标准化，从而提升交付柔性的道理是类似的。

我很多年前在电子、机械、汽车行里做产品数据管理（PDM）系统的实施，当时业界都形成共识，产品设计的通用化和模块化（commonality and modularity）是提高研发效率、降低产品成本的最重要手段。

乐高积木是零件标准化，部件模块化，产品配置化的最佳例子，可最终搭出千变万化的乐高，其构件种类和数量关系遵循了80/20原则，少数的常用标准化构件占据了大量使用比例。

我在二十年前给家电、汽车企业实施PDM系统时，就做过部件通用化和模块化策略的咨询，当时做这类课题的设计思路是：首先要做到对零部件的特性参数化、接口标准化，其实要建立企业级的标准件、通用件库，还要建立零部件跨产品的借用规则等。

然而对企业来说，这是一项浩繁的工作。从现实来看，绝大多数企业都没有能力无论是对业务组件，还是产品设计来校准内部规则，形成通用库，并且推动产品设计和研发、营销和销售、制造和供应链等各个环节来遵循这套体系。所以，直到今天，产品构件的标准化仍然是所有制造企业在产品设计、供应链管理领域的世界级难题。

今天，无论是SAP BTP，还是金蝶EBC，都在宣扬企业软件的能力模块化，这种“乐高积木模块化”的概念在企业软件行业并不是新事物。2000年，瑞典ERP软件公司IFS在上海国际会议中心发布“IFS 2000”产品，就宣称他们基于微软技术的这个新一代ERP产品有几百个功能模块可以自由组合，同时宣称其他家ERP软件不能拆成模块。当时我作为IFS在中国的合作伙伴，卖出了这个软件最早的本土客户合同，但是具体实施时，实话说并没有感受到拆成几百个模块的好处。

这个世界最缺的是架构师，更缺自上而下的执行力，不管是做物理产品，还是做软件产品，现实中为了赶进度、迎合客户等等原因，就放弃架构原则和标准化原则了。大道理讲得多，往往是搞理论的人对现实的一厢情愿。

企业软件行业的工业化程度远远低于制造业，而今天流行的全栈工程师、敏捷方法等等软件工程思想，甚至是和标准化思维背道而驰的。企业的物理产品标准化都很难做到，企业软件的微服务化、能力模块化，更加是个企业哲学和系统工程的哲学问题了。

在企业业务用户的角度，我觉得应该并不关系企业软件产品是不是微服务化的，而是关心其业务解决方案究竟是什么——只有软件开发人员、系统集成商才会关心；而我见到国内企业软件公司现在动不动就上来讲能力模块、微服务化，似乎是走入产品营销误区了。