Paul Sumner Downey explores an interesting question on his blog today: What's the difference between a mashup and integration?

Honestly, I'd never consider this an either/or question -- I just assumed you could use mashups for integration. (I suspect part of Downey's point may be mashups can be a better option than an integration project, but I'll let you decide for yourself.)

Downey's bio notes he is "acting as BT's chief web services architect." The BT Group -- better known perhaps as British Telecommunications -- is well known for its work with service-oriented architecture, though I should add this post is from Downey's personal blog.

Downey distinguishes between the two with a list of humorous questions, including asking if you need "to engage in a dialog with some jobsworth" to touch the data, if the data can be used safely in a browser "without worrying about accidentally firing nuclear missiles," and whether or not the project is fun.

The overall tone of the questions implies if your project is clean, straightforward, secure and fun, it's a mashup. On the other hand, if it's a cumbersome, unnecessarily complicated, bureaucratic effort, then it's an integration. Downey offers his condolences:

"Bad luck. It's going to be expensive, and certainly not pretty."

David Coleman of Collaborative Strategies gave a similar working guideline during last year's Enterprise 2.0. Coleman reportedly said a mashup is something that can be working in less than a day; anything that takes longer is an integration project.

But not everyone cuts such a clear distinction.

Panelist Ajay Gandhi of BEA offered a different take during the same panel, pointing out enterprise mashups are more complex than consumer internet mashups, because enterprise mashups must integrate with corporate data and include security and control.

(For a more detailed discussion of what constitutes an enterprise mashup and the challenges the concept faces, check out this post from ZDNet's Enterprise Web 2.0 blog, written by Dion Hinchcliffe.)

Business Process Management consultant and blogger Sandy Kemsley told IT Business Edge last year she believes mashups have a lot to offer complex integration projects

:

"The whole set of lightweight integration techniques, which enable Web-based integrations, or 'mashups,' is key. Many integration projects -- and I've been involved in a lot over the past 15 years -- involved too much code and too much time, even with today's tools. Web services, by which I mean those built on the WS-* standards, are considered too complex and time-consuming to develop by many people, who are using techniques like REST and JSON to create mashups."

The latest twist on this topic is debating the difference between SOA and mashups.

Just this week, Kemsley posted about a discussion at the FASTforward '08 conference on enterprise mashups. The presenters distinguished between composite applications in a SOA as being created by IT, whereas mashups are created by users. Kemsley disagreed:

"SOA is really just the services layer, which can be consumed by a user-created application just as easily as an IT-created application. The true comparison would be between a composite application development environment and a mashup creation environment, and I think that the line between those is becoming increasingly indistinct."

I think Keith Harrison-Broninski, ebizQ's IT Directions columnist, does the best job of explaining how all three concepts tie together. Using a series of graphs, Harrison-Broninski shows how mashups will leverage back-end services from SOA to provide integration within the firewall. For businesses, this will bring additional control to the process, both in terms of security and using the data.

I'm sure this is just the beginning of a long conversation about how mashups, integration and SOA relate. Don't be turned off -- this isn't about definition, but rather it's about exploring how this emerging Web 2.0 tool will fit in with the rest of your architecture. Stay tuned.