可能Anne Thomas Manes曾经宣称“SOA已死，”但是在2012 GartnerApplication Architecture, Development & Integration（AADI）峰会上，她说这是应用设计新纪元的关键。

　　“现在我们具备了所有力量，可以驱使我们改变我们设计架构的方法，”Gartner杰出的副总裁Manes这样告诉在拉斯维加斯凯撒饭店的与会者。“你可能不会有效地支持‘连接力量（nexus of forces）’，除非你改变你的架构服务方式。”

　　所谓的连接力量—盛行于本年的AADI大会上—代表着移动、云、社交和信息的融合，Gartner所说的趋势正在从根本上改变IT组织。

　　“整个行业都清楚的意识到这个事实：移动宽带开辟了一个新的联系，一端连接着用户和员工，另一端连接着应用和信息资源，” Tom Nolle说，电信和媒体策略公司CIMI的总裁。

　　尤其，Manes看到这些力量聚集到一起，需要越来越多的用户驱动的方法来为之服务。关键在于要从业务目标开始，并把用户放在心上，她说。

　　“你需要考虑你的服务正在努力支持的东西，”她解释说。“特定服务的业务目标是什么？服务用户将会怎样使用它？他们期望从中获得什么样的功能和能力？”这些问题的答案应该形成所有创建新服务的基础，据Manes所说。

　　尽管它可能是现在才获得青睐，但这个观点早就不新了，Robert Daigneau说，他是Blue Metal Architects公司服务器应用程序部主任。“心里要明确设计的服务的目的是什么——它们是如何被消耗，”他说。“但那些在SOA世界已经深深陷入到治理第一的理念中——对产品有很强的控制力。”相反，他说，架构师们首先要看一看他们客户的需求。

　　Manes强调SOA方法论是这类服务模型的关键。“像SOMG，Everware-OCBDI，SOMA和SODA这样的方法论强迫你去考虑使用这些服务的人们和可以使你实现他们想要的功能和支持活动的产品，”她说。

　　她承认虽然许多已经致力于SOA许多年，但有一些人还没有采用SOA设计模式，她说在今天这对建立正确的服务很重要。“当你在模型化服务时，你努力达到是一组业务目标，”她解释说。“你进行面向服务所使用的流程是通过运用一组原则实现，这可以帮助你达到那些目标。我是怎样实际运用这些原则的？是通过使用已定义的设计模式。”

　　她说，没有设计模式，SOA将不会支持快速修改，人们将会继续创建新的应用，与前辈旗鼓相当——但常常会慢于中间件。“将会发生的是人们会替代中间件，而不是设计他们用来创建应用的设计模式，”她说。“当你在设计服务时，你必须应用SOA设计模式。”

　　但是行业观察家也警告说SOA设计模式并不适用所有的服务构建方案。

　　“许多人说‘让我们运用设计模式’，然后他们就找地方去运用他们。这并不是他们真正打算使用的方法，”Daigneau解释说，他的书《Services Design Patterns》探索了常见服务设计挑战的解决方案。

　　“没有像现在一样对使用设计模式有更大的需求了——他们一直都是很有用的。了解什么进修使用什么样的模式是最重要的事，”他继续说。“关于移动，云和大数据，有比其他人更适用的特定模式。”

　　在某些方面，使用设计模式来架构服务在连接力量里是一个未知领域。主要的挑战：关于怎样在云中成功创建应用仍然存在大规模的问题，据Nolle所说。

　　“直到你建立一个实施构架，你都不能真正的深入了解SOA设计模式，”Nolle说。“当你与云服务进行交互时，事实上，移动设备的基本经济性和性能限制对于它连接到复杂流程，给用户发送一些东西的方式有重要的影响。”

　　Manes说，但是在所有事情之间，现在的公司要有能力决定什么样的服务才是需要的，为什么他们是必要的以及他们将会用在哪里。过去，IT组织不是采用自顶向下的方法，就是自底向上的方法来决定创建哪一个服务。

　　“自顶向下的方法是用在当一个大的SOA活动组聚集在一起，并说‘我们必须鉴别出所有我们需要创建的不同的服务’，然后一次性创建整个服务投资组合，” Manes在AADI峰会上对她的听众这样说。

　　自底向上的方法却是不一样的，它开始于项目层，它通常集中在一个特定的业务目标或消费者的需求上。

　　Daigneau指出自顶向下的方法存在很大的陷阱。“如果你试图把所有的都展开，并说‘让我们设计出所有我们可能需要的服务’的话，那么这就是一个错误的方法，”他说。“它经常会有一些你预想不到的新东西，或你误解的一些东西，因为你的信息太少了。相反，要看看项目的个人需求和用户方面的务实方法。为特定的需要鉴别和列举服务；然后随着业务的需求来引入服务。”

　　从这种方法中选择一个备选方案，Manes建议结合两种方法，作为处理服务架构的新方法。

　　她说一个实用的方法是作为项目的一部来解决服务实现的机会—更像是自底向上的方法—但也要有企业架构团队贯穿该服务投资组合之中，来识别需求和方法，从而使之加强，就像是处顶向下的方法。