许多大型IT组织及其软件专业人士几乎每天都会面对合规/治理问题。在模块化IT以匹配业务需求的过程中他们还面临着一个持续的挑战。

面向服务架构(SOA)没有改变企业架构(EA)的原则或IT治理的本质要求，但是却改变了操作领域。专业人士能够恰当地结合EA和SOA，并使其得到提升。如果EA计划包含了SOA相关功能并考虑了关注EA与SOA承诺需求交换的联合式IT收益，那么他们可以创造双赢的收益。

从IT角度来说，EA的主要目标是调整应用程序功能与业务需求之间的关系。许多情况下，这个目标抑制了未能容易地转化为业务需求变化的独立应用程序结构。SOA大部分都是将应用程序分解到业务相关功能组件中，所以理论上它可以促进EA目标的实现，但是要想让EA/SOA花生需要从不同角度下看待应用程序。

然而像TOGAF这样的EA方法已经适应了SOA，很少有企业直接将业务需求映射到SOA组件中。这种映射对于以正确的方式取得EA收益和开始SOA治理都是十分重要的步骤。企业报告称，针对这一点的关键问题是未能使SOA组件与EA定义流程看齐。

SOA组件化往往是沿着技术或者软件功能边界进行结构化，而不是依据业务流程。如果那真的发生了，那么采用SOA方法就会恶化EA与IT间的融合，实际上也会将SOA治理从业务需求中分离出来。

为了使EA与SOA融合在一起，要定义业务信息的使用情况，而这些信息要求细致而不仅仅提供几个典型的信息就可以了，这应该是计划的第一步。我们的目标是能够将基于业务的组件化定义为最高水平的SOA组件化，依据技术范畴按需继续细分组件，保留原始的业务功能关系。

大多数情况下，业务级组件比真实的软件元素要更接近于SOA组件集的虚拟程度，创建EA业务流程可以推动清楚区分SOA组件的虚拟组件。这种机制为连接业务与IT迁移需求提供了方法，这种需求直接面向SOA组件而不是应用程序。

以近乎组件化的业务单元IT需求角来看，SOA和EA也可以结合来提供促进，然后，由联合会协调起来将其提升到企业的水平，这一过程通常称为联合IT。

许多公司放弃了联合IT的方法，因为他们认为仅仅当IT在每个业务单元中几乎完全是自动的情况下该方法才会奏效，而这种结构如今很少见。实际上，有证据表明，EA流程中采用联合IT有助于SOA治理，通过清除跨业务单元信息交换和依赖关系。

针对整个组织的合规目标可以从两个维度进行剖析：

跨业务单元，可以作为指导治理的一种方法。

跨业务组件，通过将契约转化到组件级别来指导SOA治理。

也许采取EA集成及联合IT的观点来创建SOA功能组件化的最佳结果是，SOA治理需求能够直接反映到应用生命周期管理中。SOA中的ALM受到了挑战，因为SOA组件重用使得传统ALM管理依赖性更加苦难；一个组件可以使多个“应用程序”发生变化。

在基于SOA的企业中，有可能使ALM中传统应用替换掉源自EA的业务流程组件，这种做法在SOA组件化领域中就失去了意义。由于这些基于流程的业务组件与形成合规需求的EA流程一致，这些需求就很容易融入到SOA组件中。因为业务流程与SOA一致，这也将SOA应用更改与业务单元操作流一致，这使得将ALM与工作人员实践测试间的整合变得容易。

企业在内部开发SOA应用特别有助于将EA整合到SOA治理中。不仅为SOA组件化促进治理流提供更大的空间，他们也可能采用SOA设计模式使要实施实践在组件设计中与治理元素保持一致。

运用关键变化的记录功能来创建审计跟踪是治理的常见需求。这可以直接并入到包含重要信息元素的组件中。这样做就降低了因避开审计而产生的变化风险，如果工作流没有得到恰当地处理，那么在编制SOA应用程序时就会出现问题。

IT治理是将IT实践与风险管理及合规原则保持一致的过程。这就引发了使用标准和机制这两种具体源来创建一致性。“萨班斯-奥克斯利法案（Sarbanes-Oxley）”或者“ISO 9001”这样的标准是不够的，你必须将这些需求从创建的业务-IT-流程映射中分离出来。

这样EA与SOA的结合就会变得很强大。创建融合关键的第一步应该对每个SOA组件具体情况都应该很容易识别。通过将有关组件添加到业务组件元素中而实现该目标，然后，将该元素返回到治理方针中。

SOA打破了传统应用程序的边界。如果得到适当地发展,EA可以支持划分IT资产的任何功能，并能将每一组件都返回到业务需求中。这就是有效合规管理的秘诀所在。如果能结合EA/SOA关系中的张弛力及凝聚力，这样的管理方法是相当正确的，经验丰富的IT专业人士很容易就采用这种方法，这是另一个秘诀。