本文将探讨通过模型驱动SOA创建并管理企业架构，解决企业对SOA实施精细管理和协作需求中的问题，让SOA更直观，让业务更规范。

　　如果没有架构，SOA将只是一盘未必能够解决企业问题的大杂烩。

　　虽然SOA正受到越来越广泛的关注，但是创建并管理一个真正的面向服务架构并不是一项简单的任务。本文将探讨如何通过模型驱动SOA创建并管理企业架构，解决企业对SOA实施精细管理和协作需求中的问题，让SOA更直观，让业务更规范。

　　精细地管理SOA

　　不管是业务方面还是IT方面，需要处理的变化和更新是永无休止，并且难以预测的。有远见的IT团队认识到，敏捷环境能实现业务与IT之间的有效协作与交流，并能根据企业战略和策略的变化迅速做出调整。IT必须通过商业模型与技术预见他们能否实现让众多利益相关者满意的低成本、高效率的解决方案，并对IT 方案实现业务战略目标的价值进行评估。但是，由于业务与IT在操作模式上的不同，一直以来他们都无法以互相理解的方式顺利沟通需求。

　　为了填补这一方面的空白，涌现出许多相关技术与最佳实践。新兴的实现技术，比如SOA把业务与IT结合到一个可以有效协作的环境中，从而达到提高敏捷性的目的。SOA使得并且鼓励IT与业务团队在描述与分析他们的业务战略时能够一起工作。这种沟通与协作上的改善使IT团队能够部署支持公司目标和方针的信息系统及IT方案。

　　可以说，SOA是让企业走上成功之路的最佳途径。可惜的是，它也可能会让企业陷入绝境。虽然SOA有巨大的潜力，但是它也给开发与部署相关应用带来更高层次的复杂性与周密性。要发挥SOA的真正效用，就必须对SOA进行彻底地精细管理，能够让它既它充分发挥作用，又不至失去控制。

　　为了更好地管理SOA，并且给企业创建一个走向成功的环境，我们有必要讨论建模应用对SOA管理的改善。

　　架构是指导原则

　　如果没有架构，SOA将只是一盘未必能够解决企业问题的大杂烩。优秀的SOA架构可以确定高层次的业务要求，保证各个主要方案能够真正满足业务需求。要填补业务需求与实际设计之间难以逾越的鸿沟，任何SOA方案在描述与开发的各个阶段都需要一个清晰的定义。

　　此外，正确地实施SOA方案还面临一个更大的挑战，那就是SOA的核心组成部分——服务。不管是规范的Web服务还是服务总线中的软件模块，SOA服务与网络上的其它服务都是以松耦合的方式构成组合应用（composite application，亦称mashup）。组合应用取代了旧的软件应用程序——那些用来解决个别问题或某一系列问题的整体式程序。组合应用包含了“即插即用”的服务组件，使其不管在构建时还是后来必须对应用程序进行修改以适应新的业务状态时，都比那些整体式程序更具弹性、易于修改。

　　许多人认为这就是SOA的全部优点了，实际上并不是如此。SOA至少还有一个更高层次的应用——它可以让公司在相似甚至稍有不同的业务领域中重用或重新部署这些组合应用。

　　比如，一个财务应用程序可能包含应付账款、应收账款、信用卡交易处理和银行业务等松耦合的服务。第一个应用程序可能部署在公司美国的业务中。但是后来，公司业务扩展到英国，可能在英国的财务处理需求和美国非常相似，只是由于区域不同或货币不同而在银行业务方面有特殊的要求。在SOA之前，这意味着英国的 IT团队要重写美国的财务软件，甚至完全从零开始。而借助SOA，他们就可以继续使用与美国软件中相同的服务，只需要把银行业务服务替换掉即可。最坏的情况，英国的团队也只需要写一个独立的服务。

　　相对企业来说，这种层次的重用性与敏捷性既降低了开发成本又提高了业务响应性，从而使公司获得巨大的优势。由于IT必须了解并管理由SOA而产生的庞大的蜘蛛网一样的服务与应用，因此，这也意味着复杂性的增加。IT还必须决定是否需要一个新服务，或者在更新一个现有服务、开发一个新服务、通过网络购买一个第三方服务中哪种方式更利于成本节省和提高效率。

　　在SOA中采用规范的建模方法，即模型驱动SOA，可以非常有效地解决这些问题。模型驱动SOA将高层次的业务方针直接与具体的服务功能联系，方便创建与维护符合业务与设计目标的交互服务，同时还能成为一种高效的业务沟通语言。

　　构建SOA蓝图

　　对于模型驱动SOA来说，最重要的内容就是企业架构。聪明的企业为了解他们当前的业务操作情况、将来他们想用什么方式进行业务操作，以及各种技术对这些操作的支持情况想尽一切办法。而通过对企业架构进行建模便可以对此有一个大概的视图，同时获得制定SOA部署计划所需的基础信息。

　　企业架构同时作为蓝图与路线图，将IT、数据和业务过程与业务目标与战略联系到一起。它能直观地表示这些实践之间的关系，因此企业可以使用实例来分析IT 对业务操作的支持程度。为了获得更高的效率，蓝图上必须明确标出在哪里采取行动。这些行动包括IT服务，甚至包括所部署的软件，其中大部分是面向SOA进行的开发与部署。

　　企业架构模型是实现SOA的关键，它涉及多供应商、多平台环境下的松耦合应用。它提供了服务“互操作性”的企业视图，也是取得成功的关键因素之一。企业架构为企业提供了所需的信息与分析以更好地利用SOA。这些用来选择合理服务所必需的分析是SOA能带来的最大价值之一。而构建这些服务，使其成为包含技术性服务（预构建的软件模块）的、可部署应用的任务，只要交给IT团队即可，这一点将在下面讨论。

　　通过蓝图，企业可以把SOA做为一种构建架构的新方式，而不仅仅是用来传输数据的新技术。企业架构是一个实现SOA价值的平台，因为它使企业能够以新方式获取完成新任务所需的信息，从而避免只拘泥于旧有方式来使用新技术。反过来，这也发挥了SOA时效性及敏捷性的优势。

　　模型驱动SOA

　　面向服务架构SOA作为一种实现基于组合应用开发的企业方法论获得越来越多的赞同。为了发挥最大效率，这种SOA方案既需要一个明确的定义，也需要与业务和设计保持同步。

　　一旦确定了经营方案，企业就必须培养一个能使业务与IT有效协作和沟通的环境。IT部门必须通过商业模型与技术预见能否提供让众多利益相关者满意的低成本、高效率的解决方案。业务部门必须确定其计划目标可行并且实现方式成本低廉。同时，还需要评估所用方案对达成业务战略目标所起到的作用。

　　模型驱动SOA为业务与IT提供了一个通用的工作流程，使其相互间能以一种双方都能理解的方式进行交流。基于全面的设计模型作出的开发方案为企业提供了敏捷性，从而成功地将业务与IT结合到一个协作性良好的环境中。企业级的建模使IT与业务团队描述、分析业务战略时能够专注于其专业领域，并直接看到他们对宏观设计所造成的影响。这样既改善了沟通与协作方式，又使得IT团队能以最有效、最实际的方式部署支持公司目标和方针的方案。

　　真正的SOA治理

　　真正的SOA治理应该是和设计时的策略管理一起开始的。为在日常实践中成功发挥SOA的优势，企业必须保证每个项目都与业务需求和最佳实践一致。当构建大型复杂的应用网络时，企业应该尽量把初期的高层次业务需求文档整理成为详细的技术说明文档，同时保持需求与说明文档之间的可跟踪性以验证一致性。

　　保持可跟踪性也有利于在业务需求发生变化或即将发生变化时进行影响分析。对需求的追踪过程既可以提高敏捷性，又能为IT提供何时可以进行更新的参考。

　　需求定义与需求管理方案有助于策划人员集中精力进行需求采集、整理与跟踪。这些方案在提高信息可视度和改善协作能力的同时，还能对需求进行优先分级，把结果直观地显示出来，以确定需要实现的需求。业务分析人员可以在整个开发生命周期对需求进行跟踪，保证这些需求与客户要求的一致性，并保证其符合相关的产业或政府法规政策。

　　让SOA更直观

　　模型驱动SOA采用了产业标准方法和语言对组合应用进行直观的描述和管理，从而构成能在整个应用与相关技术性服务的开发周期中引入规范化并逐渐发展自动化的SOA方案。建模使业务架构设计人员、方案设计人员和开发人员能在更高的层次上工作，并通过图形分析和自动检测在整个开发周期中引入质量保证技术。这种更高层次的抽象可以抛弃细节问题，让用户根据所需的用例和功能发表自己独特的观点、集中精力考虑应用所需提供的方案而无需担心如何构建应用。用户可以通过模拟分析并测试既定设计方案的正确性和效率，从而验证方案与用户需求的一致性。

　　这种SOA开发中的建模方法能使用户在开发的各个阶段（从架构到最终部署）不断检验错误和测试一致性，因此既能保证质量又能保证更低的成本。通过暴露组件及其接口，并对现有软件进行架构上的逆向开发以重用或重新部署服务、创建SOA接口升级遗留服务、改善现有组件之间的编排机制，它使分布式的网络型应用能够发挥最大的效率。还有一种优势，可能也是最重要的，就是这种基于模型的方法使开发人员能够在进行真正的升级之前模拟并测试对当前应用所做的改变，为用户节省昂贵的检修时间，并避免用户遇到因使用未经过检测的应用升级而带来的风险。

　　使方案规范化

　　企业架构与SOA应用开发环境结合得越紧密越好。在最理想的情况下，企业在这两者之间应该实现无缝连接，甚至还能支持相关的技术，比如要求管理和变更管理。而目标则应该是实现空前的企业范围的协作，使内部团队能够明白并整理业务战略并开发能够实现商业目标的IT方案。

　　换句话说，这就是从概念到部署、连续的、具有端对端可跟踪性和可靠性的工作流程，保证各个利益相关人随时都能正确地读取数据或使用相关技术。由于商业案例驱动着需求，而需求驱动着应用开发，因此需求管理实际上贯穿着整个过程。（下文是关于需求管理在整个项目周期中作用的论述）

　　业界有关研究表明，拙劣的需求实践是导致项目失败的最大原因。相反，优秀的需求实践又是项目成功的主要原因。需求过程并不是项目生命周期中的一个一次性的预先执行的步骤。需求贯穿着所有具有共同目标的开发规则、质量保证；并且，需求还能提供开发团队与客户之间的合约。

　　由于应用开发越来越复杂，要清晰地描述应用的要求也变得越来越困难，而要理解这些描述更是难上加难。许多架构师采用了全面的过程与方法论使需求管理与应用建模能够互相提供必需的信息。这种协作过程使架构师们既能描述问题与解决方案，同时还能跟上在这个过程中所做的决策。

　　要保证优秀的需求管理和项目成功，一个办法是采用正式的需求管理方案。这样可以提高业务方针、客户需求、技术细节和政策的可视性。由于强有力的采集、关联、分析、根据需求管理变更和追踪能力，这些方案保证了与需求的一致性，并保证符合相关政策与标准。最重要的是，它们能够自动将这些基于同一目标的开发规范和质量保证结合到一起。

　　比如，建模与支持企业架构、业务过程分析、SOA应用开发和需求管理的产品的无缝集成就可以实现这种工作流程。集成的方案以一种可以被所有利益相关人理解的方式，为每个利益相关人提供了交流与检查新的或更新的商业战略、实现理念与变更的渠道。影响分析可以在整个企业中进行，让所有利益相关人都可以在制定最终决策并实施之前评估可能发生的变化。

　　从高层的业务应用与服务编排，到技术服务用途的复合应用的设计与编排，几乎在所有的层次都可以描述、分析、测试并开发SOA的概念、设计与部署。在各个层次对设计进行模拟与测试很重要，而通过设计模型则可以把实际的Web服务当做模拟的一部分来调用并执行。

　　在设计可部署的组合应用的时候，开发团队就可以在SOA建模环境中测试应用的完整性，利用测试模型获得所缺少的服务的细节与设计的基本信息，并决定应应该从第三方购买这些缺少的服务或是根据设计模型提供的信息进行开发。

　　采用模型驱动SOA

　　面向服务架构（SOA）作为一种实现基于组合应用开发的企业方法论获得越来越多的赞同。为了发挥最大效率，这种SOA方案既需要一个明确的定义，也需要与业务和设计保持同步。

　　一个规范的基于模型的SOA方案，一经验证可以填补业务与IT之间的空隙，就可以使企业合理地部署并管理SOA环境。然后，SOA就能成为高效的业务语言，有效地管理并规划所部署的应用的复杂性。建模可以直观地表示出高层次的业务方针与各种服务的具体功能之间的关系，方便各种各样的用来实现业务目标与设计目标的应用的构建与维护。

　　这项技术的前景怎样呢？跟以往一样，预测某项具体的技术将来会有什么样的发展是一件很困难的事。然而，我们可以预计，随着企业逐渐体会到SOA的强大、接受SOA带来的敏捷性与灵活性，并且能够承担随后带来的责任，越多越多优秀的过程与最佳实践也必然会随之涌现。模型驱动的SOA由于能直观地表示企业在业务与技术方面的情况，从而能够保证企业操作跟得上商业环境的变化。