《Ladder to SOE》作者访谈

SOA 的基础前提是业务活动和软件模块的对齐，这些模块提供了支撑业务活动的具体服务。但在实践中，SOA 太多时候几乎只是作为一种模块化、重用和建立软件架构的技术被实现。而经常忽略了用 SOA 联系业务和业务流程，包括尝试应用 SOA 知识去再造或优化业务。

Michael Poulin 的新书，《Ladder to SOE》，聚焦于企业以及如何使用面向服务的概念和原则实现对齐 IT 和业务，为集中解决业务问题提出了新的可能性。它的目标是提供一个通向面向服务的企业的一系列步骤（“梯子”），而面向服务的企业是在整个业务和技术中贯彻面向服务的原则而建立和运行的。

随下面的采访一起，Michael 还提供了新书的两个样章。样章1 出自本书的第4 章，分享了一些关于SOE 何以支撑业务创新的思考。样章2 出自本书的第7 章，它更多地侧重于SOA 的技术面，及其在SOE 中的应用。

这次访谈分享了一些关于Michael 著作的其它背景和评论。

Michael，你认为，相比起 SOA，SOE 以及甚至 SOBA 在本质上都是大不相同的，范畴要更广泛。但很多人会说，SOA 的目标就是广泛性，这 3 个术语其实并无分别。你的说法是建立在对 SOA 的理论分析之上的吗？或者这种理论在实践中是如何被实现的？

SOA 最初被描述为一种面向服务风格的架构，属于技术圈的知识。这当然就是它与 SOE 及 SOBA 的不同之处，SOE 代表的是面向服务的企业，而 SOBA 则表示的是面向服务的业务应用或面向服务的业务架构。由此看出，这 3 个术语至少在它们被应用的主语上就不同。 至于广泛性，则是一个稍有不同的话题了。我认为 SOA 作为一种架构风格，在它与某些技术（如 Web 服务、CORBA 等）发生联系之前，并不能被正确理解。随 Web 服务出现而至的标准风暴恰恰遮蔽了这种架构，甚至使其变得模糊不清，导致很多人开始认为 SOA 和 Web 服务是一码事，而实际上它们却不是。我们必须区分架构和技术，技术只是被用来实现架构的。

在“SOA”保护伞下的技术实现的实践撞到南墙之前，甚至在它完全替代了架构的场合中宣布其“死亡”，还是花了几年时间。这没有什么大惊小怪的，因为技术承诺的结果只能在架构级别实现，即单靠技术并不能交付这些承诺。

在 SOE 或 SOBA 中，面向服务的业务位于中央，所有问题都处于业务范围之内；架构是位于企业级别的业务骨架，并不涉及 IT。这种面向服务架构具有业务和技术两面，但技术是作为业务实现的一种形式出现。

SOE 使所有的事情变得有序起来。这就是为什么它比创建服务的技术努力更广泛的原因，对于后者，消费者（运营业务）并没有意识到要把精力放在流程和过程之上。

SOE 的本质似乎是一种真正意义上的 IT 和业务之间的合作。你能简要地指出为何这种合作在过去是如此难以实现，以及为什么你认为 SOE 可以成功地建立这种合作？

在历史上，IT 是作为一种公司内业务的支撑功能而开发的。当我们给大型机添加 PC，以及在技术由客户 / 服务器模型转向多层分布式结构的时候，这种“支撑者”的角色并未改变。过去几年间，在几个行业内，技术成为传统手工业务的基础部件变得明显起来，这些技术开始替代手工操作。此外，对于行业来说，处理交易、速度、准确性、传输质量，以及信息的分发成了一个重要的成功因素。换句话说，有迹象表明：技术“赚钱了”，无论业务是否喜欢和同意这个说法。 在 SOE 中，面向服务的企业组织结构的前提是业务和技术合作运行，它们彼此服务，不断融合。要不然，我们就不能在市场中实现高效的业务服务。某些组织已经意识到了这种新的形势，开始将 IS/IT 作为合作伙伴对待。但是，业界还并未对此有很好的认识，我期望我的书将有助于改善这种情况。

从畅销书单上看，企业似乎更关心变革、创新、适应性和敏捷，过去几十年里，它们一直受困于流程、质量和标准。为什么要改变？你认为这将使业务方更容易接纳你的建议么？

不错，你说得对，在业务目标上是有重大改变。除了人天生倾向于为每一步都制定一些指令，保持大脑对新鲜事物感兴趣之外，我无法解释对流程的迷恋。这些流程和标准化适合市场的步调；市场允许这样的行为。正如我前面所说，市场动态已经改变，在加速，并且现在全局因素和局部因素一样对它有影响。我认为这些是变革、创新和适应性的关键驱动力。 SOE 利用了面向服务模型的潜力来组合、重组和分解服务，以应对外部和内部环境的变化。也就是说，面向服务是适应变化的一种最佳机制，同样也适用于各个业务创新。在我的这本书中有一章专门讨论这个话题。

关于“敏捷文化”已有大量的文章和书籍发表和出版，它与传统的 IT 文化有何不同，是不同的价值观、对个人和团队的不同态度，还是强调产出等等？你能将 SOE 文化和敏捷文化比较一下，并说说你何以认为你可以让整个 IT 去经历一种文化上的转变？

在我看来，当 IT 说到“敏捷文化”的时候，它指的是对于业务需求的敏捷，这些需求跟公司业务需要未必相同。这种“敏捷文化”基于这样一个概念：我们在这里，他们在那里。SOE 保留了业务和 IT 的专业地位，但它消除了业务和 IT 之间的界限，不区分你我。 我可以说面向服务找到了业务 -IT 敏捷的基础，或者说二者在 SOE 中汇聚在了一起。我的结论是：既然市场中的业务动作给消费者提供了服务（产品只是这些服务的结果），既然业务本质是通过组织业务模型表达出来的，既然面向服务的原则可以被技术理解和实现，那么以业务和技术为基础的面向服务文化就可以建立起来，并分享它的价值观、观点和精神。

你谈到需要合适的简化和实现它的困难程度。SOA 远不简单：它很庞大、复杂，并且相对脆弱。SOE 何以会更简单？企业是一种“简单的”东西吗？在我们成功地找到一组简单、可组合的服务之前，是否需要从不同的视图来指导我们对业务和服务的分析呢？

是的，SOA 与其要建模的业务一样复杂。我并不认为消费者市场是复杂的；而实现这样的市场则要复杂些。我已经提过消费者市场，因为在面向服务的生态系统中是消费者在“运球”，而提供者则应该为赢得消费者而竞争和拼搏（这对企业架构范畴有重大影响）。 在本书中，我认为用技术去解决服务实际上是对现实的过度简化。就现代 SOA 来讲，尤其是在 OASIS SOA RM 发布之后，我们可以解决大多数技术实现的复杂性和脆弱性，它们中的大多数都被错误地归结为 SOA。

我用来标识服务复杂性的方法是以分解组织业务模型为基础的。顶层业务服务和一些流程可被连续分解成更简单的服务和流程，直到从业务角度看进一步的分解已没有意义。我（的分解）在这个位置停下来的原因是，更细粒度的服务只是实现的技术细节，潜在的消费者（业务）从来不会需要它们，因为它们已超出了业务范围。因此，我的建议是不要使东西比它本来的样子更简单。

在第 7 章，你给出了几个服务的关键定义和技术。你还谈到了这些服务的技术属性是如何交互的。你能谈谈这些属性中相对重要的东西，以及过于强调其中一个是何以可能会影响交互和相互支援的能力？

好的，在这一章中，我讨论了服务属性，如服务描述、服务契约、真实世界效应（Real World Effect）、服务水平协定、执行上下文，面向服务和服务激活。我的解释基于 OASIS SOA 参考模型标准以及即将面世的 OASIS SOA 参考架构草案（公共复审版）。所有提到的属性都从服务消费者的角度进行了检查。 所有这些属性都重要，但对消费者和提供者来讲表现是不同的。例如，一个服务提供者可能只维护一个服务，但为不同消费者群公布多个服务描述，同时每个服务描述可能用来创建多个服务契约。同样，还有一些情况下服务身份并不需要消费者的同意，如系统安全服务这样的强制性服务。在这种情况下，服务描述可能是针对每个消费者的一个缺省服务契约。

你能说说在 SOA 的实践中过于强调服务的某个方面或属性的缺点吗？

在 SOA 被认为是一种集成技术的日子里，开发者（甚至连架构师）都把服务接口认为是与外部世界签订的服务契约。我得承认，10 年前我也这么认为。在 SOA 跨越 IT 的边界进入业务领域之后，技术接口的角色变了。这些接口仍然是与服务进行交互的最重要技术元素。但是，现在 SOA 服务是由服务描述来定义的。 虽然服务实现是对消费者隐藏的，但是服务的业务功能和执行上下文必须象所有可应用的业务和技术策略那样被公开描述。对不同的通信渠道（包括直接的人类接口 ——GUI），一个业务服务可能有多个不同的接口。也就是说，关于服务的整个公共知识要比它的接口所能提供的要广泛得多。在我的书以及其他出版物里，我都试图说服开发者去全面的观察服务，而不是只集中于接口。相同服务的行为，甚至是业务价值，都可能因为应用策略在不改变接口的前提下发生变化；这不应该是我们要守口如瓶的秘密。

在 13 章，你给出了向 SOE 转型的梯子，共计 21 个阶梯。梯子暗示了相当严格的步骤序列。你认为这 21 步必须按顺序进行吗？或者存在同时进行的可能？这种转变要求 IT 停下手头的工作，开始爬梯子，然后沿 SOE 道路前进么？

不是所有向 SOE 转变的步骤都要顺序完成；它们中的一些必须马上通过，以并行的方式。我使用“梯子”而不是“阶梯”或“道路”，而是想说明这些步骤必须被组织利用，它们并不是独立于攀爬者孤立存在的。SOE 之梯是从业务开始，而非 IT。爬入面向服务，在转变触及 IT 之前，要求完成在组织、所有权、资助、运营和管理中的几个转变。

OMG 最近联合赞助商 IBM 一道宣布了业务生态系统项目（Business Ecology Initiative）。就这个声明而言，几乎没有什么细节和实质性的东西，但它似乎同样关注于你所提倡的业务 -IT 集成？这是个“时代的征兆？”或 “IT 中下一个大事件？”你认为你在 SOE 上的工作能给 OMG 的努力（一旦我们真的搞清楚之后）做出重大贡献吗？

我认为这是一个“时代的征兆”，如你所说；我们各自得出了相同的结论。我的书描述到达 BEI 目标（消除业务和 IT 的界限）的一种可能的道路。由于缺乏关于 BEI 的更多细节，我无法判断 BEI 中意的解决方案是否跟我描述的相同。但要是我的方法对 BEI 的进展有帮助的话，我高兴还来不及呢。

本书中有什么内容或观点你想要 InfoQ 的读者特别关注一下？

是的，有一个。我认为，在 SOE 中，IT 的生活将会变得更轻松高效。它也会减轻压力，更能预见业务需求的出现，它们不再是突然一下冒出来的。相反，由于创造性地职业之间的协作，这些需求将通常在早期阶段就被观察到。结果，公司会更高效、更稳定，IT 不再只被作为成本中心来对待，反而将成为一个积极的合作者和业务解决方案的提供者。

非常感谢，Michael。读者可以从他的网站对Michael 以及他的新书有更多的了解。

查看英文原文： Book Review: Ladder to SOE 。

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。