为 OTN 撰稿
为 Oracle 技术网撰写技术文章,获得报酬的同时可提升技术技能。
更多信息
密切关注
OTN 架构师社区
OTN ArchBeat 博客 Facebook Twitter YouTube 播客图标

Oracle 融合中间件案例

作者:Lucas Jellema

深入介绍迁移到面向服务的架构过程中人员、流程和技术的交互。

2013 年 8 月

下载
download-icon13-1Oracle Fusion Middleware

作者按

本文概要介绍一个虚构的组织 NOPERU。本文所述的 NOPERU 案例实际上是我过去几年参与的数十个组织的事件的大杂烩。这些组织没有一个体现了 NOPERU 的所有特征,但它们都经历过或正在经历与本文所述类似转变,本文所有方面都来自于现实生活中的一个或者通常许多这样的组织。

背景

NOPERU(国家排放和资源使用许可组织)是一个在业务、组织和技术方面不断转型的公共组织。业务需求不断变化,新的交互渠道层出不穷,对更高灵活性、更高吞吐量、更低成本的需求不断增长,这些都是转变的驱动力,而技术的发展和新的架构模式使这种改变成为可能。NOPERU 选择 Oracle 融合中间件作为实施新架构和所需应用的技术平台。

本文深入介绍了 NOPERU 的发展历程。这家公司成立于 20 世纪 90 年代初,主要依托于纸质文档,采用地区数据库和客户端-服务器 Oracle Forms 应用。还介绍了其近期业务目标:对组织的要求以及这些要求背后更高层次的目标。不仅简要概括架构规划,还深入介绍面向服务的设计。NOPERU 基于架构路线图和业务要求选择技术,确定采用何种技术体系可实现 IT 未来路线图。

本文讨论这种选择并详细介绍后续规划(并执行至今)的项目。新的架构和技术以及敏捷开发方法的引入对 IT 组织、流程和员工个人产生重大影响。还从人员和组织角度描述了 NOPERU 采用的方法。最后,本文讨论 NOPERU 得出的许多可能使自身和其他组织受益的结论。

NOPERU 简介

水NOPERU 是一个国家组织,负责针对过度排放(即二氧化碳)和不合理使用资源(如能源或水)发放许可。无论是商业企业、政府机构还是私人,只要排放或消耗超过规定的“合理用量”,都需要这种许可。例如,当有人建造一个室外温水游泳池或露台加热时,就需要获得这种许可。当一家公司安装新的高耗能设备(如锅炉或深冷柜)时,也需要获得 NOPERU 许可。各级政府资助的项目,如果涉及消耗大量淡水或产生大量排放,就必须向 NOPERU 申请许可。如果没有所需的许可,任何利益相关方都可以请求法庭立即终止有争议的活动。

在 NOPERU,申请人需经历的典型过程如下所示:

  1. 提交正确的纸质许可申请表,并附上支持文档。提交给具有管辖权的地区分支机构以及相应的部门。
  2. NOPERU 对提交作出回复,发送接收确认和提交费用发票。
  3. 费用一旦支付,就开始实际处理过程。
  4. NOPERU 的不同专家(财务、环境、法律等)都参与评定申请。通常,NOPERU 将需要申请人提供其他信息。
  5. 有时还要进行实地调查。
  6. 有时还需要召开听证会。
  7. NOPERU 公布裁决,分为三类:完全拒绝许可、无条件授予许可或者根据特定条件(可能包括支付特别税)授予许可。
  8. 裁决被送交申请人,并在当地报纸上公布。所有许可都登记在公共登记簿中,利益相关各方可到任一 NOPERU 办事处查看。整个过程可能需要三个星期(非常简单的普通活动)到两年(复杂的大型活动)的时间。

NOPERU 于 20 世纪 90 年代初成立。它还有五个地区分支机构,每个都可满足公民、企业和公共机构三个部门的需要。最初,与 NOPERU 的所有交互都是通过传统渠道(电话、纸质邮件、传真和信息服务亭)进行的。NOPERU 只能在办公时间内进行同步交互(即时反应)。邮件和传真当然可以随时发送,但只能在办公时间内处理。

早期支持内部业务流程的计算机应用是用当时先进的客户端/服务器技术开发的:Oracle 7 数据库上运行的 Oracle Forms。针对企业部门开发的内部应用经过克隆,形成公共机构和公民提交的申请的基础。多年来,三种应用之间的差异慢慢增大,形成了现今三种几乎互不相关的系统。而且,每个应用都有自己的数据库,因为应用在每个地区分支机构本地运行,共有 15 个数据库和 15 个应用实例,导致管理操作和应用升级繁琐无比、成本高昂、风险巨大。

NOPERU 不执行任何逻辑数据管理。每个新的应用都需要申请人重新注册。在全国范围运营、每年要提交成百上千份申请的大型企业会在五个地区各自的数据库中出现成百上千次。甚至历年来曾经在同一办事处申请过数次的各个市民在地区数据库中也用多条记录表示,记录并未实现同步。此外,NOPERU 也没有信息生命周期管理的策略。记录永远存在。因此,数据库越来越大,携带越来越多实际上用不到的数据。

原始的客户端/服务器应用现在仍在使用,与其初始实现相比几乎没有变化,只不过现在变成了基于 Forms 9i 浏览器的应用。这些应用主要是面向数据的 — 基本上就是在所有数据上提供一个窗口,支持对改数据进行查询和操作。应用不是直观式的,新员工的学习曲线很陡峭。

更糟的是,这些应用既不支持也不执行 NOPERU 的业务流程,这些流程很大程度上只存在于相关人员的脑海中。通过跟踪包含与特定应用相关的文档的纸质文件的下落来监视流程:当该文件移交给下一个操作者时,流程进入新的阶段。此外,NOPERU 的五个分支机构处理许可申请的方式各不相同,说实话,即使是同一个办事处,不同人员的处理方式也略有差异。跟踪流程、注重效率并确保满足期限要求,说得委婉些,是真正的挑战。

业务目标

上一节提出了 NOPERU 的 IT 组织方式可以进行改进的一些领域,旨在实现更高的服务质量,更快、更一致的流程执行,提高人员工作效率,降低业务和 IT 成本,让各方面都满意。

部分出于自愿,部分以政治指令以及直率的市民和参与的业务合作伙伴的提示为指导,NOPERU 管理层为未来设计了一个计划:Go Forward (2010-2018)。以下是该计划中重要的驱动因素:

  • 速度。许可申请的处理速度必须大大加快:简单、完整的申请限期三个工作日,更复杂的申请限期 6 周。
  • 可访问性。必须引入现代交互渠道,以支持 24/7 访问提交内容和跟踪许可申请。这些渠道包括 B2B 服务、Web 门户和移动应用。应研究允许非办公时间进行基本交互的语音应答系统。
  • 无纸化。到 2018 年,NOPERU 应实现无纸化。申请所需的表格和支持文档均应以电子格式提交,这将大大减少 NOPERU 运营的入站端工作量,并缩短从申请提交到员工实际开始处理申请之间的前导时间。此外,让多个员工同时处理同一申请最终将成为标准程序。为了满足代表大型企业管理许可申请及与 NOPERU 的所有相关交互的专业中介机构的需求,NOPERU 将提供一个门户网站,可以轻松地代表多个客户提交和跟踪大量申请。
  • 可用性。新员工的学习曲线应比现在短得多。NOPERU 的人员相当灵活,好几个角色的人员流动性都很高。如果新员工能够在更短的时间内提高工作效率,减少因用户界面的不友好而导致的错误,可以节省大量成本。

NOPERU 的管理还需要更多的洞察力。它希望了解流程执行中的延迟、瓶颈和其他流程低效的情况,并希望能够持续改进业务流程,不需要很长的交货时间、大量的开发工作,也不必面对高风险。他们在某个敏捷研讨会上听说了“拥抱变化”这个词,非常喜欢它。他们期望像敏捷宣讲师许诺的那样,获得灵活性、缩短上市时间。

高效。即使 NOPERU 实际上是在为中央政府赚钱,但仍然必须将运营成本降低至少 20%。为满足这种需求,减小人员规模几乎就是一个必然的主要措施。如果许可申请人以电子格式提交所有信息,并且有关申请进度的所有信息均可在线获得,那么当前工作量的很大一部分将会消失。通过门户网站和移动应用提供的自助式服务可能看似都是关于客户满意度的,但在节省成本方面有奇效。

更简单的应用,学习曲线短,对业务了解程度和流程专业知识的要求较低,应允许 NOPERU 使用临时工,这样就产生一个可随许可需求收缩和扩展的灵活的层。NOPERU 的管理层还希望可以自动裁决部分申请,例如,通过使用业务规则引擎捕获人类参与者当前应用的逻辑。

IT 目标

NOPERU 的 CIO 在架构师团队的指导下,已经确保在 Go Forward 计划的设计中包含了一些特定的 IT 目标。她希望确保 IT 在 NOPERU 运营中发挥的重要作用得到认可,并就 IT 作为 IT 路线图的起点作出明确的声明。

企业架构设计是未来所有项目的基础。企业架构将转换为现代 IT 架构模式,然后再转换成应用和基础设施的设计。

所选架构和技术必须考虑到灵活性:可以通过简单、廉价、快速、无风险的方式更改功能。NOPERU 希望在业务和 IT 两方面都实现敏捷化。此外,系统的演变和向新系统迁移必须在营业时间进行。NOPERU 不能承受关闭所带来的影响,尤其是引入 24/7 在线渠道(网络、B2B、移动)之后。

NOPERU 的 IT 必须在先进性和成熟的可靠性之间取得微妙的平衡。它应该:

  • 基于当前行业标准,这些标准是开放的,可促进交互和重用
  • 仅使用成熟的概念和组件
  • 对员工和客户有吸引力
  • 允许 NOPERU 找到合适的资源来帮助设计、开发和管理基础设施和系统
  • 使用的软件拥趸众多并且有一个或多个大型商业方提供支持(NOPERU 这一体会来之不易。)

NOPERU 打算只与少数战略供应商合作,他们拥有全面的产品组合、明确的路线图、有能力和意愿持续发展,有合作意愿,理想情况下愿意通过自己的产品负责帮助 NOPERU 取得成功。供应商产品的潜力必须通过样板客户来证明,这点幻灯片做不到。

NOPERU 对外界是开放的。过去,超出其物理场地边界的互动都是在纸面上、通过传真或电话。唯一的在线交互是电子邮件和 DMZ 中基于数据库的只读网站,每天从文件转储中刷新一次。但现在必须在 B2B 交换中支持与 NOPERU 企业系统的同步交互,以用于移动应用和交互性更强的实时 Web 应用。这些举措的核心必须是安全性;因为信息必须只能由授权方访问,与 NOPERU 打交道的任何一方都必须通过身份验证。数据的完整性也将发挥更重要的作用:自动化流程和人员在解决不一致或简单拼写错误方面自动化流程的能力也不相同。此外,由于内部系统的数据将直接发布到门户网站和 B2B 渠道,无需人工检查和筛选,其质量必须比现在要高。

该计划的一部分是通过使用单一数据库和单一应用实例整合到一个中央基础设施来减少 IT 支出。这样可以通过减少数据重复、复制和不一致的可能性来提高数据质量。这样做还将降低硬件成本、软件许可费用和薪金总额。但在计划执行的初始阶段,由于需要执行许多项目才能实现目标,IT 支出很可能会增加。将所有 IT 基础设施和所有数据整合到单一实例一方面意味着可以减轻安全官的负担:需要担心的站点、管理员和环境更少。然而,这种整合还意味着可用性(在 NOPERU 即将进入的 24/7 领域是至关重要的)成为一个更艰难的挑战。整合后的系统在逻辑上是单一实例,在几乎所有 NOPERU 活动中都是关键因素。它是单点故障 — 至少在逻辑上是。IT 路线图的一部分是采取措施保障所有 IT 组件的可用性(例如,通过集群和故障切换)。

架构路线图

NOPERU 的架构团队领导了这场技术变革。该团队起草了 IT 架构概览,选择并优化了要应用的架构模式,并与开发人员合作设计参考架构。这个参考架构就设计系统组件时如何利用模式以及如何利用所选技术实现这些模式提供了指导原则。这还提供了一个通用词汇表,用于讨论实现。

战略技术和供应商的选择部分基于这些架构设计;毕竟供应商及其产品组合能够按照 NOPERU 团队的设计实现架构才是至关重要的。

NOPERU 原来的系统涉及应用孤岛的经典案例:由数据库、业务逻辑和用户界面组成的多个独立单元。每个应用通过自己的孤岛实现,使用截然不同的技术,有时甚至是非常专有的技术,并由内向、有些过于专注自身的团队来维护。在这些团队之间灵活共享资源既不普遍,也不容易。在孤岛之间交换数据甚至在理想情况下真正共享数据所需的技术集成也很难实现;通常,在可能涉及手动操作的异步批处理中使用文件导出和导入数据。数据复制很常见,手动键入重复输入数据的任务也很常见,这只是因为数据可能已经存在于一个孤岛中,这并不意味着另一个孤岛可以访问它。而且因为数据交换并非随时可用,手动键入相同的信息往往是更简单的方法。

在新架构中,必须要打破孤岛。可以采用千层面式风格:分层架构,每层职责分明,并有明确定义的接口描述各层之间的交互。

jellema-case-for-FMW-fig01
图 1:从孤岛转变为分层架构

没一个团队或应用是本质上(并且始终应该)被视为可以在许多不同流程中使用的企业数据的所有者。团队和项目都不能掌握自己的命运:他们就技术、应用布局和实现模式所做决策必须适合企业环境。

此架构中确定的层包括:

  • 用户界面和编程接口层 — 通过面向人的界面和面向系统的接口与外界进行交互。
  • 业务层 — 数据和业务逻辑的通用接口,可以跨用户界面和编程接口重用
  • 数据层 — 所有企业信息资产(包括文档和其他非结构化数据)的持久性和完整性

识别这些层将有助于在 NOPERU 中实行明确的分而治之策略:

  • 每层都有自己的角色,使用自己的设计模式和指定的技术。
  • 对其他层而言,每层的实现都是封装的。
  • 各层只能调用下一层。
  • 除了直接位于其下的层之外,各层不知道任何其他层。
  • 通信始终是自上而下流动的。

(注:事件用于补充此规则,并且可以发布上层可能需要注意的信息。)

每层都应该有明确定义的接口,描述其支持的交互。此接口描述的一部分定义了层中可以调用的操作、这些操作所需的输入及其返回的输出(包括可能抛出的异常)以及描述了调用的副作用(如发送的电子邮件、发货的产品或保存的数据)。还应描述操作的非功能性方面;包括可用性(营业时间)、成本、授权和其他安全方面、响应时间和接受的数量。

虽然没有严格的指导原则来实际执行这一点,但架构团队仍然希望并期待在每一层内各个团队使用相同或者至少是开放的技术、共享的技能、通用的设计模式和大体上共享的基础设施。技术选择将符合这一愿望。

在架构设计早期阶段做出的关键决策之一是采用多种面向服务的架构 (SOA) 原则,包括分离(至少要松散耦合)、抽象和封装、可重用性以及位置虚拟化。应用这些原则并实施分层架构将有助于实现关键的业务需求:灵活性、缩短上市时间、通过重用提高效率以及降低风险。

三角形

一个简单的图示(倒三角形)在有关 NOPERU IT 未来的讨论中发挥着越来越重要的作用。

jellema-case-for-FMW-fig02
图 2:各层

这个三角形直观地显示了各层在重用潜力和通用性与多渠道支持和定制级别方面的差异。

数据层的特点是集中化和(逻辑)整合。数据资产有单一信息源。该层具有非常高的重用潜力和通用的企业级结构。作为核心企业资源,它对质量、完整性、可用性和机密性的要求很高。这一级别的变化率相当低,至少在元数据级如此。删除数据的情况不太频繁,数据结构的变化更慢。

向用户和应用公开接口的界面层是不同的。它有各种各样的用户界面和设备,针对非常特定的渠道、客户和用户角色,允许定制和个性化以满足特殊要求。该层中组件的平均生命周期相当短(尤其是与数据层相比),变化率要高得多。

业务层(位于中间)在可重用性和变化率方面也处于中间位置。它提供的服务旨在被各种接口组件重用。该层汇聚来自数据层的资产;实现业务逻辑;验证、处理和丰富数据;并运行流程。其变化率和功能变化均高于数据层。但与用户和应用界面层相比,数据层的变化速度要慢得多,它的关注点主要集中在重用上,极少针对特定的一次性需求。

大多数业务要求都能在顶层找到所需的大部分 IT 工作,仍有相当一部分工作位于中间层,而花在底层上的工作很少(因为重用)。因此在许多开发项目中,这个三角形还代表着工作比例,甚至还暗示着团队的组成情况。

下图显示了 NOPERU 正在经历的迁移目前处于一个非常抽象的级别:

jellema-case-for-FMW-fig03
图 3:迁移

数据域

企业架构已经确定了 NOPERU 内五个相对独立的域。每个域中的数据以及公开该数据的服务将由领域专家控制。不同域中的组件之间不存在直接关系。随时可以使用现成的商用产品(如 SaaS CRM 系统或第三方专业应用)重新实现域。

架构师确定的五个域包括:

jellema-case-for-FMW-fig04
图 4:五个域

NOPERU 和每个域各有一个重要资产:数据。大多数与域的交互和域间的交互都将涉及数据,因此对该数据取得共识并采用通用的语言进行数据交互就变得至关重要。

为此,架构师们启动了一个创建企业数据模型的计划,其中描述了所有对 NOPERU 运营有意义的业务对象,包括其属性和关系。通用术语及用于设置某些属性值的参考值列表按标准化方式定义,并在整个组织内可用。注:该模型在业务层定义,并不一定与每个域内的数据库结构和其他技术资产完全一致。企业数据模型 (EDM) 是整个 NOPERU 内(不仅限于 IT)的通用业务语言。业务层与数据层之间的所有交互都将依据 EDM。在未来相当长的时间内,数据层内的操作将使用现有的习语和结构,这既是不可避免的,也是完全可以接受的。

面向服务的架构

以面向服务的架构为主导架构原则的决定带来了一系列后果。在 NOPERU,中间件还是相当新的事物。过去围绕应用 — 围绕上述孤岛组织团队。分层架构核心的业务层将成为所有团队的新焦点。该层由多种不同类型的服务组成,将来自数据层的所有数据 — 结构化的和非结构化的、跨数据库、文档信息库、LDAP 实例和邮件服务器 — 汇聚到一起,并以标准化、统一的方式公开对这些数据的访问。而且,这些服务为应用(无论是用户界面还是编程通道)提供业务逻辑。

业务层基础的一部分是企业数据模型(或“规范数据模型”),更具体地说,该模型的 XML 表示,用大量带批注的 XSD(XML 模式定义)表示。服务处理的所有数据结构(包括输入和输出)均使用这个规范的 XSD 中的业务对象定义。这五个数据域可通过 XSD 定义中所用的命名空间结构来识别。

架构团队提出了一个服务分类方案,帮助组织服务以及使用这些服务的团队。按照这个方案,业务层细分成以下服务类型:

jellema-case-for-FMW-fig05
图 5:业务层服务
  • 基本服务:在域中提供原子功能;重用潜力很高,附加值通常较低
  • 组合服务:将两个或更多个基本服务组合成具有更高附加值的业务功能;组合服务有两种形式:
    • 在域内
    • 跨域(通常会引入对全局事务或事务补偿的需求)
  • 流程服务:异步、运行时间较长(多达数分钟、数小时甚至数天),通常在运行呈现服务包含状态:不适用于一般重用;可以满足应用或渠道(用户界面或编程界面)的特定需求,并使用该应用的特定语言
  • 实用程序服务:通用、与域无关、高度可重用的服务,通常具有近乎基础架构的性质(如日志记录、发送电子邮件、值转换、地理编码等)

为每个服务类别创建服务设计和实现指导原则。治理、所有权、测试和服务的许多其他方面也取决于服务类型。

注:除了呈现服务,所有服务均依据规范数据模型表示。它们都记录在一个中央服务目录中,潜在客户将从中找到有关服务的信息,包括功能、合同、非功能性方面和状态。在 NOPERU,该服务目录是一个简单的 Wiki,它引用服务的实时 Web 服务描述语言 (WSDL) 和 XSD 规范。

事件驱动型架构

对于架构层,规定一层不能调用更高的层,甚至不知道更高的层。然而,这并不意味着较低级别的层或服务永远没有较高级服务感兴趣的内容可讲;而是意味着必须用直接调用以外的方式传递信息。为了应对这一挑战,NOPERU 架构师采用了事件驱动型架构 (EDA) 中的元素。事件作为独立的介质来传递信息,而在信息的来源和接收者之间没有任何直接依赖关系。

除了定义规范数据模型和识别服务之外,NOPERU 分析师还努力发现“业务事件”— NOPERU 日常运营中某处可能出现的可能让其他方感兴趣的情况。NOPERU 感兴趣的事件当然也可以发生在外部:这些也归类为业务事件。

通过名称或类型、时间戳和负载来描述业务事件,这些数据用于明确事件所涉及的内容。NOPERU 中的业务事件示例包括:许可申请撤回、付款收讫、申请已裁决、企业已申请破产、某业务流程逾期、业务规则已更改。NOPERU 的参考架构描述了事件处理基础架构 — 适用于所有应用组件和服务。

jellema-case-for-FMW-fig06
图 6:参考架构

任何人都可以将业务事件发布到此事件处理程序,只要事件类型是预定义的,且负载具有预定义的结构。发布事件之后,发布者不得以任何方式参与事件的交付,甚至根本不知道事件被哪方使用。架构中任何层的任何组件均可订阅所选类型的业务事件。事件处理程序将任何已发布的事件推送给此已发布事件类型的所有订阅者。事件的使用者接收事件及其负载,并可任意进行处理。它们不知道发布该事件的组件。

通过事件实现的完美分离使得添加使用者或引入特定类型事件的新发布者变得非常简单。删除事件的订阅者是另一个零影响的过程,丢失一个或多个事件发布者也不会造成任何影响。

通过事件,基本服务、甚至数据层中的组件能够将其故事告知组合服务、流程服务、甚至用户界面组件,而无需了解它们。交互会发生,但是以一种完全分离的方式。

技术(供应商)选择

业务目标和衍生的分层架构以及更详细的架构原则,让我们对于 NOPERU 所需的技术组件有一个十分清晰的概念。NOPERU 必须从供应商处获取许多技术产品,以实施该解决方案的重要元素。

jellema-case-for-FMW-fig07
图 7:所需技术组件

NOPERU 从一开始就声示,不希望购入一个集成产品套件的原因只是因为它是一个集成套件。它希望购入的是每个类别中的优秀产品,并要求所有产品都是开放的、基于标准的、易于集成的。

另外还确定了一些额外的评估标准。因为 IT 不是 NOPERU 的核心活动,它希望使用成熟的技术和产品,有可验证的参考支持。产品必须有明确的战略、强大的社区和丰富的资源(合格的 IT 专业人员、图书、互联网论坛和博客、培训材料等),并对其供应商具有重要的战略意义。供应商本身(或开源项目)应是稳定的、适应未来发展的。最后,鉴于 NOPERU 现有的员工队伍,产品的学习曲线应明确、合理。NOPERU 对分析师的评论进行验证并加以考虑。

虽然这是一个实质性的操作,但 NOPERU 的资源仍然有限,不希望拥有需要不同技能的各种各样的技术和平台。它希望集中于少数主流行业平台(硬件、操作系统、虚拟化、数据库和中间件),防止给管理员带来噩梦。出于同样的原因,所有选定的产品都应提供足够的监视和配置选项,并应允许自动构建和部署。

当然,软件的成本也是一个重要的决定因素。在这里,NOPERU 将会看几个方面。每个计价单位(用户、CPU 内核、使用小时数)的许可费是多少?估算的计价单位数是多少?每年的支持费用是多少?其他计价元素有什么作用?有哪些折扣可以协商?许可有效期多长?可以使用哪些替代方案(如订阅费)?供应商准备对软件行为做出什么保证?它将签署哪些 SLA?供应商是否准备承担某种形式的责任保证软件的成功实施 — 可能是无效果/无报酬形式或部分基于投资回报的费用?

选择方法

NOPERU 必须做出两个紧密相关的选择:供应商和产品。

它发布了一个份信息征询书,重点是包括了特性、技术特征、实施要求、培训和预估价的清单。NOPERU 收到专用产品供应商、非常特定领域专家的反馈,以及来自涵盖各种产品的产品套件供应商的反应。它还邀请了一些方面代表开源产品。

与 RFI 流程并行,NOPERU 还从同级组织(主要是政府组织)收集有关产品和供应商经验的信息。NOPERU 还同时在线和亲自咨询了市场分析师。

根据上述标准,筛选和评估了该流程现阶段收到的信息。结果就生成了产品和供应商的候选名单。候选名单上的供应商受邀进入下一阶段:征求建议书。

在这个阶段,要求供应商提供一份计划,说明 NOPERU 如何才能更好地使用其产品,包括基础设施拓扑、许可、系统迁移以及流程和人员的转换。该建议书需要涵盖整体价格以及任何替代补偿方案(如延期付款、基于结果付费、基于订阅的费用和基于使用的费用)。

每个供应商必须提供相关样板客户,以备 NOPERU 联系和拜访。还必须制定产品路线图和长期愿景和战略。NOPERU 希望确信所提供的产品的确能够适应未来发展。到目前为止,NOPERU 已经决定采取略微不同的方法,并定义了几个技术集群以供在有些不同的阶段选用:

  • 硬件 — 无直接投资;使用 VMware 实现的虚拟化是一种短期行为;已经开始研究一种多站点、防灾、极高可用性的数据中心布局。
  • 数据库 — 在 Oracle Database 11gR2 RAC 上整合(这意味着升级一些数据库并替换一些 MySQL 和 SQL Server 数据库);对 Oracle Database 12c 版有所关注,但没有短期采用计划。
  • 移动 — 目前未做战略选择;鉴于移动市场的波动性以及移动应用在企业外部,影响不大,生命周期短的事实,认为不必进行移动技术的战略选择。
  • 内部用户界面应用 — 在相当长的一段时间内,将使用和维护一些 Oracle Forms 应用;一个应用已经迁移到 Oracle ADF 11g 中(或者说在其中重建)。NOPERU 评估了 ADF 的使用体验,做出的决定是,目前没有理由选择其他技术。当然,它验证了 ADF 对 Oracle 的战略重要性、社区的强大实力、路线图和愿景以及定价,发现一切令人满意。认识到 ADF 是任何 Java Web 开发人员可以快速掌握的 Java EE 框架,这在很大程度上抵消了对外部资源可用性的担忧,但担忧并没有完全消除。

对于以下集群,采用单独的 RFP:

  • 面向服务的中间件 — NOPERU 需要产品实现企业服务总线、服务编排、事件驱动型架构和技术适配器;这些产品必须能够通力合作,理想情况下使用相同的平台。
  • 流程和人员工作流管理 — 在此集群中,NOPERU 确定了对决策规则(即业务规则)、业务流程编排、人员任务和工作流管理以及业务活动监视 (BAM) 的需求;这些产品必须能够紧密协作并与面向服务的中间件协作。
  • 企业内容管理 — NOPERU 的 Go Forward 计划的业务目标之一就是彻底消除纸张;使用数字文档对于组织至关重要。这就需要产品能够存储、搜索和发布、转换、标记和跟踪、存档和保护各种格式的数字文档。这些产品当然应适合 NOPERU 将建立的面向服务的架构。
  • 门户和外部用户界面应用 — 由于在分层架构中实现了分离以及使用了服务,门户与其他外部接口(一方面)以及业务层中的产品(另一方面)之间的依赖性降至最低;这意味着对于这些门户所用产品的决定可以独立于其他产品选择。
  • 身份和访问管理 — NOPERU 正在对组织外部的用户开放企业应用;这种新情况需要一种新的身份管理方法、实施身份验证以及基于身份的授权;NOPERU 使用 Microsoft Active Directory 管理内部员工,目前并不急于放弃这个平台(因为它已经集成到整个办公自动化中)。它希望引进能够处理外部用户的身份和授权的产品。它还需要能够处理加密、数字签名以及适用于某些服务的其他安全技术的产品。

选择

面向服务的中间件集群和流程和人员工作流管理集群中进入候选名单的大多数产品都基于 Java EE 平台。因此,由于内部应用使用的技术被定为 ADF 11g(另一种基于 Java EE 的技术)以及原有的优秀的 Oracle Forms(也运行在 Java EE 平台上),NOPERU 决定选择 Java EE 作为所有中间件的核心平台。它还选择了 Oracle WebLogic 11g 作为首选的 Java EE 应用服务器。只有当 NOPERU 选择了具有卓越功能但无法在 WebLogic 上运行的优秀产品时,才会考虑其他应用服务器。请注意,NOPERU 特意保留了在用户和应用接口层中支持不同平台的可能性。这一决定部分可能是因为一些内部不同主张的原因;有些面向 .Net 的团队一直都对转用 Java 有些抵触。

企业服务总线和服务编排(后者很快转换为业务流程执行语言 (BPEL))的产品选择评估了 Microsoft BizTalk 和各种 TIBCO 产品以及一些开源产品,然后决定采用 Oracle SOA Suite 和 Oracle Service Bus。这种组合还引入了所需的技术适配器,通过 SOA Suite 事件传递网络对事件处理的支持,以及对 Java 消息服务 (JMS) 和 Advanced Queuing (AQ) 的支持。

SOA Suite 对决策(业务)规则和人员工作流的支持以及在设计时和运行时与 Oracle BPM Suite 的高度集成,促使 NOPERU 在为流程编排和人员工作流选择产品时强烈倾向于后者。SOA Suite 许可包括大多数所需功能,功能丰富(足够),并有多年的跟踪记录。BPM Suite 增加了对真实业务流程模型和标注 (BPMN) 流程建模和执行的支持,还提供了一系列运行时工具,可帮助设计、跟踪和监视、管理流程实例并开展协作。NOPERU 最终选择了 BPM Suite,因为其优秀的质量以及与 SOA Suite 完美集成带来的巨大优势。BPM Suite 的快速发展向 NOPERU 展示了供应商对该产品的重视,而计划在 Oracle 融合应用中同时采用 SOA Suite 和 BPM 也证明了这些产品对 Oracle 的战略重要性。

内容管理的产品选择一点也不顺利。因为 NOPERU 对这个问题基本不熟悉,他们雇佣一个外部顾问,但当发现该顾问有偏向性时,很快就请他走了。接下来,“内容”的定义引发激烈争论;有些人认为指的是网站的静态内容,而其他人考虑的是组织内传递的所有文档 — 甚至所有非结构化数据。即使是 Oracle 产品的名称 (WebCenter Content) 也能让某些人眉头上挑;它听起来像是他们争论许久之后好不容易否决的静态网站内容之类的东西。直到得到了 WebCenter Content 其实就是以前的 Universal Content Manager 的保证,一切才恢复平静。最后决定采用 WebCenter Content,并不是因为它明显胜出,而是因为它可以与 Oracle 融合中间件平台轻松集成,感觉这种集成风险较低、工作量较小。

以下列出了到目前为止 NOPERU 选定的产品:

jellema-case-for-FMW-fig08
图 8:技术选择

还需要选择门户技术;目前,现有的 .Net 和 Sharepoint 团队继续使用成熟的技术进行开发,并连接到业务层提供的服务。因为 Web 服务的标准化和互操作性,将 Microsoft Portal 技术与基于融合中间件的 Web 服务结合使用就变得很简单。

关于身份和访问管理及安全性的决定证明是很难做的。这个主题下的组件必须提供:

身份验证 — 毫无疑问地确定访问外部 NOPERU 应用(Web 服务的用户界面)的实体的身份
  • 授权 — 根据访问应用端点的实体的身份确定在当前会话中启用哪些角色
  • 资源保护 — 确保仅在启用了所需角色的会话中访问安全资源
  • 身份管理 — 创建和管理数字身份,包括密码和/或安全令牌
  • 从组件到组件的身份持久性(包括一次性登录)
  • 加密/解密、数字签名、不可否认性等特殊措施

各种供应商提供身份管理 (IdM) 组件,每个组件都可以集成与融合中间件协作。IdM 组件的选择过程变得具有挑战性。执行涵盖所有 IdM 要求的完整概念验证并不容易。IdM 的专业知识并不普及,结果证明对 NOPERU 和供应商而言都很难找到所需的专家。进展有点慢。

关于 NOPERU 系统所有潜在用户的许可条件让决策变得更复杂:几乎整个国家/地区都可以访问门户来申请许可。NOPERU 正在就如何处理许可条款中的特定情况别情形与各种 IdM 产品供应商进行协商。NOPERU 不打算为每个潜在用户获取许可(但有些供应商恰恰要求这样)。相反,它希望在三个月的时间内按最大并发用户数(也可能是最大不同用户数)支付。NOPERU 还可以决定基于 CPU 内核签署交易。尚未做出最终选择。

幸运的是,WebLogic 平台中的 Oracle Platform Security Services (OPSS) 将平台上运行的各种应用(如 ADF 应用、SOA Suite 组合应用和 Service Bus 服务)与实际 IdM 技术隔离开来。OPSS 处理请求,与所选的任何 IdM 解决方案协商确定会话的身份和角色,并向 WebLogic 中运行的应用提供此信息。

jellema-case-for-FMW-fig09
图 9:Oracle Platform Security Services

现在所做的任何开发工作将不受以后有关用于身份管理和身份验证的特定产品的决策的影响。这给了 NOPERU 时间去找到一种 IDM 解决方案并达成令人满意的交易。

董事会批准了产品选择及相关合同之后,事情继续推进;基础设施准备好之后,就是实际安装软件和培训员工了。纸上存在多年的业务目标以及白板上多次描绘的架构设计到了实现的边缘。

软件开发流程、人员和组织

NOPERU 知道 2018 年底它要达到的目标。还有一点很清楚:它不会一步到位。必须设计一种方法,在控制下逐步带领 NOPERU 的人员、系统和流程实现目标,持续增加业务价值,同时照常营业。这种方法还必须处理好员工的雄心、焦虑、特权和能力。

NOPERU 仅靠自身无法及时、低风险地采用许多新技术和新的架构原则。该组织聘请了许多经验丰富的顾问,并仔细指示他们执行两个任务:交付所需软件构件和向 NOPERU 员工传授知识、优秀实践以及工作热情。聘请这些久经考验的外部专家指导、教育、培训和支持内部资源,同时也是来设计和构建新的软件和平台组件。

预期的变化率、业务目标数量和期望的灵活性,以及降低风险、削减成本和缩短上市时间的需求,都令 NOPERU 重新评估组织软件开发的方式。在 2011 年之前,NOPERU 的运营和开发之间,以及创建新功能和维护现有特性之间,是严格分离的。前者启动项目,后者由直线型组织处理。业务需求与 IT 交付之间存在着另一个明显的分界。一旦规定了这些要求,IT 部门将准备一份建议书和预算估算,并就内容、时间和数量达成协议。这个协议实际上是由两个部门签署的合同规定的。一经签署,就会启动项目,团队开始工作。开始验收测试阶段开始之前,业务几乎不会参与。新的业务洞察只能以非常正式的方式引入。没有最终用户或业务所有者对设计或原型实现提供早期反馈,也没有设计师或开发人员在业务开始之前提出稍微不同但更便宜的实现的建议。NOPERU 采用的是严格的瀑布式方法 — 往往以惨败收场。

2010 年前后,“敏捷”软件开发一词开始引起 NOPERU 管理层的关注。敏捷开发的原则包括业务人员与开发人员之间密切的日常合作,通过快速交付有用的软件和业务能够适应不断变化的需求(即使在开发后期)可以让客户满意。“拥抱变化”是参与敏捷项目的所有人的座右铭:为改变做好准备,并确保在改变到来时可以应对。

工作软件(而不是一堆堆的纸面正式设计)是敏捷项目的基础:要频繁交付(几周而不是几个月),是进度的主要衡量标准。

根据敏捷模型,面对面交谈是很好的沟通形式,项目围绕有积极性的个人而构建,应该信任他们。应该由自组织团队执行项目。持续关注卓越技术和优秀设计是至关重要的,简单性(尽量减少不必要的工作)也很重要。

简而言之,敏捷方法(Scrum 是 NOPERU 选定的敏捷框架)让业务和 IT 开发团队之间的联系更紧密。共同关注的焦点从正式合同和过程转变为创建业务价值,从冗长的设计会议和创建通用技术解决方案转变为具体的决策和务实的实现。现在,团队不再忙于设计和实现客户 6 个月之前认为她将在 8 个月内需要的东西。相反,它今天的工作是客户昨天说她在短短两周冲刺之后需要创建的东西。(注:在 Scrum 中,“冲刺 (sprint)”是团队每两个、三个或四个星期内要完成的小型项目。)团队无需浪费许多时间完全按照要求创建特性,而是将与业务所有者协商寻求更智能的实现,可能用略微不同但更容易实现的方式提供类似的功能。

尽管压力并不是非常高,但团队必须不断关注目前的冲刺,它有明确、具体的短期目标。而且由于重点是展示具有端到端功能的完整用户故事,而不是本身不会贡献任何业务价值的单个任务,因此团队成员往往会紧密合作。仅当案例完成后,从设计到实施(包括测试和代码审查),团队才得以展示冲刺的成果。当这是“完成”的定义时,团队往往会真正合作以完成案例,从而使各种学科之间的联系更紧密。

NOPERU 工作小组参加研讨会,拜访敏捷法的早期采用者,最终启动了一个小型试点项目。虽然最初遇到些冷嘲热讽,这个试点还是取得了巨大的成功。向董事会提交的最终结果报告得到了大力肯定,工作小组通过采用 Scrum 引入敏捷开发的建议获得董事会批准。2011 年初,下一个新业务功能项目以敏捷的方式组织。不久,其他项目陆续启动。

NOPERU 的敏捷实践

NOPERU 成立了一些 Scrum 团队,最多达到 9 个人。每个团队都有能力在架构中的所有层和技术上创建端到端的分片,并可以开发用户界面、服务和数据库组件;每个团队都包括一名分析师和测试人员。每个团队本质上都是自治的:Scrum 主管组织会议并安排设备和资源,但不充当团队负责人。管理员不加入团队,但与团队密切合作;稍后我们将在 DevOps 标题下进一步讨论这一合作

所有并发项目的业务所有者一起创建积压的“史诗 (epic)”— 高级别的新功能或更改的功能。对每个史诗,就其总持续时间、业务优先级(根据义务和法规驱动的价值和紧迫性)及依赖关系进行非常粗略的估计。随后将史诗转换为被认为适合一个冲刺的用户故事。基于史诗在整个积压上的排序,以及为史诗定义的用户故事,编写冲刺积压。接下来,冲刺积压上的故事被优化并分配给 Scrum 团队。

NOPERU 决定用两周冲刺来完成工作,这大概是可以实现的最短时间。这意味着每两周,团队将会执行一个小型项目,首先是评估用户故事,再定义所有任务并决定“承诺”— 积压中团队在冲刺内致力于的一组用户故事。针对每个故事,团队会根据“完成”的定义,承诺完成所有任务和整个故事。

在 Scrum 看板上捕获冲刺计划。在 NOPERU,这就是一面墙大小的纸张,其上创建了一张大表,列分别标记为 To DoIn ProgressReviewDone。行代表作为该冲刺一部分的用户故事。每个识别的任务变成一个便利贴。所有便利贴起始于 To Do 列,并应在冲刺结束之前到达 Done 列。
jellema-case-for-FMW-fig10
图 10:Scrum 看板

便利贴简略描述了任务涉及的内容。它还指明完成任务所需的估计时间。任务工作一旦开始,其便利贴就应该移动到下一列,其中包含便利贴上指示的执行该任务的团队成员的名字。

团队共同的焦点是完成看板上的所有用户故事,从顶部开始逐渐往下做。理想情况下,每个团队成员能够执行看板上的每个任务,允许人们选择最高级别的任务(看板左上方)。实际上,团队内每个人的技能和专业知识各有所长,并不是每个人都可以做每个任务的。然而,完成用户故事(而不是专注于完成任务)的共同目标意味着团队成员经常接受不一定在其核心竞争能力范围内、但对团队来说优先级很高的任务。协作、配对编程、经常沟通和知识共享是 Scrum 成功的重要组成部分。每日站会是确保团队工作按期顺利进行的重要方式,通过 15 分钟的会议,调整团队、分享经验和遇到的障碍、监督每个人的进度以及并评估团队完成冲刺目标的进度。

冲刺结束时进行冲刺演示,这是团队一直努力的目标。在本次会议中,团队向产品所有者演示冲刺成果。理想情况下,这意味着演示软件组件,也可能涉及设计活动或研发任务的成果,或者是作为讨论结果的决策。

为获得敏捷性和持续交付,企业必须承担重要责任。业务产品所有者一直参与整个过程,而不是提出相当含糊不清的要求,然后直接下发,或者在理论上非常详尽地规定功能,然后扔到开发团队手上。她会与团队协作来平衡预算、时间和功能;不断调整用户故事的优先级;并使用新近冲刺的结果确定后续冲刺的动作。不会提前起草详细的要求。由产品所有者体现的业务价值是永恒的驱动力。从略微不同的角度来看:产品所有者有机会随时监督开发团队的工作,检查是否有明确、具体的可交付成果,并且有机会几乎每天调整该过程。业务需求与开发团队的解读之间不能出现很大的差距。团队向产品所有者的即时反馈可以帮助确定更好的解决方案和更快的实施。这些短暂的反馈周期还证明对团队有很强的激励作用 — 远胜于不久之前那种遥遥无期的期限、含糊不清的业务目标以及详细但有时明显愚蠢、不一致或莫名其妙的要求。

Scrum 方法要想顺利执行,产品所有者必须就位、参与其中,并获得授权可以决定优先级和功能设计选择。这个角色可能促进但也可能破坏软件开发的努力。

敏捷和架构

对于敏捷方法,NOPERU 的架构师可谓喜忧参半。他们能看到让业务和 IT 人员紧密合作的价值,但对于过去在发布时发现交付的软件与业务需求不一致所浪费的机会仍然记忆犹新。然而,从架构的角度来看软件设计和实现,经典瀑布式方法的优点之一是有大量的时间来为项目要做的任何事情创建一个架构计划,并有充足的余地来保证质量。只要创建了商定的可交付成果,项目团队也可以确保它位于架构边界内。

以敏捷方式做事,对业务价值(短期功能收益)过于重视,可能会掩盖中长期问题(如可维护性、一致性、技术可升级性和非功能性因素 — 安全性、稳定性和性能),导致面临严重风险。团队很容易认为:“如果能向产品所有者成功演示,那就够了。”架构师担心如果强推做正确的事,那么用正确的方式做事的理念就会受到影响。

因此他们做了许多事来防止这种情况。首先,他们将高级架构设计和约定转化为设计人员和开发人员的具体指导原则。然后,他们与所有 Scrum 团队合作,确保遵循原则成为“完成”定义的一部分 — 这意味着只有在对照这些指导原则的验证成功时,可交付成果才能视为完成。此外,架构师还在组织“公会”(围绕特定角色和技术的虚拟团队,成员来自所有 Scrum 团队,如下所述)方面起到了重要作用。公会是一个讨论正确做事方式和增进相互了解的重要场所。公会成员还定期对同行创建的构件进行跨团队评测。

技术负债的概念非常明确。为了短期功能(业务价值)而在技术质量和遵从架构指导原则方面做出牺牲,就产生了技术负债。此负债应明确标识和记录。团队负责尽快处理这种债务。产品所有者和团队收到的指示都是要确保在产品积压中融入降低此类债务的目标。架构师密切参与监视每个团队中的技术负债。当债务增长过高时,他们可能会进行干预,并在产品所有者和团队之间居中调解,确保快速解决此债务。

NOPERU 还更进了一大步,声明每个团队将不仅负责创建新的构件来支持新的项目,还负责维护当前生产中的所有软件。团队今天所采取的任何捷径也将是他们未来在处理问题和维护代码方面的责任。任何未解决的技术债务将继续困扰团队本身。

工具

只有通过自动化的构建和部署过程(理想情况下包括测试)才能缩短发布周期,实现频繁得近乎持续的交付。应对这些构建和推出软件可交付成果的过程进行协调和监视。

jellema-case-for-FMW-fig11
图 11:敏捷与瀑布式

类似的方法也适用于部署构件的环境 — 构成开发的软件运行的基础架构的平台和框架的组合。该环境由来自第三方供应商的标准软件和此软件特定于 NOPERU 的配置组成。控制这些环境的创建、发布和更新需要自动执行和控制,以便实现敏捷、受控的交付过程。

NOPERU 选择了多种工具(其中大部分来自开源项目)来辅助软件设计。其中包括有助于完成各种任务(大部分是 DevOps 领域)的工具。

为了编排和监视整个构建过程,NOPERU 选择了 Hudson,并在 Jenkins 分支出现之后仍坚持使用它。构建操作本身主要是用 Maven 完成的,与之搭配使用的 Artifactory 用作代码构件的信息库。为了进行受控部署,还获取了一个名为 DeployIt 的工具(该产品不是开源的)。使用 Puppet 解决了发布整个环境的问题。

针对各种类型的测试活动,选择了以下工具:
  • Web 服务:SoapUI(功能)、LoadUI(负载和压力)
  • Java 和 ADF 业务组件:jUnit(功能和负载)
  • Web 应用:JMeter(功能和负载,主要是负载);Selenium(功能);Oracle Application Testing Suite(正在进行功能和负载测试评估)

此外,还使用了 SOA Suite 的一些内置测试特性。尝试通过使用模拟对象来创建 Web 组件和组合服务的单元测试。为此使用了 EasyMock(用于 Java)和 SoapUI 与 Jetty(用于模拟 Web 服务)。

使用 JIRA 管理服务单(问题、要求和增强请求)。该工具还用于协调积压(产品和团队冲刺)和 Scrum 看板。

使用 Subversion 控制源代码;虽然还就迁移到 Git 进行了一些研究。

使用多种工具控制代码质量,主要用于 Java 代码,尚未考虑 Service Bus、SOA Suite 和 BPM 构件:Sonar(用于集成来自各种其他 QA 工具的结果)、Checkstyle(用于验证是否遵从代码约定)、PMD(发现不良实践)和 FindBugs(用于查找潜在错误)。

为了便于团队和公会进行协作和共享,安装了 MediaWiki;它用于清单、方法文档、配置说明、服务目录、设计考虑事项记录和决策。还有 Wiki:架构指南、编码约定和 DTAP 环境描述,以及 Oracle Service Bus、Oracle SOA Suite、Oracle WebCenter Content 和 Oracle WebLogic 控制台及相关工具的 URL。

在许多不同地点工作的 NOPERU 员工之间的协作至关重要。员工使用即时通信 (IM) 工具 Microsoft Lync 和 Skype 来促进此协作。

组织和角色

应消除进行初始开发的项目与进行纠正和适应性管理的维护团队之间的差别。由于发布周期很短,基本不再需要专门的团队针对发布周期频率比项目团队高的情况专门进行维护工作。将技术和应用的专业知识仅局限于开发和维护似乎是一种浪费。让开发人员和团队负责发展(包括纠正)自己的可交付成果是一个好主意。

同时,还舍弃了项目团队的概念。将组建专注于某些功能领域的开发团队,所包括的开发技能也只是 NOPERU 所有在用技术的一个子集。这些团队可以参加由多个业务项目定义的用户故事(特性)。还要求它们花 20-30% 的时间在纠正性和适应性维护上。最多 10% 的时间可以自由用于“投入小、收益大”的活动:业务请求实际上不是正式的用户故事或项目积压的一部分,但可以用极小的风险和努力增加巨大的业务价值。鉴于发布周期短,这种灵活性可以轻松地让最终用户和开发人员都感到满意。

NOPERU 的大多数 IT 人员都参加了 Scrum 团队。这正是其日常工作和直接职责所在。如上所述,NOPERU 还成立了公会 — 围绕常见专业知识的跨所有 scrum 团队的虚拟团队。例如,有针对 ADF、测试、中间件平台、WebCenter Content、面向服务的设计、BPM、 Oracle Service Bus 和 SOA Suite 的公会。这些团队组织会议,维护一个公共 Wiki,在上面发布标准、指南、命名约定、示例、工具配置说明、方法文档以及相关互联网资源链接。他们紧盯所关注的技术在当前供应商以及行业内的发展。公会大师还充当教练,帮助初级成员增长知识。公会成员从所有 Scrum 团队招募:任何人只要使用特定技术或处于特定角色,就可以参加相应的公会。除了共享信息和知识之外,公会还在保持各 Scrum 团队之间采用一致的方式使用技术方面发挥了重要作用。

对每个角色的影响

虽然 NOPERU 新的软件开发方法几乎对牵涉到的每个人都有影响,但对于测试员和管理员还是有特别的影响。

例如,测试人员过去经常出现在瀑布式方法中;经过充分准备后,他们会根据详细的设计文档“折磨”软件构件,验证其适用性。测试通常是隔离执行的;只能通过问题跟踪系统联系开发团队。测试几乎完全集中在用户界面上,基本上忽略了内部组件。用 Scrum 方式进行的测试 2.0 则完全不同。测试人员包含在 Scrum 团队中,测试是作为每个冲刺的一部分执行的。设计文档是高级的(如果提供的话)。测试的目标是用户预期和界面设计,并涉及大量非用户界面服务,如 Web 服务和数据库 API。使用工具进行自动化的(回归)测试的情况正在快速增多。测试人员和其他团队成员(如分析师和开发人员)之间的沟通和协作从近乎没有到相当热烈。测试人员在冲刺的早期阶段从事其他活动,分析师和开发人员在冲刺快结束时接受测试任务,这种现象很常见。软件质量的反馈比旧的工作方式快得多。但要注意,测试可能不像以前那么严格,尽管逐渐积累的自动化测试集最终会将测试带到一个相当高的水平。

同样,管理员的变化也很大。多年来,管理员要么管理硬件和系统,要么管理数据库,其活动与开发项目脱钩,仅针对生产系统。引入虚拟化意味着需要新的技能,并且可以用新的选项来快速部署新的环境,例如,将环境轻松回滚到先前的快照。规划计算机不再意味着等同于规划硬件。

下一波主要的革新是引入中间件:应用服务器作为核心元素,然后是在应用服务器上运行多个引擎,每个执行不同的功能,需要在安装、配置和监视方面进行管理。必须积累有关 WebLogic Server 的专业知识,建立对 Service Bus、SOA Suite、WebCenter Content 和 BPM Suite 的管理。

平台管理和基础设施管理被视为两个单独又互补的学科,正在采取一些步骤以私有云服务的形式组织和提供平台和基础设施。此外,已经开始研究如何使用外部云设施进行负载和压力测试等目的。

DevOps

开发和运营之间的界线在 NOPERU 变得有点模糊。一个原因是敏捷开发方法,从开发到测试、验收测试(至少在理论上)甚至生产的频繁交付都需要开发人员和管理员之间的密切协作。另一个原因是平台(数据库和应用服务器与中间件容器的组合)在现代架构中的重要性。开发人员和平台专家必须就应用服务器、服务和 SOA Suite 召开会议,讨论缓存策略、故障处理、安全要求以及其他需要功能知识才能配置的非功能性方面。

因为开发团队开发的软件所经历的典型阶段与平台和基础设施应经历的阶段(设计、构建和测试)相同,平台专家早期介入是有道理的。通常,基础设施部门中负责日常运营的管理员是安装、配置和管理平台的专家,无论平台是在运行时使用(生产环境)还是在开发和测试阶段使用。

图 12 显示了 NOPERU 体系的各层:应用、平台和基础设施。每个类别都将经历准备阶段(设计、构建和测试)并将终止于执行监视和进行修改(配置、打补丁、发布新软件组件、重新启动组件等)的运营阶段。

jellema-case-for-FMW-fig12
图 12:体系中的各层

上图显示了应用开发团队应如何与平台“开发”团队紧密合作。同时,当生产环境的应用出现问题时,应由执行应用的原始开发团队采取纠正措施,而不是由一个单独的维护团队来执行。

NOPERU 一直在努力弥补数据库和中间件平台管理员与开发人员和架构师之间因历史原因导致的关系缺口。真正开始合作的强烈动机源于相互依赖:如果开发人员开发的软件组件实际上并不适用于生产环境,开发人员就称不上成功;如果平台不能真正为最终用户提供功能业务价值,管理员也不能称作成功。NOPERU 采用的敏捷方法中软件的快速发展令所有相关方面都非常清楚这一点。

图 13 显示了开发人员和管理员都必须打交道或可用于执行其作业的技术和工具。

jellema-case-for-FMW-fig13
图 13:技术和工具

路线图和项目

NOPERU 的每个人似乎都认同 2018 年的远景。组织的目标很明确,但确切的路线图却没这么明确。预见的变化应按何种顺序发生?有多少能够实现?何时实现?最重要的是,业务重点是什么?

由于业务目标、IT 优先级(集中和整合,按新架构开展工作和应用新技术)和政治决策者的期望不一致,在 Go Forward 计划下执行的头几个项目中不得不做出一些妥协。这种理想情况将逐步实现,同时,涉及的所有 IT 人员都需要务实的做法。

企业部门的 B2B

NOPERU 一些最大的企业客户每年都要申请多个业务线的数百个许可,他们要求通过电子网关进行交互。这些企业已经与其业务合作伙伴集成,并与提供商、供应商、税务机关和其他政府机构执行 B2B,与 NOPERU 之间低效的书面交往已变成过往。

NOPERU 的利益相关方因为需要一个自动化界面,这个业务要求被视为开始实现部分 IT 路线图的一个大好机会。B2B 网关适合分层架构和面向服务的方法。这是架构师和开发人员的第一个踏脚石。考虑到安全性、可用性、吞吐量和响应时间,引入了 Oracle Service Bus 和 SOA Suite 来开发所需 Web 服务并以适当方式公开。建立了一个中央数据库,但因为区域实例尚未消失,在中央数据库与这些区域卫星之间建立了复制机制。初始消息量相当小,初始启动后的头六个月几乎变成一个延长的试行期,只有两个企业客户。后来,参与的企业数量快速增加,消息量也快速增加。

这第一个 Go Forward 计划相当成功,相对顺利。它之所以成功,部分原因可能是它没有取代现有系统,只是对现有系统的补充。测试期间非常仔细、架构团队的密切参与以及多个经验丰富的外部 SOA 顾问的参与,这些也起了重要作用。

B2B 网关的 24/7 可用性需求提出了一个重大挑战。在这个门户出现之前,NOPERU 的内部系统都只需在办公时间内使用,这就给批处理作业、系统维护和软件升级留下了足够的时间。甚至计划外停机也停留在 NOPERU 内部。但门户宣告了持续可用性时代的来临;在这个阶段,它只适用于中央数据库和中间件平台,但无需太久,也同样适用于其他系统。

数字文档

这五个 NOPERU 地点中的每一个都有一个装满了数十年纸质存档的地下室,且一直都在不断流入。在与许可申请相关的书面记录到达存档之前,它会辗转通过各办公室 — 从桌面传递到桌面,有时会丢失。NOPERU 最大的挑战之一也是节省大量资金的机会,在于从纸质文档转换到数字文档。除了腾空地下室之外,数字文档还可以更轻松地传输、并行共享、随时追踪、向外部各方发布以及自动解释和处理。许可申请人可以用电子格式将相关文档提供给 NOPERU,从而大大减少 NOPERU 自身的工作量。

数字文档的业务计划 2011 年开始实施。其目标是实现一个中央内容服务器,将通过区域办事处使用的内部 Web 应用进行公开。内容可以通过 Web 界面上载,也可以通过 Web 服务上载;任何文档均可通过相同的渠道检索。一直想增加移动支持,但目前尚未实现。除了 IT 这方面(本身就是一个大挑战),这个项目还必须让组织快速适应这种无纸化工作方式以及随之而来的所有新任务和新过程。鉴于核心业务流程(处理书面许可申请)的执行主要是由需要在办公室内经过繁琐手续的纸质文件驱动的,在启动业务流程管理 (BPM) 之前的过渡期需要另外一种组织流程的方式。

内部员工的新 UI

虽然它在政治日程表上的优先级并不高,NOPERU 还是需要对内部应用做点什么。例如,公民部门仍在使用基于字符的 Forms 4.5 应用,源自于最初于 1993 年开始采用的 Forms 3.0 应用。尽管这个应用仍然允许该部门处理许可申请,但它是以自己的特殊方式进行的。将所有快捷键熟记于心的长期用户对底层业务流程无比熟悉,基本上都使用此应用很多年了,甚至都非常有成效。然而,新用户的学习曲线出奇的长,无法让临时工帮助处理高峰工作。找到愿意使用这种过时计算机系统工作的新员工也变得越来越困难。由于代码无书面文件和在五个地点进行的升级过程,系统维护成本高昂且很费力。目前还有充足的 Forms 开发人员;但不确定这种情况还能持续多久。最后,该应用是严重面向数据的(“CRUD 式”),丝毫不能体现业务流程。转向更专注于任务和流程而较少专注于底层数据的用户界面,已经成为 NOPERU 的一个长期愿望。

2011 年中期启动了一个项目,重新为公民部门构建许可申请。从长远来看,这个新开发的应用将成为所有三个部门的平台。最初(计划于 2012 年底启动)将只有公民部门的员工使用该应用。该应用将有一个实例,集中部署和管理,并从浏览器访问。它还将拥有一个中央数据,其中整合来自五个区域的所有数据。

该应用是采用 ADF 11g 针对 Oracle Database 11gR2 数据库开发的。团队由来自外部的多位经验丰富的 ADF 顾问以及五名 NOPERU 开发人员组成。后者具有许多 Oracle Forms 和数据库开发经验,并在项目开始前接受了两周的 ADF 入门培训。在项目过程中,每个 NOPERU 员工都指定有一名个人教练以确保向其传授知识,内部开发人员也积累了 ADF 开发技能。

许可申请 (PA) 系统于 2013 年上半年推出。到五月份,所有五个地点都启用了 PA,并关闭了本地 Forms 实例。性能出现过一些小波动,但到七月初,这第一个应用已经支持数百个并发用户。

升级到 Forms 11g

企业部门和政府部门用于核心许可处理流程的 Forms 应用已经升级到 Forms 11g。这些应用也运行在 WebLogic Server 11g 上,所有其他中间件组件也是用这个核心平台。此外,还从 Forms 11g 功能中获得了一些好处,包括支持 Advanced Queuing 和使用数据库代理用户。从 Forms 4.5 到 11g 的升级用时相对较短。与现代 Forms 11g 应用相比,结果并不特别令人眼前一亮,但对于这种过渡期足够了。(注:到目前为止,这些区域将拥有 Forms 11g 应用的本地实例,基于本地数据库运行。)

下一步可以整合到一个中央数据库,然后使用虚拟专用数据库的策略从逻辑上按区域对数据分区。然后可以用基于整合后数据库运行的中央 Forms 11g 实例替代本地 Forms 11g 实例。

企业客户门户

通过门户(一个用户界面加上通过 B2B 网关提供的编程接口)为公司提供服务。通过这个用户界面,企业能够提交和跟踪许可申请并与 NOPERU 员工沟通。

该门户是用 Microsoft SharePoint 开发的,用于呈现服务,呈现服务以 SharePoint 开发人员友好的方式公开组合服务和基本服务的功能。企业门户重用了许多创建 B2B 网关时创建的服务。此门户还利用了中央数据库(它有使用区域数据库建立的共有副本)。

设计和开发支持新业务需求的软件时使用的分离式方法大大有助于门户的创建。门户设计人员和 SharePoint 开发人员根据 UI 设计指明其服务要求。随后,对应地设计了现有和新的组合服务和基本服务。所有服务和操作的界面由指定团队设计,当表明意图并达成一致时,两个团队就开始顺利实现组件。

内部管理人员的移动应用

目前还在进行另一个计划:负责批量处理许可申请的 NOPERU 管理人员要求采取一种手段来更好、更即时地了解团队运作情况。满足许可过程中每个步骤的正式期限很重要;事实上,可能会有法律后果。加快流程,至少快速识别停滞的流程变得越来越重要。

预计当引入 BPM 时,它多少能提供一些现成的这种运营洞察力。目前,数据库开发人员将创建很多视图,以公开有关许可申请的状态信息。然后,呈现服务将这些视图作为 RESTful、基于 JSON 的服务发布的服务公开。

移动应用(iPad 的原生 iOS)由外部公司开发。为这家公司提供 RESTful 服务和 JSON 负载的定义之后,这家公司现在就以高度分离的方式在异地工作了。

未来发展

在不久的将来,NOPERU 计划启动几个新项目:

24/7 可用的公民自助网站

如果公民可以自行查看许可申请的进度,而不是必须在办公时间联系 NOPERU,可能会消除公民的许多烦恼。因此,就像企业部门开通了门户一样,公民部门也将开通门户。任何公民都可以使用相应的身份证号码登录此门户。在门户中可以请求新的许可,也可以查看运行中的申请的状态。NOPERU 可以要求公民提供更多信息或上载附加文档,而公民也可以向 NOPERU 提问。

公民可以通过门户提供所有与目前以纸质递交的许可申请(必须手动扫描和输入)相关的所有信息。这显然将可以大大减轻 NOPERU 人员的工作量。同时,用户可能会觉得这种自助功能非常便利,让他们可以随时随地开始申请许可。

尚未决定采用哪种技术创建公民门户。它将重用为企业门户创建的服务。

通过 BPM 实现业务流程的方法

如上所述,NOPERU 希望采用业务流程管理。它希望更好地掌握业务流程,优化和简化业务流程,改进实现,在更多方面实现自动化。当 IT 系统由流程驱动时,NOPERU 希望能够快速更改流程,让新员工快速上手,因为系统将指导员工完成流程。这种流程方法预计可以为管理层提供运营洞察,并在有超过阈值或期限的危险时发出警报。

CRM 的标准应用

没有人知道什么时候(或是否)会发生,但不久的将来就可以使用现成的商业 CRM 应用(如 Oracle Siebel)替代定制应用管理客户详情。架构师对于保持 CRM 域完全隔离和封装给出了严格的指示,因为总有一天它们会被取代。发生这种情况时,从 CRM 域公开的所有服务就必须使用 CRM 应用作为其实现。只要所有 CRM 服务接口都可以使用 CRM 应用中的 API 实现,CRM 服务的任何使用者都不应感觉到这种替代的任何影响。

总结

NOPERU 已经完成了部分 Go Forward (2010-2018) 计划。在通过 IT 迁移现有系统或引入新业务功能的许多项目中,头几个已经执行或正在进行中。已经引入了新技术,从根本上改变了软件的开发方式。虽然道路是坎坷的,但成功还是远多于失败。刚开始采取服务导向和分层架构时,还有很多人不情愿,但现在这种情绪已经改变了。许多 IT 员工现在普遍都相信这种方法,并相信自己能够在其中发挥作用。热情随着自信与日俱增。

过去几年,NOPERU 自己的员工、政府对口单位、合作伙伴和客户对 NOPERU 的印象大为改观。应用现代化受到相关各方的欢迎,均报告服务和信息质量有所提高。一项最新调查发现,等待时间缩短,错误减少,体验更佳。一项内部评估报告了类似的结果,满意度上升,标准调查问题“您是否打算在今后的一年在 NOPERU 工作?”的得分明显提升。

Go Forward 计划刚开始时,将数据整合到一个数据库中,并将所有基础设施集中到一个数据中心(为了进行故障切换,有两个物理站点)。所有管理活动也集中了。事实证明,效率要更高:需要的管理员更少,所需的管理员都各有专长。现在管理员负责更大一片专门领域,而不必须什么都管 — 从网络和存储一直到操作系统和数据库。这种专业化大大减少了需要外部帮助的次数。这又意味着成本下降,解决问题的时间变短。

数据整合分几个步骤进行。首先,数据存储在一个数据库中,按地区和部门进行逻辑分区。逐渐地,数据正在变得真正共享,减少复制和由此导致的不一致。这不仅仅是一个技术过程;它还需要向对共享数据心存警惕的业务代表施压。

从 Oracle 经典形式(Forms、CRUD 式数据、面向数据库、SQL 和 PL/SQL、Discoverer、Designer)和瀑布式方法转变到全新的敏捷和面向服务(以及 Java 和 Web 用户界面、移动和 BPM)对于 NOPERU 人员是一个极大的冲击。指导、保证、解释甚至精神上的支持对于激励和培养几乎每种角色的员工都是绝对必要的。长期以来,需要不断关注才能让心存怀疑的人参与进来。如果 NOPERU 想要成功快速发展,沟通是至关重要的。

从业务所有者到管理员的所有角色都需要参与初始过渡以及涉及软件开发的每一个新计划。

“拥抱变化”是敏捷方法对软件开发的咒语。但这对于许多有关方面仍然是一个挑战。即使大家公认变化是游戏的一部分,方向和规划的变化还是经常导致业务中断。为了保证参与和积极性,让 Scrum 团队成员在这种改变发生的早期就参与非常重要。

Scrum 方法在 NOPERU 快速站稳根基。最初的怀疑大部分很快被消除,有些早期的怀疑者现在成了真正的(有时是狂热的)Scrum 信徒。团队成员对团队的承诺以及团队对业务目标的承诺均有大幅提升。持续关注近期期限以及业务代表的快速反馈极大地激励了团队,而团队对业务的快速反馈也有助于后者调整需求。IT 人员通常都很聪明,虽然有点过于专注,他们的意见用于改进计划和设计。

业务所有者对敏捷开发的深入参与和支持对于努力的成功至关重要。业务所有者的支持度越来越高,表明了对转变到这种新的工作方式中所涉及的所有角色的影响。特别是管理员和测试人员必须适应新的思维方式。尽管在 Scrum 方面取得了成功,NOPERU 仍困扰于冲刺的短期重点与长期架构目标之间的紧张关系。“技术负债”(如上所述)应在不久的将来解决,所有各方原则上都同意;但是业已证明,要将团队的部分能力从功能业务价值转到长期软件质量和可维护性还需要长期努力。

由于所有关注重点都在中间件上,还需记住数据库和 SQL 及 PL/SQL 技能对于整个 NOPERU 应用架构的成功仍然是非常重要的。性能、可扩展性、完整性可能因数据库功能的良好运用受益,也可能因不良运用而受损。

已经证明,引入经验丰富的顾问对 NOPERU 大有裨益:这有助于防止成本高昂(且费时)的错误(这些错误还会产生挫败感,削弱对一个已经脆弱的环境的信心),还有助于 NOPERU 选择和应用成熟的优秀实践。有经验的外部人员还会负责在实际操作环境中传授知识,而不仅仅是在教室中。

最初,引入外部人员演示做事方式,然后与内部人员平等协作,最后在内部人员真正接手时充当兼职教练和质保员。长期目标是增长内部人员的能力;在短期内,经验丰富的外部人员可以帮助提高工作效率。

面向服务的架构

尽管从长远来看,服务导向会产生巨大回报(通过现有服务上的重用与敏捷开发),但需要初期投资才能将架构和基础设施落实到位。有些投资是先于收益的。推进分层架构和采用这种 SOA 是一个需要坚定执行的战略决策。

服务的实现与使用者无关。这意味着,除了其他好处之外,如果可以将原有应用封装在与标准兼容的接口内,通过这些原有应用之上的适配器从接口进行协调,那么原有应用可以非常好地嵌入 Go Forward 的新架构中。通过封装,随后可以使用所选技术(或许是一个 COTS 产品)用自定义实现替代服务的原有实现及其适配器。

采用分离式架构方法,专业团队还可以在系统环境内明确标识的隔离区域内工作;这还意味着不是每个开发人员都需要(立即)获取相关的所有工具和技术的技能。

采用分层架构和分离式软件设计,可以将大量工作外包给外部合作伙伴。例如,一旦议定全部服务接口,就可以让另一个公司基于这些接口构建网站或移动应用。快速开发和灵活的软件工程能力 — 特别是在使用基于云的开发环境时 — 都直接摆在 IT 经理面前,唾手可得。

治理 — 通过生命周期管理服务和相关资产的方法(如规范模型)— 至关重要,尤其是在中长期范围内。它还包括识别新服务和对现有服务的更改,以及编制服务目录,便于查找和最终重用服务。另一个要组织的方面是设计和实施方面的 QA,以确保一致性和遵从作为治理举措的一部分指定的标准。

展望

在不久的将来,NOPERU 将继续执行 Go Forward 计划。BPM 是新的主要焦点,它不仅能确保正确执行过程并提供有关当前事务的管理信息,还有助于优化流程和部分实现流程自动化。希望在引导新员工完成流程时可以减少所需的培训。其中一些操作将变成自助活动,由作为编排的流程中的参与者的外部各方执行。

吸引 IT 新人和积累内部专业知识以降低对外部顾问的依赖,这对 NOPERU 来说非常重要,它现在正在积极接洽当地专家,尝试将他们挖过来。对于现有员工,NOPERU 正在组织开发计划,这将帮助他们增长与新引入的技术和方法有关的技能。员工可以参加国际会议和研讨会,以便接触同行,了解新信息。NOPERU 还邀请了一些著名演讲者为内部员工和希望雇用的受邀者举办专题讲座。在这一次重大技术变革中发挥关键作用的机会已经吸引了许多新的 Oracle 融合中间件专家到 NOPERU IT 部门的各级职位。

从稍微长远的角度来看,NOPERU 希望可以用现有数据做更多的事情,这可能会引起外部各方的兴趣。NOPERU 还希望能够更多地了解峰值量和趋势,以便简化流程和准备人员。

移动应用的发展刚刚开始。NOPERU 的近期计划中,还包括郑重地开放多个渠道。它期望利用分层架构和可重用服务,以便能够快速推出新的交互方式。

最后,国家政府内的重大发展也会影响 NOPERU。所有公民和企业都将拥有一个身份证号码,用于与包括 NOPERU 在内的任何公共机构互动。有关这些各方的基本信息将由一个指定的国家机构集中管理。不再允许各机构在自己的系统内记录此类信息,而是必须利用这种集中保存的数据。另一个中央机构将负责从与任何政府机构有财务交易的任何一方收费。这意味着 NOPERU 将必须与这个新机构打交道。请注意,这些计划与面向服务的架构中发生的事情非常类似:各业务功能是隔离的,打包在明确定义的适合重用的接口中,并具有封装的实现。

最后说明

您的组织不大可能与 NOPERU 完全一样。但同时也有可能与 NOPERU 的起始情况、业务目标和/或它正在经历的技术转型有很大的重叠。本文的方法、步骤以及结论很可能也适用于您的情况。

关于作者

Lucas Jellema 自 1994 年起就活跃于 IT 领域(就职于 Oracle)。作为专注于 Oracle 融合中间件的 Oracle ACE 总监,Lucas 担任了多个领域的顾问、培训师和讲师,包括 Oracle Database(SQL 和 PLSQL)、面向服务的架构、ADF 和 Java。他是《Oracle SOA Suite 11g Handbook》一书的作者,并且经常在 JavaOne、甲骨文全球大会、ODTUG Kaleidoscope、Devoxx、OBUG 和其他会议上作演讲。
联系 Lucas Jellema Oracle ACE 总监