异步开发和中台 ｜ 新产品开发IPD方法论的首要原则
我在介绍 IPD 方法源头的文章《正宗IPD ｜ IBM的集成产品研发（IPD）实践（二）》里提到，IPD流程设计有四项基本原则：异步开发、业务分层、结构化流程、基于团队的管理。国内管理界对IPD 流程讨论，往往忽视了“业务分层和异步开发”这前面两项基本原则，而将主要关注点放在结构化流程和跨职能团队的协作和产品阶段评审决策机制上。
异步开发是指基于产品的平台化策略，在一个产品平台上，软件、硬件、服务等子系统的业务实行分层管理，各层之间的研发流程相对独立，并非同步开发，在产品层面来统一整合，产品平台强调模块化设计，避免一个层面的研发进度对另一个层面的研发造成影响，造成整个进度的延迟；业务分层则是指这些业务层面有独立的商业模式和上市决策逻辑，可以根据自己业务所处市场的技术创新和竞争态势，来决定产品研发节奏。
异步开发是很重要的业务流程再造的理念，意味着企业需要能力很强的产品架构设计师来将产品解耦为子系统以及更小的通用化组件，拆开子系统间的依赖关系，因为复杂高科技设备各个子系统的技术生命周期是不一样的，例如软件生命周期较短，电子元器件生命周期居中，而网络通信等基础设施技术的生命周期较长，所以各个子系统的新产品开发节奏是不同的，要异步错开才能避免相互影响研发进度。下图是医疗设备的不同子系统的不同生命周期的例子：
IPD方法提出产品的共用基础模块（Common Building Blocks，简称CBB）是 IPD 成功的主要赋能因素。 CBB指可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果。如果不同产品或产品线之间的技术和组件的共享程度低，随着产品种类的增长，会给供应链、服务支持、制造成本等带来一系列复杂性的问题。产品在开发中尽可能多地采用企业级的共用基础模块和技术，产品设计要考虑在系统、子系统、组件等各个层级具备标准化通用接口，便于对接标准化的组件，保证产品交付的质量、进度和成本，降低产品开发的技术风险。
每个组件要有相对独立的产品管理团队，即“业务分层”的思想，这跟二十多年后出现的“微服务”治理有异曲同工之处。IT应用系统去中心化的组件称为“微服务”，如下图所示，微服务之间通过标准化 API 来连接，而每个微服务都有一个自治的研发运维一体化（DevOps）团队来负责，这也就是前几年盛极一时的所谓“中台组织”的理论。
所以 ，90 年代出现的 IPD 方法中的异步开发和业务分层，其实就是后来的中台方法论的理论前身，我一直不觉得中台是啥创新的发明。