With the advent of rich internet applications and extensible interfaces such as AJAX, we now have the ability to quickly create mashups to solve specific business problems using standard dynamic interfaces that front services. Mashups provide powerful ways to take existing applications and services, and create something even more useful for business.
We could say that the lines between the enterprise and the Web are blurring…first blurred at the content or information levels with the early mashups, and now at the service and process levels as well. We could find that we soon live in a world where it’s difficult to determine where the enterprise stops and the Web begins. Now that’s scary and exciting at the same time.
While the best example of a mashup is the old and overused Google Maps-meets-some address-databases, this type of mashup solution really highlights the value of the notion. Somebody has a need, takes a few days to create the mashup to solve the problem, and there you have it.
Moving on from there, you have more complex mashups that approach the concept of composite applications, or, applications that are made up of many services…an advanced SOA concept. For instance, mashing up a customer database, with marketing metrics, and then mashing up the results even further with your sales forecast processes. Some of the information and services you own and maintain, perhaps managed from your SOA, and some of which are accessible over the Internet.
Preparing for Mashups
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, 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 will be stuck with an enterprise that can’t see the new Web, and I think those enterprises will have a huge strategic disadvantage in the years to come.
So, 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 core architectural activities that are required to get you to the Promised Land of mashups on top of 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 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 lifecycle 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 mashup 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 insure 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, as well as consider the technology employed. In essence, you’re testing a development platform with all of its supporting components.
Mashup are an emerging notion, and are clearly merging together with SOA. They provide value by linking the new components of Web 2.0 with our own sets of information and services. What’s more, they provide a quick and easy way to solve many of today’s rudimentary business problems, and should be able to solve more complex and far reaching problems in the future. They make the value of both the emerging Web, and SOA, much more visible and shorter term.
However, like any new concept, each enterprise must consider the overall value in context of their own business issues, and make sure they localize the concept for their own needs and requirements. First, consider the infrastructure needed to support mashups, typically a SOA, as well as the costs and benefits of both the underlying investment, and the value of the solutions that mashups may bring.
