IT部门之外的大多数企业雇员在一个团队中、一个部门、一个单位或某种类似的分级结构中工作。这种组织模式很长时间一直有效地适应大企业、政府和军队的需要。可以理解的是，在这种组织结构中的人通过这种体系中他们所处位置的环境看世界。但是，当IT解决方案要求来自企业各个部分的代表的意见时，这种组织结构给SOA带来挑战。

　　分级机构对SOA的冲击

　　IT部门之外的大多数企业雇员在一个团队中、一个部门、一个单位或某种类似的分级结构中工作。这种组织模式很长时间一直有效地适应大企业、政府和军队的需要。可以理解的是，在这种组织结构中的人通过这种体系中他们所处位置的环境看世界。但是，当IT解决方案要求来自企业各个部分的代表的意见时，这种组织结构给SOA带来挑战。

　　软件世界经过许多年发展成熟到了分析与设计成为非常细化的流程的程度。IT世界中的多数人目前相当熟悉用于收集业务需求和开发系统架构的主要技术。主题专家(SME，有时叫做领域专家)的角色现在在软件开发项目中很常见。这一角色很好地服务于构建传统上满足业务单位需要的业务线系统――软件竖井，如果你愿意这样称呼的许。直接利用业务专家的知识使开发团队可以开发契合业务单位需要的解决方案。这个流程绝不简单，但它至少是常见的、得到充分了解的。

　　部门利益或影响SOA整体实施效果

　　一个独特的SOA挑战是它需要将来自企业各个部门的SME召集起来。SOA构建一个新的协作的知识基础，描述企业如何在一个高于单个业务线之上的水平运行。来自每个业务线的代表必须参与分析SOA的需求和能力。如果每个业务单位拥有自己的IT人员，这种人可能也要参与。

　　这不只是让更多的人提供意见、解释自己部门的需要的问题。随着参与这个分析过程的人员数量的增加，观点的数量也在增加。业务单位代表可能看到被他们亲近自己的业务单位所歪曲的分析，而忽视其它业务单位的观点和需要。这实际上是意料之中的，因为每个人都在他们熟悉的领域中发挥作用，可能没有意识到其它领域并不以同样的方式运行。通常，SME是自己所在部门的领导人，可能持一种“一切都是关于我”的态度；这里的“我”实际上就是我的部门。这种态度很少是有意的，但代表着我以前写过的SOA和集成项目中相当常见的系统偏见形式。我喜欢会与许多代表一起开会，以鼓励参与者看到更大的图画。

　　在我从事的行业中，我常常参加有来自财务、会计和运营(售后)以及IT的代表参加的会议。这些团队成员都对企业中的某一数据流有着独特的观点，但每个成员只看到一个部分。这种数据的陈述对于每个部门是不同的，但基础实体是相同的：订单和相关财务数据。

　　财务人员通常关心收入如何计账，收益如何计算。会计人员实际上不关心这些细节，而希望确保总账准确反映财务的意图，满足GAAP(通用会计准则)和审计要求。运营团队一般更关心让订单通过批准流程和外部系统之间的流动，常常不知道会计或财务人员对财务方面的看法。当财务部门认可可能部分收到的收入时，常见的冲突出现了；会计人员说这违反了他们的GAAP；运营人员说你不能在不破坏他们的流程的情况下分割订单。同时与这些代表讨论这些问题使他们可以了解其它部门如何对待同样数据的不同方面。当来自每个业务线的领导人面对其它业务线的现实时，这常常软化他们对妥协的抵制。最后，他们都在同一个团队中。

　　按照定义，SOA旨在将人们联合在一起来构建用于整个企业的系统。这导致另一个问题：个性差异对群体动力的影响。这种情况只会因许多代表参加的这些会议而变得更糟，因为邀请所有人参加的原因是他们的不同需要。很常见的是群体中的某个人(这个人通常能言善辩或深受尊重)获得对出现这类会议的设计决定的不适当的影响。为了消除这种影响，我希望混合大小群体会议以及一对一的后续会议(或预备会议，但这要小心)。这样做有助于过程中出现的筛掉大量的信息和分歧的观点。这种群体动力影响在跨国企业中甚至更加显着。

　　沟通障碍对SOA的影响

　　最后的问题是传统软件分析中的常见问题：沟通障碍。一个问题的答案可能由于问题的提出方式会差别很大。这可以是基本交流技能和提出问题的语境的结果(就我而言，语境是交流的一部分，因此也许我这里赘述了)。当讨论已有流程的细节时，询问抽象的问题常常生产一个过于具体的答案。即，答案可能过于针对执行，无助于企业架构师了解问题的范围以及这个使用案例的特殊变化。

　　例如，讨论可能涉及来自SME的意见，“我们必须接收来自X、Y和Z的格式A、B和C的订单。”重要的是不要过于迷失在当时的细节中。这会让你偏离抽象理解的重要踪迹，与执行细节分离。微妙而有破坏性的问题是在这么具体后可能很难回到抽象。但是，你仍需要细节。非常奇怪的是，这种难点可能出现在SME或业务分析师身上；或者，它可能涉及整个群体。有时，你对此毫无帮助。尽你最大努力做笔记；但是一定要知道能力或服务实际接收订单。可能存在具体客户的执行差异，但这种现象出现在分析流程链下游的位置。

　　我经常使用的一个技巧是以3种不同的方式询问SME同样的问题，一般不在同一个会议中。这种交流常常可能遵循这样的模式：

　　“那么，什么是订单可以遵循的可能的工作流(状态变化)？”

　　“有没有订单可以走另一种不同的路径的时候吗？”

　　“如果存在例外并且订单必须进行没有规定的状态变化的话，你怎样做？”

　　使用来自以另一种方式重述的回答的信息可以让SME超越他们的立即或当前执行去思考。他们将透露更多真实的要求，而不是当前的能力。这在讨论SOA需要的业务能力时甚至更重要。

　　为使之顺利进行，及早确定一个设想。将它有效地与SME和参与SOA分析的其他成员交流。首先，你的设想将是SOA可以为企业所做的事和流程将如何开始。随着时间的发展，这种设想由最初的一般陈述演进为被分析的企业的具体设想。这种设想发挥着使你可以以清晰和非技术方式向SME(他们越来越知道SOA)传达SOA介绍性的和抽象的概念。你可以开始交流这种设想，也许向支持你的高级IT管理层，但是企业将迅速承认它并推动它的演进。这正是拼图变成一幅完整图画的地方。