BPM与SOA时代集中式工具失败的具体教训

很多人对流程自动化的负面印象，源自BPM（业务流程管理）和SOA（面向服务架构）时代留下的历史包袱——了解这段失败史，有助于把这些偏见和现代工作流引擎区分开。象牙塔中的BPM：BPM作为学科涵盖发现、建模、分析、度量、改进、优化和自动化业务流程，是个很宽泛的话题，但很多BPM项目组和IT系统严重脱节，做BPM的人长期孤军奋战、不考虑流程如何在真实IT基础设施里落地，结果建出的流程模型无法运作，却被甩给IT部门去”简单实现一下”——效果可想而知。集中式的SOA和ESB：SOA兴起时正撞上SOAP这类异常复杂的技术，任何团队都难以自行提供或使用服务，给厂商打开了市场空间；SOA的组织治理通常高度集中，大厂商以自上而下方式卖出昂贵的中间件（企业服务总线ESB，核心是消息系统+周边服务接入/数据转换工具），带来至少四个具体缺陷：集中式部署（团队不仅要实现部署自己的服务，还得和SOA团队沟通、配置中间件，冲突频发）、与开发流程相悖（破坏自动化测试和CI/CD管道，很多工具甚至不支持自动化测试或部署）、厂商驱动（厂商在行业最佳实践成型前就把产品卖出去，迫使公司引进无效方案）、基础设施与业务逻辑耦合（重要业务逻辑最终散落进路由配置、部署进中间件，权责不清、不同团队各自实现同一业务逻辑的不同侧面）。被误用的BPM套件：这是SOA与BPM捆绑销售的产物——一套独立的核心工作流引擎加周边工具，同样以集中式、自上而下方式引入，由中心团队统一维护并成为唯一能部署服务的团队，形成单点依赖；值得一提的是，BPM套件盛行的年代，多数公司软件还跑在物理硬件上，自动化部署管道当时还未真正实现。