将其应用于各处！
融合助力
您是否需要整个整合团队，或者如果有人关注您的工作方式以进行优化驱动是否有价值？我们很乐意利用我们多年的知识和专家团队来减轻贵组织的集成负担。请联系我们，进行一次探索性会议，我们将共同讨论如何为您提供最 喀麦隆 数字数据 好的支持。
如何引发麻烦
“他跳过了 SOA 项目生命周期的第一阶段。而且它也被称为关键阶段。”是的，我确实跳过了那一个。这是因为，作为一名顾问，我从来没有参与过这个第一阶段。既然您提到了这一点，那么现在也不是。通常，我在服务库存蓝图尚未绘制但另一张图已经绘制时就开始了。从那个蓝色方形大图中，我被要求设计“服务”或“API”。我的回答总是：“什么服务？没有。这些只是线路。”然后用户故事就出现了：系统 A 需要来自系统 B 的信息 X。所以我想出了一个我能想到的最佳名称作为服务名称。两个冲刺之后，另一个系统需要或多或少相同的数据，但使用另一个键，不需要这三个字段，而是需要那五个额外的字段。那是相同的服务吗？或者我应该发明一些其他的名字来或多或少地解释我们在这里所做的事情？
正如你所见，麻烦很快就随之而来。
技术人员聚会
为什么首先要画出这个蓝色大方块呢？根据我的经验，这与一般项目范围有关。尽管 SOA 的假设是公司最大的愿望是将业务人员与 IT 人员协调一致，但实际情况是大多数公司项目都是只邀请技术人员参加的聚会。一个普遍可识别的项目范围是“将这个大系统升级到Y版本”。这显然只是技术性男女的事情。没必要让我们的商人为此烦恼。但请稍等一下！在升级时，这些技术人员应该真正遵循我们最新、最伟大的架构原则：现在一切都应该是服务！因此，我们的旧系统与系统 X 的数据库有直接联系，现在这应该是一项服务！我们的旧系统与系统 Y 之间存在一些文件传输功能，现在这应该是一种服务！
此时，项目范围已不再可协商，因为预算已经确定。这绝对不允许任何商人参与，因为当我们决定预算时，我们唯一想要的就是升级这个大蓝色广场。这里有线路，只需提供服务！
回到黄砖路
在阅读完本文的一半时，我已经解决了刚才描述的问题。那么，猜猜我要提出什么建议？不，不要从服务库存蓝图开始。这是 SOA 项目生命周期的第二步。从第一步开始：问自己问题。例如：您的（整个）公司现阶段是否已为 SOA 做好准备？您的项目范围是否全是关于技术，或者您是否已准备好开始处理业务问题？治理是否到位？有哪些风险？换句话说：尽早考虑集成，并且在绘制大蓝色方块图之前一定要考虑集成。