Implications of the Kintera Data Sharing Announcement

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)

Excellent Talks this Week

Three excellent talks are scheduled for the Peninsula this week. The first is tonight at Bay CH I: Fred Turner will talk about his new book, From Counterculture to Cyberculture: How the Whole Earth Catalog Brought Us Virtual Community. His talk is at PARC tonight at 7:30pm.    (LJQ)

Tomorrow, Allison Fine will talk about her new book, Momentum: Igniting Social Change in the Connected Age. It’s required reading for folks in foundations or nonprofits. The talk will be at Margaret Jacks Hall at Stanford tomorrow at 7pm.    (LJR)

On Thursday at 4pm, Jim Spohrer will speak at PARC on his Service Science initiative at IBM. If you haven’t heard him give this talk yet, you need to go. His vision and approach are extraordinary.    (LJS)

Unfortunately, I won’t be able to make Fred’s talk tonight, but I am planning to be at Allison’s, and I’m hoping to make Jim’s.    (LJT)

Learning and Collaboration

On a warm summer evening in Virginia last July, I sat on Marcia Conner‘s porch and wondered aloud whether we were in the same business. Marcia cares about collaboration, but she’s nuts about learning. If she doesn’t hear the word “learning” in the context of projects she’s involved with, alarm bells go off in her head.    (LJ7)

I’m equally passionate about collaboration and learning, but I can talk about my work without ever mentioning the latter. My reasoning, as I explained that night, was that good collaboration encompasses learning, and the best way to learn is to collaborate. You can’t talk about “collaboration” without also thinking about “learning.”    (LJ8)

Doug Engelbart often says that high-performance communities are experts at CoDIAK — collectively developing, integrating, and applying knowledge. I hate the acronym, because I think it’s unnecessarily esoteric. What CoDIAK boils down to is:    (LJ9)

  • Learn.    (LJA)
  • Share and apply what you know.    (LJB)
  • Repeat early and often.    (LJC)

There’s that “learn” word again.    (LJD)

I still believe that collaboration encompasses learning, but I’ve changed my mind about whether it’s important to explicitly mention learning in the context of my work. Marcia, of course, is to blame. We were chatting in the attic of a colleague’s home last Friday, with her two year old son, Clarke, playing on the floor as we talked, and our conversation again drifted towards learning. I was talking about a project I’m involved with, and I explained that while it still felt important, I wasn’t learning any more.    (LJE)

As soon as I said it, I laughed to myself, because it sounded like something that Marcia would have complained about. Yesterday, as I was reading Allison Fine‘s Momentum, a book that Marcia gave me, I was again struck by how important learning is to my work. I believe very strongly in defining projects concretely and getting things done, but I refuse to take on a client who doesn’t care about learning. I expect to learn from my work, and I expect my clients to want to learn as part of our collaboration. This is not a requirement to be in this business. There are plenty of projects where clients don’t give a damn about learning. They just want you to get the work done. I’ve been offered these kinds of projects in the past, and the work itself is often intellectual, enjoyable, and well-paying. I still turn it down. My mission is to help people learn about collaboration, and I won’t work on projects where that’s not happening.    (LJF)

I’ve already made it a practice to describe Blue Oxen Associates‘ long-term goal as building and facilitating a Learning Community centered around collaboration. I could just as easily have chosen Engelbart’s term, Improvement Community, or Etienne Wenger‘s term, Community of Practice, but I chose Peter Senge‘s instead, and the fact that “learning” is there was a major reason why. I’m currently in the process of revamping our web site, and I plan on making “learning” a more explicit part of our message.    (LJG)

Curriculum on Thinking and Learning

I’ve done a lot of volunteer teaching, and back in 1998, I had become fed up with the classes that I was helping with. In particular, I had spent six horrible weeks volunteering at a class to teach kids computers, which turned out to be a glorified typing class.    (LJ2)

Afterwards, I asked the volunteer coordinator if I could come up with my own curriculum, and she agreed. Most of my exercises did not require any interaction with an actual computer. The first exercise was to have kids write down instructions for making a peanut butter and jelly sandwich, which I then followed literally. Another exercise converted the kids into a computer and demonstrated how complex problems could be solved by breaking them down into simple operations. The tour de force was when I had the kids rip apart musical greeting cards to show that computers came in other forms besides desktop and laptop machines.    (LJ3)

That experience was far more rewarding, but also made me realize that I didn’t really want to teach kids about computers. I wanted to help them become better thinkers. So on August 24, 1998, I wrote down three principles that represented my philosophy for what a proper curriculum should achieve. On April 8, 2002, I added a fourth principle. Looking back, that fourth principle reveals how much my mindset had shifted towards the importance of collaboration. Not coincidentally, I happened to be knee deep in the planning stages of Blue Oxen Associates at that point.    (LJ4)

I just put the curriculum up on my Wiki at Learning Curriculum. In the spirit of Mark Oehlert‘s recent challenge, here is the curriculum boiled down into six words:    (LJ5)

Reward questions, stories, lateral thinking, collaboration.    (LJ6)

Quilting Patterns from Gee’s Bend

Last month, I went to see “The Quilts of Gee’s Bend” exhibition at the de Young Museum with my friend Betty Toole. To be honest, I found most of the quilts disappointing. The story is very compelling, even if most of the quilts are mediocre. I wish the quality of the collection wasn’t as hyped as it was, as it took away from the overall experience.    (LHY)

There were a few beautiful quilts, however. My favorite was a red quilt in an “H” pattern by Nettie Young, and the story accompanying it is a wonderful commentary on the danger of patterns.    (LHZ)

https://i0.wp.com/www.auburn.edu/academic/other/geesbend/explore/catalog/slideshow/thumbnails/q021-06_jpg.jpg?w=700    (LI0)

Young said:    (LI1)

I always loved sewing. Didn’t need a pattern. If I sew a dress or a quilt or something I liked, I can make it. I just draw it out the way I want it. In the quilting bee time, I started using patterns, but I shouldn’t have did it. It broke the ideas I had in my head. I should have stayed with my own ideas. I kept making quilts all the way up to last year (1999). I still got the feeling now and then to sew, but I just don’t have the mind to do it now. My hands are good, but I don’t quite got the spirit. Not like before when I was always ready day and night. Age got me.    (LI2)