One concept I try and use in understanding the new world of feeds, open APIs and brittle but powerful web services, is what I call Feed/Portal duality. That’s a play on Wave/Particle duality (please excuse the spoon-feeding).
Why do I think its important to hold two slightly contradictory notions in our head as we offer web services and so on? Because we’re creating gardens without walls- we have to make people want to hang around in them, rather than being forced to.
How many people read my blog? I have no idea. I can look at page views, and or or numbers of bloglines subscribers, or look at alexa, but the point stands that there are two radically different mechanisms at hand for touching my content-one is my url, one is my feed. Oh yeah- then there is feedblitz, for people that prefer newsletter modes.
As many of you are aware, RedMonk.com is completely lame from a portal stickiness standpoint, which is why we’re working on a redesign right now. But our feeds rock, because the content is rich. So when it comes to Feed/Portal duality we’re definitelty skewed to Feed.
Intriguingly – Google is considerably stronger on Portal than feed/APIs. That is – people go to Google to do things. Yahoo would appear to have more APIs and feed-based services available, but hasn’t found a way to succesfullly turn its Feediness to dollars.
This morning I read VC Fred Wilson on The Bad Script Trip. While Fred has made his blog far stickier from a portal point of view, by adding a bunch of services into the mix using nice powerful brittle tools, he got into trouble when the 130 small pieces, loosely joined, started acting up. So by concentrating on Portality at the expense of feediness, Fred “broke” his own web presence. Is he going to stop adding all the new cool widgets to the site because of recent performance issues? No – he is coming down on the side of Portality.
Have I got to the point yet? Getting there. So while Cal Henderson’s architecture for Flickr undoubtedly scales, one of the things that makes it scale so well is the offline client the user runs on their machine, to upload photos.
There is a great piece on Salesforce Heretic (hat tip SalesForceWatch.com) today about the construction of salesforce’s APIs.
So what are the feed/portal duality implications of the fact “over 40% of Salesforce.com’s traffic is Web Services“, according to salesforce.com CTO Chris Fry?
First off, read the articles, and then try and internalise the challenge of developing services for salesforce.com, which have to scale both in the portal, but also in the cloud. And finally understand why Chris knows that join functionality is so important– its good for user/developers, because they need it, but also for salesforce itself, because adding the functionality will reduce strain on its resources.
People building web presences, applications, and so on will increasingly need to think about Feed/Portal duality when they build out their infrastructure. Its just as important, if not more so, that the APIs scale, than the site does. We need to think about Portality and feediness, or whatever you want to call these things. Suffice to say there are two different axes of richness to consider.
One way to ensure scalability in the feed dimension is open data. Allow a developer to suck a dataset once a day, or whatever, that they then hit, rather than hitting your back end directly ever time, and you’ll have more scale.
Oh dear- I seem to be describing a three tier architecture. So much for feed/portal duality… Likesay, there is nothing new in IT. But the more open your data is, the less you need to worry about the resources required to scale it effectively – that might be a useful insight.
Why should enterprises care about feed/portal duality? One simple reason: related design patterns are going to dictate service oriented architecture (SOA) choices. What does scale mean in SOA? Are you processing locally or externally? There are two related focuses: scaling up and scaling up for consumabllity, scaling out and scaling out for consumability.
Would love some feedback on these ideas, if you have any. Thanks.
—————————————————————————————
disclaimer: I have no financial relationship with salesforce.com
Dan Davies Brackett says:
July 31, 2006 at 7:38 pm
The ‘Enterprise’ content frameworks of the past 5 years or so have concentrated on what you call Portality, I think; the Feediness aspect is what distinguishes a SOA from a non-SOA. Isn’t it? I mean, what is it that Archtectures that aren’t Oriented toward Services oriented toward?
I think you’re quite right to consider Feediness and Portality as different ends towards which you can optimize, and I think there’s good comparisons to be drawn between those two and the features/ease-of-use duality. That is, if you’re not very careful then adding more of one usually takes some away from the other and quality in design can be expressed as the extent to which your site/program/suite/presence/whatever exhibits both.
Christopher Mahan says:
August 1, 2006 at 2:26 am
A portal is already assembled for consumption, or, “ready to be experienced” as Tim Bray would say.
A feed is a data source that is not rendered but is prefiltered, more like a query result if you will.
A true API in my opinion would allow a consumer out there to “set the conditionals” on the feed/consumables and get just that. For example, if I could send a “query” through an API that said: when was the last update, and the response was 18 minutes ago, and my consumer service knew that it had last fetched the info 41 minutes ago, it could then ask the API: give me everything between 18 minutes ago and 41 minutes ago. If there had been no new info the last 41 minutes, I would have not downloaded anything from the site.
Now this API could then also be used by the software building the portal.
The feed is a dumb API. The feed needs to grow legs.
Bill Higgins says:
August 1, 2006 at 10:38 am
The feed/portal duality starts to converge when you move towards an Ajax/REST architecture. I’ve been meaning to write about this on my blog.
Richard G Brown says:
August 1, 2006 at 9:23 pm
Being able to perform a join across multiple queryable web services would be extraordinarily neat.
http://gendal.blogspot.com/2006/08/feeds-vs-reads.html