The Google Maps variety typifies visual mashups. The formula is simple: Take two different resources and create something that is more useful than the sum of its parts. It’s easy to see the value because it’s right there on the screen. Note, however, that visual mashups can also be intra-enterprise, without involving a public service, as in a mashup of sales figures with a graphical enterprise logistics system.

Nonvisual mashups combine two or more services to create an integration point that serves a business process. They may operate behind the scenes and never appear on screen, at least not directly, but they are mashups nonetheless.

Typical examples might include mashing up a stream of customer addresses with an address validation service and mashing up a stream of Social Security numbers with a credit check service. Each nonvisual mashup may send exceptions off to another stream or queue for processing later, or perhaps to other mashups.

More complex and valuable nonvisual mashups can be concocted easily, using either SOA services, externally hosted services, or some combination of the two. Truth be told, while visual mashups are cool and useful, nonvisual mashups will be more valuable to business in the long run, especially in an SOA environment. For one thing, nonvisual mashups can be used by multiple applications, while visual ones mash at the glass.

In the future, we could reach a point where enterprises own a minority of their mashup interfaces and construct SOAs primarily as jumping-off points for mashup solutions, whether visual or nonvisual. It may seem odd to think of an SOA as a mashup platform, but in most organizations, it will increase the value of an SOA tremendously.

Get ready to mash
The huge quantity of mashable services and content now on the Web boggles the mind. But having such resources available for the price of a broadband connection does not mean you’ll be able to leverage it properly. Indeed, it will take some time before enterprises are prepared to leverage mashups beyond the browser.

The best approach is to design and deploy an SOA with mashups in mind. In other words, make your enterprise’s systems exposable to services or applications outside of your firewall, or able to consume those same services or applications. This is harder than it sounds. Chances are your current systems can’t see outside their own operating systems, let alone the firewall.

To leverage Web-based services and content as resources for mashups, you need to catalog and test services you don’t own and attempt to mash up systems inside and outside of the firewall — and make sure your security planning considers this notion as well. An enterprise that can’t see the new Web will have a huge strategic disadvantage in the years to come.

Mashup preparation can be divided into six familiar stages: requirements, design, governance, security, deployment, and testing. These are core architectural bases you must touch if you are to arrive safely in the promised land of mashups on top of an SOA.

Some sort of requirements document for mashups is needed to surface the issues endemic to your enterprise. A common mistake is to “manage by magazine” and assume that all of the cool stuff that works for other enterprises will be right for you. Instead, consider both your unique business drivers and the state of the current architecture. Start thinking about which mashups will be valuable and how much change must occur to get you there.