3 Things I Forgot the Mention in the Mashup Article

If you spotted my article, “Enterprise mashups meet SOA,” in this week’s InfoWorld you may have noted some of the core ideas, such as:

“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.”

And

“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.”

However, there are a few things I should have added to the article, and one of the great things about having a blog is commentary on my own content after the fact. So, here they are:

1. You really need to solve a specific problem when thinking mashups and SOA…such as mashing up accounting services with logistics interfaces to determine the best routes for sales on an ongoing basis. Complex mashups should be avoided, perhaps approach those as complex composites.

2. As you inventory your SOA components, you need to think “what’s mashable,” or how the technology will work and play well together. Many assume this will be the case, perhaps because the use of “standards.” However, more often than not the technology is incompatible and thus not “mashable.” I have a client who is dealing with this now.

3. Mashups unto themselves have the potential to become sources for other mashups, or services. Thus, this notion should be considered within the design.