tigretigre.com

(Note: as I said in a previous post, the social networking aspect is merely a special case of a larger issue, but it is the hot topic of the moment so I will speak only of this concrete case for now. The priniciples are very easy to generalize.)

So what I'm plotting is an SOA approach to social networking, with what is referred to here as "entity aggregation". The basic idea is each account at a social network is essentially a service (even if no service API is currently available, it can certainly be turned into a service, even if it comes down to screen-scraping). Each service gets its representation mapped to a standard entity representation, and an entity aggregator determines which entities are duplicated in some form or fashion across services and ties them together.

So far as I can tell, nobody is quite approaching it like this. There are people who are creating all-encompassing portals, but taking it the SOA level means no one person controls the process. There are five distinct levels at which anyone could become a player:

1. Social network - may or may not offer an API for developers, but this is where people have their actual accounts and the data really lives.
2. Network-specific service provider - could be someone independent from the actual social network, especially if the network doesn't create a service on their own or their service is very deficient. Terms of Service might get in the way of indie players here, but that doesn't mean it won't happen, or that networks would be wise to enforce TOS against such.
3. Aggregator service provider - They have to figure out which features across networks are useful to aggregate, and come up with (or copy) a good aggregate representation to which mappings must be created. An ideal aggregator will provide a means for selecting which mapped network services to use.
4. Mapping service provider - They connect the network services to the aggregators, by translating between the two. They have to make themselves known to the aggregators to be used, and they have to keep up with what the network service providers offer so that they can offer more to the aggregators, so they are highly dependent in both directions. Aggregator providers will probably typically need to jump-start this level with a few mappings of their own before their aggregator has enough life to motivate other players to enter here.
5. User interface providers - Not necessarily married to the aggregator provider, especially since the interface could be a Web page or it could be a desktop or mobile app. And if mulitple providers present the same aggregation service, the interface provider could hook up to any one. (I won't even get into the meta-level at which multiple aggregator providers could have their services aggregated.)

This eco-system is not a formula for any one player to make a fortune. It is a robust topology that allows many players to offer competitive products that can succeed or fail on either technical or economic terms. It can allow constant evolution at every level as competition at any one level can push changes in both directions. The key to success therefore is a means of passing rewards along. (While I will treat this mostly in economic terms, there are other ways to conceive of such rewards which I will leave as an exercise to the reader.) I think the individual tasks are broken down sufficiently to make the barriers to entry low enough that a market-based approach could function efficiently, as long as the reward mechanism cannot be held hostage at any one level. Service providers can charge micro-fees along the way (yes, I went there, and maybe it's time you did too) so the end-user will need some way of recognizing and, as I alluded to earlier, choosing the set of costs associated with a given aggregated task.

So that's the big idea. Now to figure out a logical set of steps to getting there...