“淘宝”因为升级而暂停使用？微信发布新功能前需要用户卸载？GPS重新规划路线耗时五分钟？

 

上述这些情形从未发生。

 您也不会接受这种事情。

 

        那么，为什么要接受PLM系统年复一年地出现性能问题呢？为什么愿意等待6个月之久去使用新的定制功能？为什么在系统升级时您需要停用PLM系统数天时间？

 

        现代系统基于云原生技术，而当今市场上的所有PLM系统都基于25年前设计的单体架构——这就是不同之处。

 

        单体系统使用一个单层的软件应用，其中用户界面、逻辑和数据被合并到一个应用中。该应用被设计为一个系统，只运行在特定的认证硬件、数据库、编程语言和第三方软件上。

 

        因此，单体架构软件修改不便，升级困难，部署时间周期长。

 

        而云原生技术采用最新一代的云技术，实现了灵活性和可扩展性的最大化。这种技术原本是为社交媒体和电商开发的，性能、可扩展性和可用性是最重要因素——而这些也恰好是PLM的首要需求。

 

 

        云原生架构有以下四个特质：

 

        ① 基于微服务：每个服务间相互独立，彼此松耦合。这意味着它们能够单独地开发运维，根据功能选择不同的编程语言或者数据库。

        ② 基于容器：将微服务各自部署到硬件或云环境上，以容器姿势运行。

        ③ DevOps：整合软件开发与IT运维，加速软件的开发、测试、部署和运维。

        ④ 持续交付：流程自动化，基于敏捷开发和DevOps工具改善代码质量，增加新功能，脱离了时间地点的限制，同时不影响终端用户的使用，实现持续交付。

 

 

        那么云原生技术会对您的PLM系统产生什么影响？云原生PLM又能够为您提供什么呢？

 

        过去的25年里，我参与过全球众多大规模、高难度的PLM实施，在现场看到所有客户无一例外地遭遇了五大挑战：

 

        ① 硬件依赖

        传统的PLM系统仅支持特定品牌、型号、硬件和数据库版本上的部署——客户只能使用PLM供应商指定的硬件。您的PLM软件版本决定了您可以使用的服务器或者操作系统，也决定了数据库甚至第三方软件的版本。

 

        这种限制阻碍了客户公司的快速扩展，为提高性能或支持公司基础架构而更改第三方软硬件也变得困难起来。由于迁移PLM系统的复杂性，IT部门常常受困于旧的硬件和旧的操作系统，管理困难。

 

        然而云原生应用不限部署环境，支持任何公共云、私有云或本地的部署。

 

        PLM系统中的不同服务可以部署在不同的硬件上，这为改良协作、缩短响应时间和增强分析能力提供了全新的机会。

 

        每项服务还可以使用不同的数据库，采取最高效的技术来支持系统中的特定功能或性能需求。

 

        ② 需求响应

        当今，通过对标准的PLM系统定制来满足企业产品生命周期管理需求已经成为常态。应用不是“一卡通”制，我们不能拿制造飞机的系统去设计芯片。

 

        因此，所有的PLM系统都需要通过一定程度的二次开发来实现，进一步支持业务。业务需求日新月异，PLM系统也应该进行相应的迭代来促进业务发展。

 

        定制单体的PLM系统成本高，耗时久。尽管每年一两次的功能增强并不能真正推动终端用户的业务，但他们中的大多数人仍然安于现状，止步于此。

 

        而对于使用微服务、容器、DevOps和持续交付的云原生应用，只要终端用户需要，它可以每周甚至每天进行部署改进。微服务支持程序的独立开发和测试，而DevOps和容器又可以部署和监控系统以实现持续的改进。

 

        ③ 系统升级

        传统PLM系统的升级更新耗资巨大。

 

        需要重构所有代码，再将数据转移到到另一个数据库，购买和安装新硬件，并且要重新测试整个系统。

 

        除了升级复杂，在实际迁移过程中，PLM系统还需要脱机几天。

 

        我已经看到太多升级比重启还要昂贵的例子。系统升级费用之高，风险之大，留给业务的价值已经很难去界定。用户别无他法，只能尽量拖延下一次迁移的时间，有公司因此长达十年不作PLM系统的迁移。

 

        这种等待不仅意味着公司无缘供应商发布的新功能，还意味着他们的硬件和操作系统失去保障，风险上升。

 

        然而在云原生应用中，每个微服务不限时间独立升级。无需重启服务器，无需迁移数据，无需更改硬件，为客户节省出大量成本和精力，并在规避风险的同时保证工作的持续进行，让用户享受最新的功能。

 

 

        ④ 系统性能

        性能问题老生常谈，我在很多传统的PLM系统上都遇到过，不同行业和实施类型有各自的性能问题，它们的相同点是：问题可能会迟到，但不会不到。

 

        性能问题最常见的原因在于关系数据库的使用限制、硬件限制和核心设计方面，未能按预期执行第三方软件也是原因之一。

 

        部分问题可以通过性能调整来解决，但更多时候，如果想要从根本上解决问题，只能去升级硬件或重新设计功能。

 

        云原生技术专为庞大的数据密集型系统设计，如社交媒体和电商，因为他们的终端用户不愿意等待。因此，性能管理是云原生应用的核心。

 

        基于云原生应用，系统资源可以独立分配到每个微服务上，且服务不间断地受监控。如果一个微服务出现性能问题，系统将自动重新分配资源以提高性能。

 

        此外，由于不同的服务提供的功能都大不相同，关系数据库并非万能。在基于微服务的系统中，您可以根据功能需求选择不同的数据库。例如，同一个PLM系统中，您可以使用图形数据库来处理复杂关系，时序数据库来管理密集数据，所以选择NOSQL数据库或者关系数据库都是基于服务所需的功能。

 

        ⑤ 实时数字化链

        数字化链能够帮助企业理解产品从需求到服务这整个生命周期不同阶段中的数据间的关系，赋能决策。

 

        在今天，产品生命周期中的所有数据都单独存储在多个系统中，系统间无法关联，这让相关人员无法快速了解到A部门的产品决策会对B部门产生什么影响。

 

 

        传统的PLM系统多次被定位为“单一事实来源”——所有产品数据存储在一个大型数据库中。即使所有产品数据集中存储，用户也很难分析这些数据对制造、供应商或采购所产生的影响，因为它们被锁在关系数据库里，缺乏集成能力。

 

        而云原生应用中，微服务间相互关联，应用间也相互关联。微服务通过事件驱动发布或订阅事件，实现数据在不同服务、应用的共享和消费，自动构建动态的实时数字化链。

        此外，使用图形数据库来管理微服务间的关系，就让使用关系数据库时的“不可能”实时分析复杂的关系变成“可能”。