帮助管理者和客户了解SOA

Question

我经常听到面向服务的体系结构（SOA）作为非技术客户或项目经理之间的流行语而被抛弃，对实际需要的内容几乎没有关注或理解（例如：“我可以购买SOA吗？”）。还有很多关于SOA的错误信息（例如：“只有Web应用程序可以使用SOA”）以及对其功能的普遍缺乏理解（例如：“SOA可以使您的所有数据一起工作”）。

作为理解SOA技术方面的人，您有哪些关键事实用于教育项目经理如何正确使用和理解SOA？设置记录的最佳方法是什么？直接与非技术人员？

Answer 1

对于非技术人员，我会使用以下概念。整个专业领域以服务为导向。

• 而不是通过烘焙饼干 亲爱的，你去面包师。
• 而不是试图治愈自己， 你去看医生。
• 而不是编写程序 请程序员为此执行此操作 你。

这意味着两大优势：

• 每个人都比他做得更好 我们都试图解决所有问题 任务分开。
• 有一种方法，允许非 专业人士与之沟通 那些将解决我们任务的人（在 现实世界就是金钱和金钱 商业合同）

在软件世界中，通过定义专用于执行特定任务的专用服务（应用程序）并通过定义协议来实现这种体系结构，这些协议解决了这些应用程序之间的通信问题。 部署此类体系结构后，您将获得一些好处，这些好处也可以映射到现实世界：

• 如果医生不在，你就不能 被治愈，但至少你可以得到一个 来自面包店的饼干！在软件中，这意味着一个失败的服务不会破坏整个系统。

• 通常医生和面包师不会共用同一个房间，这样可以让他们更好地操作。就像在软件中一样，您可以将每项服务放在自己的硬件上。

对于软件世界而言，这意味着更好的可用性，可维护性，重用性和降低的成本。 祝你好运！

Answer 2

“当工作对于当前团队来说太大时，SOA就像招聘新员工一样。”整个系统的每个部分都与员工类似。经理了解员工;）

Answer 3

也许您的公司有一些应用程序可用作演示。

尝试向他们展示大量依赖松散服务的大局，其中包含各个团队创建的一些常见需求/功能，并提取这些嵌入但常用的功能并将其用作服务提供商。

我想到的另一件事是向他们展示服务可以用来进行通信的各种连接器（也许有一些非常古老的屏幕抓取传统应用程序）。此外，需要澄清具有规范化和事务处理的消息总线概念。在我看来，非技术人员应该将整个SOA概念视为松散耦合的服务，它们通过任何类型的消息相互交流，其中服务由不同的团队编写/管理/管理（因此正式的服务声明和SLA可以派上用场）

尽可能避免提及供应商。或者为每个部分提及许多供应商和技术，以向他们展示各种选项。