组建理想的 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 中的工作。

查看本文来源