Rick Sweeney是最近新书《实现面向服务架构：应用企业架构的方法》（Wiley, June 2010）的作者，也是位于Massachusetts 的蓝十字蓝盾Blue Cross Blue Shield的前任首席架构师。他同时也是医疗行业SOA和SOA管理厂商社团的积极推动者。这是对其总共两段采访的第二部分。在第一部分中，Sweeney讨论了架构驱动的SOA范例，以及阻碍这种方法应用的原因。本文是第二部分，Sweeney谈论了架构驱动的SOA对文化，组织架构和操作方面的影响，以及为什么SOA架构师需要积极参与和领导这一实施。

　　为什么你认为架构的限制会阻碍SOA的采用？

　　Sweeney：一个原因是架构如果不成熟，会阻碍SOA的实现；另一个原因是，有很多阻力会影响采用/解决这些架构相关的问题。如果厂商想卖给你一套ESB，他们会告诉你“这是一个很容易实现的东西，从现实中看来，这只是一个具有短期价值的短期成果”吗？ 他们不会告诉你最好去建立一个架构，去建立竞争力，因为这将花费更多的时间来交付。技术绝对不是问题；技术固然很重要，但那只是一个工具。首先你需要有一个架构，然后再在架构上面应用工具。实际上他们是分开的。

　　你看一下SOA成熟度模型：从试验到文档化的操作过程，然后是可重复流程级别；一旦你能够在未来的开发中保护先前的投资，你就实现了真正的价值。大多数公司尚未达到这个级别。很少几个公司能实现可重复级别的人员，实践经验，流程和平台管理。

　　面向服务架构方法是如何影响文化，组织以及运营的？

　　Rick Sweeney：业务部门不再拥有控制权了。在传统的IT工程项目中，每个业务部门负责它想做的一个工程。发起部门控制和主导着所有的产出结果，好像它控制相关的任何东西一样。当转向SOA时，你不再控制着任何东西——你利用既有的和新创建的组件，因此责任/所有权的范围大大超出以前了。

　　这是一个很大的文化上的改变。就象你从自己家的房子搬到了一个公寓一样，你多了一些便利条件，比如说有了修好的车道。但另一方面，你不能随意地将前门涂成你喜欢的颜色，也不能增加一个车库。这是一个文化的变动，原来是你自己的私有财产，你想干什么就干什么；现在在公寓中，外面的所有一切都不在你的控制下。

　　从IT的方面来讲，这不再是一个单一的工程。在SOA中，一个工程需要多个团队的合作才能完成：一个小组在改进通道层，一个小组在构建新服务，一个小组负责集成事宜，或者一个小组可能在改进多个通道，一个集成小组把所有部分集成在一起。和传统的工作方式相比，SOA的实施并不那么直观。

　　从组织结构上讲，项目经理，不再只监管一个项目，现在可能是一个矩阵，所以所有的集成，所有的通道改进等等都一次提交。一个项目包含多个不同的组件，软件生命周期流程需要依据以下而变：需求如何收集，如何编码，以及在组织架构方面人员/技能/角色如何变化。

　　从操作角度来说，如何部署以及如何测试，这些都不一样了。当你部署SOA时，如何管理在部署方面的变化，这同样也发生了变化。

　　你说SOA架构师需要承担最大的义务，做绝大多数工作。你能解释一下为什么吗？

　　Sweeney：SOA的有效实施是非常复杂的，并且需要大量的改变和转换。并且，这是随着时间而演变的。SOA架构师应该最理解其复杂性，什么需要改变，以及如何改变。架构师需要是协调者，指导者，在很多情况下，是实施者。在传统的企业组织架构中，架构师是在象牙塔中：“我们只管设定标准，如果没有正确的实施，那不是我们的错”。

　　对于SOA，人们都在努力将它建设成为一个全新的东西，因此，架构师需要去引导和辅助他们。SOA架构师一个很大的责任就是实现这个计划。这种引导和帮助是多个方面的——沟通所要满足的需求，知道如何去指导运营操作的管理，如何指导中小企业，设计人员，开发人员，测试人员，因为他们各不相同。架构师需要将他们从舒适区中拽出来，指导他们，推动他们。如果你简单将任务交给他们并由他们自主决定，并因此导致了最后的失败，你就再也没有机会去挽回了。