不要建立自己的平台：复用应作为内部开源库，而非定制平台

呼应[[私有工作流平台自建facade几乎必然失败的教训]]的观点，本章从组织采用流程的视角再次强调：不要建立公司级流程自动化平台。作者常见到的两个建立动机——不想依赖某个厂商，或者想让所有项目都能对接公司的某些具体细节——都很难成立，因为搭建这样的平台本身就很困难，还会分散团队交付业务价值的精力；更重要的是，在最初就把某些架构基础要素定死了，后续项目积累的经验就很难被真正吸纳进来；维持平台更新、修bug、跟上底层产品新版本功能，这些都复杂又耗时；而且遇到问题时，用户没法像搜索知名开源产品那样在网上搜到帮助，因为坑都是自己独有的。作者观察到的现实是，每一个这类举措都在挣扎，建议在至少有几个项目真正上线之前，都不该考虑创建定制平台——只有到那个阶段，你才真正理解哪些东西具有共性、值得沉淀成通用能力。当然，最初的项目中仍然可以做一些让运维人员或企业架构师满意的准备工作（如对接认证授权基础设施、让工作流工具的日志输出到集中式日志系统），这类代码本身对后续项目有复用价值。真正有效的复用模式不是搭平台，而是把可复用的组件或库当作内部开源项目来运作：提供给全公司，配上一定资源和支持，好用自然会有人用，但没有人被强迫必须用；这些库可以在最早的项目里被开发和演进，后续项目如果需要额外功能，完全可以提交pull request或直接fork，不会被”锁死”在扩展受限的库里——这种规模的复用既能实实在在帮到开发者，又不会成为效率提升的阻碍，核心原则是提供有用的指导，而不是设置约束。此外，很多流程自动化计划还热衷于”提取流程片段、在不同业务流程间复用”这种想法，作者对此持怀疑态度：如果复用范围仅限一个项目团队内部，问题不大，但不该在团队之间共享这类片段——跨团队场景下更该做的是把这段逻辑提取成一个有清晰定义功能和API的独立服务，让不同上下文各自去调用它，而不是共享流程片段本身。