Mashups and SOBAs: Which is the Tail and Which is the Dog?

New buzzwords are one of the many side-effects of emerging markets, and into our buzzword-heavy world comes yet another doozie — the mashup. According to Wikipedia, a mashup is a Web site or Web application that seamlessly combines content from more than one source into an integrated experience. Falling under the increasingly broad buzz-umbrella of Web 2.0, Mashups bear a more-than-passing resemblance to the Service-oriented composite applications ZapThink frequently speaks about — known in analyst-speak as Service-Oriented Business Applications, or SOBAs. In fact, the overlap of mashups and SOBAs, or enterprise mashups, has recently become a hot topic du jour in the blogosphere.

The collision of two heretofore distinct areas of discussion within the blogosphere (in this case, mashups and Service-Oriented Architecture, or SOA) inevitably results a measure of consternation, because the people within each group bring a different context to the discussion. In this case, there is confusion over the question as to whether mashups are the critical “new thing” and SOBAs are simply a type of mashup, or vice-versa. That’s why we ask: which is the tail and which is the dog?

The Context for Enterprise Mashups
The reason for much of the chatter about mashups and SOBAs arises from the fact that mashups, and Web 2.0 in general, are primarily social phenomena, while SOBAs, and SOA generally, are primarily business phenomena. Yes, there is money to be made in some mashups, to be sure, but business motivators aren’t generally driving mashup development. Instead, mashups are part of the broader social context of Web 2.0, leveraging the power of the Internet to augment communication and collaboration among individuals, not between companies and their customers. In contrast, the “B” in “SOBA” clearly indicates their business context: the point of SOBAs is to deliver flexible IT resources to meet continually changing business needs.

Given this difference in context, let’s break down the discussion of poor Fido and his tail into two key questions:

Question #1: Are mashups the result of bringing SOA to the Web 2.0 party?

Or:

Question #2: Are SOBAs the result of bringing Asynchronous JavaScript and XML (AJAX) and other Web 2.0-related technologies to the enterprise’s efforts with SOA?

To explore question #1, it’s important to realize that what SOA brings to the party is the loose coupling between the providers and consumers of Services. Loose coupling means that businesses can change how they consume Services without having to make changes to the implementation of those Services, and vice-versa. Most of today’s mashups care little about loose coupling. After all, if Google changes the implementation or location of their Service interface, for example, then developers of the various mashups that leverage one of Google’s Services would have to update their mashups. Such changes might be annoying, but they’re really not a big deal in the social context of Web 2.0.

However, if the mashup is an enterprise mashup in that its creator intended it to solve a particular business problem, then tight coupling between provider and consumer software would be a serious concern. The last thing a business wants is to leverage mashups for a core business purpose, only to find that they fail capriciously depending upon the whims of the creators of the underlying Services.

Mashups that meet business needs, therefore, will require SOA, and the SOA infrastructure necessary to guarantee loose coupling. Without that loose coupling, mashups are little more than toys from the enterprise perspective.

Question #2 approaches the issue from the opposite direction. From the business perspective, mashups represent a new class of user-centric capabilities that enable a broad range of new uses for software, including the collaborative, social capabilities at the core of Web 2.0. In fact, ZapThink frequently discusses the Web Services tipping point, where the focus on Services will shift from providers to consumers of Services. After the tipping point, enterprises will care just as much about how they use Services as they do about creating and exposing Services for consumption.

What makes a Service useful is not simply its machine-processable interfaces, but also interfaces that humans can use. Furthermore, Services must be composable not only in theory, but in practice. Clearly, it doesn’t matter how useful a SOBA appears to be if the consumers of that SOBA prevent users from taking advantage of the flexibility that Service-orienting the application promised in the first place. It now seems that we’re approaching (or even passing) that tipping point as Service consumers with rich interfaces increasingly enable mashups and other collaborative capabilities of software.

But that doesn’t mean that we’re ready for enterprise mashups, however, or even that mashups will be the appropriate context for user interaction with SOBAs. In fact, there are several mitigating forces that may limit the “SOBA as enterprise mashup” equation:

While it’s true that SOBAs require rich user interface functionality to ensure their promised flexibility, Rich Internet Applications (RIAs) built with Web 2.0 technologies like AJAX are only one set of interface options. Desktop applications ranging from spreadsheets to accounting packages will also be likely SOBA consumers. Also, since SOBAs enable Service-oriented processes, many SOBA consumers may simply be other SOBAs. Therefore, mashups will be at most only a part of the SOBA consumer story.
Today’s mashups largely reside within the world of techies. While mashup creators don’t need the technical chops of, say, a seasoned Java developer, creating mashups is still out of reach of most businesspeople, even reasonably technically savvy ones. Of course, this situation will likely change as mashup tools mature.
Most importantly, SOBAs require governance. Clearly, no business would risk allowing any of its employees to assemble and reassemble business processes willy nilly, with no controls in place to ensure that the resulting SOBAs followed corporate policies. Implementing identity and access management for the SOBAs is only the first step in providing the necessary governance. The problem is, today’s mashups are inherently ungoverned — that’s what makes them so appealing to techies. The bottom line is, the more governed an enterprise mashup becomes, the less like a Web 2.0-style mashup it’ll be.

The Next Generation of SOBA Interfaces
The fact that mashups and SOBAs come from two different worlds with disparate contexts doesn’t mean that there isn’t some middle ground. For insight into how the exciting world of mashups should enhance the comparatively dull world of SOBAs, consider the various users of SOBAs and how they should be able to work within the enterprise environment. As SOBAs continue to gain prominence in the enterprise, many business users will do little more than consume the capabilities of the SOBA. The classic example of a high-value SOBA is in a call center, where the call center reps regularly interact with multiple systems in order to do their day-to-day activities. Through the use of SOBAs, they can now interact with one coherent user interface that composes Services into a single view that provides all the visibility and control they require, where before their life was filled with complex, error-prone “swivel chair” integration of disparate, legacy application interfaces.

Users on the level of the call center rep, however, are not where the primary value of the SOBA comes through. After all, you’re probably offshoring that rep anyway. On the contrary, it’s the hands of the knowledge worker that can wring the most value out of SOBAs. These users not only consume the functionality of the SOBA, but also have some measure of responsibility over configuring the SOBAs as well, depending upon their role within the organization.

Remember, configuration is how the business updates a SOBA, once the Services that feed the SOBA are in place. SOBA configuration includes any change the business user would like to make, from the simplest adjustment of parameters to the most complex reorganization of business-critical processes. The user interface this knowledge worker uses, therefore, must leverage the combination of SOA, which enables the metadata-driven declarative nature of SOBAs, and a comprehensive governance framework that guarantees that nobody will make changes to SOBAs that violate corporate policies. It will not be sufficient for the user interface to offer nothing more than the call center rep’s screens — true SOBA interfaces must also include all the reconfiguration capabilities that the business requires from its applications. SOBAs with such interfaces are the true enterprise mashup — governed, yes, but nevertheless putting great power into the hands of the business.

The ZapThink Take
ZapThink’s vision of the enterprise mashup, therefore, requires a special kind of business user: a knowledge worker who is adept at leveraging the power of SOBAs to meet ever-changing business needs. Indeed, while some knowledge workers have the technical capabilities necessary to construct today’s mashups, the true promise of SOBAs depends upon user interfaces sophisticated enough for a broader business audience to use. Fortunately, enterprises already have knowledge workers at this level: people who are proficient with Microsoft Excel. Not only does Excel make a powerful SOBA consumer in its own right, but the technical skill people need to get value out of an application like Excel is the level SOBA tools vendors should target when building SOBA interface applications. Few such tools exist today, but the writing is on the wall: the enterprise mashup is the future of the SOBA consumer.