With the emergence of Web 2.0 and SOA technologies, mashups have gained in popularity. Web 2.0 provides a rich user experience, and SOA technologies facilitate the underlying flexible plumbing required to make mashups happen. So you could say mashups are a mashup of Web 2.0 and SOA!

If you're reading this article, mashups have been on your mind, and you probably caught some of the buzz from the likes of Google, Yahoo, eBay, and Amazon. Mashups on the Web from public APIs have a cool factor, but the real value of mashups is in the enterprise. Enterprise mashups facilitate information at your fingertips in the right context. Here we'll delve deeper into enterprise mashups and the factors you need to take into consideration for a successful mashup strategy and lifecycle.

With mashups in the enterprise, you combine different streams of information to provide actionable knowledge to the stakeholders. The concept behind mashups is that the value of a mashup is greater than the sum of its individual parts. There are essentially two kinds of mashups: (a) mashups at the UI and (b) mashups at the business layer. Let's observe these two types in more detail.

Mashups at the UI
UI mashups aggregate and overlay information at rendering. Web 2.0 technologies make the user experience friendly, rich, and lightweight. Services from Google and Yahoo fall into this category. For an enterprise scenario, consider the following examples:
• Example 1: Utility companies such as power, telephone, and cable tend to have regional outages. Let's say there's been an overnight storm and the residents in the 90210 Zip code have lost power. The power company has all the information related to managing this outage, but in various silo'd systems. The customer information is in SAP; field technician location information is in a workflow system; affected homes are registered in a trouble ticket system, and so on. What would be valuable to the stakeholders managing this outage is a mashup of information from all these systems. A 360-degree view of the outage as a single one-stop-shop dashboard would make crisis management more efficient as all the necessary information would at the decision makers' fingertips.
• Example 2: It' the end of the quarter and your company's regional sales directors would like to create war rooms to track and manage all the key deals for the quarter. Today in most companies this is managed by fax, phone, e-mail, and a CRM system like Siebel. Once again, what would be very valuable and efficient is to have the consolidated information of deals, contacts, legal, finance, sales operations, all working off of the same dashboard and set of information instead of e-mailing each other Excel spreadsheets.

Today these kinds of dashboards or user- and context-centric functional consoles are built with hard-wired connections to back-end systems for pre-determined use cases. They do not lend the flexibility of the stitched-together on-demand capability that mashups offer.

At first glance one might say, "What's the big deal about these dashboards? Companies have been doing them for decades." That's a valid argument. With each generation of new technologies, however, building user-centric and context-centric information is getting easier and cheaper. We've heard of composite portals. Mashups still carry forward that concept except that they take the game to the next level. Mashups significantly lower the barrier to entry. If designed right, one doesn't need to have much technical knowledge to assemble a mashup. That's the Holy Grail. This means that once IT provides the underlying services, business users can then quickly assemble mashup-based applications by leveraging easy-to-use GUI widgets. This is the philosophy on which Yahoo Pipes is built.

Mashups at the Business Layer
While mashups at UI are themselves valuable, mashups at the business layer (MBL) can be even more powerful. The tooling for MBLs would be different than that for UI-based mashups. MBLs also would require knowing languages like XML and XQuery. These developers are adept at quickly stringing together an MBL based on existing base level services. There are already standards and specifications in the works (such as Service Component Architecture (SCA) and Service Data Objects (SDO)) that facilitate service assembly. MBLs could then be leveraged at the UI or at other tiers in the composition chain.

For those who have been entrenched in the SOA world for the past few years, this may look like the notion of Composite Services. In a way, MBLs are very similar to Composite Services. The key difference is that Composite Services, as we know today, are more use case-specific and have harder links to back-end systems. MBLs are virtual by nature and independent of the architecture of underlying base services. Looking at this another way MBLs would be built on top of Composite and base services. MBLs are logical in architecture, while most Composite Services are physical in architecture. Also, if technologies like virtual data services and workflow are thrown into the mix, MBLs can offer services that are suited for multiple contexts that can be quickly wired together to form a new mashup. MBLs, therefore, bring down the cost of integration significantly and unearth valuable information buried in the enterprise back-end systems.

The concept of MBLs is not new concept - some of the forward-looking SOA architectures have already been leveraging this type of approach. MBL is more of a design pattern. This article just brought this pattern to light.

The Network Effect
The true power of mashups will only be realized when there is a strong Network Effect. According to Wikipedia, a Network Effect is a characteristic that causes goods or services to have a value to a potential customer that depends on the number of other customers who own goods or use the service. The Internet is built on this phenomenon. The more people contribute and leverage the Internet, the more value it offers. Similarly, public transportation like subways play to a Network Effect as well. The more elaborate the network is, the more we tend to leverage its services, and the more value we get out of the system.

Similarly, as you put up more services, the power of AND kicks in, and the more valuable the service portfolio gets. After a certain threshold of services, your mashup and service infrastructure could even be a differentiating factor against the competition. With its ease of use, business stakeholders can quickly assemble workspaces, collaborate, and make timely decisions. In the earlier example, just imagine the outage team being able to manage the process, resources, and people in a streamlined way due to better access to information. Information is power. That's what mashups are poised to provide.

Governance for Mashups
To realize the benefit of Network Effect for services, proper control and governance measures are essential. Without governance, services would be misused and the infrastructure would quickly fall apart. As an analogy, think about traffic rule. Roads are a powerful transportation mechanism. Without rules, however, roads would quickly become unusable. The same logic applies to services in an enterprise. They need to be governed and managed carefully.

In most organizations, SOA governance (and by extension mashup governance) typically revolves around four main areas - security, performance, change control, and compliance. Governance can be broadly classified into two types: design-time governance and runtime governance. Both have to address the four core areas mentioned above. The topic of governance in itself is a vast subject and an article like this can't do it justice. But here's a quick look at what it has to addresses - especially in the context of mashups and services.

Design-Time Governance
Governance at this stage typically involves:

• Policy-based access control, so that unauthorized teams/individuals don't tap into the service.
• Defining Quality of Service (QoS) metrics such as service level agreements (SLA), performance guarantees, and other policies associated with the service.
• Mapping and managing dependencies between underlying services.
• Compliance requirements such as HIPAA and SOX may impose additional policies as well. For example, there may be policies around the ability to change the service contract or SLAs.

Runtime Governance
Governance at this stage is mostly about enforcement. It typically involves:

• Restricting the access to a resource based on pre-defined authorization rules.
• Raising an alert (and optionally generating a report) if a given service violates an SLA. Some companies use automated scripts to execute appropriate action(s) based on the SLA violated.
• Managing deprecations and end-of-life for services (in a transparent manner to the client)
• Compliance requirements may require stringent auditing for non-repudiation and transaction tracking.

An important aspect that transcends both design-time and runtime governance is protecting the underlying services (and back-end systems) from the extra load imposed by new mashups. This is where access policies to services even at design-time become very important. If a developer or business user creates a new mashup that puts strain on the back-end systems - the load requirement should be designed and planned for end-to-end. Many times, the existing services may need to be modified or extra hardware added to support a new load. Therefore, understanding the usage patterns for the functionality offered by a given mashup is important. Many companies, as a best practice, form a Center of Excellence (CoE) that monitors and manages the governance process.

Conclusion
You've probably realized by now that mashups, as powerful as they are, require significant responsibility and discipline in an organization. If not, they may cause more damage than good. However, this shouldn't deter companies from taking full advantage of their enormous benefits. The benefits of mashups far outweigh the governance overheads. There are also tools in the market that offer good solutions around service infrastructure and governance. So plan, execute, and reap the magic of mashups.