Design an SoE ecosystem to support rich user experiences

Systems of engagement: The new age of the cloud


More and more, online consumers require a rich experience that leverages information from disparate structured and unstructured sources, social channels, and fellow consumers. The value that's contained in this information can be quickly extracted to fulfill a person's objectives and enable informed choices. Already the norm in the consumer space, this type of experience is becoming the general expectation for business applications too. A system of engagement (SoE) enables this rich experience by extracting value from the information that comes from multiple channels and enabling new digitized business models. A cloud operating environment (CloudOE) is the platform that supports SoE workloads. The CloudOE enables the agility and velocity that an SoE needs by providing an ecosystem for developing, deploying, and operating SoE applications.

Designing an SoE ecosystem is a new sort of undertaking, and traditional analysis methods such as use cases are too limited to represent the decisions that are the basis of an SoE model. This article presents an alternative approach and describes its impact on the design process. Using an example in the field of tourism, it explains the relevant design concepts and the development flow.

Engagement-based processes and systems

Engagement-based processes are already mainstream for several industries and becoming increasingly important in others. Examples include:

  • Vacation planning: Vacation planning that uses the Internet is the most mature online engagement-based market. Accessing price-comparison engines, consulting reputation systems such as TripAdvisor, viewing contextual data (such as pictures on Google Maps and weather information on the Weather Channel), and finding and exchanging information with expert groups on social networks is common behavior for the digital-native traveler.
  • Financial counseling: Banks have long since moved from merely offering a counter where financial operations are performed, to being a financial-health counselor through a continuous, stable, person-to-person relationship with clients. Such a relationship requires continuous, up-to-date knowledge and trust between counselor and client.
  • New individual welfare plans: With reduced budgets and under increased economic pressure, some governments are shifting focus from avoiding social unrest through subsidies to obtaining social results through personalized programs that re-include the citizen in the production cycle. This approach requires collaboration across agencies, integration of citizens' data from public and private sources, and correlation of structured and unstructured information to identify the plan that's most likely to succeed for the individual situation.
  • Fraud and abuse investigation: In a global electronic market, fraud and abuse have taken new forms and reached new complexities. Investigating them requires the analysis and comparison of huge amounts of structured and unstructured data from different and often apparently unrelated sources. Time- and geolocation of that data, as well as collaboration among multiple organizations, are key enablers for this scenario.
  • Context-based shopping based on location awareness: Location awareness that's based on the geolocation of personal mobile devices enables a new scenario for retail, extending an experience that is already common on the Internet with search-engine "contextual" advertisements that are based on consumers' navigation history.

Support for SoEs opens new possibilities to many industries. Users can have a rich experience with the system — the type of experience that in the past was possible only through human-to-human interaction. Engagements are, in fact, human-centric by nature. As opposed to a system of records (SoR) — whose record-centric processes track users' progress through a sequence of data registrations — an SoE's aim is to achieve objectives that are meaningful to the user.

The SOE ecosystem

In essence, SoEs apply predictive analytics to mobile, social, cloud public services', and traditional IT systems' (SoRs') data to deliver applications and smart products directly in the context of the daily lives of customers, partners, and employees.

Figure 1 illustrates an SoE ecosystem:

Figure 1. An SoE ecosystem
Illustration of an SoE ecosystem. The SoE uses data that comes from mobile     devices and sensors, social channels, public services, and systems of records. It     performs predictive analytics on the data and delivers recommendations to the user.
Illustration of an SoE ecosystem. The SoE uses data that comes from mobile devices and sensors, social channels, public services, and systems of records. It performs predictive analytics on the data and delivers recommendations to the user.

An SoE:

  • Enables collaboration: SoEs are for humans, and they assume that humans will collaborate among themselves. By contrast, SoRs' main concern is the interaction between the user (human) and the system (machine) with respect to a specific process. In an engagement, human-to-human and human-to-machine interactions are on an equal footing and are part of an overall collaboration.
  • Exploits rich data from multiple sources: SoEs are impossible without big data. Analysis of disparate data sources to extract meaningful and actionable information is at the core of human reasoning and at the core of SoEs as well.
  • Adapts to identities and preferences: When you act as an IT professional you have different behaviors and preferences from when you act as the parent of your child at school (albeit the two identities influence each other in some ways). Nevertheless, for some SoRs all of your roles use the same ID, address, government ID number, and so on. This is not the case for an SoE. SOEs must take into account your job, your preferences, and your history (in short, your context) to provide the expected rich experience. In practical terms, SoEs must use either a lot of on-the-fly data analytics or a master data management (MDM) system in which complex information about users is maintained and constantly enriched.
  • Is time- and location-aware: A rich user experience must take account of the fact that we live in time and move around in space. Receiving a picture of a sunny beach for your next week's vacation when a tropical storm is expected at your destination that very week is not a good service for your engagement. (It is the level of service that most current reservation SoRs give.) Mobile devices open opportunities for even richer interactions as you move around during an engagement.
  • Supports multiple ways to interact: Mobile devices are likely to give the richest customer experience, because they can include the user's location in the engagement logic. But certain engagements don't require location awareness and so can be effective when used from a regular PC. Other type of devices, such as kiosks or even ATMs, can play a role in other types of engagements
  • Maintains appropriate security and privacy: Because an SoE knows so much about you, it must keep this information secure. The user must be able to control who gets what information. But the less data that's exposed, the less service that's received — because the customization of information and services to users' personal interests is the main function of the system. (In this respect an SoR is much less demanding, because it can usually reduce differences in behavior to user classes or profiles.)

Cloud operating environment: The technology behind SoEs

In contrast to SoRs, SoEs must be designed to deal with erratic resource requirements and unplanned and unpredictable capacity needs. Moreover — to differentiate themselves in the market and increase revenue — they must enable clients to gain greater insight quickly from the available data. For these reasons, SoEs need a platform that makes it easy to deploy, manage, and scale applications. Developers can then focus on the development and operations of the application itself and not on the infrastructure needed to host the application.

Infrastructure as-a Service (IaaS) clouds give developers data centers of virtually unlimited size without requiring them to make any up-front hardware purchases. However, the developers still need to configure the virtual machines, install middleware software, connect system components, and maintain systems — all of which takes time away from the real job of innovation. Even when developers implement DevOps on top of IaaS, they still need to spend time building and managing operations.

The cloud is capable of doing more than providing IaaS. A CloudOE can take care of deploying, configuring, and connecting the virtual machines, which enables the developers to concentrate on the application. A CloudOE can automate DevOps procedures, which translates to NoOps for the developers. The key to the success of a CloudOE is how well and how fast it enables front-line developers to build their applications.

Service categories

Case studies have shown that a CloudOE platform should support four categories of services, all of which are needed for building and operating cloud-centric (or cloud-native) applications such as SoEs:

  • Development services
  • Application services
  • Infrastructure services
  • Operational services

A CloudOE platform should provide a variety of these services and should make them easily usable through a cohesive and simple client API. Support for a single programming language and a single web container are insufficient. Instead, The CloudOE should accommodate various fit-for-purpose web development frameworks (such as Grails, Play Framework, Ruby on Rails, and Django), languages (such as Java®, Ruby, Python, and Node.js), and programming models.

Among core application services, the platform should provide, at minimum:

  • Relational database services
  • Document-based (NoSQL) database services (such as MongoDB)
  • Messaging services
  • Storage services (such as OpenStack Object Storage)

Figure 2 summarizes the key services that a CloudOE platform should exhibit to support SoE workloads:

Figure 2. Key services to support SoE workloads
Illustration of key services (development, applicatoin, infrastrucure and     operational) that suport SOE applications and workloads
Illustration of key services (development, applicatoin, infrastrucure and operational) that suport SOE applications and workloads

Most important, everything should flow around a smooth, elegant developer experience that might look like this:

  1. Genesis:
    • I create my account from the CloudOE portal.
    • I download the command-line tool (as a developer I love the command line) for managing applications and services.
    • I download the CloudOE client API in the language I prefer.
    • I can also download the CloudOE plugin for my preferred IDE.
  2. Now I can start developing my next SoE application. I need a relational database for metadata and an object storage service for saving the object blobs that I want to manage (such as photographs, graphics, and articles). Then I need the runtime support for the web development framework that I want to use.
    • I look at the documentation and I discover that the CloudOE provides all of these.
    • I user either the command line or the IDE plugin to request a database service and an object storage service. The CloudOE automatically deploys these services for me in its infrastructure.
    • I write my application, interfacing the services by using the CloudOE client API.
    • I deploy the application by using either the IDE plugin or the command line. The CloudOE automatically provisions the runtime environment for the application, creates the connections with the services it needs, and gives me a URL for accessing the application.
    • I test the application.

With a CloudOE, developers can accomplish in hours what would require days in a traditional environment. They don't need to deploy the web application server to host the application, and they don't need to deploy the database and reserve the storage.

A CloudOE platform's infrastructure and operational services make the platform's value all the more evident. These services come into play mainly when applications move from the development environment to the verification environment and finally to the production environment. The CloudOE should provide the ability to configure multiple segregated environments for hosting the applications, and tools that simplify the task of continuous delivery and integration.

The salient feature of infrastructure services is the horizontal scaling of applications: adding more instances when the demand increases and releasing instances when the demand decreases. Operational services give access to application's management as a service, without the need to deploy and maintain a set of management products on premises. Ideally, an operations team can turn on regular backups of an application (and its services) with few mouse clicks in the CloudOE portal. The developers can take snapshots of the services data so that they can restore it in a different environment to analyze a problem.

Pluggability and external systems

Unless customers can connect their SoRs to the CloudOE platform and make them usable as a service to their development organizations, they'll find the (public or private) CloudOE to be useless. A compelling CloudOE platform should make it possible to plug in new services and to leverage external systems as a service.

For example, Cloud Foundry introduced user-provided service instances as the quickest way to provide developers with services that reside outside the platform, such as an existing SoR. With that function a customer can use a public CloudOE, and:

  • An on-premises SoR — a customer-records database, for example — can be connected through a VPN service that's offered by the cloud provider.
  • A user-provided service instance is created for the customers-records database. (The SoR owner supplies the URL and user credentials in this phase, as well as any other attributes that the applications need to work with the customer-records database).
  • Developers can use the existing client libraries of the customer-records database when developing applications. The URL and credentials for connecting to the database are provided by Cloud Foundry in the application's environment

SoE actors and architecture

An SoE is an ecosystem that is designed for extension. Unlike an SoR, It is not a "fenced," fully finished entity. An SoR is the direct implementation of one or more business processes that have a start, a set of actions, possibly some well-defined decision points, and an end. An SoE supports collaborations among business actors. Collaborations are much more difficult to define than business processes. And collaborations typically evolve over time, like any human experience. An SoE must be ready to evolve; it must be built as a business platform that's designed for evolution and for the support of collaboration among multiple actors.

We'll use the terminology that Rashik Parmar (President of the IBM Academy of Technology and an IBM Distinguished Engineer) uses (in an unpublished internal paper entitled "Introduction to Disruptive Businesses Platforms") to define a business platform's actors (emphasis added):

At the centre of the platform are the platform owner and provider. Although these may be one and the same, the distinction is important in multiindustry or cross industry business platforms. The complementers exist to add value to the platform and take a share in the value capture from the consumers. The suppliers are distinct from complementers in that they do not directly enhance or provide services to the consumers. Rather they provide tools, technologies and resources to the platform provider, to allow the provider to discharge their responsibilities. The consumers are enticed to purchase the services from the business platform due to either the diversity, the levels of service or the low cost. Novel use is also encouraged across the business platform, so for example, consumers may transact between each other.

Figure 3 shows the actors in a business platform and how they interrelate:

Figure 3. Actors of a platform ecosystem
Illustration of the actors that interact in a business platform ecosystem: end     users, platform owner, platform provider, complementers, and suppliers.
Illustration of the actors that interact in a business platform ecosystem: end users, platform owner, platform provider, complementers, and suppliers.

As an example, take the Apple iPhone/iTunes platform. Apple is the platform owner and the platform provider. FoxConn, manufacturer of the iPhone, is a supplier to Apple, which sells the phones to consumers. On the platform, various complementers (other companies) sell music and apps directly to consumers, thereby enhancing the platform's value.

Successful business platforms share these characteristics:

  • The ecosystem of complementers and platform provider can solve a common problem for a broad spectrum of consumers and so make the platform financially viable.
  • Interfaces that enable complementers to enhance the platform are open and standards-based to create trust in the ecosystem.
  • The platform can be easily expanded, and it enables nondisruptive evolution.
  • Innovation and novel use by both complementers and consumers is encouraged.
  • Complementers can add value and capture value through the interface.
  • The unique service provided at the core of the platform is difficult to replace.
  • The ecosystem is stable.

In essence, a business platform is a combination of a business platform provider and an ecosystem of complementers that support one another in providing services to a marketplace of consumers.

Architectural principles

Now we can define the architectural principles of an SoE platform:

  • An SoE provides a rich experience that requires services of superior quality — especially throughput, scalability, and reliability. SoEs are especially challenging environments for application architects to design, because they must ensure the satisfaction of nonfunctional requirements while having limited control over the underlying infrastructure. (See Related topics for books and articles that discuss how nonfunctional requirements can be integrated into the architectural description of complex, software-intensive systems.)
  • An SoE is a business platform. Any available function must expose APIs and be capable of being extended or of being shadowed by another competing implementation. Those implementations and extensions need to be published in an open catalog. Complementers must be able to access the full set of tools needed to add capabilities to the platform at any level.
  • Cloud is the basic technology behind an SoE. In addition, an SoE needs other underlying technologies:
    • A highly scalable, high-performance messaging service.
    • An adapter for external SoRs that's built on the messaging service. (SoRs will always be the actuators of the results of the engagement, as well as sources of critical structured data.) Such an adapter might need connectors to legacy systems and to the catalog of external events that are meaningful to the engagement and that might trigger the engagement.
  • Given the sensitive aspect of SoE data, cloud-enforceable security is needed for identification, authorization, and privacy.
  • Big-data and analytics capabilities (including data and analytics about the operations of the platform itself, such as its key performance indicators [KPIs]) must be present in the platform (maybe with more than one implementation). Big data will come from multiple sources that need to be made interoperable, so some sort of public metadata and semantic engine must also be present.
  • Mobile is a key aspect of an SoE. Everywhere, any-time access and location awareness can enhance the value of an engagement.
  • An SoE is full of rules that range from personal preferences in decision making to accounting rules for a complementer's service. A business rules management system is needed, both as a runtime engine and as a public rules repository
  • Because SoEs are about human engagement, user access (the portal) and the social tools (public or platform-specific) are key building blocks of the solution.

Additional requirements

Some further requirements apply to the technology that supports an SoE:

  • Service orientation at the core: As digital ecosystems and business platforms, SoEs have services at their heart. Those services are lightweight and based on Representational State Transfer (REST) architecture. SoEs would not even be conceivable without a service-oriented architecture as their base.
  • Based on industry standards: SOEs are multiactor, built-for-growth platforms. They cannot thrive without strong common standards.
  • Leveraging and extending open source technologies: Because standards ensure real interoperability only after a long learning curve — SOAP, for example took several years to reach full interoperability with WS-I profiles — the consensus in the IT industry is that open source technologies can ensure a faster and easier path to robust and interoperable solutions.
  • Process integrity at Internet scale: In building an SoE you cannot assume data proximity, guaranteed response, or request rates different from those that you can achieve over the Internet — unless you can explicitly enforce them right from the drawing board.
  • Integration with enterprise capabilities and back-end systems: SoRs are here to stay, because they do well what they are designed to do (record or enforce a process). An SoE will probably need to integrate with one or more (probably more) SoRs as well as with the enterprise capabilities with which the SoRs interface.
  • Providing the platform for a growing ecosystems: It's in the nature of their mission for SoEs to be evolutionary. Their architecture consists of the exposed capabilities of general-purpose subsystems more than of connected interactions among special-purpose components. Their design strives for richness and openness more than elegance and efficiency.

Designing an SoE

In designing an SoE solution, as with any type of solution, the first task is to define the requirements of the would-be user experience. Users expect SoEs to leverage the convergence of mobile access, location awareness, collaboration, and big data exploitation to assist the human actor in making the best possible decision by an informed evaluation of the possible options.

The design of a user experience that effectively supports human decisions is a crucial aspect of an SoE. This experience cannot be prescriptive and cannot use a fixed flow or process. It must enable the correlation of disparate information, ranging from simple visual correlation to complex analytics. The experience is constrained by mobile devices' small screens, and it must include support for audio and video technologies, including voice recognition.

Further discussion of experience design is beyond this article's scope. We'll continue to focus on the more architectural aspects of an SoE.

As we've established, a typical SoE interfaces with a number of SoRs that are the actuators of the decision process and of the decision itself. If you consider the typical requirement space of an SoR (let's assume it is a travel-support system), this translates well into a use case model such as the example in Figure 4:

Figure 4. An example of use case model for a travel-support SoR
Use cases diagram for a travel-support system of records
Use cases diagram for a travel-support system of records

The use case model in Figure 4 gives a good indication of the overall business process for a travel-support SoR:

  1. Identify yourself.
  2. Get tickets or use your free pass.
  3. Make reservations and if necessary modify them.

The use cases can be decomposed to a granularity that's detailed enough to identify the main functions of the solution-to-be. And the use cases can be grouped into aggregations that represent a first cut of the future system's components.

Now consider the other aspect of the engagement: how the traveler chooses which vacation to take and how to organize it. Figure 5 shows the factors that can influence that decision:

Figure 5. An example of factors in an holiday decision
Illustration showing the types of multiple criteria that can influence a the     decision of which vacation to take
Illustration showing the types of multiple criteria that can influence a the decision of which vacation to take

Here, use cases give no clue to the decision-making process. It can be a lengthy, trial-and-error process that takes days, or a one-second decision such as "I must go to such-and-such place that I saw in a movie."

In this case, other things are more relevant as requirements for the solution than the process itself:

  • Information to be considered (data sources and their relationships)
  • Decision criteria, including personal preferences
  • Influencers (human and nonhuman)
  • Context including time and places
  • Collaboration among involved parties

In short, what's relevant is what some modeling frameworks (including TOGAF/ArchiMate) call the motivation model behind the engagement.

After the motivation requirements are clear, the shape of the engagement can be established in terms of:

  • Business functions to be provided on top of information objects affecting the decision
  • Collaborations among actors
  • Process entities that describe the SoRs' part of the solution

Figure 6 shows the TOGAF/ArchiMate metamodel of an SOE:

Figure 6. SoE TOGAF/ArchiMate metamodel
Enterprise architecture metamodel of the SoE
Enterprise architecture metamodel of the SoE

As Figure 6 shows:

  • The technical infrastructure for an SoE is a CloudOE and one or more SoRs.
  • The CloudOE is the platform that runs SoE workloads.
  • Services are physically realized through interfaces, and applications through components.
  • Components implement a business process or a business activity) and can use other components through their interfaces, or technical functions through technical interfaces. Technical functions, for the most part, offer the capabilities commonly provided by middleware products (for example, a NoSQL database).

Example: A "Tourism in the Valley" SoE

As an example of the methodology that we've outlined, we'll use the case of a platform to support and promote tourism in an Alpine valley. We'll follow this example all the way from the stakeholders' motivation model to the identification of the CloudOE middleware services needed to support the SoE.

Figure 7 shows the TOGAF/Archimate model of the stakeholders' motivation:

Figure 7. "Tourism in the Valley" motivation
Architectural model of the stakeholders' motivation
Architectural model of the stakeholders' motivation

The model includes the point of view of the main stakeholder (the tourist) and the objectives of the other stakeholders of the domain: providers of services such a hotels, restaurants, transportation, and events (the suppliers); the valley tourist office (the platform owner); and providers of added-value applications and external opinion makers (the complementers).

To simplify the explanation, we divide the model into two parts: Tourist-driven and other-stakeholders-driven. We also omit discussion of KPIs and measurement (including nonfunctional requirements), which in and of themselves could be the subject of an entire separate article.

The tourist is influenced in decision making by a series of drivers including his or her personal interest and preferences, the weather forecast, and earned membership fidelity rewards.

The tourist office is in charge of promoting the valley as a vacation destination. This office acts through advertisements, incentives, and support for local events that are capable of attracting customers to the valley services. The tourist office's main requirements are to know the results of these actions and to gather the information that it needs improve the valley business system — such as typical visit patterns (perhaps by market segment) and the attractiveness of natural spots.

The service providers (hotels, restaurants, and so on) want the quality and price of their services to compare favorably with the competition. They also want to match their offerings to customer needs and preferences — a requirement that's shared by providers of value-added applications (who, in addition, must protect their intellectual capital from unauthorized use).

A slice of the model

To help explain the example, we'll focus on the "slice" of the model that includes the selection of services that will make up a holiday plan. We won't consider all topics linked to transportation and service booking (which are the areas that are more linked to traditional SoRs), and we'll trace the modeling of the following requirements:

  • The need for a service catalog that contains service information (availability, price, schedules, and so on), local events, notices about incentives, and other types of promotions.
  • The need to compare services based on multiple criteria (such as price, reputation, and trusted opinions), and to select the best fit.
  • The need to be able to select services by their location, by the proximity to another location of interest, or by the fact they can be linked to a specific one-time event occurring at the location.
  • The need to consider context information, primarily weather. (Traffic can be another example.)
  • The need to manage user preferences in the engagement (tourist master data).

These requirements are shown in the model in Figure 8:

Figure 8. "Tourism in the Valley" tourist's requirements
Tourist requirements for the Tourism in the Valley example
Tourist requirements for the Tourism in the Valley example

The requirements are reflected in corresponding business functions:

  • 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
Tourist business model for the Tourism in the Valley example
Tourist business model for the Tourism in the Valley example

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:

  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. I'll install it.
  3. But I have to register: yet another account, another password. No!
  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.
    • The app uses the identity & access manager CloudOE service to delegate authentication to Facebook and get a user token.
  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:
    • 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.
  9. I get three proposals. I can pick one as-is, or I can pick one and slightly change it.
  10. Wow! 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:

Figure 10. "Tourism in the Valley" SoE application
Diagram of the components of the SoE visualization manager application
Diagram of the components of the SoE visualization manager 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
Diagram of the initial Cloud operating environment for the Tourism in the Valley example
Diagram of the initial Cloud operating environment for the Tourism in the Valley example
  • 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.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Cloud computing
ArticleTitle=Design an SoE ecosystem to support rich user experiences