Eugene Eric Kim

Andy Dale reported earlier this month that La Leche League will be using Kintera‘s software for member and donor management. More importantly, the two organizations will use open “standards” to share data between their respective systems. Andy’s company, ooTao, is implementing the data sharing using technology known as XDI.    (LK3)

The data sharing problem is well-known in every large organization, and it boils down to this: You have common data across multiple systems and databases, and none of it is linked. Because it’s not linked, it’s difficult to update information, it’s difficult to maintain a high-level accuracy, and it’s difficult to do any serious reporting. Every time you add a new system, it gets exponentially harder to do all of the above.    (LK4)

Does Kintera’s announcement mean that the data sharing problem has been solved? No. But it’s still an important announcement. To understand why, it’s important to delve a bit deeper into what makes the data sharing problem hard in the first place.    (LK5)

First, standards are inherently hard.    (LK6)

Second, getting an established market of vendors to agree on a set of standards is even harder. The problem is that every vendor thinks that lock-in is good for their business. The bigger problem is that they’re absolutely right, as long as lock-in is the status quo. Open data sharing is not viable until a critical mass of tools support it, and there’s no short-term return on being first to market (other than marketing value, which I would argue is underappreciated).    (LK7)

Third, those who have been trying to address the problem have been going about it the wrong way. In particular, they’ve made the social problem bigger when it should be smaller, and they’ve made the technical problem smaller when it should be bigger.    (LK8)

The most common mistake that people make when trying to agree on a standard is to try to get everyone on board up-front. That is the path to certain failure. The best approach is to get two people on board up-front, build something that works and is open, and then approach others about joining the effort. Getting small groups of people to collaborate is hard enough. Don’t make it harder than it needs to be.    (LK9)

On the technical front, people seem to have oversimplified the problem. It’s not just about coming up with the right set of APIs and XML schemas. You have to also think about identity — on many levels, as it turns out. The data needs to be addressable, which means you have to think deeply about identifiers. Also, the most common type of common data is people information — in other words, digital identities. The requirements around Digital Identity — especially User-Centric Identity — are more complex. The good news is that engineers are well-equipped to handle this kind of complexity; you just need to make sure it’s part of the problem statement.    (LKA)

Back to the Kintera announcement. They’re doing the right thing by building something that works between two organizations, rather than declaring a standard up-front and trying to convince everyone to jump on board willy nilly.    (LKB)

They’re also doing the right thing by hiring ooTao to implement this piece, because ooTao understands the identity problem, and it has credibility in the grassroots identity community. While calling XDI a “standard” is a stretch — there’s not even a published spec yet — it will most certainly be open, and a number of organizations and individuals have already contributed to it. More importantly, all of this stuff will work with OpenID and i-names, two technologies that can be accurately called open standards.    (LKC)

Will XDI “win”? It doesn’t matter. The architectural and practical lessons learned in implementing and deploying something real will move us one significant step closer to solving the data sharing problem, regardless of the role that XDI plays in the the long-term solution.    (LKD)

Should you avoid XDI because of the uncertainty over whether it will “win”? Absolutely not. The architectural changes you will need to make to support XDI will be largely spec-independent. Should you need to migrate to a different spec at a later point, the work required will be relatively minor.    (LKE)