I just read a really good, short Fast Company article that mythbusts five popularly held ideas about mashups.
It's so short, I wasn't even going to blog about it, but then I kept going, "That's interesting. I didn't realize that," and decided you might find it educational as well. (I also remember I'm not quite 5'2" in my tennis shoes, so who am I to cast short stones?)
In particular, I was pleased to see the article take on these misconceptions: Anyone can build a mashup. The article notes that even though business users are getting more tech savvy, they still aren't developers. "In non-technical terms, IT builds the mashup lab and the business gets to play mashup mad scientist without worrying about blowing up the building."
Personally, I'm starting to wonder if business users are actually getting savvier or if the technology's just getting easier. Let's face it: Most people never got the hang of HTML-but they didn't need to because of blogging software. Then again, I could just be aging into a .... hey! Get off my lawn, you darn kids! That's it! Where's my cane?
It will be interesting to see how and if mashups actually do affect IT in any substantial way. Dan Woods, chief technology officer and founder of Evolved Media, wrote an interesting piece on this topic for Forbes awhile back. He cautioned, and rightly so, frustrating users by expecting too much:
"One of the reasons some mash-up efforts sputter is that too much is expected of users. While they can use mash-up technology to create solutions, they cannot create new services, troubleshoot problems or make things scale when a winning solution has been created. Mash ups create a new kind of partnership, one in which the special expertise of the users and of the IT staff is more properly separated and leveraged."
"New kind of partnership" sounds good, but try telling it to the IT staffer who had to remove Elf Bowling spyware - for the fifth season in a row - from a business user's PC.
Mashups Require SOA. I thought mashups would require SOA, or, if not SOA per se, then Web services. But, no. You can do mashups without SOA. It's telling, however, that the article does add this cautionary note:
"Sure, mashups put a business face on SOA, so to speak. And it's easier for you to create mashups if there are a lot of mashable' (i.e. SOA-based) data sources."
Obviously, SOA and mashups are two ideas that go well together, particularly for smaller data integration projects. But it's nice to know SOA isn't required.
Even mashups can be silos. Hmmm. Didn't know that, did you? I suppose they don't mean silos in the traditional sense, but if a mashup can't be used and collaborated on, then for practical purposes, it's as siloed as that legacy server chillin' in the server room during the big Web 2.0 party.
Ideally, these mashups should be reusable. Gartner's Anthony Bradley calls it "The MacGyver Principle" and explains that, like MacGyver, developers should be able to, with a few tweaks, use whatever mashups resources are on hand to solve the problem.
The Forbes article notes the easy fix for this is a registry/repository. There are also mashup servers, if you're so inclined, and IBM this year unveiled a 'multi-tiered mashup portfolio,' whatever that means.
Thanks, btw, to Joe McKendrick for pointing out the Fast Company article.