A Mashable Web Services API is Sticky, Contagious, and Attention-grabbing
August 3, 2007 at 9:31 am | Posted in Composite Applications, Enterprise 2.0, Mashups, portals, Web 2.0 | 1 CommentI’m hoping that my recent postings on mashups (see here and here) have served to point out that 1) mashups are easier to define as an attitude and “feel” than a strict technological definition and 2) that mashups are not something new, although the attention to the quick&easy end of the composite application development scale is a good thing
I’d like to now add a #3 to that list: 3) that a killer web services API is sticky, contagious, and gets the creator/hoster a lot of good attention.
See this example from the EMC Documentum 6 enterprise content management platform. I had a few conversations with Documentum about the importance of web services APIs and what kinds of things and level of granularity they should operate at. Those conversations may have had a positive effect because Documentum subsequently released their first set of web services APIs, which I thought fit the mold of what customers were looking for. With version 6 they have pushed this further and added a development tool:
– Documentum Enterprise Content Services: a new, Web Services-based API that simplifies development and integration with ready-to-use enterprise content services for easy integration with other enterprise applications within a Service Oriented Architecture (SOA). EMC’s new services interface was redesigned to eliminate Documentum specific methods and terminology and replace it with a vendor-neutral framework for working with content management functionality. These services enable developers with no Documentum experience to build ECM applications quickly and easily. This open, generic approach eliminates the “knowledge barriers” that get in the way of incorporating ECM functionality in all enterprise applications and business processes that deal with content
– Documentum Composer: provides a standardized environment for development and configuration tools that reduce the need for coding and facilitates composition of applications with reusable elements
I’m hoping that as vendors realize how powerful Google Maps has become in part because of the great API that has encouraged thousands of websites to create mashups that depend on it, they will also want to provide “mashable” APIs. “We want to be the Google Maps API of the xxx industry” is shorthand for saying that a vendor (or enterprise with B2B channels) wants to make available a mashable web service that is:
- Sticky: Once a website incorporates a web services API it is unlikely to remove it for quite a long time.
- Contagious: Every website incorporating the API acts as an ambassador to visitors that get ideas about how it could be used in their website. To quote an obnoxious 70′s shampoo commercial “And they’ll tell two friends, and so on, and so on, and so on …”
- Good attention: When the UI being integrated is branded or the source somehow easily recognizable, it acts as an advertisement for the infrastructure underneath.
Mashup is a State of Mind
August 2, 2007 at 4:06 pm | Posted in Composite Applications, Mashups, Web 2.0 | Leave a commentIn my previous posting on mashups, I described how the origins of mashups (quick combination of parts that weren’t meant to go together) don’t match the most common apps called mashups (Google Maps mashups or “mapsups”). I then wrote “So, if the most common example of mashups doesn’t fit the narrative of the mashup and its origins, does that mean mapsups aren’t mashups? Or that the word has evolved and, if so, what does it mean now?”
That day an article by Ben Worthen appeared in the Wall St. Journal (“‘Mashups’ Sew Data Together”, 7/31/07, B4). Of course the screen shot was a mapsup (journalists, please check out this mashup of Sudoku with numbers from flickr – a non-mapping mashup – to validate this isn’t a one-trick concept). But the non-technical, business-related focus of the WSJ would certainly force them to give a good definition that is declarative, binary, and unique right? Think again.
“Mashups essentially are a way to take data trapped in separate applications and combine them into new, hybrid applications”. Just “a” way – if there are others then what’s the difference? And portals don’t fit this definition? Is it that the pieces being combined can be placed on top of each other or aggregated versus side-by-side like in a portal? But Facebook doesn’t fit that definition. Does it have to use Web 2.0 rich internet application technologies like Ajax?
Maybe it’s a new subcategory. Is this an implementation of service oriented architecture (which states apps from piece parts like mashups as an end goal) or an alternate mechanism? Is this a type of composite application? But still, it has to be differentiated from other types.
And talk about giving a non-unique definition, a few paragraphs later the WSJ quotes another definition “A mashup ‘combines data from disparate sources into something that is more valuable than the sum of its parts’”. If it’s really combining data you’re after, don’t business intelligence (BI) tools do that? Or dashboards? Or are those mashups too?
I can come to only one conclusion: Mashup is a state of mind. It’s a way of doing things, not a new technology. Just like Web 2.0 is more of an attitude (be more social and networked, emphasize informal networks over corporate heirarchy, use the latest set of technology on the web, etc.) that can be applied to new and old tools, mashup is an attitude that says there are a lot of great things you can do quickly by ignoring detailed integration and just slamming different pieces together. Quick is a relative term – I created a Google mapsup in a few hours with some Javascript coding which may not be “easy” to some, but compared to how long it looks like it would take it’s pretty good. That’s as much a credit to the Google Maps API though as it is to the mashup concept.
If that’s true, then it isn’t appropriate to say “Mashups do xxx”. One should say “doing things in a mashup way enables you to do xxx”. But they won’t – the term has taken on a life of its own. And if it leads to people rediscovering technologies like portals, BI, and dashboards; creating new web-based composite application creation tools like Popfly or Yahoo Pipes; and attaching a new label to aggregated apps like Facebook then that’s fine with me.
Will the Real Mashup Please Stand Up
August 1, 2007 at 3:23 pm | Posted in Composite Applications, Mashups, portals, Web 2.0 | 1 CommentI think I get this whole “mashup” thing, but there’s one part I’m still figuring out: why is a combo made with Google Maps considered a mashup?
To explain my confusion, I’ll start with some history. The term mashup is derived from the music world where it describes a song created by combining (generally overlaying) parts of other songs. I’d describe it as a “frankensong”. The term “mash” has implications of a forceful, less-than-orderly combination of things. If you check the dictionary, you’ll see definitions and synonyms for “mash” that include words like “violence”, “pounding”, “crush”, and (yikes!) “pulpy mass”. The implication is that the musical combination is supposed to be quirky, creative, and charmingly rough. The outcome should be “new” – a different vibe, emotion, genre. It should be an unintentional use of the pieces involved.
I can see how a messy Facebook page, with all sorts of seemingly disconnected content and media crammed next to each other to create a new and charming mosaic of someone’s life, would fit the mashup concept.
But take a look at everyone’s favorite web-based example of mashups: Google Maps. A client recently told me mashups should really be called “mapsups” because Google Maps seems to be the only example anyone can give! In fact, according to ProgrammableWeb, Google Maps accounts for 50% of all mashup API use. John Musser’s Mashup Feed shows 54% of examples leveraging Google Maps.
But are they mashups?
Google provides a mapping API that is used to provide geographic visualization. It’s not unintentional or hijacking something for an unintended use. It’s just an API. This is what it is for. It is no different than calling out to a charting API and, indeed, there have been visualization libraries for a long time for bar charts and geographic mapping (Microsoft MapPoint comes to mind). Maybe it seemed like a clever type of repurposing and combinatorial innovation to the first few people that saw mapsups, but they may have been uninformed about the code-calls-API underpinnings.
So, if the most common example of mashups doesn’t fit the narrative of the mashup and its origins, does that mean mapsups aren’t mashups? Or that the word has evolved and, if so, what does it mean now? I’ll mull that over a bit and publish my thoughts in another blog entry.
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.
