Model-Driven Mashups: The Business Opportunity

In our discussions on Service-Oriented Architecture (SOA), ZapThink has always focused on the overlap between business and technology. We see SOA as Enterprise Architecture, which concerns the business and how it leverages technology to meet business needs. It follows, then, that our analysis of mashups also drills down into the business applications of technology.

While others may scorn mashups in general little more than proofs-of-concept for distributed and sometimes Service-oriented applications, ZapThink feels that the business potential of mashups is so great, in fact, that this ZapFlash is the third in a series on the topic. In Mashups and SOBAs: Which Is the Tail and Which is the Dog? we defined enterprise mashups (Web applications that combine content from more than one source into an integrated experience) and discussed their relationship to Service-Oriented Business Applications (SOBAs), which are applications composed of Services in a declarative manner. We then concluded that for mashups to be of interest to the enterprise — to be an “enterprise mashup,” they must incorporate governance so as to prevent unintended or unallowed consequences of combining enterprise Services. In a subsequent ZapFlash, we discussed the ideal mashup creation tool in The SOA Killer App, where a significant business opportunity exists for building a Service-oriented application that combines modeling, lifecycle management, rich Service consumer capabilities, business dashboards, and SOBA composition capabilities. While the need for such a tool is compelling, we set the bar quite high for any vendor courageous enough to bring one to market.

We feel the business opportunity in the nascent enterprise mashup market goes well beyond the SOA Killer App, however. As the focus of enterprise architects implementing SOA shifts from providing Services to consuming them, we predict the growth of a diverse set of business-centric products and services related to enterprise mashups. Of course, since we’re still crossing the chasm with regards to SOA, the market for such products and services resides squarely in the future. The best we can do to outline the business opportunities in this market-to-be, therefore, is to uncover some of the challenges that vendors and their investors might identify as potential targets for investing their time and money in developing tomorrow’s enterprise mashup-related solutions.

Uncovering the Enterprise Mashup Opportunity
Every entrepreneur looks for three key characteristics when searching for the right business opportunity:

1. The new approach must meet a current or future business need
2. The new approach must be innovative in some important way
3. The problem the new approach presents must be hard enough so that solving it provides a barrier to entry to competitors, but not so difficult as to take more time or money than potential investors have the patience to provide.

One of the reasons why enterprise mashups are so compelling is because enabling business users to assemble Services, and thus create new applications, in flexible, innovative ways, within the context of a governance framework, has broad, untapped business value that firmly addresses the first characteristic of a business opportunity. Since we’ve frequently addressed the business need for such classes of composite applications, we’ll focus this flash on the latter two characteristics of business opportunities: a new approach to solving old problems and changing the status quo so significantly that it presents a barrier to entry.

For a mashup-based solution to be innovative, it follows that it can’t be too much like an existing approach. For example, it doesn’t make sense to retool a business-process management tool, portal application, or a traditional collaboration tool. Instead, the new solution must break new ground. The key to this innovation, unsurprisingly, is SOA. Without SOA, mashups are relegated to the Web tier of an n-tier architecture, essentially a fun thing to do in a browser with Rich Internet Application (RIA) capabilities leveraging technologies like Asynchronous JavaScript and XML (AJAX) and Flash.

In the Service-oriented context, however, the sort of enterprise mashups that businesses require combine rich interface capabilities with SOBAs that enable not only the use, but also the creation and configuration of the SOBAs themselves. Furthermore, the Services that make up the SOBA composition might abstract capabilities on either the client or the server, as illustrated below in Figure 1:

Figure 1: A Mashup as a Composition of Client-Side and Server-Side Services

The critical innovation lies in the fundamental nature of a Service. Services exhibit location independence, in that the Service represents an abstract interface to functionality that can be located anywhere. In practice, this location independence enables a framework for a collaborative approach to mashups that blurs the dotted line between client and server, enabling the sharing of mashup capabilities in new, innovative ways.

The Challenge of Model-Driven Mashups
Location independence between client and server, itself an aspect of loose coupling, is easier said than done, however, and thus offers the third characteristic of business opportunities. After all, clients are personal, numerous, sometimes disconnected, and diverse, while servers are centralized, shared, managed, and integrated. Thus, the code that provides a Service on the client is necessarily quite different from the code that provides a corresponding Service on a server. There’s no reason to expect that it would be practical to move the code from one to the other, given the fundamentally heterogeneous nature of the distributed business environment.

Fortunately, the loosely coupled approach of SOA is antithetical to code portability in any case, and correspondingly, so are mashups. Indeed, we implement enterprise mashups as configurations of Services defined via metadata, rather than in code at all. Users might represent enterprise mashups entirely in an XML file, for example, that would include all the configuration metadata that constitute the business logic of the mashup. People are therefore welcome to relocate the mashup by moving or copying the XML file, rather than the underlying code or execution environment.

However, the market is far too immature for anybody to have a particularly good idea of how to define a fully declarative standard for representing mashups. The key to solving this problem is to ratchet up the level of abstraction and take a model-driven approach to mashups. We need a tool that can abstractly represent the business logic in a mashup as a model, and then use that model to generate the appropriate configuration files for all possible locations of Service providers and consumers, as well as all required representations of the mashup. We can explain the concept of model-driven mashups better with a diagram, as shown in Figure 2:

Figure 2: The Model-Driven Mashup

Today’s Web-only mashups follow the leftmost arrow: the mashup tool simply creates the user interface (UI) representation. Extend the concept of mashups to SOBAs, and you have the rightmost arrow: a mashup tool creating a SOBA representation, that is a composite, Service-oriented application that might not even have a web-based user interface. Neither the left-most, nor the right-most, arrows represent the approach we need to build truly flexible, location independent, and therefore Service-oriented mashups that allow for variability of business function, location of logic, as well as user interface.

If the mashup tool can generate the appropriate model of the mashup, however, we’ve achieved the required flexibility. Now, it should be possible to generate the appropriate UI representation from the model, as well as the appropriate SOBA representation, regardless of which parts of the mashup are on which client or which server.

ZapThink frequently points out that while object-oriented approaches to distributed computing are based upon code portability, Service-oriented computing leverages Service interoperability: we leave the code wherever it is, regardless of platform, language, or other implementation details, and teach it to send and receive messages as specified in a Service contract. We can therefore build loosely coupled interfaces in heterogeneous environments, and from there all the benefits of SOA follow.

The concept of model-driven mashups, however, brings the notion of portability back to the table. Where before, it was the code that was portable, requiring homogeneous distributed virtual machines to work (changing “write once, run anywhere” into “write once, debug everywhere”), we’re now talking about portability of the model itself, represented in metadata. If we can use the model to generate the appropriate metadata for the deployment environment transparently to the user, then from the user’s perspective, they can create a mashup, post it to a blog or email it or upload it to a portal server, and anybody can find it, access it, run it, and modify it at will, all within the context of a robust governance framework. At that point, the distinction between client and server will fade from importance. Instead, the business user will simply think about enterprise mashups that meet the business need at hand.

The ZapThink Take
The challenge for entrepreneurs or investors, therefore, is to identify the appropriate problem to solve. They might add location-independent mashups to the laundry list of capabilities the SOA Killer App offers. Model-driven tooling also presents a substantial opportunity. Furthermore, mashups require special server-side support, since simply generating the right config file for a server-based mashup won’t provide the qualities of service that enterprises will expect from such collaboration capabilities. And finally, the market for mashup governance might be the greatest opportunity of all. How will companies create, communicate, and enforce the policies for building, changing, and using mashups, when the Services that make up those mashups are location independent? Or even more interesting: how can model-driven mashups help companies become more compliant with corporate policies, across both IT as well as the enterprise at large?