Best of Breed 与 ESB：给每个业务挑最好的软件……以及随之而来的集成破事

01 Best of Breed：业务部门很开心，IT 部门就没那么轻松了

举一个非常具体的例子：车队管理。 你找到了一款很棒的专业软件。车队负责人爱不释手。车辆、加油卡、合同、租赁公司、修理厂、里程，它全都能管，说不定连 Michel 那辆 Clio 的左后轮胎压都能管。 很好。现在，车队负责人还需要知道公司有哪些员工。 总不能每天让他手工导入一次员工名单吧。他还需要知道员工的缺勤情况，例如检查休假期间有没有异常使用加油卡。可能还需要财务数据。软件本身又可能连接着租赁公司、修理厂和其他服务商。 于是，你口中那款“市场上最好的软件”，渐渐站到了一张蜘蛛网的正中央。

当然，还有另一种方案。招一些人，整天埋头录数据。也能运行。只不过会有一点输入错误，数据晚三天更新，Excel 在邮件里飞来飞去，导出靠手工，还有人每天上班先导入十五个 CSV。 说实话，这可不是我向往的生活。 更何况，应用组合一直在变。一款新软件上线，一款旧软件下线，第三款换了供应商，第四款突然宣布 API v1 已废弃，建议你在本周五之前迁移到 v3。 欢迎来到 Best of Breed 的世界。

02 现在，该让这群软件互相说话了

确定 Best of Breed 方向之后，我们需要找到一种技术方案，让这些不同的软件能够通信。 于是，我们开始研究 ESB。 ESB 是 Enterprise Service Bus，即企业服务总线。它是一种集成平台，用来集中管理并编排不同应用之间的数据交换。 翻译成人话就是：

从某个地方拿到数据，必要时转换一下，再送到另一个地方。

当然，ESB 能做的远不止这些：编排、监控、错误处理、转换、连接器、API 调用、异步处理等等。但如果你刚接触这个领域，先记住上面那句话就够了。

03 为什么不自己开发？

当时，我们内部大约有四名开发者。 从技术上讲，没有任何东西阻止我们自己开发集成流程。用 .NET、Java、Python，或者团队熟悉的任何技术写一个服务，都能从一款软件取出员工数据，再发送到另一款软件。 所以，我们做了一些研发。就像任何一支被问到“买现成软件还是自己写”的优秀开发团队一样，我们展开了几场格外冷静、克制的讨论。

那当然了。

但我们最担心的，其实不是把流程做出来。

做出一条流程，相对简单。让它连续工作十年，就是另一回事了。 系统出问题时，需要日志。需要知道哪条数据失败了。需要能够重放。需要告警、邮件或通知。需要监控。还需要在六个月后看懂：Michel 当初为什么在代码里塞了这么一个离谱的条件。 最重要的是，Michel 辞职、转岗或者退休以后，系统还得继续工作。 你可以用三天写完一个流程，然后花十年做它的 MCO，也就是维持它正常运行。 这时，专业平台才开始显现真正的意义：统一流程的开发、监控和维护方式。 那次评估大约是四年前做的。今天，我想补充一个重要的保留意见。

随着 AI 辅助开发工具和 vibe coding 的快速发展，如果现在让我从零开始，我不确定还会自动推荐完全相同的架构。 如果有一支优秀的开发团队，再加上能够分析代码、维护文档、生成测试和监控现代架构的智能体，那么自建集成平台又成了一个值得讨论的问题。 我还没有最终答案。 但无论买 ESB，还是自己开发平台，需求始终存在。 你都需要一层集成能力。

04 我们的选择：Blueway 的 Phoenix

明确需求以后，我们评估了不同的解决方案。 最后选中了 Blueway 的 Phoenix。此后，Blueway 被 SoftProject 收购。 当时有几个因素吸引了我们。首先是开发集成流程的能力，其次是上手体验。还有一个看似次要、回头看却非常重要的因素：所有操作都在同一个 Web 界面里完成。 我们也看过其他方案：

• 用一个桌面客户端开发；
• 用另一个界面部署；
• 用一个 Web 门户做运行维护；
• 管理时还要再打开另一套工具。

这些方案在大型组织中或许运行得很好。但对于一支不到五人的集成团队，我们更担心的是工具越来越多，复杂性也跟着增加。 Phoenix 看起来更适合我们团队的规模。 预算当然也是因素之一。毕竟，与某些销售的想象不同，不是每个 IT 部门的楼底下都埋着一座锂矿。

05 接下来，要把开发者变成集成人员

特别有意思的阶段开始了。 你要向开发者宣布：从现在起，你们是集成人员了。要从最喜欢的 IDE，搬到某种 low-code 界面里。 而他们大概率会觉得，这东西简直难以忍受。 这很正常。他们从几乎完全自由，变成了点按钮。 以前：

“我写个循环、一个类、两个函数，再放一个中间对象，就能按我的想法把问题解决。”

现在：

“什么？你这玩意儿只有一个 WHILE 循环？”

你会观察到几个阶段：否认、愤怒、讨价还价、想趁午休把 ESB 自己重写一遍，可能还会有人辞职。 但从某种角度看，这种挫败感也是好事。说明他们是真正的开发者，而且热爱自己的职业。 他们此时的感觉，大概就像一只刚被关进笼子的鸟。

“为什么我不能再按自己的想法做了？”

然后，他们把第一条流程上线。六个月之后发现，只要最初的分析和设计没有做得太糟，自己几乎没再碰过它。 这时通常会冒出一句：

“嗯……其实也没那么差。”

06 在集成任何东西之前，先改变规则

采用这套思路以后，我们也不得不在公司里建立一些规则。 业务部门要采购新软件，当然应该先咨询 IT 部门。嗯……理论上是这样。 更重要的是，我们决定让 IT 部门拥有真正的技术否决权。 因为一款软件可以在功能上极其出色，却在集成上糟糕透顶。 用户会告诉你：

“它太棒了，我们需要的功能它全都有。”

然后你问：

“有 API 吗？”

沉默。

“能自动导出吗？”

沉默。

“有 webhook 吗？”

继续沉默。

“技术文档呢？”

销售开始看天花板。 你这才慢慢明白，他们宣传的“与贵公司信息系统全面集成”，就是每周日凌晨两点往 FTP 上放一个 Excel 文件。

07 没错，我对 API 有点执念

有人会说，平面文件照样很好用。他们说得对。也有人说，SOAP 现在仍然能用。他们同样没说错。 就我个人而言，只要条件允许，我更喜欢现代 HTTP API，通常是 REST/JSON，或者相应产品提供的 OData。 这是一种架构选择。可能也是我这个技术人员的一点小任性。 既然要做新集成，我更愿意采用广泛使用、有文档、容易操作的技术。 这绝不意味着 REST 有魔法，也不意味着 CSV 一定不好。

事实上，你根本躲不开文件。总会有平面文件：例如 SEPA 文件、某些银行交换、只有这一种方式的合作伙伴，还有那些没人敢碰服务器的老系统。据说 2007 年有人重启过一次，三天后它才回来。 不过，对于以下业务对象：

• 员工；
• 客户；
• 供应商；
• 报价单；
• 订单；
• 发票；

只要有一套靠谱的 API，我自然会优先选择它。

08 为什么我更喜欢实时或近实时

过去很长一段时间，很多接口都在夜间执行。现在当然也依然存在。 凌晨一点启动，2:17 某个环节崩了。如果最初的开发者做得不错，告警应该已经发出去了。不然，9:04 一位会计会提交工单：

“你好，我的发票去哪儿了？”

又开始了。 那时候，有时还要避开备份窗口，特别是数据库冷备份。开发者找基础设施团队商量运行时段。对方说不行。开发者继续争取。对方还是说不行。 夹在中间的某张发票，正拼命想从一个软件搬到另一个软件。 今天，只要可能，我明显更愿意采用实时或近实时处理。几秒钟，或者几分钟。 好处有不少：数据新鲜、负载更分散、用户持续获得更新的信息。更重要的是，故障发生时，你的团队很可能还在办公室。 下午 14:32 修一个问题，总比早上七点发现六万行数据整夜没导进去舒服得多。

09 一个分号，让四万行文件全部失败

文件处理还有一个特别“美妙”的特点。 你收到四万行数据，其中 39,999 行都完美无缺。但 Gérard 成功在描述里塞进了一个没人考虑过的分号。或者一个转义字符、一段没闭合的 XML 标签，又或者一个谁也看不懂的回车。 然后有时候：

砰！

10 接下来，欢迎来到 webhook 的世界

那些或主动或被动转型成集成人员的开发者，还要学习一套新的词汇。 例如 webhook。 当某个事件发生时，webhook 让一个应用可以自动通知另一个应用。 比如，人力资源软件中的一位员工被修改了。与其让 ESB 每隔五分钟去问 API：

“有新东西吗？”

“没有。”

“现在呢？”

“还是没有。”

“那现在呢？”

不如让 HR 软件直接调用你提供的 URL：

https://monentreprise.com/webhook

消息可能只包含一句：

“员工 123456 已被修改。”

ESB 收到通知后，可以先把它暂存在消息队列或 Data Queue 中，再过几秒或几分钟对 API 发起 GET，取回完整数据。 非常方便。而且会显著改变你思考接口的方式。

11 GET、POST、PUT、PATCH、DELETE……欢迎来到 API 世界

团队还需要掌握主要的 HTTP 方法。

嗯，这个名字本身应该已经给了你一点提示。 然后你会发现，API 的理论和实际是两个世界。有些供应商设计得很聪明，另外一些就没那么聪明。 为了改一个数据，有的供应商要求你：

1. 先 GET；
2. 取回整个对象；
3. 修改目标字段；
4. 再发送 PATCH。

也有供应商提供 upsert：一个调用就能在资源不存在时创建它，存在时更新它。 这个行业有约定，有最佳实践，也有标准。 以及供应商开发者周二早上突然决定采用的做法。 两种世界，你都得学会适应。

12 OAuth 与 Bearer Token 的奇妙世界

接着，团队会接触 OAuth、Client ID、secret、scope、token、refresh token，以及 Bearer Token。 还有一些文档，用五页解释怎样获得 token，却始终不肯明确告诉你应该调用哪个 URL。 这也属于工作的一部分。 如果团队刚开始学 API，记得把工具配齐。

13 Postman 很快会成为你最好的朋友

想摸清一套 API，专业工具几乎必不可少。 我个人经常用 Postman。当然，也有 Insomnia、Bruno、Hoppscotch 等替代工具。但在分析和集成阶段，Postman 确实很实用。 你可以把调用按文件夹组织起来，创建环境，保存变量，快速测试 GET，发送 POST，调整 payload，弄清楚 JSON 为什么被拒绝。 然后三周后再打开同一个目录，问自己：

“我为什么把这个请求做了六个版本？”

选择软件时，一定要索取 API 文档。最好是 OpenAPI / Swagger 规范。 如果供应商组织得足够好，还会提供一份对应关系文档，说明：

• 界面里显示的字段名称；
• API 中的技术字段名称。

看起来是小事。但当界面里的“所属机构”在 API 中叫作 org_unit_ref_02 时，你会非常庆幸手里有这份文档。

14 买标准软件，也意味着不能再什么都定制

用户侧同样需要经历转变。 如果企业决定停止定制开发、转而购买市场上的标准产品，就必须接受这个决定的后果。 你买的是标准软件，不是一支专门服务于你公司的开发团队。 售前阶段，有些供应商当然会说：

“没问题，这个可以给你们定制。”

小心，这未必是好消息。 如果产品一开始就支持干净、可维护的扩展，那很好。但如果所谓定制是专门给你们建一个软件分支，你可能正在亲手制造下一场大型灾难。 供应商想卖产品，很正常。开始时一切顺利。下一版本发布后，定制突然不兼容了。或者开发团队已经走了。又或者根本没人知道为什么会有这个分支。 与此同时，IT 部门一直让用户以为，他们还能保留与过去相同程度的定制。 这说不通。 到了某个阶段，CIO 也必须站出来坚持方向：

我们既然决定买标准软件，有时就得略微调整业务做法，去适应软件。

不然，还不如继续自己开发。

15 第一个真实项目：三库台球开始了

好了，ESB 选好了，新软件也选好了，项目开始。 一位用户来找你：

“我需要在这个软件里看到订单。”

简单。当然。把数据从那里拿出来，再放进这里。不难吧？ 于是，你打开 API 文档。 第一个问题：

它到底有没有创建订单的接口？

有。胜利。 第二个问题：

用户到底需要哪些数据？

订单号、供应商、明细行、金额、工地、机构、采购员、合同，还有财务负责人最喜欢的颜色。 总之，先列清单。 再回到 API 文档，你发现三个字段根本不提供。或者某个字段有，但只能读。又或者界面里有，API 里没有。 欢迎。

16 然后，真正的集成问题才开始

你要检查字段长度。ERP 允许一百个字符，目标系统只允许五十个。 很好。谁来决定砍掉哪一半？ 你还得导入基础数据。因为订单引用了一家机构，而目标软件还不知道这家机构。机构又引用一家公司，而这家公司必须先存在。 慢慢地，你会遇到集成信息系统中一个根本性的问题：

每一类数据，到底哪个系统是主系统？

接下来当然是：

哪个系统是从系统？

从这里开始，图就得画起来了。毕竟到了某个规模，再想把整个信息系统全装在脑子里，实在有点困难。

17 而且，日期格式当然不一样

你打开 Postman，尝试第一次写入。错误。再试一次。还是错误。 检查 payload 才发现，ERP 给你的是：

18/09/2026

但 API 要的是：

2026-09-18T00:00:00Z

很好。 ESB 培训时，没人教过你怎样转换日期。就在这一刻，你终于意识到：

“把数据从那里拿过来，再放到这里。”

可能只是对问题做了一点点过度简化。 你陷进坑里了。 但最重要的是：别灰心。 这完全正常。 因为你很可能同时在学习：

• 一个新 ESB；
• 一套新业务软件；
• 这套软件的 API；
• 有时候还有一个全新的业务领域。

东西确实很多。

18 开发者突然开始整天打电话

你还会发现，这份工作的形态发生了一种意想不到的变化。 以前，开发者拿到需求，然后开发。现在，集成人员整天在以下角色之间来回穿梭：

• 业务用户；
• 软件项目经理；
• 供应商开发者；
• ESB 技术支持；
• 有时还有基础设施团队；
• 以及不断自问“我当初为什么不去开面包店”的自己。

因为想推进项目，就必须不断拿到答案。 这时，你大概会发现 AMOA 非常有用，也就是有人专门协助业务方澄清和组织需求。 总得有人过滤、梳理用户请求，避免集成人员把 50% 的时间花在组织会议上。

19 预计三天完成的流程，最后做了三周

这件事也得做好心理准备。 纸面上：

“这个流程？三天。”

从技术工作量来说，可能没错。三天开发。 但在这三天之间：

• 你在等业务回复；
• 供应商还要确认某个问题；
• API 缺一个接口；
• 用户略微改了一下需求；
• 需要新建基础数据；
• 项目经理在休假；
• 得找人开防火墙；
• 供应商开发者下周二才有空。

20 售前承诺和真实 API，有时隔着一个宇宙

售前阶段：

“放心，我们的 API 什么都能做。”

三个月后：

“其实呢，那个接口只给我们自己的移动应用用。”

很好。 你开始跟供应商一起翻文档，渐渐发现：他们内部似乎也没怎么真正用过某些接口。 有时，你会产生一种很微妙的感觉：自己正在给一款付费 SaaS 的 API 当 beta 测试员。 你同时是：

• 客户；
• 集成人员；
• 测试人员；
• 差不多还是供应商的技术顾问。

而到了月底，许可证账单当然一秒不迟地送到了。 总觉得自己像那个被当冤大头的人。 这种感觉，很有意思。

21 过几年，你挑软件的方式会彻底改变

随着经验积累，我们改变了启动新项目的方式。 现在，从售前阶段开始，我就要问：

有 API 吗？

然后：

把文档给我看看。

再然后：

所有业务功能都能通过 API 使用吗？

最后：

到底有多少客户真的在用你们的 API？

最后这个问题很重要。因为下面两句话，差别巨大：

“有，我们有 API。”

以及：

“有三百家客户每天用我们的 API 同步他们的信息系统。”

我还会尽早找供应商那边真正的技术人员聊。不只是销售，不只是项目经理。 而是能打开 Swagger、能与集成人员讨论接口的人。 这样有时能少受好几个月的罪。

22 写文档，画图，把字段映射做清楚

这可能是我最想强调的建议之一。 把流程写下来，把图画出来，明确记录：

• 主系统；
• 目标系统；
• 触发条件；
• 交换哪些数据；
• 需要什么转换；
• 依赖哪些基础数据；
• 调用哪些 API；
• 可能出现哪些错误。

尤其是：

把字段映射写清楚。

源字段。目标字段。类型。长度。转换。是否必填。默认值。 一开始可能觉得很费时间。但六个月之后，有人问为什么工地编号被发送到 ContractId 时，你会庆幸自己留了 mapping。

23 把接口拆成“半流程”来思考

这是我们逐渐学会的一种方法。随着信息系统规模增长，它会变得非常有价值。 不要只想着：

软件 A → 软件 B

试着用半流程来思考。 例如：

ERP → ESB 内部的标准化订单

然后：

标准化订单 → 软件 B

这样，你的集成层里就有了一个干净的“订单”对象。 明天，软件 C 上线，也需要订单。你不需要重写从 ERP 取数据的全部逻辑，只要开发：

标准化订单 → 软件 C

之后软件 D 又来了。还是同样的思路。 你开始慢慢理解，ESB 为什么值得做。 同一份数据，从主系统只取一次。转换成自己掌握的格式，也只做一次。然后，它就可以发往 N 个应用。 不必为了反复获取同一种信息，一遍遍复制粘贴晦涩代码。 你的信息系统，终于开始具备真正的集成架构。

24 再加上 webhook 和消息队列，整个系统开始提速

现在，加上 webhook。 ERP 修改了一张订单，发出事件。事件来到 ESB，可以先在队列里存几秒。流程取得数据，更新内部对象，然后向各个订阅系统分发。 修改后的几秒钟，或者几分钟：

数据已经到处都有了。

这时，公司里有些事情开始变化。用户慢慢不再问：

“接口什么时候跑？”

因为接口一直在跑。

25 突然之间，日子居然有点舒服了

数据在流动。

监控集中管理。

流程失败时，你能看到。

团队可以在白天处理问题。

集成人员不必再维护用十二种技术写成的一百五十个程序。

数据是新的，业务部门满意了。

那位三年没理你的会计，开始问你假期过得怎么样。

你睡得更好了。

天空里出现了独角兽。

你开始怀疑，是不是有人往咖啡里放了什么。

但相对于处理规模，系统本身的 RUN 工作量已经变得非常低。 说到底，这正是我们当初想实现的目标。

26 那么，我推荐 Best of Breed 吗？

推荐……但不是仅仅因为能买到更好的软件。 Best of Breed 对信息系统的改变更深。它会改变架构，改变团队，改变开发者的工作，改变软件选型方式，改变 IT 与业务之间的关系，也改变你思考数据的方式。 最重要的是，它逼着你把集成当作真正的内部产品，而不是让某个开发者夹在两个工单之间随手写的一段代码。 要有耐心。要接受犯错。要多画图、学 API、挑战供应商、写文档、做监控。 刚开始时，大概总有那么几个瞬间，你会认真问自己：我到底为什么要折腾这些？

但一旦最初的基础搭好，后面就会开始加速。每条新流程都能利用以前的成果。每次新集成都丰富技术资产。每个标准化好的业务对象都可以复用。 渐渐地，信息系统不再只是一堆各自独立的软件。

它真正变成了一个系统。

这也许才是 Best of Breed 最有意思的地方。