Kerrie Holley在五十多个SOA项目中是不可分割的一部分，其角色从设计师到总架构师。他拥有多项SOA专利。目前他是IBM的员工，Holley监管成百上千个SOA项目的技术方向。最近他关注通过业务规则、BPM、分析和SOA的使用增加业务灵活性。为了达到这一目标，Holley和他的同事Ali Arsanjani博士共同编写了《SOA百问百答》（100 SOA Questions Asked and Answered）一书。SearchSOA.com有幸同Holley进行了对话。这是此次对话的第二部分，在第一部分中，我们探讨了《SOA方法和服务识别》，这部分中，我们将讨论面向对象编程如何适应SOA，请继续关注更多内容。

　　在书中，你声明“SOA是一种旅程。”但是敏捷实践者过去经常用短跑代替长途旅程。从这方面来讲，SOA和敏捷是否一致呢？

　　我认为我们完全可以找到认为这两个事情是冲突的实践者。一些人将SOA看做行军，可能甚至是一种死亡行军，取决于他们如何实施。我想看一下问题，这种方法并没有给我们观察为什么人们正在使用SOA的机会。

　　例如，我曾经在一家公司工作，这家公司是敏捷开发的极大支持者。但是他们所面临的问题是敏捷归根结底是催化上市时间。然而，如果他们广泛地成功了，他们的产品成功（准时和符合预算）上市，随后他们不得不回去修改产品，他们还敏捷吗？他们仍旧能够就他们所做的回去使用敏捷方法作出更改吗？答案很可能是不。

　　这也正是组织把SOA看做一种旅程的原因。这并不是“让海洋沸腾”的问题。我们不能够马上去看每一种事情。但是我们会问我们开发生命周期中的元素是什么？治理的部分是什么？方法的部分是什么？业务和IT之间的关系的部分是什么？我们要调整架构的哪部分，不是切割和取代，而是调整?为了让这些价值命题回归真实。

　　这些都是SOA要处理的问题。然而，我们会发现组织对他们的结果感到失望，无论是SOA还是敏捷。我们会发现组织说他们尝试了敏捷，这就是一种“黑客天堂（很容易被黑客闯入的计算机系统）”，开发人员逐渐发狂了。我们也会发现组织高度成功；我们发现共同之处就是SOA以及每一次人为尝试。答案不是打击A或者B，但是要理解如何产生价值。

　　我说SOA是一种旅程的意思是我们将要不断地用例拉动流程。我们不是今天就做或者明天就做。可能是完全的六到十个月，我们将为变化寻找一种新的技术或者方法，我们会为其添加SOA。我认为SOA作为IT市场逐渐补充了我们的知识体，结果，这成为最佳实践，SOA不是你马上就能应用的。你可能经常应用，这就是我为什么将其称之为一种旅程的原因。