A Mashable Web Services API is Sticky, Contagious, and Attention-grabbing
August 3, 2007 at 9:31 am | In Composite Applications, Enterprise 2.0, Mashups, Web 2.0, portals | No CommentsI’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 | In Composite Applications, Mashups, Web 2.0 | No CommentsIn 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 | In Composite Applications, Mashups, Web 2.0, portals | 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.
Mashed Portals
April 30, 2007 at 1:45 pm | In Web 2.0, portals | 1 Comment<homer>Mmmmm …. garlic mashed portals … </homer>
I received a question from a client about whether mashups are the same thing as portals. I’ve heard other analyst firms say mashups are the next version of portals too, so I wanted to clear up some confusion. They certainly have some aspects in common and are branches from the same conceptual tree, but they are not exactly the same.
Here is where they are related: they are both methods for building composite applications. Composite applications are apps made up of existing parts. Portals let you create composite applications using a screen real-estate metaphor by marrying a set of back-end integration and front-end delivery capabilities that provide information in context, personalized to a user’s role and needs. Other ways to build composite apps include business process management (a flow chart metaphor) and SOA development tools (a wiring diagram metaphor).
Here is where they differ: enterprise portals are defined by a set of infrastructure that is used to deliver contextual websites. Mashups don’t rely on that concept of personalization (although I’m sure you could put it in there, but it’s not core to the idea), and they don’t have the set of integration into enterprise applications. Another difference is that mashups can overlay information where portals isolate different information in their own square boxes. The mashups I find most exciting are those where the components are mashed up in the same window, like with Zillow or other apps that lay out information on a map. There are mashups that don’t rely on blending information from multiple sources in the same window, but those just seem to have the portal UI without the portal infrastructure so they don’t thrill me as much.
All these methods for building composite applications can be useful. But I’d never tell a client that has gotten into mashups that now they don’t need a portal product. What if they want to provide personalized access with common infrastructure to get at multiple enterprise applications? I don’t see a product I’d call a mashup tool doing that anytime soon. And I wouldn’t tell a client that has a portal product that it can handle all their mashup needs. A portal product isn’t going to help you lay out your sales data onto a map.
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.