技术开发 频道

CIO如何组建理想的SOA团队

【IT168 技术文章】

  趋向采用 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 团队定义中,此角色的工作由应用程序架构师完成,而不是由企业架构师完成。应用程序架构师或业务架构师是业务小组和技术小组间负责技术设计方面的协调人,而业务分析人员则是负责业务方面的协调人。

0
相关文章