Mashups are new and exciting aspects of Web 2.0. As is often the case with new technologies or approaches the industry often gets caught up in promoting the value proposition of what’s emerging. The hype often muddies the water between the value of what can be created with the new technology and the value of what exists today. With mashups, it's often unclear to IT professionals how their existing Web applications might be different from the proposed innovative approach to mashing-up data with a browser.
One of the first questions that customers often ask is "What’s the difference between a mashup and the Web applications that we currently use in our enterprise today?" The difference has little to do with technology or the integration of systems. Instead, it reflects the ease with which the application can be created by users, how the application is intended to be used, and the lack of nonfunctional requirements (for example, reliability, availability, and performance) that need to be addressed after the mashup or Web application is deployed.
In this article, we compare Web applications with a newer style of mashups, often referred to as enterprise situational applications, that are used for business purposes. The mashups are created for specific situations and are often utilized only for short periods of time while the situation exists. To appreciate the differences between mashups and traditional Web applications, let’s first review what they have in common.
With the recent announcement of the IBM® Mashup Center offering, which consists of Lotus® Mashups and InfoSphere™ MashupHub, IT architects and business analysts can consider how to leverage the product’s components and features to better address their situational needs and to improve their company’s competitiveness in today’s market place.
Now let’s look at the differences between the two types of applications. The reference to traditional Web applications is loosely applied with many subjective criteria; in some respects, the reference is relative to how a given Web application is developed today. In general, the classification of traditional has more to do with the use of formal development and deployment methodologies models. Classifications of traditional Web applications are also meant to include applications that dynamically generate content based on user interactions (for example, submitting a form or clicking a link), but where the aggregation of information within the UI and the linkage of UI controls are done on the server. Thus, applications based on Java Server Pages (JSP), Active Server Pages (ASP), or IBM WebSphere® Portal technologies are considered traditional Web applications. Web-based applications that support page-based navigation are also considered traditional Web applications as they limit a user’s ability to view and act on data efficiently. Even Web applications that utilize Adobe® Flash technology with highly interactive interfaces can be considered traditional Web applications when you look at how they are constructed and deployed.
Web applications that are deployed in the enterprise for lines of business customarily require formal development teams and operational support. First, the costs of development and support can be justified only if the number of users who benefit is large or if the application is mission-critical. In either case, a formal process is required to ensure the highest rate of return on the investment.
Second, unique skills are typically aligned with the organizations of a business to optimize the use of resources. In many cases, the people with development and deployment skills are not the same people as those with knowledge about the business domain. Typically, a line of business has a set of requirements that needs to be addressed to support business processes or customer-related sales and services initiatives. These requirements are addressed through the design and development of UIs, control logic that manages how an application functions, and code that utilizes and manipulates business data.
The development effort for an enterprise Web application is typically very formal with requirements definition, design, development, functional and system testing, and deployment stages. Combined, the end-to-end solution process can take months, if not over a year, to complete. In this approach, line-of-business organizations are dependent on the IT and programming departments within their company. When the formal processes are followed, though, the result is more likely a comprehensive and stable solution that is optimized for a target set of users. Similarly, the trade-offs are the amount of time it takes to develop and deploy the Web application and the overall costs of delivering and maintaining the application. In some cases, the business need for the application might change or become superfluous if the cycle time to create the Web application is long.
As noted earlier, mashups utilize many of the same technologies as traditional Web applications both in the enterprise servers and in the browser. The concept of mashups is not new, as businesses and Web developers have been aggregating and integrating data for the past decade using the Web as a platform. To minimize confusion, let’s clarify a few points about mashups. For many, mashup is considered a technical term regarding the mashing of disparate data to produce something new and interesting. A situational application is considered a tactical application, one that is often temporary and built by the people who use it. In this respect, a mashup can be a situational application, and a situational application can be a mashup. For this article, mashup means a situational application that is implemented as a mashup. See figure 1 for an overview.
Figure 1. Characteristics of mashups and situational applications
A primary difference between mashups and traditional Web applications concerns the mashup application life cycle and the tendency of mashups to join seemingly unrelated data from public sources in meaningful ways with little or no formal agreements with the data providers.
Mashups can be considered a special genre of Web application for several reasons. They are created by the user or business analyst in relatively short periods of time with little or no additional costs to cover IT resources. Similarly, mashups used in an enterprise are often associated with data aggregation of both enterprise data and data from public sources. They create value by virtue of integrating data from multiple sources (most often leveraging public sources of seemingly disparate data) in a meaningful way that addresses a business or personal need. The aggregated data becomes relevant information when placed in the right context; producing something new and interesting is the trick of creating a successful mashup.
For instance, consider a supply chain management example in which a regional operations manager constructs a Web page (mashup) containing a weather feed, a Yahoo! map, and enterprise inventory data to aid in the logistical management of merchandise in response to a natural disaster such as a hurricane. For another example that shows value to an individual consider a Web-savvy employee (sales representative) who is relocating for business purposes and is shopping for residential property. The employee creates a Web page using a Google map and integrates into the map real estate listings with images, public tax records, public records of criminal incidences, and a list of his or her customers. The employee accomplishes this task by dragging each list of data from a palette and dropping it on top of the map, which causes each entry with address information to display as a pin mark on the map. The resulting mashup aggregates the disparate data from the multiple sources into a common view, which offers value to the employee by helping him or her make a decision on a house purchase that is reasonably priced, is near customers, and is in a safe neighborhood.
A traditional Web application (for example, a portal) can aggregate data too. Typically, though, a mission-critical application does not rely on public data sources because of concerns about availability and data validity. Similarly, a business analyst does not possess the skills to build such an application.
To enable business users to create mashup applications, a mashup maker, editor, or assembler is often used (for example, Lotus Mashup editor, IBM Lotus Widget Factory). The mashup maker itself can be a simplified browser-based development environment. The user simply selects widgets from a palette in the mashup maker, arranges them on a workspace, and performs a few steps to customize the widgets and to link them to create a simple Web application: a mashup or, more specifically, a situational application mashup. Likewise, a mashup feed can be created with similar tooling (for example, InfoSphere MashupHub client) that merges, filters and transforms a set of existing feeds in creating a new feed to be consumed by widgets. The widgets themselves are independent application components with formal interfaces and customizable properties that often provide UI views of the data, UI controls, and background processing of data (for example, invocations of server-side services, database CRUD operations, screen scraping, or transcoding and mapping of data between widgets). The creation of mashups and their deployment for use by others are performed in the mashup maker without any reliance on formal IT operational teams. Some initial dependencies still exist between the line of business and the IT organization to deploy the tooling, setup, and enablement of the mashup system and to make the tooling available to the business user to create a mashup style of Web application.
IT must still set up and configure systems in the production environment or internally behind the firewall, as is also required for traditional Web applications. Specific mashup system components need to be deployed on servers, similar to how a portal engine is required for portal-based Web applications. In addition, if business data isn’t accessible using standardized syndication feeds (RSS or ATOM), Representational State Transfer (REST) APIs, or simple Web services APIs, then the IT organization needs to create such interfaces.
One simple alternative for creating syndication feeds to enterprise data sources is to leverage a mashup hub component (for example, InfoSphere MashupHub) that interfaces with the enterprise systems on the back end while presenting individual syndication feeds for each system or an aggregated set of syndication feeds for the systems that can be use in mashup applications. Similarly, if views of data need to be customized beyond what a widget’s properties allow or if the user interactions require custom widgets, then the IT organization can choose to create new widgets or customize existing widgets from the existing inventory. After the business data and logic are externalized through standardized APIs and after customized widgets are added to the inventory of widgets, the dependency on IT is greatly reduced. IT might be needed only to ensure that the systems are maintained with the appropriate middleware and that monitoring and support are provided to ensure system availability. Because the widgets are reusable application components that are assembled together in an ad-hoc fashion to provide business capabilities, trade-offs do occur. The trade-offs can include reduced customization of the UI, less tuning ability for performance, and little or no formal support for the aggregated set of widgets that make up the mashup application itself.
With so many similarities, yet with some distinct differences, you might not see a clear advantage to adopting one approach over the other. Consider these points to determine whether using a traditional Web application development and deployment model is your best choice:
- The application is necessary to the success of the business.
- A large community of users requires the application to be highly available with formal support.
- The application needs to address a comprehensive set of requirements that mandate a highly integrated and customizable UI.
- Complex document workflow or process workflow needs to be managed.
If these considerations do not point you to a traditional Web application approach, consider the following points to determine whether a situational application mashup is your best choice:
- The business needs are immediate and short-lived.
- Users or business analysts are web-savvy.
- Business data can be associated in meaningful ways with content from multiple sources (internal or external to the enterprise).
- Rapid prototyping is required to demonstrate business needs to the IT organization.
- Productivity increases can be gained within the user community by enabling self-service aggregation and integration of business data.
- "Good enough" solutions are sufficient to address business and personal needs.
- Data sources support syndication feeds.
- Data services support REST-style interfaces or simple Web services interfaces.
- Many business users need access to the same data, but for different reasons.
The value proposition of situational application mashups is that after your enterprise has enabled access to business logic and data through standardize interfaces, applications can readily be created by the users themselves. The applications are constructed using a set of widgets that can display and enable actions on the enterprise data, allowing the users to directly leverage a company’s investment in SOA and other standards and to implement a self-service style of behavior to address their own needs to optimize their productivity. These productivity gains by individuals and by their teams require and that of their team with little reliance on IT organizations; thus, these benefits are not offset by IT resource costs.
Read the developerWorks® article, "Mashups: The new breed of Web app."
Read the developerWorks article, "IBM Mashup Center and the InfoSphere MashupHub, Part 1: Get started with InfoSphere MashupHub."
Read the developerWorks article, "SOA Meets Situational Applications, Part 1: Changing computing in the enterprise."
Read the developerWorks article, "Mashups -- The evolution of the SOA, Part 2: Situational applications and the mashup ecosystem."
Learn more about situational applications.
Learn more about mashups.
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.
John Gerken is a Senior Architect for IBM, where he is responsible for recognizing, promoting, and developing prototypes of software technologies and trends that could positively affect IBM's customers. He is a recognized thought leader in the area of situational applications, widgets, and mashup ecosystems and is a principle evangelist for these technologies to IBM customers. John is a member of the North Carolina Technical Experts Council (NC TEC), which is an IBM Academy affiliated, technical advisory and vitality organization serving the Research Triangle Park, NC area. While his Masters degree is in Software Engineering, he also holds a Bachelor's of Science degree in Jazz Performance and plays at every opportunity.