设计一个 SoE 生态系统来支持富用户体验

参与型系统:全新的云时代

无论是在消费者环境还是企业环境中,参与型系统(systems of engagement)都在日常生活中发挥着越来越重要的作用。用户在寻找一种从多个不同的结构化和非结构化来源收集和分析信息的富体验(rich experience),以帮助他们快速制定精明的决策并付诸行动。云操作环境是支持参与型系统的平台。本文介绍了一种设计参与型系统的生态系统的方法。

Fabio Castiglioni, 高级 IT 架构师, IBM

Fabio CastiglioniFabio Castiglioni 是 IBM 意大利的销售和分销部门的一名高级 IT 架构师。他在一个开发实验室有十三年多的经验,包括了国际项目中的技术和管理职位。在 1995 年,他在一个 OO 技术的研究项目中被委派为技术总监。在 1998 年,他在大的政府项目中作为一名 IGS 高级 IT 架构师。Fabio 是 IBM 架构师组件建模课程的一名教师。他于 2005 年在 SOA 和 Web 服务研讨会上担任讲师,于 2006 和 2008 年担任 TLE 讲师。


developerWorks 投稿作者

Michele Crudele, 软件架构师, IBM China

Michele Crudele 在罗马的 IBM 软件部 Tivoli 实验室担任软件架构师。他拥有 20 年的 IT 从业经验,主要从事系统管理产品和解决方案的开发工作。Michele 曾从事过不同类别的工作,拥有广泛的技术经验,比如变更配置管理、监视和可用性管理、IBM 自主计算技术及出版行业的数字资产管理。Michele 目前致力于云计算解决方案的开发,是 TSAM 扩展的首席架构师。



2014 年 1 月 16 日

在线用户越来越多地需要一种富体验,以利用来自不同的结构化和非结构化来源、社交渠道和同伴用户的信息。用户可以快速提取这些信息中包含的价值,从而实现个人目标和支持明智的选择。这种类型的体验不仅已经成为消费者领域的标准,而且目前还成为了企业应用程序的一般期望。参与型系统 (SoE) 能够支持这种富体验,从来自多个渠道的信息中提取价值,实现新的数字化业务模型。云操作环境 (CloudOE) 是支持 SoE 工作负载的平台。CloudOE 提供了一个开发、部署和操作 SoE 应用程序的生态系统,实现了 SoE 所需的敏捷性和速度。

设计 SoE 生态系统是一项新任务,像用例这样的传统分析方法局限性太多,无法代表支撑 SoE 模型的决策。本文提供了一种替代方法,介绍它对设计过程的影响。通过使用一个旅游业示例,解释相关设计概念和开发流。

基于参与的流程和系统

基于参与的流程已是多个行业的主流,在其他行业也变得越来越重要。这方面的示例包括:

  • 假期规划:使用 Internet 的假期规划是最成熟的基于在线参与的市场。访问价格对比引擎,咨询 TripAdvisor 等信誉系统,查看上下文数据(比如 Google Maps 上的数据和 Weather Channel 上的天气信息),以及找到社交网络上的专家组并与之交换信息,这些都是数字化游客的常见行为。
  • 金融咨询:银行很久以前就已从仅提供一个执行财务操作的柜台转变为财务健康顾问,与客户建立了一种持续、稳定、当面的关系。这样一种关系需要持续的、最新的知识,以及顾问与客户之间的信任。
  • 新的个人福利计划:由于更少的预算和越来越大的经济压力,一些政府正将注意力从通过津贴避免社会动荡,转向通过再次让居民参与生产周期的个性化计划获得社会成果。这种方法需要跨机构协作,集成来自公共和私有来源的居民数据,关联结构化和非结构化信息以识别最可能在各个情形中获得成功的计划。
  • 欺诈和滥用调查:在全球电子市场中,欺诈和滥用已出现新的形式,达到了新的复杂高度。要调查它们,需要分析和对比来自不同的、常常似乎无关的来源的海量结构化和非结构化数据。该数据的时间和地理位置,以及多个组织之间的协作,是这一方案的关键促成因素。
  • 基于上下文的购物(基于位置感知):基于个人移动设备的地理位置的位置感知,使一种新的零售场景成为可能,通过基于用户导航历史记录的搜索引擎 “上下文” 广告,扩展了在 Internet 上司空见惯的体验。

对 SoE 的支持为许多行业带来了新的可能性。用户可拥有该系统的富体验,在过去,这是只能通过人与人的交互实现的一种体验类型。实际上,参与在本质上是以人为中心的。在记录系统 (SoR) 中,以记录为中心的流程通过一个数据注册序列跟踪用户的进度,与之相反,SoE 的目的是实现对用户有意义的目标。


SOE 生态系统

在 2011 年的一份 白皮书 中,顾问 Geoffrey Moore 引入了术语参与型系统 来描述一类系统,这类系统致力于 “让企业中层能够使用改编自消费领域的下一代 IT 应用程序和基础架构,跨企业边界、全球时区及语言和文化边界进行沟通和协作。”

在本质上,SoE 对移动、社会、云公共服务和传统 IT 系统 (SoR) 应用了预测分析,以便直接在客户、合作伙伴和员工的日常生活环境中提供应用程序和智能产品。

图 1 演示了一种 SoE 生态系统:

图 1. 一种 SoE 生态系统
一种 SoE 生态系统的演示。该 SoE 使用了来自移动设备和传感器、社交渠道、公共服务和记录系统的数据。它在该数据上执行预测分析并向用户提供建议。

一个 SoE:

  • 支持协作:SoE 是为人类而生的,它们假设人们将会相互协作。相反,SoR 的主要关注点是用户(人类)与系统(机器)就某个特定流程进行的交互。在一次参与中,人与人之间的交互和人机交互具有平等的地位,是整体协作的一部分。
  • 利用来自多个来源的丰富数据:SoE 离不开大数据。通过分析不同的数据源来提取有意义的实用信息,这是人类推理的核心,也是 SoE 的核心。
  • 适应身份和偏好:在担任 IT 专业人员时,您拥有与学龄儿童的父母不同的行为和偏好(尽管两种身份通过某些方式相互影响彼此)。但是,对于一些 SoR,您的所有角色都使用相同的 ID、地址、政府 ID 编号等。SoE 不是这样。SOE 必须考虑您的工作、偏好和历史(简言之,您的背景)来提供想要的富体验。实际上,SoE 必须使用许多动态数据分析或主数据管理 (MDM) 系统,在其中维护并不断充实复杂的用户信息。
  • 时间和位置感知:富用户体验必须考虑我们生活在时间中并在空间中移动的事实。如果预计您打算去的海滩下周将会发生热带风暴,但您却收到了这个海滩的阳光明媚的照片,这对您的出行而言不是一种优秀服务。(这是大多数当前的预定 SoR 所提供的服务水平。)在您参与一次活动的过程中,移动设备为更丰富的交互提供了机会。
  • 支持多种交互方式:移动设备可能带来最丰富的客户体验,因为它们可包含用户在参与逻辑中的位置。但一些参与不需要位置感知,所以可从常规 PC 有效地使用这些参阅。其他类型的设备(比如信息亭,甚至是 ATM)可能在其他例行的参与中发挥着一定作用。
  • 维护适当的安全性和隐私:因为 SoE 了解了您如此多的信息,所以它必须保证这些信息的安全。用户必须能够控制谁能获取该信息。但公开的数据越少,获得的服务就越少,因为针对用户个人兴趣的信息和服务定制是该系统的主要功能。(在这方面,SoR 没有那么严格,因为它通常可将行为差异归纳为用户类或用户个人资料。)

云操作环境:SoE 背后的技术

与 SoR 相反,SoE 必须被设计为用于处理不稳定的资源需求及计划外和不可预测的容量需求。此外,为了让自身在市场中脱颖而出并提高收入,它们必须使客户能够快速从可用数据获取更多的洞察。出于这些原因,SoE 需要一个平台来使应用程序容易部署、管理和扩展。然后开发人员可以专注于应用程序本身的开发和操作,而不是需要托管该应用程序的基础架构。

基础架构即服务 (IaaS) 云为开发人员提供了几乎没有大小限制的数据中心,无需提前进行任何硬件购买。但是,开发人员仍然需要配置虚拟机、安装中间件软件、连接系统组件和维护系统,所有这些都会占用真正的创新工作的时间。甚至在开发人员在 IaaS 之上实现 DevOps 时,他们仍然需要花时间构建和管理操作。

DevOps

DevOps 是一种软件方法,旨在改进开发人员与操作团队之间的沟通、协作和整合,目的在于加速软件交付流程。一种 DevOps 实践是将重复性的配置管理任务描述为模板(称为处方或秘诀),(使用 Chef 等工具)构建运行该模板来自动化基础架构的管理和维护的系统。

云的功能不仅仅是提供 IaaS。CloudOE 可负责部署、配置和连接虚拟机,让开发人员能够将更多的精力集中在应用程序上。CloudOE 可自动化 DevOps 过程,这会转化为面向开发人员的 NoOps。CloudOE 成功的关键是它能够多有效和多快地支持前线开发人员构建自己的应用程序。

服务类别

案例分析已经表明,CloudOE 平台应支持 4 种类别的服务,所有这些服务都是构建和操作以云为中心(或云原生的)应用程序(比如 SoE)所必需的:

  • 开发服务
  • 应用程序服务
  • 基础架构服务
  • 操作服务

CloudOE 平台应提供了各种不同的这类服务,通过一个有结合力的、简单的客户端 API 可以让它们易于使用。只对单一编程语言和单一 Web 容器提供支持是还不够的。CloudOE 应适应各种专用的 Web 开发框架(比如 Grails、Play Framework、Ruby on Rails 和 Django),语言(比如 Java®、Ruby、Python 和 Node.js),以及编程模型。

在核心应用程序服务中,该平台至少应该提供:

  • 关系数据库服务
  • 基于文档的 (NoSQL) 数据库服务(比如 MongoDB)
  • 消息服务
  • 存储服务(比如 OpenStack Object Storage)

图 2 总结了一个 CloudOE 平台为支持 SoE 工作负载而应该提供的关键服务:

图 2. 支持 SoE 工作负载的关键服务
支持 SOE 应用程序和工作负载的关键服务(开发、应用程序、基础架构和操作)演示

最重要的是,所有操作都应具有一种流畅、简洁的开发人员体验,可能类似于:

  1. 起源:
    • 我从 CloudOE 门户创建我的帐户。
    • 我下载命令行工具(作为开发人员,我喜欢命令行)来管理应用程序和服务。
    • 我下载采用我喜爱的语言的 CloudOE 客户端 API。
    • 我还可以为我喜爱的 IDE 下载 CloudOE 插件。
  2. 现在我可开始开发下一代 SoE 应用程序了。我需要一个关系数据库来存储元数据,需要一个对象存储服务来保存我想要管理的对象 blob(比如照片、图形和文章)。然后我需要获得针对我想要使用的 Web 开发框架的运行时支持。
    • 我看过文档,我发现 CloudOE 提供了所有这些功能。
    • 我使用命令行或 IDE 插件请求一个数据库服务和一个对象存储服务。CloudOE 自动为我将这些服务部署到其基础架构中。
    • 我编写我的应用程序,使用 CloudOE 客户端 API 连接该服务。
    • 我使用 IDE 插件或命令行部署该应用程序。CloudOE 自动为该应用程序配置运行时环境,创建与所需服务的连接,而且还为我提供了一个 URL 来访问该应用程序。
    • 我测试该应用程序。

可移植性

客户不希望被一个云提供商禁锢。他们应该能够因为在一个不同的 CloudOE 中运行而轻松调整自己的工作负载。理想情况下,CloudOE 应用程序可部署在客户自己的硬件和中间件软件上,只需更改配置,无需更改节点。

使用 CloudOE,开发人员可在几小时内完成在传统环境中需要几天的工作。他们不需要部署 Web 应用服务器来托管应用程序,也不需要部署数据库和保留存储空间。

CloudOE 平台的基础架构和操作服务使得该平台的价值变得更加明显。这些服务主要在应用程序从开发环境转移到验证环境并最终转移到生产环境时发挥作用。CloudOE 应提供配置多个托管应用程序的隔离环境的能力,还应该提供简化持续交付和集成任务的工具。

基础架构服务的显著特征是应用程序的水平扩展:在需求增加时增加更多的实例,在需求减少时释放实例。操作服务提供了以服务形式访问应用程序的管理功能的能力,无需部署和维护一组内部管理产品。理想情况下,一个操作团队只需在 CloudOE 门户中单击几次,即可启用应用程序(及其服务)的定期备份。开发人员可获取服务数据的快照,以便可将它们还原到不同的环境来分析问题。

真实的 CloudOE

本文描述的 CloudOE 不是科幻小说;它们很快就会成为现实。一些云平台即服务 (PaaS) 提供商正在加速推进 CloudOE。其中包括 Pivotal 的 Cloud FoundryHeroku 或 Red Hat 的 OpenShift

IBM 已发布了 BlueMix,基于 IBM Open Cloud 架构 和 Cloud Foundry 开源 PaaS 的下一代云平台。IBM BlueMix 将不断发展,提供基于广泛的 IBM 软件组合的服务和运行时。它将支持访问高级服务,让开发人员可以轻松地使用移动设备信息、社交渠道和公开的信息。

对 Cloud Foundry 开源社区的第一种贡献是 IBM WebSphere Liberty Buildpack,参与 BlueMix 项目的客户将可获得它的预览版。

可插拔性和外部系统

除非客户可以将他们的 SoR 连接到 CloudOE 平台并将它们以服务形式供其开发组织使用,否则他们将会发现(公共或私有)CloudOE 毫无用处。一个富有吸引力的 CloudOE 平台应该支持插入新服务并以服务形式利用外部系统。

例如,Cloud Foundry 引入了 用户提供的服务实例,作为向开发人员提供平台(比如现有 SoR)之外的服务的最快方式。借助该功能,客户可以使用公共 CloudOE,此外:

  • 一个内部部署的 SoR(比如一个客户记录数据库)可通过云提供商提供的 VPN 服务建立连接。
  • 为客户记录数据库创建一个用户提供的服务实例。(SoR 所有者在此阶段提供 URL 和用户凭据,以及应用程序处理客户记录数据库所需的其他所有属性)。
  • 在开发应用程序时,开发人员可以使用客户记录数据库的现有客户端库。用于连接到数据库的 URL 和凭据由应用程序环境中的 Cloud Foundry 提供。

SoE 角色和架构

SoE 是一种为扩展而设计的生态系统。不同于 SoR,它不是一个 “受保护的”、完整的实体。SoR 是一个或多个业务流程的直接实现,这些流程具有开端、一组操作、一些可能的明确定义的决策点和一个结尾。SoE 支持在业务角色之间进行协作。协作比业务流程难定义得多。而且协作通常在不断演变,就像任何人类体验一样。SoE 必须是可以演变的;它必须被构建为为了演变和支持多个角色之间的协作而设计的业务平台。

我们将使用 Rashik Parmar(IBM Academy of Technology 的总裁兼 IBM 杰出工程师)用来(在一篇名为 “破坏性业务流程简介” 的未发表的内部文章中)定义业务平台的角色(已加粗):

平台的中心是平台所有者提供商 (provider)。尽管这些可能一回事,但它们的区别在多行业或跨行业业务平台中至关重要。补充者 (complementer) 为平台增加了价值,参与了从用户那里捕获价值的过程。供应商 (supplier) 不同于补充者,因为他们不会直接增强服务或将其提供给用户。他们向平台提供商提供工具、技术和资源,使得提供商能够减轻其职责。考虑到多样性、服务水平或低成本,消费者 (consumer)被说服从业务平台购买服务。支持跨业务平台的新颖用法,所以举例而言,消费者可彼此交易。

图 3 显示了一个业务平台中的角色和它们的相互关联:

图 3. 一个平台生态系统包含的角色
一个业务平台生态系统中相互交互的角色演示:最终用户、平台所有者、平台提供商、补充者和供应商。

以苹果公司的 iPhone/iTunes 平台为例。苹果公司是平台所有者和平台提供商。富士康是 iPhone 的制造商,是苹果公司的供应商,而苹果公司向消费者销售电话。在该平台上,各种补充者(其他公司)直接向消费者销售音乐和应用程序,从而增加了平台的价值。

成功的业务平台具有以下共同特征:

  • 补充者和平台提供商的生态系统可为广泛的消费者解决一个共同问题,从而使得在财务方面应用该平台变得可行。
  • 使补充者能够增强平台的接口是开放且基于标准的,以便在生态系统中建立信任。
  • 平台可轻松扩展,而且它支持非破坏性演变。
  • 补充者和消费者的创新和新颖使用受到鼓励。
  • 补充者可通过该接口增加价值和捕获价值。
  • 在平台核心提供的惟一服务难以替代。
  • 生态系统是稳定的。

在本质上,一个业务平台是业务平台提供商与通过相互支持向消费市场提供服务的补充者生态系统的组合。

架构原则

现在我们可以定义一个 SoE 平台的架构原则:

  • SoE 提供需要卓越的服务质量的富体验,尤其在吞吐量、可伸缩性和可靠性方面。SoE 对应用程序架构师而言是一种特别难以设计的环境,因为它们需要确保满足非功能性需求,同时对底层基础架构具有有限的控制权。(参见 参考资料,查阅讨论如何将非功能性需求集成到复杂、软件密集型系统的架构描述中的图书和文章。)
  • SoE 是一种业务平台。任何可用的功能都必须公开 API 并能够被另一种竞争性实现扩展或覆盖。这些实现和扩展需要发布在一个开放目录中。补充者必须能够访问向该平台的任何级别添加功能所需的全部工具。
  • 云是 SoE 背后的基本技术。此外,SoE 还需要其他基础技术:
    • 一种高度可扩展、高性能的消息服务。
    • 一个针对外部 SoR,构建于消息服务之上的适配器。(SoR 始终是参与结果的激励器,也是关键结构化数据的来源。)这样一个适配器可能需要使用连接器来连接到遗留系统,并连接到对参与有意义和可能触发参与的外部事件目录。
  • 考虑到 SoE 数据的敏感方面,需要可在云上实施的安全性来实现身份证明、授权和隐私保护。
  • 平台中必须存在大数据和分析功能(包括有关平台本身的操作的数据和分析,比如它的关键绩效指标 [KPI])(可能具有多于一种实现)。大数据将来自多个需要可互操作的来源,所以还必须有某种类型的公共元数据和语义引擎。
  • 移动是 SoE 的关键方面。随时随地访问和位置感知可增强参与的价值。
  • SoE 包含大量规则,从决策制定过程中的个人偏好到针对补充者服务的会计规则。需要一个业务规则管理系统,用作运行时引擎和公共规则存储库
  • 因为 SoE 关于人类参与,所以用户访问(门户)和社交工具(无论是公共还是特定于平台)是该解决方案的关键构建块。

其他需求

一些进一步需求适用于支持 SoE 的技术:

  • 以面向服务为核心:作为数字生态系统和业务平台,SoE 将服务作为他们的核心。这些服务是轻量型的,基于具象状态传输 (REST) 架构。没有面向服务的架构作为基础,SoE 甚至无法想象。
  • 基于行业标准:SOE 是多角色的、为增长而构建的平台。它们的发展壮大离不开强有力的公共标准。
  • 利用和扩展开源技术:因为标准只有在经过较长的学习曲线后才可保证真正的互操作性(比如说,SOAP 花多年时间才实现了与 WS-I 配置文件的全面互操作),IT 行业一致认为开源技术可以确保更快、更轻松地实现可互操作的健全的解决方案。
  • Internet 规模的流程完整性:在构建 SoE 的过程中,无法假设数据相似性、有保障的响应,或者使用与可通过 Internet 实现的请求速率不同的速率,除非可以从绘图板上显式执行它们。
  • 与企业功能和后端系统的集成:SoR 已站稳脚跟,因为它们很好地实现了设计目标(记录或执行一个流程)。一个 SoE 可能需要与一个或多个 SoR 相集成,并与这些 SoR 连接到的企业功能相集成。
  • 为不断扩展的生态系统提供平台:SoE 的任务实质上是革命性的。它们的架构由通用子系统的已公开功能组成,而不是仅包含特殊用途组件的相关交互。与高雅和效率相比,它们的设计在丰富性和开放性方面投入了更多的努力。

设计一个 SoE

在设计一个 SoE 解决方案时,与任何类型的解决方案一样,第一项任务是定义目标用户体验的需求。用户希望 SoE 融合对移动访问、位置感知、协作和大数据的利用,通过明智地评估可能的选项来帮助人类角色制定最佳的决策。

能有效支持人类决策的用户体验设计是 SoE 的一个关键方面。这种体验不能是规范性的,不能采用某种固定的流程。它必须支持关联不同的信息,从简单的可视关联到复杂的分析。这种体验受移动设备的小屏幕的约束,而且还必须提供对音频和视频技术的支持,包括语音识别。

对体验设计的进一步讨论不属于本文的介绍范围。我们将继续关注 SoE 的架构方面的更多内容。

前面已经确定,典型的 SoE 与许多 SoR 相连接,这些 SoR 是决策流程和决策本身的激励器。如果考虑 SoR 的典型需求范围(我们假设它是一个旅游支持系统),利用很好地将此转化为一种用例模型,比如图 4 中的示例:

图 4. 一个旅游支持 SoR 的用例模型的示例
一个旅游支持记录系统的用例图

图 4 中的用例模型很好地表明了一个旅游支持 SoR 的总体业务流程:

  1. 识别您自身。
  2. 获得门票或使用免费入场券。
  3. 执行预约服务,并在必要时修改它们。

用例可被分解为某一个粒度,其细程度足以识别目标解决方案的主要功能。而且用例可被分组为聚合(aggregation),代表着未来系统的组件的粗略分类。

现在考虑参与的其他方面:游客如何选择使用何种假期类型,以及如何组织它。图 5 显示了可能影响决策的因素:

图 5. 一个假期决策中的因素示例
该插图显示了可能影响使用何种假期类型的决策的多种标准类型

在这里,用例没有为决策流程提供任何线索。这可能是一个需要数天的漫长时间进行反复试验的过程,也可能是一个只需一秒就能制定的决策,比如 “我必须到达我在一部影片中看到的某个地方去。”

在此情况下,与流程本身相比,其他方面与解决方案的需求的关系更为紧密:

  • 要考虑的信息(数据源和它们的关系)
  • 决策条件,包括个人偏好
  • 影响者(人类和非人类)
  • 上下文,包括时间和地点
  • 参与各方之间的协作

简言之,相关的部分是一些建模框架(包括 TOGAF/ArchiMate)所称的参与背后的动机模型。

明确动机需求后,即可形成参与性的以下方面:

  • 要在影响决策的信息对象之上提供的功能
  • 角色之间的协作
  • 描述解决方案的 SoR 部分的流程实体

图 6 显示了一个 SoE 的 TOGAF/ArchiMate 元模型:

图 6. SoE TOGAF/ArchiMate 元模型
SoE 的企业架构元模型

如图 6 所示:

  • 一个 SoE 的技术基础架构是一个 CloudOE 和一个或多个 SoR。
  • CloudOE 是运行 SoE 工作负载的平台。
  • 服务通常通过接口来物理地实现,应用程序是通过组件实现的。
  • 组件实现一个业务流程或业务活动,可通过它们的接口使用其他组件,或者通过技术接口使用技术功能。技术功能在很大程度上提供了中间件产品(例如一个 NoSQL 数据库)常常提供的功能。

示例:一个 “峡谷旅游” SoE

作为我们概述的方法的一个例子,我们将使用一个平台来支持和推广 Alpine Valley 的旅游。我们将介绍这个示例的方方面面,从利益相关者的动机模型,到识别支持 SoE 所需的 CloudOE 中间件服务。

图 7 显示了利益相关者的动机的 TOGAF/Archimate 模型:

图 7. “峡谷旅游” 动机
利益相关者的动机的架构模型

点击查看大图

图 7. “峡谷旅游” 动机

利益相关者的动机的架构模型

该模型包含主要利益相关者(游客)的观点和该领域的其他利益相关者的目标:服务提供商包括酒店、饭店、运输和活动(供应商);峡谷游客办公室(平台所有者);以及增值应用提供商和外部观点收集者(补充者)。

为了更容易理解,我们将该模型分解为两部分:游客驱动部分和其他利益相关者驱动部分。我们还省略了对 KPI 和度量(包括非功能性需求)的讨论,这些可作为单独一篇文章的主题。

游客在决策过程中受一系列驱动因素影响,这些因素包括他或她的个人兴趣和偏好、天气预报和获得的会员忠诚度奖励。

游客办公室负责推广该峡谷作为旅游目的地。这个办公室提供了广告、刺激计划,还支持能够吸引游客享受峡谷服务的地方活动。游客办公室的主要需求是了解这些行动的结果,收集改善峡谷业务系统所需的信息,比如典型的访问模式(或许按市场类别分类)和自然景点的吸引力。

服务提供商(酒店、饭店等)希望其服务的质量和价格比竞争对手更有利。他们还希望将其产品能够客户需求和偏好相符,这是增值应用程序提供商(以及必须保护其智能资本免受未授权使用的用户)的一种共同需求。

该模型的一部分

为了帮助解释该示例,我们将重点介绍该模型的某一部分,这部分包括选择将组成假期计划的服务。我们不会考虑链接到运输和服务预定的所有主题(这些区域与传统 SoR 链接更紧密),我们将跟踪以下需求的建模:

  • 需要一个包含服务信息(可用性、价格、时间表等)、地方活动、刺激计划通知及其他类型的促销的服务目录。
  • 需要基于多个条件(比如价格、信誉和可信观点)来对比服务,选出最匹配的选项。
  • 需要能够按以下因素选择服务:位置、与另一个感兴趣的位置的邻近性,或者它们可链接到该位置发生的特定的一次性事件的事实。
  • 需要考虑上下文信息,主要是天气。(交通状况可能是另一个例子。)
  • 需要管理参与过程中的用户偏好(游客主数据)。

这些需求如图 8 中的模型中所示:

图 8. “峡谷旅游” 游客的需求
“峡谷旅游” 示例中的游客需求

点击查看大图

图 8. “峡谷旅游” 游客的需求

“峡谷旅游” 示例中的游客需求

这些需求反映在相应的业务功能中:

  • 平台提供商和服务提供商管理业务服务目录,维护酒店、饭店、活动、运输和其他服务的最新信息。在最低限度上,服务信息必须包含服务何时可用、服务时间表、服务的价位。服务提供商提供的信息越好,它与一些客户的偏好相匹配的几率就越高。(例如,表明该酒店 “适合孩子入住” 的广告可能会吸引携带小孩出游的家庭。)
  • 一种多条件搜索和排名功能,使用目录中的信息和第三方信息,比如服务的信誉、社交网络上的观点、刺激性计划,以及客户拥有的奖赏。客户对比服务产品的决定可能是因为考到了外部公告,比如一则广告。
  • 客户能够在在线地图上显示服务和自然兴趣点,以便可以基于位置和距离制定决策,还可以用上下文信息(比如天气和交通状况)进行补充。
  • 能够提供和管理复杂的客户需求和兴趣记录(一个个人主数据管理器),不仅包括过去的购买和旅游历史记录,还包括客户观点和其他个人细节的可靠来源。(这种类型的高度敏感信息只能在客户知晓并准许的情况下进行收集和使用,仅供客户使用。将此信息提供给游客的好处很多,而且匿名化机制可确保其他人无法访问完整的信息。)

图 9 显示了 “峡谷旅游” SoE 满足游客需求的业务模型部分:

图 9. “峡谷旅游” 游客业务模型
“峡谷旅游” 示例的游客业务模型

业务功能必须受 SoE 云环境中的实际服务的支持。此外,这些服务必须由平台提供商或补充者提供的实际应用程序组件来实现。例如,补充者可以在该平台的目录 API 之上开发一个 “查找适合孩子的服务” 应用程序。

服务和应用程序协同工作

现在我们将使用一种可能的用户体验,展示服务和一个应用程序如何协同工作。一个针对 “峡谷旅游” SoE 的 可视化管理器应用程序是 CloudOE 中的一个 Web 应用程序,可由游客从移动应用商店下载。可视化管理器与其他应用程序组件交互,以提供完整的 SoE 体验:

  1. 我决定去度假,而且我想去 Alpine Valley 旅游。
  2. 我在应用商店中找到一个应用程序,它有可能简化整个体验,从酒店预定到运输,到关于在 Valley 中的事项的一些建议。我将安装它。
  3. 但我需要注册:另一个帐户、另一个密码。No!
  4. 但是等等 — “Alpine Valley” 应用程序允许我通过 Facebook 或 Twitter 登录。我拥有一个 Facebook 帐户,所以我将使用该帐户进行登录。
    • 该应用程序使用身份和访问管理器 CloudOE 服务将身份验证工作委托给 Facebook 并获取一个用户令牌。
  5. 我输入了我的 Facebook 凭据,现在我已经 “进入” Valley。
  6. 该应用程序使用地图服务显示 Valley 的风景和相关兴趣点:与照片关联的村庄和山脉,以及简短总结。
  7. 我决定到那里去,所以我键入了出发日期和逗留的时间,让应用程序为我提供一些替代方案。
  8. 该应用程序使用多个服务来组织这次旅行:
    • 它查询天气服务,以获取所逗留的那几天的天气信息。
    • 它查询运输服务,以查找最佳的火车和公共汽车。
    • 它查询酒店服务,以查找最佳的酒店(价格和质量之间的一种很好的折衷)。
    • 它查询峡谷活动服务,以安排我逗留的那几天的日程。
  9. 我获得了 3 份提案。我可按原样挑选一个,也可挑选一个并稍微进行更改。
  10. 哇!最上面的提案有点贵,但其中的一家酒店提供了一位著名厨师的烹饪课程。我妻子非常喜欢烹饪(这是 SoE 分析从她的 Facebook 个人资料信息中发现的),她一定会非常兴奋。我选择了这个选项并输入了我的支付信息。
  11. 该应用程序使用支付服务确定订单,它使用 BPM 服务启动预定工作流。该工作流再次与酒店、运输服务和峡谷活动服务交互,最终确定预定。
  12. 我收到一封确认电子邮件。我可以使用同一个应用程序跟踪我的请求的状态。
  13. 该应用程序使用 MDM 服务保存我的选择。它将在未来的服务活动中使用此信息增强我(和其他人)的体验,比如说,细化最佳的 3 个提案,或者仅向通知我可能感兴趣的活动。

图 10 显示了应用程序组件:

图 10. “峡谷旅游” SoE 应用程序
SoE 可视化管理器应用程序的组件图

一些应用程序组件需要使用技术供应商所提供的中间件服务。

图 11 显示了该示例的初始核心 CloudOE 的模型:

图 11. “峡谷旅游” CloudOE
“峡谷旅游” 示例的初始云操作环境图表
  • 服务目录 (Service Catalog) 包含有关将通过搜索发现的服务、活动和刺激计划的信息。此服务最终基于一个 NoSQL 数据库,该数据库具有 CloudOE 所提供的文本搜索功能。
  • 因为服务搜索、对比和上下文分析功能基于对大量结构化和非结构化数据的分析,所以它们利用了 CloudOE 的分析功能。
  • 用于存储用户偏好的人员 MDM (Person MDM) 组件需要使用 CloudOE 中一项相应的 MDM 功能。它还需要销售跟踪 SoR 和一个位置跟踪服务(使用游客智能电话的 GPS 接口)的接口,以理解旅游动向的一般趋势和具体的个人偏好。
  • 身份管理、访问管理和单一登录 (SSO) 用于对用户执行身份验证,保护对敏感用户数据的访问。这是一个 CloudOE 功能,可使用人员 MDM 作为 ID 存储库。
  • 分析的智能可视化(包括使用 Google Maps 等应用程序的地理可视化)需要使用一个多设备应用服务器来支持移动和 Web 平台上的富用户体验。
  • 需要使用一个业务流程管理器引擎作为业务交易和薪酬管理器,以协调连接的运输预定和支付 SoR。
  • 业务规则管理功能是多条件对比引擎的核心。业务规则的使用提供了灵活性,从而提高了支持富客户体验所需的上下文和参与数据分析的灵活性。
  • 需要一个能够保存涉及 Web 和移动设备的 Internet 级消息的消息服务器,以支持发生在 SoE 内部的和发生在 SoE 与 SoR 之间的消息流。

一些服务将由技术供应商在 CloudOE 中的某些地方提供,可提供高度可扩展的、富有弹性的平台和中间件解决方案,而且这些服务将通过它们的 API 供远程访问。另外,CloudOE 是外部 SoR(公共、Internet 上或位于必须通过 VPN 访问的私有网络中)记录用户关于旅游的决策,并启动合适的业务流程(比如结算)。该应用程序可将服务目录中和人员 MDM 中的信息与 GPS 位置相结合。然后,举例而言,在进餐时它可向用户的智能电话推送一家提供了用户最喜爱的菜品的邻近饭店的菜单。


结束语

使用 SoE,IT 技术向基于数字的企业提供了一些全新的功能。这些功能可自然地融入云基础架构中,但需要使用云概念来实现一种超越我们今天熟悉的 IaaS 服务的 CloudOE 实现水平。

建模 SoE 和 CloudOE 实现需要一个自顶向下的流程,从参与动机开始,到识别支持 SoE 应用程序所需的 PaaS 基础架构。

致谢

感谢 Michael Bradley、Martin Gale、Moti Nisenson 和 Thalia Hooker 提出了本文中包含的许多创意。感谢 Fabio Benedetti(SmartCloud Orchestrator 首席架构师)和 Donald Cronin(IBM 的云和智慧基础架构 CTO)抽出宝贵的时间审阅本文并提供建议。

参考资料

学习

讨论

  • 加入 developerWorks 中文社区。探索由开发人员推动的博客、论坛、组和维基,并与其他 developerWorks 用户进行交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=959977
ArticleTitle=设计一个 SoE 生态系统来支持富用户体验
publish-date=01162014