如何组建理想SOA团队

趋向采用 SOA

软件开发领域的主要发展趋势是从传统软件体系结构过渡到面向服务的体系结构 (SOA)。在传统软件体系结构中，将项目视为单个新应用程序的交付。在SOA中，将项目视为集成服务的交付——一些是新建的，一些是现有的。不管其规模和预算如何，几乎全部信息技术(Information Technology，IT)部门当前都在进行过渡到SOA的工做。您可能已经读过多篇关于SOA采用、成熟度模型和实现的文章了。本文将描述在组织采用SOA或过渡到更高的SOA成熟度水平的过程当中，您的IT团队成员中所需的一组新角色及其各自的职责。

在造成SOA团队时，最大的范式转换是从组合应用程序交付过渡到服务交付。传统软件开发人员一般构建应用程序中的 一个模块，或典型的三层体系结构中的单个层的一部分。开发人员的一个例子就是在模型-视图-控制器(Model-View- Controller，MVC)体系结构中负责控制器或模型层的人员。在SOA环境中，这些开发人员如今负责服务实现。他们并不须要知道什么时候、如何或为什 么调用服务以及谁调用服务。他们所关心的就是，服务进行什么工做以及须要符合什么样的服务水平协议(Service Level Agreement，SLA)。

为了进行此范式转换，您须要造成完整的SOA团队，其中的每一个角色的职责与传统软件开发团队中的相同角色略有不一样。本文将说明SOA团队中如下角色的状况:

　·架构师
　　·开发人员
　　·业务分析人员
　　·项目经理

在典型的IT组织中还包括多个其余角色，包括基础设施支持、数据库支持、安全性等等。不过，了解了这些主要角色如何改变后，您就可以对其余角色进行调整，以与其匹配。

理解架构师的角色

在较大的组织中，一般有两个体系结构小组。企业体系结构小组定义组织内的每一个应用程序小组都必须遵循的控制策略、最佳实践和过程。应用程序体系结构小组负责其特定应用程序的体系结构，确保体系结构可以支持当前和未来的业务需求。

企业架构师

在SOA组织中，企业架构师的角色是推进和促进SOA的采用。他们须要帮助应用程序架构师和各个开发小组理解SOA的基础知识并将业务需求转换为有意义的服务，以便这些小组进行实现和公开。

仅由您本身的应用程序或业务流程使用的服务几乎没有价值。企业架构师须要确保全部应用程序架构师按期讨论其项目， 以肯定他们能够公开或使用的服务。在不能重用现有服务的状况下，企业架构师还须要确保充分利用构建新服务的每一个机会。促进对现有服务的重用确定比编写新服 务具备更高的优先级。最后，他们必须确认服务是在可靠的技术之上构建的，且可以知足所确立的 SLA。

企业架构师负责定义测定和跟踪 SLA 的机制。他们定义有关控制、安全性、灾难恢复等等的策略和过程。他们一般是涉及到 Web 服务管理、编排和企业服务总线的解决方案的主要决策者。

应用程序架构师

应用程序架构师的角色是确保所编写的代码是面向服务的，且遵循可用于面向服务的开发的最佳实践和流程。他们须要在不会对解决方案进行过分设计的前提下将业务需求转换为有意义的服务。典型的服务建立和使用比代码的直接调用开销更大。所以，肯定做为服务公开的粒度级别以及如何进行公开是此角色的主要工做职能。

应用程序架构师还要与组织中的企业架构师及其余应用程序架构师紧密合做，以确保充分利用每一个服务重用机会，且恰当地对服务进行构建、发现、安全保护、使用和测定。

应用程序架构师最终负责服务交付和使用(非功能要求)的全部技术方面的工做，包括 SLA 遵循状况的可测定性、符合控制策略、执行和确保安全策略等等。

阅读不一样SOA文献中关于架构师的信息时，您可能会遇到术语业务架构师，即应该理解业务状况并设计服务的人员。在 个人SOA团队定义中，此角色的工做由应用程序架构师完成，而不是由企业架构师完成。应用程序架构师或业务架构师是业务小组和技术小组间负责技术设计方面 的协调人，而业务分析人员则是负责业务方面的协调人。

开发人员的角色

在传统IT小组中，开发人员一般负责应用程序的一个片断。这些片断能够由功能(如注册中心或报告模块)或技术(如 JavaServer Pages? [JSP]、Enterprise JavaBeans [EJB]、数据库层等等)肯定。

因为SOA团队一般采用较短的开发周期，因此按技术对开发人员进行划分并不实际。所以，将按功能划分的开发团队转变到新的SOA开发人员角色更为容易一些。

成功的SOA开发人员将能同时理解业务流程和功能。他们会恰当构建所需的服务来知足业务流程的需求。愈来愈重要的 是，要执行用于错误处理、跟踪/审核、数据转换和安全性的良好设计原则，并确保将其加入到任何服务代码中。因为SOA的核心原则之一是重用，因此开发人员 必须放弃传统开发人员但愿构建一切的想法。若是某个方面的服务已经存在，请使用这个服务——而不要本身从头构建。

因为 Web 服务的技术发展并有大量有关该技术的参考材料可供使用，所以能够说开发人员已经“全副武装”，能充分胜任其在新SOA环境中的工做了。

业务分析人员的角色

业务分析人员多是最可贵到正确认识的一个角色。做为技术人员兼架构师，我倾向于将架构师视为最关键的SOA团队 成员。不过，基于经验和最慎重的考虑，我必须指出，做为SOA团队中的一员，实际上业务分析人员的工做变化最大。不管开发环境如何，业务分析人员都执行两 个主要职能:

与执行人员和策略级的用户沟通，以了解其对系统的要求。

与技术团队成员沟通，以将肯定的要求转换为能进行编码和测试的技术规范。

在SOA环境中，业务分析人员还有两项新职能:

与整个开发团队合做，让他们开始以服务 的方式思考问题。(他们须要何种服务来进行其工做?已经存在哪些服务可供使用或在调整后进行使用？如此等等。)

与技术团队合做，以设计和构建必要的服务，可能会利用已经存在的现有服务。

不管喜欢与否，在不少企业中，因为组织使用的技术的局限性，业务分析人员一般会不断更改相关要求。这个问题可能并不能获得消除，但在SOA环境中，业务分析人员进行服务设计的空间确定更大，而不用过多地担忧技术。

项目经理的角色

SOA 环境中的项目经理的角色与传统IT环境中的项目经理之间的主要差别在于项目生命周期。不管SOA团队采用何种方法(IBM Rational? Unified Process (RUP)、瀑布式、敏捷方法)，项目经理一般都须要为每一个服务计划较短的交付周期。他们与业务用户和不一样服务使用者一块儿定义服务水平协议 (SLA)。此外，他们必须与多个IT小组(如基础设施支持小组)共同确保这些 SLA 是能够实现的。

项目经理在服务运行时进行协调和跟踪方面的角色比跟踪平常服务交付更为重要。不过，因为周期较短，这个工做相对较为容易一些。

总结：SOA角色及其对您的团队的意义

本文讨论的关键词是培训。当您决定进行SOA项目时，须要仔细考虑团队人员的当前角色，并确保经过培训、指导和调整试验及错误周期来帮助他们准备好进行其在SOA中的工做。