越来越多的在线消费者需要丰富的体验，这些体验可以利用来自结构化和非结构化来源，社交渠道以及其他消费者的信息。 可以快速提取此信息中包含的价值，以实现一个人的目标并做出明智的选择。 这种体验已经成为消费者领域的常态，也正成为商业应用程序的普遍期望。 参与系统 （SoE）通过从来自多个渠道的信息中提取价值并启用新的数字化业务模型来实现丰富的体验。 云操作环境 （CloudOE）是支持SoE工作负载的平台。 CloudOE通过提供用于开发，部署和操作SoE应用程序的生态系统，实现了SoE所需的敏捷性和速度。

设计SoE生态系统是一项新的任务，而传统的分析方法（例如用例）太局限，无法代表作为SoE模型基础的决策。 本文介绍了一种替代方法，并描述了其对设计过程的影响。 以旅游业为例，说明了相关的设计概念和开发流程。

基于参与的流程已经在多个行业中成为主流，并且在其他行业中变得越来越重要。 示例包括：

对SoE的支持为许多行业带来了新的可能性。 用户可以对系统有丰富的体验-过去只有通过人与人的交互才能实现的体验。 实际上，敬业度是以人为中心的。 与记录系统 （SoR）（以记录为中心的过程通过一系列数据注册来跟踪用户的进度）相反，SoE的目的是实现对用户有意义的目标。

本质上，SoE将预测分析应用于移动，社交，云公共服务和传统IT系统（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）和编程楷模。

在核心应用程序服务中，平台应至少提供：

图2总结了CloudOE平台应展示以支持SoE工作负载的关键服务：

最重要的是，所有事情都应该围绕着流畅，优雅的开发人员体验而流动，如下所示：

1. 创世纪：
2. 现在，我可以开始开发下一个SoE应用程序了。 我需要一个用于元数据的关系数据库和一个用于保存要管理的对象Blob（例如照片，图形和文章）的对象存储服务。 然后，我需要要使用的Web开发框架的运行时支持。

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

CloudOE平台的基础架构和运营服务使该平台的价值更加明显。 这些服务主要在应用程序从开发环境移至验证环境，最后移至生产环境时起作用。 CloudOE应该能够配置多个隔离的环境来托管应用程序，并提供简化连续交付和集成任务的工具。

基础架构服务的显着特征是应用程序的横向扩展：在需求增加时添加更多实例，而在需求减少时释放实例。 运营服务使您可以访问应用程序的管理即服务，而无需在内部部署和维护一组管理产品。 理想情况下，操作团队只需在CloudOE门户中单击鼠标即可打开应用程序（及其服务）的常规备份。 开发人员可以拍摄服务数据的快照，以便他们可以在不同的环境中还原数据以分析问题。

除非客户可以将他们的SoR连接到CloudOE平台并使它们可以用作其开发组织的服务，否则他们会发现（公共或私有）CloudOE毫无用处。 引人注目的CloudOE平台应该可以插入新服务并利用外部系统即服务。

例如，Cloud Foundry引入了用户提供的服务实例 ，这是向开发人员提供驻留在平台外部的服务（例如现有SoR）的最快方法。 通过该功能，客户可以使用公共CloudOE，并且：

SoE是为扩展而设计的生态系统。 与SoR不同，它不是一个“有栅栏的”，完全完成的实体。 SoR是一个或多个业务流程的直接实现，这些业务流程具有起点，一组动作，可能有一些明确定义的决策点以及终​​点。 SoE支持业务参与者之间的协作。 定义协作要比业务流程困难得多。 协作通常会随着时间的推移而发展，就像任何人类经验一样。 SoE必须准备好发展。 它必须构建为旨在发展并支持多个参与者之间的协作的业务平台。

我们将使用Rashik Parmar（IBM技术学院院长和IBM杰出工程师）使用的术语（在未发表的内部论文“颠覆性业务平台简介”中）定义业务平台的参与者（强调）：

平台的中心是平台所有者和提供者 。 尽管这些可能是相同的，但在多行业或跨行业的业务平台中，区别很重要。 补充者的存在是为了为平台增加价值，并在从消费者那里获得的价值中分得一杯share。 供应商与补充者的不同之处在于它们不直接增强或向消费者提供服务。 相反，它们向平台提供者提供工具，技术和资源，以允许提供者履行其职责。 由于多样性，服务水平或低成本， 消费者被诱使从商业平台购买服务。 还鼓励在整个业务平台上进行新颖的使用，例如，消费者之间可以进行交易。

图3显示了业务平台中的参与者以及它们之间的相互关系：

例如，以Apple iPhone / iTunes平台为例。 苹果是平台所有者和平台提供商。 iPhone的制造商FoxConn是Apple的供应商，后者将手机出售给消费者。 在该平台上，各种补充程序（其他公司）直接将音乐和应用出售给消费者，从而提高了平台的价值。

成功的业务平台具有以下特征：

从本质上讲，业务平台是业务平台提供者和补充者生态系统的组合，这些补充者生态系统在为消费者市场提供服务时相互支持。

现在，我们可以定义SoE平台的架构原理：

一些其他要求适用于支持SoE的技术：

与任何类型的解决方案一样，在设计SoE解决方案时，首要任务是定义潜在用户体验的要求。 用户期望SoE能够利用移动访问，位置感知，协作和大数据开发的融合来帮助人类参与者通过对可能的选择进行明智的评估来做出最佳决策。

有效支持人类决策的用户体验设计是SoE的关键方面。 这种经验不能是规定性的，也不能使用固定的流程或过程。 它必须启用各种信息的关联，从简单的视觉关联到复杂的分析。 这种体验受到移动设备小屏幕的限制，并且必须包括对音频和视频技术（包括语音识别）的支持。

对体验设计的进一步讨论超出了本文的范围。 我们将继续专注于SoE的更多体系结构方面。

正如我们已经建立的那样，典型的SoE与许多SoR交互，这些SoR是决策过程和决策本身的促成因素。 如果您考虑SoR的典型需求空间（假设它是旅行支持系统），则可以很好地转换成用例模型，例如图4中的示例：

图4中的用例模型很好地说明了差旅支持SoR的整个业务流程：

1. 证明你的身份。
2. 获取门票或使用您的免费通行证。
3. 进行保留，必要时进行修改。

可以将用例分解为足够详细的粒度，以标识待解决方案的主要功能。 而且用例可以分组为代表将来系统组件的第一个部分的聚合。

现在考虑订婚的另一个方面：旅行者如何选择休假以及如何安排休假。 图5显示了可能影响该决定的因素：

在这里，用例不会为决策过程提供任何线索。 这可能是一个漫长的，反复试验的过程，需要花费数天的时间，也可能是一秒钟的决定，例如“我必须去电影中看到的那个和那个地方”。

在这种情况下，与流程本身相比，其他事物作为解决方案的需求更重要：

简而言之，与此相关的是某些建模框架（包括TOGAF / ArchiMate ）称呼参与背后的动机模型。

明确动机要求后，可以根据以下方式确定参与的形式：

作为我们概述的方法的一个示例，我们将使用一个平台的案例来支持和促进高山山谷的旅游业。 从利益相关者的动机模型到支持SoE所需的CloudOE中间件服务的识别，我们将一直遵循此示例。

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

该模型包括主要利益相关者（游客）的观点以及该领域其他利益相关者的目标：酒店，饭店，交通和活动的服务提供者（供应商）； 山谷旅游局（平台所有者）； 以及增值应用程序的提供者和外部意见制定者（补充者）。

为了简化说明，我们将模型分为两个部分：游客驱动和其他利益相关者驱动。 我们还忽略了关于KPI和度量（包括非功能性要求）的讨论，而KPI和度量本身可能是整篇单独文章的主题。

该旅游者的决策受到一系列驾驶员的影响，包括他或她的个人兴趣和喜好，天气预报以及获得的会员忠诚度奖励。

旅游局负责推广山谷为度假胜地。 该办公室通过广告，奖励措施和对当地活动的支持来开展活动，这些活动能够吸引客户使用山谷服务。 旅游局的主要要求是了解这些行动的结果，并收集其所需的信息，以改善山谷商业体系，例如典型的游览方式（可能按市场细分）和自然景点的吸引力。

服务提供者（酒店，饭店等）希望他们的服务质量和价格能够与竞争对手相比。 他们还希望将其产品与客户需求和喜好相匹配-增值应用程序提供商（他们必须保护自己的知识资本不受未经授权的使用）的共同要求。

为了帮助解释该示例，我们将重点介绍模型的“切片”，其中包括构成假期计划的服务的选择。 我们不会考虑与运输和服务预订相关的所有主题（与传统SoR更相关的领域），我们将跟踪以下需求的建模：

这些需求显示在图8的模型中：

需求反映在相应的业务功能中：

Figure 9 shows the portion of the Tourism in the Valley SoE's business model for meeting tourist requirements:

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.

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:

1. I decide to take a vacation, and I think I want to visit the Alpine Valley.
2. 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. 我将安装它。
3. But I have to register: yet another account, another password. 没有！
4. But wait — the "Alpine Valley" app lets me log in via Facebook or Twitter. I have a Facebook account, so I'll do that.
5. I insert my Facebook credentials and now I'm "in" the Valley.
6. 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.
7. 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.
8. The app uses several services to organize the journey:
9. I get three proposals. I can pick one as-is, or I can pick one and slightly change it.
10. 哇！ 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.
11. 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.
12. I receive a confirmation email. I can track the status of my request using the same app.
13. 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:

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:

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.

    以上就是本篇文章【fdu soe_设计SoE生态系统以支持丰富的用户体验】的全部内容了，欢迎阅览 ！ 文章地址：http://ww.kub2b.com/news/16498.html
     栏目首页      相关文章      动态      同类文章      热门文章      网站地图      返回首页 企库往资讯移动站 http://ww.kub2b.com/mobile/ , 查看更多