越来越多的在线消费者需要丰富的体验，这些体验可以利用来自结构化和非结构化来源，社交渠道以及其他消费者的信息。 可以快速提取此信息中包含的价值，以实现一个人的目标并做出明智的选择。 这种体验已经成为消费者领域的常态，也正成为商业应用程序的普遍期望。 参与系统 （SoE）通过从来自多个渠道的信息中提取价值并启用新的数字化业务模型来实现丰富的体验。 云操作环境 （CloudOE）是支持SoE工作负载的平台。 CloudOE通过提供用于开发，部署和操作SoE应用程序的生态系统，实现了SoE所需的敏捷性和速度。
设计SoE生态系统是一项新的任务，而传统的分析方法（例如用例）太局限，无法代表作为SoE模型基础的决策。 本文介绍了一种替代方法，并描述了其对设计过程的影响。 以旅游业为例，说明了相关的设计概念和开发流程。
基于参与的流程和系统
基于参与的流程已经在多个行业中成为主流，并且在其他行业中变得越来越重要。 示例包括：
- 假期计划 ：使用Internet的假期计划是最成熟的基于在线参与的市场。 访问价格比较引擎，咨询TripAdvisor系统等信誉系统，查看上下文数据（例如Google Maps上的图片和天气频道上的天气信息）以及在社交网络上与专家组查找和交换信息是数字广告的常见行为-本地旅行者。
- 财务咨询 ：银行早已从仅提供进行财务操作的柜台转变为通过与客户保持持续稳定的人对人关系成为财务健康咨询师。 这种关系需要顾问和客户之间持续不断的最新知识和信任。
- 新的个人福利计划 ：随着预算的减少和经济压力的增加，一些政府正在将重点从通过补贴避免社会动荡转移到通过个性化计划获得社会成果，这些计划将公民重新纳入生产周期。 这种方法需要跨机构的协作，整合来自公共和私人来源的公民数据，以及关联结构化和非结构化信息，以识别最适合个人情况的计划。
- 欺诈和滥用调查 ：在全球电子市场中，欺诈和滥用已经采用了新的形式并达到了新的复杂性。 要研究它们，需要分析和比较来自不同且通常是不相关的来源的大量结构化和非结构化数据。 该数据的时间和地理位置以及多个组织之间的协作是此方案的关键推动力。
- 基于位置感知的基于上下文的购物 ：基于个人移动设备地理位置的位置感知实现了零售的新场景，通过基于消费者的搜索引擎“上下文”广告扩展了互联网上已经很普遍的体验的导航历史记录。
对SoE的支持为许多行业带来了新的可能性。 用户可以对系统有丰富的体验-过去只有通过人与人的交互才能实现的体验。 实际上，敬业度是以人为中心的。 与记录系统 （SoR）（以记录为中心的过程通过一系列数据注册来跟踪用户的进度）相反，SoE的目的是实现对用户有意义的目标。
国有企业生态系统
本质上，SoE将预测分析应用于移动，社交，云公共服务和传统IT系统（SoR）的数据，以直接在客户，合作伙伴和员工的日常生活中交付应用程序和智能产品。
图1说明了一个SoE生态系统：
图1.一个SoE生态系统
国有企业：
- 实现协作 ：SoE适用于人类，他们认为人类将在彼此之间进行协作。 相比之下，SoR的主要关注点是用户（人类）与系统（机器）之间针对特定过程的交互。 在互动中，人与人之间以及人与机器之间的交互作用是平等的，并且是整体协作的一部分。
- 利用多种来源的丰富数据 ：没有大数据，就不可能有SoE。 分析不同的数据源以提取有意义的可操作信息是人类推理的核心，也是SoE的核心。
- 适应身份和喜好 ：当您担任IT专业人员时，您的行为和喜好与您在学校担任孩子的父母时的行为和喜好不同（尽管两个身份在某些方面会相互影响）。 但是，对于某些SoR，您所有的角色都使用相同的ID，地址，政府ID号等。 对于SoE而言并非如此。 国有企业必须考虑您的工作，您的喜好和您的历史（简而言之，您的背景），才能提供预期的丰富经验。 实际上，SoE必须使用大量的实时数据分析或主数据管理（MDM）系统，在其中维护并不断丰富有关用户的复杂信息。
- 具有时间和位置感知能力 ：丰富的用户体验必须考虑到我们生活在时间中并在太空中移动这一事实。 当您预计下一周的目的地会是热带风暴时，在下周的假期中接收一张阳光明媚的海滩的照片，这对您的订婚并不是很好的服务。 （这是大多数当前的预订SoR所提供的服务水平。）随着您在参与过程中四处走动，移动设备将打开机会进行更丰富的交互。
- 支持多种交互方式 ：移动设备可能会带来最丰富的客户体验，因为它们可以在参与逻辑中包含用户的位置。 但是某些互动不需要位置感知，因此在常规PC上使用时可能会很有效。 其他类型的设备（例如信息亭或ATM）可以在其他类型的参与中发挥作用
- 维护适当的安全性和隐私权 ：由于SoE非常了解您，因此必须确保此信息的安全。 用户必须能够控制谁获得哪些信息。 但是，公开的数据越少，获得的服务就越少-因为根据用户的个人利益定制信息和服务是系统的主要功能。 （在这方面，SoR的要求要低得多，因为它通常可以减少用户类或个人资料的行为差异。）
云操作环境：国有企业背后的技术
与SoR相比，SoE必须设计为处理不稳定的资源需求以及计划外和不可预测的容量需求。 此外，为了使自己在市场中脱颖而出并增加收入，它们必须使客户能够从可用数据中Swift获得更大的洞察力。 由于这些原因，SoE需要一个易于部署，管理和扩展应用程序的平台。 然后，开发人员可以专注于应用程序本身的开发和操作，而不是宿主应用程序所需的基础结构。
基础架构即服务（IaaS）云为开发人员提供了几乎无限大小的数据中心，而无需他们购买任何前期硬件。 但是，开发人员仍然需要配置虚拟机，安装中间件软件，连接系统组件以及维护系统，而所有这些工作都需要花费大量时间来进行实际的创新工作。 即使开发人员在IaaS之上实现DevOps ，他们仍然需要花费时间来构建和管理操作。
云不仅可以提供IaaS，还能做更多的事情。 CloudOE可以负责部署，配置和连接虚拟机，这使开发人员可以专注于应用程序。 CloudOE可以使DevOps过程自动化，从而为开发人员转换为NoOps 。 CloudOE成功的关键在于它使一线开发人员构建应用程序的能力和速度。
服务类别
案例研究表明，CloudOE平台应支持四类服务，所有这些服务对于构建和运行以云为中心（或云原生）的应用程序（如SoE）都是必需的：
- 开发服务
- 申请服务
- 基础设施服务
- 营运服务
CloudOE平台应提供各种此类服务，并应通过内聚且简单的客户端API使其易于使用。 对单一编程语言和单一Web容器的支持不足。 相反，CloudOE应该容纳各种适合目的的Web开发框架（例如Grails，Play框架，Ruby on Rails和Django），语言（例如Java®，Ruby，Python和Node.js）和编程楷模。
在核心应用程序服务中，平台应至少提供：
- 关系数据库服务
- 基于文档（NoSQL）的数据库服务（例如MongoDB）
- 讯息服务
- 存储服务（例如OpenStack对象存储）
图2总结了CloudOE平台应展示以支持SoE工作负载的关键服务：
图2.支持SoE工作负载的关键服务
最重要的是，所有事情都应该围绕着流畅，优雅的开发人员体验而流动，如下所示：
- 创世纪：
- 我从CloudOE门户创建帐户。
- 我下载了用于管理应用程序和服务的命令行工具（作为我喜欢命令行的开发人员）。
- 我以我喜欢的语言下载了CloudOE客户端API。
- 我也可以为我的首选IDE下载CloudOE插件。
- 现在，我可以开始开发下一个SoE应用程序了。 我需要一个用于元数据的关系数据库和一个用于保存要管理的对象Blob（例如照片，图形和文章）的对象存储服务。 然后，我需要要使用的Web开发框架的运行时支持。
- 我查看了文档，发现CloudOE提供了所有这些。
- 我使用命令行或IDE插件来请求数据库服务和对象存储服务。 CloudOE在我的基础架构中自动为我部署这些服务。
- 我编写了应用程序，使用CloudOE客户端API连接了服务。
- 我使用IDE插件或命令行来部署应用程序。 CloudOE会自动为应用程序配置运行时环境，创建与所需服务的连接，并为我提供用于访问应用程序的URL。
- 我测试应用程序。
借助CloudOE，开发人员可以在数小时内完成传统环境中需要几天的工作。 他们不需要部署Web应用程序服务器来承载应用程序，也不需要部署数据库和保留存储。
CloudOE平台的基础架构和运营服务使该平台的价值更加明显。 这些服务主要在应用程序从开发环境移至验证环境，最后移至生产环境时起作用。 CloudOE应该能够配置多个隔离的环境来托管应用程序，并提供简化连续交付和集成任务的工具。
基础架构服务的显着特征是应用程序的横向扩展：在需求增加时添加更多实例，而在需求减少时释放实例。 运营服务使您可以访问应用程序的管理即服务，而无需在内部部署和维护一组管理产品。 理想情况下，操作团队只需在CloudOE门户中单击鼠标即可打开应用程序（及其服务）的常规备份。 开发人员可以拍摄服务数据的快照，以便他们可以在不同的环境中还原数据以分析问题。
可插拔性和外部系统
除非客户可以将他们的SoR连接到CloudOE平台并使它们可以用作其开发组织的服务，否则他们会发现（公共或私有）CloudOE毫无用处。 引人注目的CloudOE平台应该可以插入新服务并利用外部系统即服务。
例如，Cloud Foundry引入了用户提供的服务实例 ，这是向开发人员提供驻留在平台外部的服务（例如现有SoR）的最快方法。 通过该功能，客户可以使用公共CloudOE，并且：
- 可以通过云提供商提供的VPN服务连接本地SoR（例如客户记录数据库）。
- 为客户记录数据库创建了一个用户提供的服务实例。 （SoR所有者在此阶段提供URL和用户凭据，以及应用程序与客户记录数据库一起使用所需的任何其他属性）。
- 开发人员在开发应用程序时可以使用客户记录数据库的现有客户端库。 Cloud Foundry在应用程序环境中提供了用于连接到数据库的URL和凭据。
SOE参与者和架构
SoE是为扩展而设计的生态系统。 与SoR不同，它不是一个“有栅栏的”，完全完成的实体。 SoR是一个或多个业务流程的直接实现，这些业务流程具有起点，一组动作，可能有一些明确定义的决策点以及终点。 SoE支持业务参与者之间的协作。 定义协作要比业务流程困难得多。 协作通常会随着时间的推移而发展，就像任何人类经验一样。 SoE必须准备好发展。 它必须构建为旨在发展并支持多个参与者之间的协作的业务平台。
我们将使用Rashik Parmar（IBM技术学院院长和IBM杰出工程师）使用的术语（在未发表的内部论文“颠覆性业务平台简介”中）定义业务平台的参与者（强调）：
平台的中心是平台所有者和提供者 。 尽管这些可能是相同的，但在多行业或跨行业的业务平台中，区别很重要。 补充者的存在是为了为平台增加价值，并在从消费者那里获得的价值中分得一杯share。 供应商与补充者的不同之处在于它们不直接增强或向消费者提供服务。 相反，它们向平台提供者提供工具，技术和资源，以允许提供者履行其职责。 由于多样性，服务水平或低成本， 消费者被诱使从商业平台购买服务。 还鼓励在整个业务平台上进行新颖的使用，例如，消费者之间可以进行交易。
图3显示了业务平台中的参与者以及它们之间的相互关系：
图3.平台生态系统的参与者
例如，以Apple iPhone / iTunes平台为例。 苹果是平台所有者和平台提供商。 iPhone的制造商FoxConn是Apple的供应商，后者将手机出售给消费者。 在该平台上，各种补充程序（其他公司）直接将音乐和应用出售给消费者，从而提高了平台的价值。
成功的业务平台具有以下特征：
- 补充者和平台提供商的生态系统可以解决广大消费者的共同问题，从而使该平台在财务上可行。
- 使补充程序能够增强平台的接口是开放的且基于标准的，以建立对生态系统的信任。
- 该平台可以轻松扩展，并实现无中断演进。
- 鼓励补充者和消费者进行创新和新颖的使用。
- 补充者可以通过界面增加价值并获取价值。
- 平台核心提供的独特服务难以替代。
- 生态系统稳定。
从本质上讲，业务平台是业务平台提供者和补充者生态系统的组合，这些补充者生态系统在为消费者市场提供服务时相互支持。
建筑原理
现在，我们可以定义SoE平台的架构原理：
- SoE提供了丰富的经验，需要优质的服务-特别是吞吐量，可伸缩性和可靠性。 对于应用程序设计师来说，SoE尤其具有挑战性，因为它们必须确保对非功能性需求的满足，同时对基础架构的控制有限。 （请参阅相关主题的书籍和文章，讨论如何要求非功能性可以集成到复杂，软件密集型系统的架构描述。）
- SoE是一个业务平台。 任何可用的功能都必须公开API，并且能够被其他竞争实现扩展或掩盖。 这些实现和扩展需要在开放目录中发布。 补充者必须能够访问在任何级别向平台添加功能所需的全套工具。
- 云是SoE背后的基本技术。 此外，SoE需要其他基础技术：
- 高度可扩展的高性能消息传递服务。
- 基于消息传递服务构建的外部SoR适配器。 （SoR始终是参与结果的执行者，以及关键结构化数据的来源。）这样的适配器可能需要连接到旧系统以及对参与有意义并且可能触发的外部事件的目录订婚。
- 考虑到SoE数据的敏感方面，标识，授权和隐私需要云可执行的安全性。
- 大数据和分析功能（包括有关平台本身的操作的数据和分析，例如其关键性能指标[KPI]）必须存在于平台中（可能具有多个实现）。 大数据将来自需要互操作的多个来源，因此还必须提供某种公共元数据和语义引擎。
- 移动是SoE的关键方面。 无论何时何地，随时随地访问和位置感知都可以提高参与的价值。
- SoE充满了各种规则，从决策中的个人喜好到补充服务的会计规则。 需要一个业务规则管理系统，作为运行时引擎和公共规则存储库
- 由于SoE与人的参与有关，因此用户访问权限（门户）和社交工具（公共或特定于平台的）是解决方案的关键组成部分。
其他要求
一些其他要求适用于支持SoE的技术：
- 面向服务的核心 ：作为数字生态系统和业务平台，SoE 的核心是服务。 这些服务是轻量级的，并且基于代表性状态传输（REST）架构。 没有面向服务的架构作为基础，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的整个业务流程：
- 证明你的身份。
- 获取门票或使用您的免费通行证。
- 进行保留，必要时进行修改。
可以将用例分解为足够详细的粒度，以标识待解决方案的主要功能。 而且用例可以分组为代表将来系统组件的第一个部分的聚合。
现在考虑订婚的另一个方面：旅行者如何选择休假以及如何安排休假。 图5显示了可能影响该决定的因素：
图5.假期决策中的因素示例
在这里，用例不会为决策过程提供任何线索。 这可能是一个漫长的，反复试验的过程，需要花费数天的时间，也可能是一秒钟的决定，例如“我必须去电影中看到的那个和那个地方”。
在这种情况下，与流程本身相比，其他事物作为解决方案的需求更重要：
- 要考虑的信息（数据源及其关系）
- 决策标准，包括个人喜好
- 影响者（人类和非人类）
- 上下文，包括时间和地点
- 参与方之间的合作
简而言之，与此相关的是某些建模框架（包括TOGAF / ArchiMate ）称呼参与背后的动机模型。
明确动机要求后，可以根据以下方式确定参与的形式：
- 在影响决策的信息对象之上提供业务功能
- 演员之间的合作
- 描述解决方案SoR部分的流程实体
图6显示了SOE的TOGAF / ArchiMate元模型：
图6. SoE TOGAF / ArchiMate元模型
如图6所示：
- SoE的技术基础架构是CloudOE和一个或多个SoR。
- CloudOE是运行SoE工作负载的平台。
- 服务通过接口在物理上实现，应用程序通过组件在物理上实现。
- 组件实现业务流程或业务活动），并且可以通过其接口使用其他组件，也可以通过技术接口使用技术功能。 大多数情况下，技术功能提供了中间件产品（例如，NoSQL数据库）通常提供的功能。
示例：“山谷旅游” SoE
作为我们概述的方法的一个示例，我们将使用一个平台的案例来支持和促进高山山谷的旅游业。 从利益相关者的动机模型到支持SoE所需的CloudOE中间件服务的识别，我们将一直遵循此示例。
图7显示了利益相关者动机的TOGAF / Archimate模型：
图7.“山谷旅游”的动机
该模型包括主要利益相关者（游客）的观点以及该领域其他利益相关者的目标：酒店，饭店，交通和活动的服务提供者（供应商）； 山谷旅游局（平台所有者）； 以及增值应用程序的提供者和外部意见制定者（补充者）。
为了简化说明，我们将模型分为两个部分：游客驱动和其他利益相关者驱动。 我们还忽略了关于KPI和度量（包括非功能性要求）的讨论，而KPI和度量本身可能是整篇单独文章的主题。
该旅游者的决策受到一系列驾驶员的影响，包括他或她的个人兴趣和喜好，天气预报以及获得的会员忠诚度奖励。
旅游局负责推广山谷为度假胜地。 该办公室通过广告，奖励措施和对当地活动的支持来开展活动，这些活动能够吸引客户使用山谷服务。 旅游局的主要要求是了解这些行动的结果，并收集其所需的信息，以改善山谷商业体系，例如典型的游览方式（可能按市场细分）和自然景点的吸引力。
服务提供者（酒店，饭店等）希望他们的服务质量和价格能够与竞争对手相比。 他们还希望将其产品与客户需求和喜好相匹配-增值应用程序提供商（他们必须保护自己的知识资本不受未经授权的使用）的共同要求。
模型的一部分
为了帮助解释该示例，我们将重点介绍模型的“切片”，其中包括构成假期计划的服务的选择。 我们不会考虑与运输和服务预订相关的所有主题（与传统SoR更相关的领域），我们将跟踪以下需求的建模：
- 需要包含服务信息（可用性，价格，时间表等），本地事件，有关奖励的通知以及其他类型的促销的服务目录。
- 需要根据多个标准（例如价格，声誉和可信赖的意见）比较服务，并选择最合适的服务。
- 需要能够根据服务的位置，与另一个感兴趣的位置的接近程度或可以将这些服务与该位置上发生的特定一次性事件相关联的事实来选择服务。
- 需要考虑上下文信息，主要是天气。 （流量可以是另一个示例。）
- 需要管理参与度中的用户偏好（游客主数据）。
这些需求显示在图8的模型中：
图8.“山谷旅游”对游客的要求
需求反映在相应的业务功能中：
- Management of the business services catalog by the platform provider and services providers to maintain up-to-date information on hotels, restaurants, events, transportation, and other services. At the minimum, the service information must include when the service is available, with which schedules, at what price. The better the information that a service provider provides, the higher the probability that it matches some customer preferences. (For example, advertising that the hotel is "child-friendly" is likely to appeal to families traveling with small kids.)
- A multicriteria search and ranking capability that uses the information in the catalog, plus third-party information such as the service's reputation, opinions on social networks, incentive programs, and rewards owned by the customer. The customer's decision to compare the offerings might originate from seeing an external notice such as an advertisement.
- The customer's ability to display services and natural points of interest on an online map so that decisions can be based on location and distance, and complement the picture with context information such as weather and traffic.
- The capability to feed into and manage a complex record of customer needs and interests (a personal master data manager) that includes not only past purchases and travel history, but also trusted sources of opinions and other personal details. (This type of highly sensitive information can be collected and used only with the customer's knowledge and approval, and is to be consumed only by the customer. The benefit that this information gives to the tourist is substantial, and anonymization mechanisms can ensure that the full information cannot be accessed by others.)
Figure 9 shows the portion of the Tourism in the Valley SoE's business model for meeting tourist requirements:
Figure 9. "Tourism in the Valley" tourist business model
The business capabilities must be supported by actual services in the SoE cloud environment. In turn, these services must be implemented by actual application components that are provided either by the platform provider or by a complementer. For instance, a complementer might develop a "Find child-friendly offerings" app on top of the platform's catalog APIs.
Services and applications working together
Now we'll use one possible user experience to show how the services and an application work together. A visualization manager application for the Tourism in the Valley SoE is a web application in the CloudOE and can be downloaded by the tourist from a mobile-app store. The visualization manager interacts with other application components to provide the complete SoE experience:
- I decide to take a vacation, and I think I want to visit the Alpine Valley.
- I find an app in the app store that promises to simply the whole experience, from hotel reservation to transportation, to recommendations about things to do in the Valley. 我将安装它。
- But I have to register: yet another account, another password. 没有！
- But wait — the "Alpine Valley" app lets me log in via Facebook or Twitter. I have a Facebook account, so I'll do that.
- The app uses the identity & access manager CloudOE service to delegate authentication to Facebook and get a user token.
- I insert my Facebook credentials and now I'm "in" the Valley.
- The app uses the map service to show a view of the Valley with the relevant points of interest: villages and mountains trails correlated with photos and brief summaries.
- I decide that I want to go there, so I type the start date and the duration of my stay and let the app decide on some alternatives for me.
- The app uses several services to organize the journey:
- It queries the weather service to get weather information for the stay.
- It queries the transportation service to find out best trains and buses.
- It queries the hotels service to find out the best hotels (a good compromise between price and quality).
- It queries the valley events service to organize my agenda during the stay.
- I get three proposals. I can pick one as-is, or I can pick one and slightly change it.
- 哇！ The top proposal is a bit more expensive but includes a hotel that offers cooking classes with a famous chef. My wife, who is a fanatic for good cooking (which the SoE analytics discovered from her Facebook profile), will be thrilled. I select this option and enter my payment information.
- The app uses the payment service to finalize the order, and it uses the BPM service to initiate the reservation workflow. That workflow interacts again with the hotels, transportation, and valley events services to finalize the reservation.
- I receive a confirmation email. I can track the status of my request using the same app.
- The app uses the MDM service to save my choices. It will use this information in future engagements to enhance my (and others') experience — for example, for refining the top three proposals or for notifying me only of events I might be interested in.
Figure 10 shows the application components:
Figure 10. "Tourism in the Valley" SoE application
Some of the application components require middleware services that technology suppliers provide.
Figure 11 shows the model of the initial core CloudOE for the example:
Figure 11. "Tourism in the Valley" CloudOE
- The Service Catalog contains information about services, events, and incentives that will be discovered by searches. This service will ultimately be based on a NoSQL database with text-search capabilities that's offered by the CloudOE.
- Because the service search, comparison, and context-analysis functions are based on the analysis of large volumes of structured and unstructured data, they leverage the CloudOE's analytics capability.
- The Person MDM component for storing user preferences needs a corresponding MDM function in the CloudOE. It also needs interfaces to sales-tracking SoRs and to a location-tracking service that uses the GPS interface of the tourist's smartphone — to understand both general trends in touristic movement and specific per-person preferences.
- Identity management, access management, and single sign-on (SSO) are used to authenticate the user and protect access to sensitive user data. This is a CloudOE function that can use the Person MDM as an ID repository.
- Smart visualization of analytics — including geographic visualization using an application such as Google Maps — needs a multidevice application server to support the user rich experience on mobile and web platforms.
- A business process manager engine is needed to act as a business transaction and compensation manager to coordinate the transportation-booking and payments SoRs that are interfaced.
- A business rules management capability is at the heart of the multicriteria comparison engine. The use of business rules provides flexibility, which in turn drives the flexibility in the analysis of the context and engagement data that's needed to support a rich customer experience.
- A messaging server capable of sustaining Internet-grade messaging that includes web and mobile devices is needed to support the message flow that's internal to the SoE and that occurs between the SoE and SoRs.
Some of these services will be offered somewhere in the CloudOE by technology suppliers that can provide highly scalable, highly resilient platforms and middleware solutions, and the services will be accessed remotely through their APIs. Also, the CloudOE is the interface to external SoRs (public, on the Internet, or residing in private networks that must be accessed through VPN facilities). These SoRs (such as the transportation engine component) record user decisions about the travel and start the appropriate business processes (such as billing). The application can combine the information in the service catalog and in the Person MDM with the GPS location. Then, for example, at mealtime it can push to the user's smartphone the menu of a nearby restaurant that serves the user's favorite dishes.
结论
With SoEs, IT technology is opening an entirely new class of capabilities to digital-based businesses. These capabilities find a natural match in cloud infrastructure but require cloud concepts to achieve a CloudOE implementation level that exceeds the IaaS services that we're accustomed to today.
Modeling SoE and CloudOE implementations requires a top-down process that starts from the engagement motivations and arrives at identifying the PaaS infrastructure that's needed to support the SoE application.
致谢
Thanks to Michael Bradley, Martin Gale, Moti Nisenson, and Thalia Hooker for many of the ideas included in this article. Thanks to Fabio Benedetti, SmartCloud Orchestrator Lead Architect, and Donald Cronin, Cloud and Smarter Infrastructure CTO at IBM, for the precious time they spent in the review and the suggestions they provided.
翻译自: https://www.ibm.com/developerworks/cloud/library/cl-cloudecosystem/index.html
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
