CIO如何组建理想的OA团队

软件开发领域的主要发展趋势是从传统软件体系 结构过渡到面向服务的体系结构 SOA 在传统软 件体系结构中 将项目视为单个新应用程序的交付 在 SOA 中 将项目视为集成服务的交付 一些是新 建的 一些是现有的 无论其规模和预算如何 几乎 所有信息技术 Information Technology IT 部门当 前都在进行过渡到 SOA 的工作 您可能已经读过 多篇关于 SOA 采用 成熟度模型和实现的文章了 本文将描述在组织采用 SOA 或过渡到更高的 SOA 成熟度水平的过程中 您的 IT 团队成员中所需的一 组新角色及其各自的职责 在形成 OA 办公系统团队时 最大的范式转 换是从组合应用程序交付过渡到服务交付 传统软件 开发人员通常构建应用程序中的一个模块 或典型的 三层体系结构中的单个层的一部分 开发人员的一个 例子就是在模型 视图 控制器 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 团队中的 一员 实际上业务分析人员的工作变化最大 无论开 发环境如何 业务分析人员都执行两个主要职能 与执行人员和策略级的用户沟通 以了解其 对系统的要求 与技术团队成员沟通 以将确定的要求转换 为能进行编码和测试的技术规范 在 OA 办公系统环境中 业务分析人员还有 两项新职能 与整个开发团队合作 让他们开始以服务 的 方式思考问题 他们需要何种服务来进行其工作 已 经存在哪些服务可供使用或在调整后进行使用 如此 等等 与技术团队合作 以设计和构建必要的服务 可能会利用已经存在的现有服务 无论喜欢与否 在很多企业中 由于组织使 用的技术的局限性 业务分析人员通常会不断更改相 关要求 这个问题可能并不能得到消除 但在 SOA 环境中 业务分析人员进行服务设计的空间肯定更大 而不用过多地担心技术 项目经理的角色 SOA 环境中的项目经理的角色与传统 IT 环 境中的项目经理之间的主要差异在于项目生命周期 无论 SOA 团队采用何种方法 IBM Rational Unified Process RUP 瀑布式 敏捷方法 项目 经理通常都需要为每个服务计划较短的交付周期 他 们与业务用户和不同服务使用者一起定义服务水平协 议 SLA 此外 他们必须与多个 IT 小组 如基础 设施支持小组 共同确保这些 SLA 是可以实现的 项目经理在服务运行时进行协调和跟踪方面 的角色比跟踪日常服务交付更为重要 不过 由