It’s important to remember that there is a huge resource being created on the Web these days in terms of both services and content. This includes access to SaaS applications (that are better than their enterprise-bound counterparts), service marketplaces (such as StrikeIron), and even mash-able applications that you can mix and match with other Web 2.0 applications / APIs / services or enterprise applications / services to quickly solve business problems.

However, having such a resource available for the price of a broad-band connection does not mean you'll be able to leverage it properly. Indeed, it's going to take some time before your enterprise is prepared to leverage mashups beyond the browser.

The best approach to SOA / mashup synergy is to design and deploy the first-generation SOA with the mashups in mind. In other words, make your enterprises systems "exposable" to services or applications outside of your firewall, or, "able to consume" the same services or applications. This is harder than it sounds, and chances are your current systems can’t see outside of their own operating systems, if not their firewalls.

Truth-be-told, most SOAs, if built correctly, will have the side benefit of being able to leverage the Web-based services and content as resources for mashups, but you need to design for that capability in order to make your infrastructure most effective. This means cataloging and testing services you don't own, attempting to mashup systems inside and outside of your firewalls, and making sure your security planning considers this notion as well. Many who don't plan for this scenario will be stuck with an enterprise that can't see the new Web. I think those enterprises will have a huge strategic disadvantage in the years to come.

What do you need to do to prepare for mashups? It’s a matter of addressing the following areas: Requirements, Design, Governance, Security, Deployment, and Testing. In essence, these are the core architectural activities that are required to get you to the Promised Land of mashups, and these are in addition to your existing activities when you create a SOA.

Requirements for mashups are needed to understand your own issues that are local to your enterprise. A common mistake many make is to “manage-by-magazine,” and assume that all of the cool stuff that works for other enterprises will be the right fit for yours. Truth be told, notions such as mashups or SOA, in general, have variations in value depending upon the enterprise. Consider both the business drivers and the state of the current architecture. Key questions include: What mashups will be valuable to my enterprise? How much change needs to occur to get me there?

Design for mashups refers to the process of figuring out how the systems should be configured, and how enabling technology and standards are applied to provide the best platform for mashups and the best value for the underlying SOA. Key questions here are: What interfaces will I expose and how? How will I handle scalability? How will I approach both visual and non-visual 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 for mashups considers the role of mashups and how they are managed. Given that mashup are made up of services, and may indeed become services themselves, the organization must now manage these services across the entire lifecycle, from inception through analysis, design, construction, testing, deployment and production execution, as with any service or process contained within a SOA. Thus, at each stage, certain rules or policies must be carried out. This means selecting, building, and maintaining a registry, repository, policy enforcement, and governance rules engine that is mashup-aware. Moreover, mashups, albeit quick and dirty in some instances, may need life-cycle management as well.

Security for mashups is critical, considering that you’re looking to leverage interfaces, content, and services you did not create nor do on your own. As such, you could find that your innocent-looking AJAX interface that you mash up with your customer data is actually sending your customer data to some remote server, and thus compromising your customer list and your business. Care must be taken to implement a well-thought-out and systemic security policy and technology layer that will protect the value of your mashup platform. This should mesh with your SOA security, or become an extension to it.

Deployment for mashups means that you’ve selected the proper enabling technology and standards. Clearly, AJAX is popular for interfaces, but is not always a fit for all enterprises. Moreover, how will the technology link to the governance and security plans? What are the key products you’ll leverage to support mashups within your SOA, and how will they be linked to the enabling technology solution already implemented within your SOA?

Testing for mashups means that you consider all sorts of patterns of use and create a test plan to reflect them. Care must be taken to ensure that your SOA and external “mashable” components are able to work and 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, and you must consider the technology employed as well. In essence, you’re testing a development platform with all of its supporting components.