The line is blurring between the enterprise and the Web. Mashups live on that porous perimeter, offering the reusability of an SOA plus very rapid development using prebuilt services outside the firewall. Soon, we may live in a world where it’s difficult to tell where the enterprise stops and the Web begins. It’s scary — and exciting at the same time.
But just having the ability to create mashups doesn’t mean they’ll be valuable. You need to properly provision and manage the services available for mashups and understand their purpose and place in an SOA. (See also "Mashup platform vendors.")
The task is threefold. First, you must prepare existing infrastructure to support mashups. Second, you need to understand your requirements. And third, you’ve got to wrap your head around the potential value that mashups can and cannot bring.
Although mashups originate with Web 2.0, which epitomizes development on the fly, mashups in the enterprise require preparation. You need to build and support an SOA that’s “mashable” with services and content, as well as with APIs that are both local and remote to the enterprise. Among other things, that means existing enterprise application services must be able to access Internet-hosted services safely.
Combining, creating, and cohabiting
Google Maps mashups, which hook the wildly popular mapping service to some database that includes street addresses, have become almost cliché. Yet this type of solution is actually a perfect demonstration of the value of the mashup notion: Somebody has a need, takes a few days to create the mashup solution, and there you have it.
More complex mashups approach composite applications (those that are made up of many services), an advanced SOA concept. For instance, you could mash up a customer database with marketing metrics, then mash up the results even further with sales forecast processes. You own and maintain some of the information and services; some are accessible over the Internet.
So, who’s providing these services? SaaS (software as a service) players such as Salesforce.com seem to have the largest number of enterprise-class services, with service marketplaces such as StrikeIron in the mix, as well as services from vertical sites such as finance, retail, and health care. All have provisioned services, data, and content that are consumable over the Web.
Even more complex solutions are possible — such as mashups that become sophisticated business processes, applications, or sets of services in themselves. You can see where this is going: full-blown services, processes, and composites that span from your new SOA to hundreds of Web-based services hosted by SaaS players, commercial Internet properties such as Google, and vertical market exchanges.
The big Web players clearly have bought into this vision and are now working on the mother of all SOAs in support of emerging enterprise SOAs and mashups. Google may have been first, but Microsoft, Yahoo, and others are close behind.
Breaking out and mashing up
Although enterprise mashups are new, their solution patterns are already emerging. Broadly speaking, there are really two types of mashups: visual and nonvisual.
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.
The design for mashups involves figuring out how the systems should be configured and which enabling technology and standards should be applied to provide the best SOA-based mashup platform. Key questions here: What interfaces should I expose and how? How will I handle scalability? How will I approach both visual and nonvisual mashups? How will I leverage services and interfaces delivered over the Web? How will I manage the exposure of my interfaces and services to others on the Web, if needed?
Governance — the creation and enforcement of design time and runtime policies — is tricky business for mashups. Given that mashups are made up of services and may indeed become services themselves, you need to manage these services across the entire lifecycle, as with any service or process contained in an SOA. Among other things, this means selecting, building, and maintaining a mashup-aware registry/repository. However, although mashups need to be managed, you should avoid overloading them with policies and procedures, or you’ll discourage developers from creating them.
Mashup security is critical, considering that you’re looking to leverage interfaces, content, and services you neither created nor own. No one wants to discover that an innocent-looking AJAX mashup is actually sending customer data to some remote server and compromising the business. Care must be taken to implement security policies and technology layers that will protect the value of the mashup platform. This should mesh with your SOA security or become an extension to it.
To deploy mashups properly, you need to select the proper enabling technology and standards. Clearly, AJAX is popular for interfaces, but there’s also Adobe Flex — it all depends on what you think you’ll need to build and what your developers are up to speed on. Moreover, consider how the technologies you choose will link to governance and security. What are the key products you’ll leverage to support mashups within your SOA, and how will they be linked to the enabling technology solutions already implemented?
Consider all sorts of usage patterns and create a test plan that reflects them. Care must be taken to ensure that your SOA and external “mashable” components can play well together, and that the enabling technology and standards are working up to expectations. The test plan should be linked with design, governance, and security. In essence, you’re testing a development platform with all of its supporting components.
Where to from here?
Mashups and SOA are part of the same continuum. By linking the new components of Web 2.0 with our own sets of information and services, mashups provide a quick and easy way to solve many of today’s simple business problems — and should scale nicely to solve more complex and far-reaching problems in the future. They make the value of an SOA much more visible over a much shorter term.
As with any new concept, each enterprise must localize the concept for its own needs. One size does not fit all. But the beauty of both an SOA and a mashup is that, with the right foundation, they can be configured to meet almost any set of business requirements — and can be reshuffled quickly when those requirements change.