在“成功规划SOA”系列文章的第一篇文章:Successfully Planning for SOA(中文版,dev2dev,2005年12月)中,我讨论了什么是面向服务的架构(Service-Oriented Architecture,SOA),以及如何确保它为您的业务交付价值。我特别关注了域模型的业务策略与流程、架构以及成本和收益等方面。第二篇文章讨论了如何创建有效的SOA路线图。在这最后一篇文章中,我将介绍域模型的其余3个方面:构件块(Building Blocks)、项目和应用程序(Projects and Applications),以及组织和管理(Organization and Governance),并将重点放在如何把它们集成到长期项目规划中去。
如图1所示,BEA SOA域模型是一个强大的工具,有助于指导客户实施SOA规划战略。图中重点显示的6个主要部分应给予同等重视,以确保实现成功。
图1. BEA域模型
本系列前面的文章考察了开始3个部分——业务策略与流程(Business Strategy and Process)、架构(Architecture)以及成本和收益(Cost and Benefits)。然而,实现开始后,对SOA的规划并没有终止,而是继续贯穿于SOA项目的每个阶段。
当进入迭代和增量阶段后,域模型的最后3个部分对于确保动态评估以及项目的灵活性都相当有用。对正在进行的项目进行有效评估可以使您在发现没有成功地交付业务价值时马上进行纠正。本文的其余部分将更详细地分析其中每个部分,并说明它们对于SOA长期规划的作用。
SOA依赖于成功地将重用制度化。SOA的构建块是分散、可重用的服务和架构元素,可以用于构成复合的应用程序和服务基础架构。每个构建块在实现之后就会被添加到SOA功能的总体目录中。随着该目录的增长,对于未来要开发的项目来说,需要开发的新代码和服务基础架构就将减少,维护成本降低,而且ROI也肯定会稳步增加。
明确地定义一个服务,并能够以一种一致和可重复的方式将其交付到实际部署中,这就是SOA项目成功的关键所在。服务最好通过3个元素来定义:
服务可以从现有应用程序公开,也可以从新开始构建,但是应该首先实现哪个服务呢?处于企业核心的简单服务是最佳选择,可以从对业务单元最不可知的服务开始,然后逐渐转向更加特定于业务单元的服务。这种方法允许团队习惯于在不过分关注复杂性的情况下构建和重用服务。类似地,应该从技术上较容易的服务开始,然后一步一步转向技术上的难点。最早构建的服务中有一些是基础架构服务,比如日志记录、审计、错误处理以及类似功能。
服务路线图是从识别企业中已有的IT项目和功能开始的。接下来,企业需要开发使架构完整的项目以及交付业务价值的单个项目,并按照重要性对这些项目进行排序。
一开始,需要了解现有应用程序和项目的情况,以便确定可以在哪里重用现有功能。对于那些完全特定于其所在的应用程序或为其开发的项目的功能,此时就完全可以不用考虑。
一定要知道以下内容:
这些数据将帮助您了解当前的项目和应用程序,并帮助识别通用功能。
SOA要求在人员的协作方式方面有所变化。有必要在IT部门之间建立更紧密的协作,因为这样能够推动全体人员都重视交付业务价值,而不是只在单个功能性部门中。
要想在此领域中获得成功,有两个方面是必不可少的。首先,必须提供足够的培训,以便让团队不仅能够了解SOA的技术方面,还能了解它所需要的文化变化。没有提供这些关键消息的企业将很难继续进行下去。
其次是组织和管理,要将SOA的采用当作是一个企业改变的计划,而不仅仅是最新的技术方向。从高级管理人员获取并保持支持将有助于企业的各个部门进行无缝协作,并确保您具有足够的权限来获得服从。
不同企业进行组织和管理的方式各不相同,这取决于企业的成熟度和发展方向。对于最初的SOA实现来说,自顶向下的集中式管理是最有效的,接下来是联邦或部分联邦的管理,最后是一个自治程度更高的层次系统。这种结构便于整体而有效地查看结构、资金、操作流程和工具、标准、技能变化管理以及指导原则。它还有助于根据以下(以及其他)SOA常见问题来决定、制定和改进流程:
最后,组织和管理功能将确保该过程以及通过SOA项目交付的业务价值是可度量的。如果未达到指标,就可以采取更经济有效的矫正措施。
在这个系列文章中,我的目标就是指导您使用BEA的域模型作为规划、实现和评审的框架,在您的企业中规划和部署SOA。本文主要关注长期规划,指出了SOA依赖于成功地把重用文化制度化、为什么要了解当前的IT项目(从而了解通用功能),以及如何建立组织和管理模型。想要了解有关域模型和BEA的SOA解决方案的更多信息,请访问BEA SOA资源中心。