Mashup business scenarios and patterns: Part 1

This initial article in a two-part series discusses the relationship of usage patterns that can be used today for deploying enterprise mashups to address business needs. Part 2 will address solution architecture and architectural patterns used to implement the business scenarios and usage patterns.

Share:

Holt Adams, Executive IT Architect, IBM

Holt Adams is an Executive IT Architect in IBM software's Emerging Technology group, where he currently supports IBM's jStart Program and Customer Innovation Team. His skills allow him to play the roles of both solution architect and engagement manager to be an effective catalyst in customer adoption of emerging Internet technologies. He has experience as a practitioner in both the business and technical aspects of customer engagements from activities that include lead generation, business qualification, requirements management, solution architecture, solution design, and contract negotiations. As an IT Architect, Holt refines customer business needs to IT requirements that can be addressed with IT capabilities of emerging technologies in building leading-edge solutions. During his tenure in the jStart Program and other services-related jobs, his technology portfolio has included wireless/pervasive computing, Internet infrastructure, Java/J2EE, XML, Web services/SOA, open source, Web 2.0, social networking, and enterprise mashup technologies.



29 June 2009 (First published 27 January 2009)

Also available in Chinese Japanese

Editor's note: Know a lot about this topic? Want to share your expertise? Participate in the IBM Lotus software wiki program today.

Introduction

The use of mashups to address enterprise needs has progressed in the adoption curve to the point where the growth rate is becoming exponential. The technology is being leveraged by many industries to address unique business scenarios utilizing common usage and architectural patterns. More times than not, a solution for one industry can be deployed horizontally to cover other industries with similar needs.

The differences in the mashup solutions are the roles of the users and the data sets being aggregated to create unique value. In many cases, the usage patterns (for example, capturing of search criteria, rendering of data within the user interface (UI), updating of secondary tables based on primary data selection, manipulating data, and communicating with others) are similar, but the business goals and objectives being addressed are distinctive for each customer.

The design and architectural options of mashups are determined by the mashup platform chosen for implementation. Business scenarios that leverage a large set of common usage patterns can be implemented using a small set of design and architectural patterns (for example, use of RSS/ATOM feeds, invocation of REST services, widget communications through the pub or sub model, aggregation of data sources through centralized hubs, and data filtering at data and service sources).

Figure 1. Mashup adoption trend
Mashup adoption trend

Introduction

The IBM® software Emerging Technology team (jStart) has been working with customers and business partners for the past few years leveraging various mashup technologies (for example, QEDWiki, IBM Mashup Center) in proof-of-concept environments to address business needs in validating the usefulness of the technology. From the jStart team’s experiences, many common scenarios and solution implementations of the technologies have been observed and documented as formal work products. These artifacts are utilized with early adopters in promoting the value proposition of enterprise mashups.

Enterprise mashups implemented as situation applications are a newer style of mashups that are used for specific business purposes. A situational mashup is created for a unique business need and is often utilized only for short periods of time while the business situation exists. The applications can be created by the user and, by design, do not address the same nonfunctional requirements (for example, reliability, availability, and performance) that are associated with mission-critical Web applications. These applications are often classified as good enough by their users and are becoming the norm for business professionals who prefer the self-service approach to solving their own problems in moving their business forward in today’s marketplace.

As in all solution development disciplines, reuse of assets, such as methodologies, design concepts, and components, is common practice and is encouraged to promote efficiencies and to reduce development costs and schedules. When these assets are reused in common, repeatable ways they are often referred to as patterns. The term in and of itself is generic and can be used to describe, individually or in combination, business scenarios, usage interactions, architectural designs, and implementations. For this series of articles, we use the term when describing supported interaction and architectural aspects of how mashup applications are designed and implemented.


Mashup business scenarios

The accelerated pace of mashup adoption in the enterprise is related to two business parameters: revenue and costs. As always, businesses need to growth their revenue through increased sales and services. In today’s economy, though, it’s more likely that businesses need to stabilize customer loyalty to secure existing revenue streams. Similarly, the other parameter that justifies investment in enterprise mashups is the need to reduce operational costs. Minimizing the use of IT resources for application development or optimizing IT professionals in their daily tasks can both contribute to the bottom line in a positive way.

Businesses are starting to leverage enterprise mashups in significant ways to address both of these business parameters mainly due to the backlog of applications queued up for IT development. In many cases lines of businesses (LOBs) want to have more control to address their own needs and to limit their dependence on IT organizations. Similarly, IT organizations that are feeling the pressure to deliver applications to LOBs more quickly with less funding, are utilizing mashups for non-mission-critical applications because they require less expensive skill sets and can be turned around in less time. IT organizations use mashups to supplement less Web savvy business users who are not able to fully author their own mashup applications. Figure 2 shows some business scenarios for mashups.

Figure 2. Business scenarios
Business scenarios

These two business drivers, revenue and cost, are typically accompanied by a few common goals by the companies that are leveraging the use of mashups. These goals include the following:

  • Improve decision making by management
  • Optimize productivity of human resources
  • Demonstrate new business opportunities by business analysts
  • Find and locate expertise and content by employees, business partners, and customers
  • Improve informal business processes by collaborative teams

Many of the business scenarios in which mashups are utilized to address business needs can be adopted across multiple industries. Two common scenarios are resource management and personal dashboards. Resource management can be used to manage retail inventory between stores to optimize the sale of products in response to world events or natural disasters. It can also used to manage capital assets such as railway cars or ships to optimize the transportation of cargo. It can also be applied to the assignment of human resources to maximize revenue in sales and services opportunities. In all cases, data from different sources is aggregated onto a single screen to allow business users to improve their decision making, optimize their productivity, and improve their informal business processes.

Personal dashboards can be less specialized in support of a given business process, but they are often more customizable for given users. They offer great value for improving decision making, improving informal processes, and locating expertise and content. More times than not, they are not created to address a specific business objective, but instead to allow users to consolidate information and manage tasks to support their day-to-day activities. Dashboards are used to aid in emergency response, financial analyses, enterprise resource planning, and even battlefield analyses.

Other collaborative business scenarios that are being implemented include personal communications and field support services where teams are able to view and update information and initiate calls, emails, and instant messaging. Consumer scenarios also provide customers with self-services where they can manage their banking accounts, find branch offices and ATMs, and initiate communications with banking staff.

One underlining concept with these scenario examples is that the basic interaction model of the users (to be discussed later in this article) and the aggregation of data can easily be leveraged to address other business needs for different user roles with their data sources. Therefor, the focus of this article is patterns.


Early adopter interaction model

Regardless of the specific business scenario or industry, the current trend of jStart mashup projects for early adopters often falls into one of two styles of applications: search/lookup or personal dashboard.

The first style uses a mini-Web form to conduct a search on one or more information sources. The results are presented in some visual manner: within a table, as points on a map, as bars in a chart or graph, and so on. The user selects one item, and additional details about that item are presented to the user (search and review behavior). Typically, the information that is presented comes from multiple sources, internal enterprise systems or external Internet sources. At this point, the business scenario ends or the user utilizes the mashup to take an action based on the information rendered.

The personal dashboard style captures user credentials (ID and password) and uses them to present the user with a customized "dashboard" of data. This presentation can be the entire scenario, or the previous scenario can be repeated, where the user clicks an item, gets more detailed information, and then takes an action based on what’s rendered. More recently, early adopters are extending these two basic styles of mashups to include update, creation, and deletion of data to back-end systems (search, review, update behaviors) and communication mechanisms to enable collaboration among employees, partners, and customers (search, review, collaborate, update behaviors).

Figure 3. Early adopter interaction model
Early adopter interaction model

Figure 3 depicts an interaction model for early adopters to help facilitate an understanding of basic mashup usage. A specific interaction is considered a paired user action with one or more responses from the mashup (for example, clicking a tab that results in content being hidden while making other content visible, moving the mouse over an image that results in a popup action, or selecting a data record that results in additional details being populated in secondary tables). When covering usage patterns in this article, interactions are labeled, and they include discussion on the user action and resulting mashup response.

It is important to note that the search, review, update, and collaborate types of mashup behaviors are the basis for the initial set of business scenarios described previously. Looking over the horizon, you can envision a much broader use of the technology that includes video, automatic update, integration of remote IP-based devices, and global positioning systems (GPS). Most business scenarios, regardless of their business goals, user roles, data or industry focus, can be represented in the preceding interaction model. The common usage patterns that support this interaction model for early adopters are derived from participants of jStart projects and are discussed in the following sections.


Business scenarios as opposed to usage and architectural patterns

From the preceding discussion, business scenarios are described as high-level business activities to address business goals with little reference to technology. The realization of the scenarios means that business users perform tasks through interactions with specific technology in common ways that in this series of articles are called usage patterns. The patterns include common steps (that is, actions) exercised by individuals (for example, log into mashup, enter search criteria, select data from tables, mouse over images, add or update data records) while using features or controls of the mashup interfaces. When a user interacts with a control or data presented within a mashup, some of the actions performed result in processing by the mashup that either changes the rendering of the UI itself (for example, navigation, visibility of controls), invokes services or data sources from other software, or displays additional information and images within the mashup. In some cases, all three of these processing examples can be executed by the mashup in response to the user action. See figure 4.

Figure 4. Scenarios as opposed to patterns
Scenarios as opposed to patterns

The implementation of the supported behaviors and interactions by a mashup application is dictated by its underlying architecture. Mashup applications are constructed from components called widgets that are linked together to create a UI and model for aggregating data to be viewed and acted upon by a user. These widgets can be both visible for rendering the UI or hidden for performing background processing. Visible widgets can also perform or initiate background processing. The linkage (programmatic coupling or communications) between widgets is the mechanism by which the mashup application provides an interactive and responsive experience to the user (for example, clicking a control of one widget that results in a data refresh within other widgets or the rendering of additional widgets within the interface). How the linkage is defined and implemented depends on the mashup application platform. Part 2 of this series provides the designs by which the usage patterns are implemented to enable the mashup’s behaviors and user interactions.


Usage patterns with enabled actions and mashup responses

The jStart team has worked with more than 50 customers to adopt mashup technologies to address real-world business needs. Based on the initial set of search, review, collaborate, and update behaviors with mashup applications, many universal usage patterns have been documented and reused. The capabilities provided by the patterns can easily be mapped to common IT requirements of customers who have adopted mashups and thus can explain their popularity for reuse and applicability in multiple industries. The usage patterns (interactions with actions and responses) outlined in the following sections are those implemented by the jStart team during the initial stages of customers’ adoption. These patterns should be considered a small set of what is possible when leveraging the capabilities of mashup technology to address business needs.

Access control and personalization patterns

Many enterprise mashups leverage corporate data considered valuable assets based on the data's intrinsic market value or confidential data because of individuals’ personal data or the competitive advantage afforded by the data. In both cases, authentication and authorization of the user community are needed and require members to log in before being presented with the mashup application UI. The user community can be a combination of employees, business partners, and customers. Figure 5 illustrates the typical usage patterns and enabled actions at login.

Figure 5. Login interactions
Login interactions

After a user’s credentials are captured and validated, access to corporate data can be provided and personalization can be done based on the role of the user. This authorization also includes controlling access to the mashup application’s features (for example, navigation controls, communication controls). Similarly, access to fee-based services can also be controlled based on roles to ensure proper use of services. Upon login, the user is able to initiate actions by clicking controls within the mashup UI to direct which features and data are presented in the UI based on the business task at hand.

Rendering mashup UI and retrieval of data patterns

To optimize the aggregation of data from multiple sources within a mashup and to limit the amount of data retrieved from these sources to the most relevant data, an initial query is done for a set of primary data records using search criteria defined by the user. The criteria are often captured within a form using text input fields, drop-down menus, check boxes, or radio buttons. Depending on the type of data sources or services being integrated, the simplest case can be an invocation directly to the data source or service to extract an RSS or ATOM feed. Alternatively, a request can go to a hub to aggregate data from multiple sources (for example, feeds, SQL, files, Web services, LDAP, SAP) or from sources with different data formats (for example, RSS, ATOM, CSV, XML, unstructured strings) to create a consolidated data feed.

More complex invocations can also include data extracted directly from back-end systems using their native protocols and APIs (more on this when we discuss architectural patterns in Part 2). Often, filtering is done to remove irrelevant or redundant data to minimize the amount of information exchanged between the browser where the mashup is rendered and the back-end corporate systems, external public data sources, or services from other vendors. When possible, Figure 6 illustrates the typical usage patterns and enabled actions after login to define search criteria.

Figure 6. Search and retrieve interactions
Search and retrieve interactions

Upon retrieving an initial set of data, the mashup renders the primary data records using visible widgets that include tables, lists, hierarchical tree structures, maps, menus, and images, to name just a few visible components used for presenting information. The data can be structured data from databases shown within columns of a table, colored icons to identify unique sets of resources on a map, slide shows of images or contacts listed in buddy groups with presence awareness indicators.

Review and manipulation of data patterns

After the primary data set has been presented to the user, the user can start to perform tasks to accomplish whatever business activity is supported by the mashup. The review and manipulation of the highly relevant data by design enables improved decision making, optimized productivity, faster locating of expertise and content, and improved informal business processes.

The aggregation and association of disparate data in a common view to provide unique value are the cornerstones of mashups. Immediate value can often be afforded to business users by enabling them to easily navigate through the data to view it side by side, associating data from one source to that of another. Having the ability to drill down into more details by selecting individual data records and having secondary data presented in tables, bar charts, or maps enables business users to work with data visually at multiple levels. Figure 7 illustrates the typical usage patterns and enabled actions after an initial set of data has been retrieved or a refresh made of a follow-up query.

Figure 7. Data review interactions
Data review interactions

By providing users access to their data from multiple systems and allowing them to manipulate the data in real time (updating records, creating new records, or deleting records) from a common view enables users to optimize their tasks in performing a business activity. Updating data could include adding unstructured comments, assigning a service request to a team member, or tagging banking transactions to a budget category. Creating new data records could include adding a contact to a buddy list. Executing a transaction such as a transfer of funds between banking accounts can also generate new records in a data set. Data can also be deleted and removed entirely from the data set. See figure 8.

Figure 8. Data manipulation interactions
Data manipulation interactions

In all cases, any manipulation of the data must be replicated to the back-end systems immediately to persist the changes for future use by other team members. Depending on the systems and protocols supported, it is often preferred to let a server-side component manage the coordination of updates (for example, two-phase commit) when multiple systems are involved.

Communication with others patterns

Teams work best when members are easily able to communicate with one another. In today’s world of remote offices, dispersed teams, and members on the go, the standard means of communicating among the team using only phone or email isn’t sufficient. In addition, mashups that enable users to connect using additional means add great value by matching preferred communication methods to those of the community. Asynchronous messaging such as chatting using instant messaging (IM) or texting using short messaging service (SMS) has become a preferred communication mechanism for many professionals and consumers for short, non-emergency communications. Figure 9 illustrates the typical usage patterns and enabled actions for enabling communications for a collaborative team.

Figure 9. Communication interactions
Communication interactions

As a standard mode of operations, mashups that enable communication mechanisms use contact lists where team members can be organized into groups (for example, buddy lists) and assigned nicknames for ease of use. By enabling teams to collaborate through multiple communication channels based on their personal preferences or situation, mashups ensure that efficiencies are obtained during the execution of business activities. The goal is to equip teams to perform informal business processes together by leveraging the team members’ expertise and workflow policies. See figure 10.

Figure 10. Communication interactions details
Communication interactions details

After a communication option is selected, the mashup application can populate the necessary information from the primary data set that is required for initiating the communications (phone numbers, email address, IM name, and server of IM provider). The mashup can also do processing of user input messages to ensure formatting, spelling, and adherence to message lengths.

The usage patterns described here are specific to jStart projects implemented for multiple business scenarios across multiple industries, but they represent only what was necessary to support the stated business activities of the customers. Because mashups leverage Java™Script running within the browser and can access server-side components, you are essentially unlimited in the interactions that a mashup application can support. The sky is the limit if you have the IT skills to develop and customize widgets for use in your mashups.


Conclusion

Today’s mashup applications can be described using a simple interaction model that supports search, review, collaborate, and update behaviors. Mashups can be used for business scenarios, providing support for common interactions where a user takes an action and the mashup application provides one or more responses. The user roles and data for each industry where mashups are used today are different and provide unique value to address the industry’s business requirements. The usage patterns are similar, though, because the underlining IT requirements are basically the same. This article touches a small set of possibilities afforded by mashup technology based on the use of early adopters. Enabling business users to create their own situational applications to address their own needs or solve their own problems is the value proposition that can be realized with mashup technology and IBM Mashup Center. Part 2 in this series of articles covers solution architecture and architectural patterns used to implement the business scenarios and usage patterns outlined in this article.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into IBM collaboration and social software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Lotus, Sample IT projects
ArticleID=366778
ArticleTitle=Mashup business scenarios and patterns: Part 1
publish-date=06292009