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.