COMMENT ON THIS ARTICLE
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.
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.
With the rediscovery of AJAX (Asynchronous JavaScript and XML) technology and the mushrooming popularity of rich Internet applications, we now have the ability to create mashups that quickly solve business problems by using the standard dynamic interfaces that front services. Mashups provide powerful ways to take existing applications and services and create something even more useful for business.
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 healthcare. 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.
Although enterprise mashups are new, their solution patterns are already emerging. Broadly speaking, there are really two types of mashups: visual and non-visual.
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.
Non-visual 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 insurance numbers with a credit check service. Each non-visual mashup may send exceptions off to another stream or queue for processing later, or perhaps to other mashups.
More complex and valuable non-visual 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, non-visual mashups will be more valuable to business in the long run, especially in an SOA environment. For one thing, non-visual 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 non-visual.
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 catalogue 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.
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
