A quick follow-up to respond to some of the comments on my recent post about Dataslots as a replacement for Web2.0 style API's.
A quick precis is that instead of a service providing an API to manipulate my data (for example eBay might provide an API to list the auctions I have bid on) the service should pass the data (in some agreed format) back into my eBay slot so that it's under my control. I can then make this (along with other appropriate data) available to whatever services I want.
Julien Couvreur asks:
Doesn't this end up being just an API as well?
And of course he's right. There will have to be a bidirectional slot-API to allow the data to be manipulated. But this kind of misses the point. I'm not arguing against API's per-se, I'm arguing against a hegemony of service specific API's to manipulate data that may have other uses. Since it is unlikely that we can get API's harmonized (just look at the problems with API's for implementing weblog access; Does Blogger implement the MetaWeblogAPI even today?) we need another way.
But like I say we will still want API's and services to process this information and with the enhanced data at our disposal we will expect them to do more for us. The key point is that we will be the gatekeepers of this functionality. A service will not be able to arbitrarily limit the value of the data by constraining the API.
I do like the idea of a personal data store, although I tend to think of it in a distributed fashion instead of centralized.
I would disagree on this point. I will argue that most people don't want their information scattered over 1,000 distributed databases (or 100 or 25) but really want it consolidated into one convenient place. The more distributed it is the harder it is to keep track of, to keep it up to date, and the harder it becomes to protect. Whereas having my information in my own personal silo gives me convenience, oversight, and (hopefully) unified access controls for when I want to share it.
In short I want distributed services, but centralized information.
Marco over at Clipperz likes slots so much he's building a company around the idea. Clipperz has a different approach to PAOGA and it will be interesting to see how it develops. I recommend you go take a look at what they're doing.
Terry Donaghe also gets it:
I think the Dataslot idea should be standardized and all organizations that have data about me should share it with me if I chose to want to access it. I'm not sure that I personally would do anything with it, but I can see programs (like the personal agents we all want) that could access and manipulate this sort of stuff.
Absolutely. The heart of the Dataslot concept is that by getting control over my information I enable a range of new opportunities. If you're a high net worth individual you might have a concierge service that learn your needs and help sort out your life but most of us aren't willing to fork over several hundred pounds a month for this kind of thing. If our information was given back to us then low-cost personal agents could learn about us, our needs, and our preferences and help make life smoother and more convenient.
Terry also raises a good point:
Of course, the big problem seems to be one of security. I'd guess marketers and identity fraud folks would LOVE access to all of this information.
Security is a problem. The bigger the honey pot the larger the swarm of bee's. From a PAOGA perspective we have invested a lot of effort in building a platform that delivers security. For example each individuals information is held in our database encrypted with their own personal keys. With the caveat that security is a journey not a destination, we think we're in pretty good shape in this respect.
Where we will be focusing our efforts is on the permission question. How do you make it convenient and (as far as possible) fool-proof for individuals to decide who gets to see subsets of their information? I don't have even a remotely good answer to this question yet but we're working on it because it's a very important question.
But, getting back to the point, YES marketers and other folks want this information. There's really nothing wrong with that if we give informed consent for them to have it. If you want a particular product or service and you trust the supplier it's rarely a problem. Where the system goes wrong is that for so long we have been abused by people we don't trust representing products and services we don't want.
This is why it's so important to give control back to the individual. Once individuals trust they are in charge enterprise can go about mending the fences that it has spent so long trampling over. The end result will be a better deal for everyone (at least for everyone who plays fair).
And this brings me to another point that I shall probably address in a future post but trail here: Enterprises are slowly waking up to the fact that those very expensive CRM databases they are building (and, at great cost, maintaining) are really a huge liability. All that data sloshing around is rotting faster than they can replace it and the bad press when it gets lost, stolen, and exploited can damage that brand you spent so much to acquire.
The answer is to give as much of the data as possible back to the customer (best place for it anyway) and ask for permission to access it. The Dataslot is a great way of getting started because you can begin to give the data back to the customer and let them help you keep it up to date. As the architecture and processes evolve you can just turn off the bits of CRM you no longer need. There are other offshoots here but I'll save those for future posts.
So, in summary, control for the individual, the possibility of more effective services, enabling of personal agents, a more ethical and less risky approach to CRM. Sounds to me like Dataslots have a lot going for them.
But I could still be crazy... you decide!