Normally, I wouldn’t nitpick about this, but there are two key domains where this is vital and I’m knee deep in both: contracts and platforms.

Doc said:

Like, is the customer always the first party and the vendor the second party?

Well, no. So, some clarification.

First and second parties are like the first and second person voices in speech. The person speaking is the first person, and uses the first person voice (I, me, mine, myself). The person being addressed is the second person, and is addressed in the second person voice (you, your, yourself).

And

To sum it up, third parties mostly assist vendors. That is, they show up as helpers to vendors.

The first point is great, and if you continue this further (and make the leap from parties to data providers), you get something like this:

The ownership of “your” and “my” data is usually clear. However, ownership of the different types of “our” data is a challenge at best.  To complicate matters further, every instance of “my data” is somebody else’s “your data”. In every case, there is this mutually reciprocal relationship between us and them. In the VRM case, we usually think of the individual as owning “my data” and the vendor as owning “your data”, but for the vendor, the reverse is true: to them their data is “my data” and the individual’s data is “your data”. Similar dynamics occur when the other party is an individual. I bring my data, you bring your data, and together we’ll engage with “our” data. We need an approach that respects and applies to everyone’s data, you, me, them, everybody..

Which is from my post on data ownership. The trick is that 1st party and 2nd party perspectives are symmetrical.  We are their 2nd party and they are their 1st party. Whatever solution we come up with in the VRM world needs to work for everyone as their own 1st party. Everyone. Including “them”. Including Vendors.

In fact, that’s the only way we can get out of the client-server, subservient mentality of the web. It’s also the only way to make sure that our solutions work even when the “vendor” is our neighbor, our friend, or our family.

This is particularly clear in the work we are doing at the Kantara Initiative’s Information Sharing Work Group. We are creating a legal framework for protecting information individuals share with service providers. As such, it’s vital that the potential ambiguities of language are anchored in rigorous definitions. And what has emerged is that every transaction is covered by a contract between two parties. Not three. Not four. Not one. Two. And to the extent that third (or fourth) parties are mentioned, they are outsiders and not party to the contract. Since we are building a Trust Framework, there is a suite of contracts covering the different relationships in the system, but the legal obligations assumed in each contract have clear and unambiguous commitments between the first and second parties only.

Platforms

But where I think where Doc’s framing most needs a bit of correction is that, in fact, historically, third parties are never presumed to be working for second party. Not in the vernacular and not in any legal context. This presumption only emerges once you add a Fourth Party claiming that it works on behalf of the user. That is, 3rd-party-as-ally-of-the-2nd-Party is a corollary to Fourth Party concept, not a foundation for explaining it.

Take Skype, which I have on my Verizon cell phone. In the contract with Verizon, Skype is a third party application and Skype, Inc. is the third party.  But Skype isn’t working on Verizon’s behalf.

This is not only true in the sense of 3rd party applications whose value proposition is clearly at odds with the 2nd party, it is even more true when it comes to platforms. And especially when you consider the relevance of VRM as a platform for innovation.

In every platform, there are third parties who create apps that run on the platform. Microsoft built Windows, but Adobe built Photoshop. Apple built the iPhone, but Skype built Skype.  For platforms to be successful, they necessarily bring in 3rd party developers to build on top of the platform. These developers aren’t necessarily working on behalf of the platform provider, and it would be a miscarriage of alignment to claim that they are. They are out for themselves, usually by providing unique value to the end user. Some new widget that makes live better.

This becomes even more true when you are dealing with open platforms, or what I called Level 4 Platforms (building on Marc Andreeson’s The 3 Platforms You Meet on the Internet). In open platforms, you actually have 3rd parties helping contribute to the code base of the platform itself.  Netscape adds tables to HTML. Microsoft adds the <marquee> tag.  But here, it is even crazier to imagine that these 3rd parties are acting on behalf of the platform party… because there really isn’t a platform party. Nobody owns the Internet.

I think the right way to think about 4th Parties is that they have a fiduciary responsibility to the 1st party and 3rd parties may or may not.

Fourth Parties answer to the 1st party.

3rd Parties may not answer to anyone.

The term “ownership” simply brings too much baggage from the physical world, suggesting a win-lose, us-verses-them mentality that retards the development of rich, powerful services based on shared information.

Anyone up for sacred cow cheeseburgers?

I’m a member–and a big fan–of Steve Holcombe‘s “Data Ownership in the Cloud” LinkedIn group and I love the efforts of the Dataportability guys and am a big supporter of the Privacy and Public Policy work group at Kantara. There is a lot of good work being done by folks trying to figure out how to give people greater control over the use of data about them (privacy) and gain access to data they use or created (dataportability).

Unfortunately, sometimes the arguments behind these efforts are based on who owns–or who should own–the data. This is not just an intellectual debate or political rallying call, it often undermines our common efforts to build a better system.

Consider this:

1. Privacy as secrecy is dead
2. Data sharing is data copying
3. Transaction data has dual ownership
4. Yours, mine, & ours: Reality is complicated
5. Taking back ownership is confrontational

Privacy as secrecy is dead

First, the data is pretty much already out there. The issue isn’t “How do we keep data from bad people,” it’s “How do we keep people from doing bad things with data?” DRM and crypto and related technology as the sole means to prevent data leakage and data abuse are failures. Sooner or later, the bad guys break the system and get the data.  Sure, there are smart things we can do to protect ourselves. Just like we wear seatbelts and lock our front doors, we should also use SSL and multi-factor authentication, but we can’t count on technology to keep our secrets. We need solutions that work even when the secret is out.

In fact, privacy isn’t about information we keep secret. It is about information we have revealed to someone else with expectation of discretion, e.g., when we tell our doctor about our sexual activities. It’s no longer a secret from the Doctor, but because it is private, we have rules that keep the information from being used inappropriately. Most of the time, with most doctors, it works. Those few who break those rules are dealt with through legal means, both civil and criminal, as well as social approbation. So, because we inherently need to release data to different parties at different times, we can’t control it through secrecy alone. Instead, we need to build a framework for preventing abuse when others do have access to sensitive information. Like in the case with our doctor, we want our service providers to have the data they need to provide the highest quality services.

Data sharing is data copying

Second, in the world of atoms, there can only be one of a thing, which is the reverse of the world of bits. With atoms, even if there are copies, each copy is itself a singular thing. Selling, transferring, or stealing a thing precludes the original owner from continuing to use it.

This isn’t true for information, which can easily be sold, transfered, and stolen without disturbing the original version. In fact, the entire Internet is basically a copy machine, copying IP packets from router to router, as we “send” images, web pages, and emails from user to user and machine to machine–each time a new copy is created whether or not the originating copy is deleted. To think of bits as if they were ownable property leads to attempted solutions like DRM that try to technologically prevent access to the information within the data, which is only good until the first hacker cracks the code and distributes it themselves. Instead, if we build social and legal controls on use, we can give information more freely, but under terms set by each individual when they share that information. Enforced by social and legal rather than purely technological means, this makes the most of the low marginal cost of distributing  online, while retaining control for contributors.

Transaction data has dual ownership

Image via Wikipedia

Third, much interesting data is actually mutually owned… which means the other guy can already do whatever the heck they want with it.  Consider web attention data, the stream of digital crumbs representing the websites we’ve visited and any interactions at each: all our purchases, all our blog posts, all our searches. Everything. Some folks argue that we own that data and therefore have the right to control the use of it. But so too do the owners of the websites we’ve been visiting. We don’t own our http log entries at Amazon. Amazon does. In fact, in every instance where two parties interact, where we engage in some transaction with someone else, both parties are co-creating that information. As such, both parties own it. So, if we tie the issue of control to ownership, then we’ve already lost the battle, because every service provider has solid claims to ownership over the information stored in their log files, just as we, as individuals, own the browsing history stored on our hard drive by Firefox, Internet Explorer and Chrome.

In the movie Fast Times at Ridgemont High, in a confrontation with Mr. Hand, Spicoli argues “If I’m here and you’re here, doesn’t that make it our time?”  Just like the time shared between Spicoli and Mr. Hand, the information created by visiting a website is co-created and co-owned by both the visitor and the website.  Every single interaction between two endpoints on the web generates at least two owners of the underlying data.

This is not a minor issue. The courts have already ruled that if an email is stored for any period of time on a server, the owner of that server has a right to read the email.  So, when “my” email is out there at Gmail or AOL or on our company’s servers, know that it is also, legally, factually, and functionally, already their data.

Yours, mine, & ours: Reality is complicated

Fourth, when two parties come together for any reason, each brings their own data to the exchange. We need a framework that can handle that. Iain Henderson breaks down this complexity in a blog post about your data, my data, and our data, talking about an individual doing business with a vendor, for example, someone buying a car.

“My data” means data that I, as an individual have that is related to the transaction. It could include the kind of car I’m looking for, my budget, and estimates of my spouse’s requirements to approve of a new purchase.

“Your data” means data that the car dealer knows, including the actual cost of the vehicle, the number of units in inventory, the pace of sales, current buzz from other dealers.

“Our Data” means information that both parties have in common. That could be Shared Information, explicitly given by one party to the other in the course of the deal, such as a social security number so the dealer could run a credit check. It could be Mutual Information, generated by the very act of the transaction, such as the final sale price of the vehicle. Or, it could be Overlapping Information, which each party happens to know independently, such as the Manufacturer Suggested Retail Price (MSRP) of a vehicle (which we found online before heading to the dealership).

The ownership of “your” and “my” data is usually clear. However, ownership of the different types of “our” data is a challenge at best.  To complicate matters further, every instance of “my data” is somebody else’s “your data”. In every case, there is this mutually reciprocal relationship between us and them. In the VRM case, we usually think of the individual as owning “my data” and the vendor as owning “your data”, but for the vendor, the reverse is true: to them their data is “my data” and the individual’s data is “your data”. Similar dynamics occur when the other party is an individual. I bring my data, you bring your data, and together we’ll engage with “our” data. We need an approach that respects and applies to everyone’s data, you, me, them, everybody.

In these complex Venn diagrams of ownership, it is more important who controls the data than who owns it.  We’ve already lost the crudest form of control–secrecy–and we are going to continue to lose more as we opt-in to seductive new services based on divulging more and more information: our purchase history, browsing activity, and real-world location data. But we still need to control how all this data is used, to protect our own interests while still enjoying the benefits of the great big copy machine that is the Internet.

Taking back ownership is confrontational

© Regien Paassen | Dreamstime.com

Fifth, we don’t need to pick a fight to change the game. There is a lot of data out there that many of us believe we should have control over. I agree. A lot of people argue that we should have the right to exclude other people’s use because we own the data, because it’s ours in some legal, moral, or ethical framework. The problem is, those other people already have it, and they also believe that they are legitimate owners. In fact, many of them paid for that data, buying it from data aggregators who compile all sorts of things about people, from both public and private sources. This entire ecosystem of customer data is a multi-billion dollar business and every single player “owns” the data they are working with. So if we focus our energy in claiming ownership over that same data in order to take control, we are framing the conversation as a fight, a fight against a powerful, well-healed, well-funded, entrenched bunch of opponents.

Most of these “opponents” are the very people we are trying to win over to our way of thinking. These are the vendors we want to embrace a new way to do business. These are the technologists we want to transform their proven, value-generating CRM systems to work with our data on our terms, instead of their data on their terms. Arguing over ownership puts these potential allies on the defensive, when what we really want is their collaboration.

From Ownership to Authority, Rights, and Responsibilities

Rather than building a regime based on data ownership, I believe we would be better served by building one based on authority, rights, and responsibilities. That is, based on Information Sharing.

• Who has the authority to control access and use of particular information?
• What rights does a party have in using and distributing a piece of information?
• What responsibilities does an information user have to others with respect to that information?

Let’s stop arguing about who owns what and start figuring out how we can share information in ways that allow everyone to win.

When we collect all of our information into a single conceptual repository, and then share access to it with service providers on our own terms, we create a high quality, highly relevant, curated personal data store. This allows us to bootstrap a control regime over all of our data in a way that creates new value for us and for our service providers. Now, instead of iTunes Genius or a Last.FM scrobbler only having access to our media use with their service, they can provide recommendations based on all the information stored in our personal audio data store. We get better recommendations and they get better data to drive their services. This personal data store is entirely under the authority of the user, sharing information with service providers according to specific rights and responsibilities.

The Information Sharing approach neatly sidesteps the complexities involved in privacy and dataportability issues of the information already known by service providers. These remain serious issues, worth addressing. Resolving them will require long term investment in the legal, regulatory, moral, and political systems that govern our society. Fortunately, sharing the information in our personal data store can begin almost immediately once we have working specifications.

This controlled sharing of information will dramatically increase our comfort level when revealing our intentions and interests. We would have control over the use–and would be able to prevent abuse–of that information, while making it easy for service providers to improve our lives in countless ways.

At the Information Sharing Work Group at the Kantara Initiative, Iain Henderson and I are leading a conversation to create a framework for sharing information with service providers, online and off. We are coordinating with folks involved in privacy and dataportability and distinguish our effort by focusing on new information, information created for the purposes of sharing with others to enable a better service experience. Our goal is to create the technical and legal framework for Information Sharing that both protects the individual and enables new services built on previously unshared and unsharable information. In short, we are setting aside the questions of data ownership and focusing on the means for individuals to control that magical, digital pixie dust we sprinkle across every website we visit.

Image by hegarty_david via Flickr

Because the fact is, we want to share information. We want Google to know what we are searching for. We want Orbitz to know where we want to fly. We want Cars.com to know the kind of car we are looking for.

We just don’t want that information to be abused. We don’t want to be spammed, telemarketed, and adverblasted to death. We don’t want companies stockpiling vast data warehouses of personal information outside of our control. We don’t want to be exploited by corporations leveraging asymmetric power to force us to divulge and relinquish control over our addresses, dates of birth, and the names of our friends and family.

What we want is to share our information, on our terms. We want to protect our interests and enable service providers to do truly amazing things for us and on our behalf. This is the promise of the digital age: fabulous new services, under the guidance and control of each of us, individually.

And that is precisely what Information Sharing work group at Kantara is enabling.

The work is a continuation of several years of collaboration with Doc Searls and others at ProjectVRM. We’re building on the principles and conversations of Vendor Relationship Management and User Driven Services to create an industry standard for a legal and technical solution to individually-driven Information Sharing.

Our work group, like all Kantara work groups, is open to all contributors–and non-contributing participants–at no cost.  I invite everyone interested in helping create a user-driven world to join us.

It should be an exciting future.

This material is based upon work supported by the National Science Foundation under Award Number IIP-08488990. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the author and do not necessarily reflect the views of the National Science Foundation.

From cable TV to YouTube, from newspapers to blogs, from Wal-Mart to eBay, from Ma Bell to the Internet, the shift from centralized, structured systems of authority to emergent, collaborations between individuals has been reshaping our political, social, and economic world for generations. This is a trend that has driven—and been driven by—the massive success of the Internet, email, the World Wide Web, eBay, Google, RSS, FaceBook, YouTube, and Twitter. Each of these examples took an existing model and made it more user driven: networking, messaging, electronic publishing, buying & selling, content discovery & advertising, news aggregation/syndication, online video, status updates.

The conclusion: companies which find ways to be more user driven are more valuable, more profitable, and more successful.

What does it mean to be “user driven”? At its most basic, it means putting the user in charge, in some way. Fully realized, it means putting the user at the center of the system, as a point of integration, origination, and control. We call these fully realized systems “User Driven Services”.

User Driven Services put users in charge. Users start each interaction, manage the flow of the experience, and control what and how data is captured, used and propagated.  Users are the cause and the controller, working with service providers to co-create collaborations that create value for all parties.

From self-serve gas stations and soda fountains to ATMs and self-checkout grocery stores, companies have been putting users in charge of different aspects of their services for years. With GetSatisfaction—which allows users to self-organize for cooperative customer support—and Facebook—which provides social context for user-generated content—users are not just self-servicing, they provide the core content behind the user experience. Now, through user-centric Identity and API access to most popular online services (Flickr, Twitter, Facebook, etc.), users can direct which parts of their experience are serviced by which providers, allowing unprecedented realtime flexibility in service creation.

User Driven Services are redefining how we interact, how we manage our businesses, and how we engage in both public and personal conversations. Businesses and organizations that want to thrive in this new reality would do well to help co-create a new mutually beneficial marketplace for products, services, and ideas. Individuals, participating in this rising tide of personal power, have an opportunity to coordinate with each other and with service providers to craft a future that meets all of our needs, as individuals, entrepreneurs and business people.

Terminology

A few key terms:

System: a group of independent but interrelated elements engineered to operate as a unified whole.

(The systems to which we refer are not natural or conceptual systems, but rather, operating mechanisms designed and implemented to perform intended functions.)

User: any individual interacting with a system.

Service: a value generating experience available to users through interactions with a system; also the system providing such experiences.

User Driven Services: services that maximize value creation by maximizing user control and authority.

Characteristics

User Driven Services have the following characteristics:

1. Impulse from the User
2. Control
3. Transparency
4. Data Portability
5. Service Endpoint Portability
6. Self Hosting
7. User Generativity
8. Improvability
9. Self-managed Identity
10. Duty of Care

We will explore each of these characteristics in a series of articles over the next few weeks.

No longer is it sufficient for companies to package a value proposition on their website and then drive traffic to it through ads, search engine optimization, and reciprocal links. Today companies must find ways to provide a value proposition wherever the user might be: on Facebook and Twitter, on their iPhones, and even through 3rd party applications accessing deep into the company’s datasphere through APIs and webhooks.

The Internet is reconfiguring around the user, wherever people happen to be.

I’ve been talking with folks in the VRM community about this topic over the last few years. VRM is, at its core, about starting with the user, re-engineering systems to maximize user freedom and control, and placing the user at the point of integration.  Or, as Doc Searls puts it, creating tools for “both independence and engagement”.

For example, I’ve led several discussions at various VRM workshops on what I call “user driven search“: what would happen if the user were truly in control of all the data related to their search and could engage any Search provider they like with the full scope of that information and under the user’s terms?

In the last several months, I have been advocating a new term has that captures the core direction of both VRM and User Driven Search: “User Driven Services”.

When you configure your services around the user as the primary point of origination, integration, and control, you are building User Driven Services.

Over the next few weeks, I’ll dive into what we mean by User Driven Services; consider it a warm up for both the VRM West Coast Workshop 2009 and the Internet Identity Workshop.

More …

I had heard a bit about this before and it sounded great… but there’s always such a drive to just start coding! Before I reach Carolyn Snyder’s excellent Paper Prototyping, I hadn’t realized what I was missing.

The key difference from what you might be thinking–and definitely what I was thinking–is that paper prototyping isn’t just about doing mockups of the UI and asking users for feedback. It means recreating the a subset of the core user experience using a paper-based model, with a human “computer” and the user interacting not with the facilitators or testers, but directly with the pieces of paper, by pointing for hovering, touching for clicking and writing for typing.

The results were amazing.

We took two weeks to develop & construct a paper prototype for our upcoming Search Map software, which is the first implementation of the SwitchBook approach to User-driven Search (which is the focus of our work with the VRM community). That was followed by one week doing the actual testing.

To build out a paper prototype like this you have to have a critically specific definition of what it is you are building. Depending on how early you are in the gestation of your software idea, this might be impossible. But if you have a pretty good idea of the basics, the paper prototype will force you to actually write down both

• a subset of tasks in sufficient detail for the user and the prototype to do with paper assets, and
• create the pieces of paper that represent every window, every menu, every dialog box, every state in the interface.

It felt like we went through three revisions of our core UI before we actually had any users. We found there were so many assumptions hidden in our initial requirements documentation that we were missing key parts of the user experience. And then, by mapping out those parts of the experience, we made significant leaps in simplifying and unifying the overall design.

Prior to the actual testing, we first did a dry run with a fellow associate as a user. This was eye opening. Not only did we identify a few assets we were missing, we realized we had several key assumptions that we had overlooked in our design. These assumptions led us to revise the paper prototype significantly, leading to an even better run through with the live testers.

This pattern repeated itself for everyuser. Snyder strongly suggested doing just a handful of tests, no more than two per day. So, 4-6 testers over two-three days. After two weeks building the prototype, I was thinking we should have more testers to really get the value out of this thing. But after the trial run, I realized that there is so much opportunity to update & improve between tests, that you want to immediately assimilate each session and update the prototype.

That is the real beauty of the paper prototype.  Because it is just paper… and in particular just sketches on paper–not a beautifully designed custom UI–it is trivial to change. We were evolving in leaps and bounds between every test, taking out portions of the interface, creating new icons, adding buttons here and removing them there, even updating dialog boxes in mid-test.

It would be hard to overstate how powerful it was to engage in such rapid evolution based on real user feedback. With ~3 revs in the construction phase, 1 with our trial run, and 4 more revisions from each test, I estimate a good 8 substantial revisions to our design in just three weeks.

Our timing for this exercise was just about perfect. We just started a 6 month dev cycle in January, after over a year of internal development (largely on the server side with a basic architectural prototype on the client). The core experiential basics had been fairly stable, and we were ready to integrate a lot of conceptual learning into a new rev. So, we had a lot of detail about what we wanted to do, and were in a good point to take a moment, document our requirements rigorously, and sit down with users to see what really works. For the record, we spent about three weeks in requirements engineering prior to working on the paper prototype (which was another three weeks of effort). I don’t know if I’ve ever spent a more useful 6 weeks in any programming project.

We also quickly saw the limitations of this approach. Of course, it was slow. We joked that the McKinney 5000 was operating at about 110hz. (Sam McKinney acted as our “human” computer for the testing–and did a great job I must say.) A good portion of our user experience depends on finding “flow” during advanced searches across many different websites and different search providers. Just keeping track of the user’s behavior was a breakneck task… simultaneously updating the screen to indicate the real-time feedback and recommendations from our server was even harder. The result is that although we got to test our core workspace, the technique was too slow to really test the work flow.

So, Carolyn Snyder, thanks so much for the easy and thorough guide to paper prototyping. It was an amazing exercise for our whole team. And for those of you who are working through the details with disruptively innovative software, I encourage you to try it. I think you too will be amazed at your results.

p.s.

My apologies that we didn’t get any pictures of the experience. We were so busy doing it, nobody stopped to capture the look & feel of the interactions.

It wasn’t something new to the movement, rather it was a realization about the primacy and criticality of what we are doing and how to communicate it. It has always been a part of the conversation, just one that we often took a bit of time to get around to. And yet, it is perhaps the most important piece of all:

When we put the user at the center, and make them the point of integration, the entire system becomes simpler, more robust, more scalable, and more useful.

This is a profound shift that has some interesting parallels with a concept in AI called “stigmergy” and with a bit of classic Einstein becomes a totally new way to think about next generation systems design. In other words VRM changes the landscape in a way that not only makes life better for individuals, it profoundly improves the information architecture that modern society depends on.

If you’ll indulge me, I’ll try to explain.

User Centrism

VRM has its roots in the user-centric Identity movement and has user-centrism at the core of its DNA. The first, and perhaps most obvious, interpretation of user-centrism is user control. That, unfortunately, is part of the problem.

User Control

User control is critically important. It resonates with the core of the modern social contract. Freedom. Liberty. Capitalism. The Age of Reason. Liberalism. These systems and ideologies all assume that the individual, and only the individual, has legitimate moral authority over his or her life, assets and the disposition of both. These are powerful concepts. So powerful, that when you build systems that provide individual control, you energize vast personal resources that in turn become real economic power, measured in trillions of dollars, just to consider US GDP. Contrast this with fascism, communism, and socialism, which place the state above the individual and in varying forms take control away. There’s some powerful mojo supporting the whole capitalistic freedom-loving democracy thing.

Regulated Freedoms

Of course, unfettered freedom isn’t the ultimate answer. We’ve learned how unregulated markets fail in various ways, often recreating abuses of power that eventually lead back to a loss of individual control. Think Standard Oil. Southern Pacific Railroad. AT&T. All monopolies that abused their power. And they all owe their break-up to the Progressive political movement which itself was an exercise in user control that started in the early 1900s and arguably ended in the 1990s when Clinton “reformed” welfare.

The Political Siren Call

The problem with user control is that it is so powerful as a political concept. “Putting users back in control” is a seductive rallying cry. In fact, it echoes with John Edward’s current populist campaign against poverty as well as Marx’s call to “workers of the world, unite!” The echoes also show up in user centrism in efforts like the Attention Trust, on which I’ve commented before. Much of the Attention Trust work is important, powerful work. But I still don’t know what they mean when they say that people own their attention data. Does that mean we somehow have the right to “nationalize” private data silos in the name of the people? Without debating the politics of this question–there are good points on both sides–it is clear that this line of thinking about VRM, user control, and user rights, is deeply political and therefore, controversial.

The Conflict of Control

It is also challenging to the graceful and speedy realization of our goals. Starting the conversation by asserting user control implies a loss of control somewhere else. Usually that means conflict, as few entities have ever given up control without a fight. So, thinking and talking about putting users in control resonates with users. But it scares the crap out of vendors. Too bad, some people say. Even yesterday, on that same VRM conference call: “We’ll punish them and get them to be more open and more transparent.” We may be able to do just that, but it is unlikely to be the easiest route to realize our goals.

Especially not if there is a way to reframe the conversation, a way to redefine the important matters, such that the debate is not about user control, but rather about the inherent efficiencies and power of user-centrism. If we can do that, then user control gets built into the system automatically and those who would be giving up some of the control they have today–in their precious vendor data silos–do so not out of punishment, but out of honest, natural desires to improve their bottom line. Along that route lies the embrace of vendors and, I believe, more fruitful relationships for everyone.

User Centrism as System Architecture

Doc Searls shared a story about his experience getting medical care while at Harvard recently. As a fellow at the Berkman center, he just gave them his Harvard ID card and was immediately ushered into a doctor’s office–minimal paperwork, maximal service. They even called him a cab to go to Mass General and gave him a voucher for the ride. At the hospital, they needed a bit more paperwork, but as everything was in order, they immediately fixed him up. It was excellent service.

But what Doc noticed was that at every point where some sort of paperwork was done, there were errors. His name was spelled wrong. They got the wrong birthdate. Wrong employer. Something. As he shuffled from Berkman to the clinic to the cabbie to the hospital to the pharmacy, a paper (and digital trail) followed him through archaic legacy systems with errors accumulating as he went. What became immediately clear to Doc was that for the files at the clinic, the voucher, the systems at the hospital, for all of these systems, he was the natural point of data integration… he was the only component gauranteed to contact each of these service providers. And yet, his physical person was essentially incidental to the entire data trail being created on his behalf.

User as Point of Integration

But what if those systems were replaced with a VRM approach? What if instead of individual, isolated IT departments and infrastructure, Doc, the user was the integrating agent in the system? That would not only assure that Doc had control over the propagation of his medical history, it would assure all of the service providers in the loop that, in fact, they had access to all of Doc’s medical history. All of his medications. All of his allergies. All of his past surgeries or treatments. His (potentially apocryphal) visits to new age homeopathic healers. His chiropractic treatments. His crazy new diet. All of these things could affect the judgment of the medical professionals charged with his care. And yet, trying to integrate all of those systems from the top down is not only a nightmare, it is a nightmare that apparently continues to fail despite massive federal efforts to re-invent medical care.

(See The Emergence of National Electronic Health Record Architectures in the United States and Australia: Models, Costs, and Questions and Difficulties Implementing an Electronic Medical Record for Diverse Healthcare Service Providers for excellent reviews of what is going on this area, both pro and con.)

Profoundly Different

Doc’s insight–and that of user-centric systems–isn’t new. What’s new is the possibility to utilize the user-centric Identity meta-system to securely and efficiently provide seamless access to user-managed data stores. With that critical piece coming into place, we have the opportunity to completely re-think what it means to build out our IT infrastructure.

What clicked on the conference call was first, that this approach actually has some intriguing resonance with a field of AI called “swarm intelligence” and the concept of stigmergy. And second, as a result, the user as the point of integration has the potential to be profoundly different and profoundly more efficient than current practices.

Swarm Intelligence and Stigmergy

Swarm Intelligence looks to the world of insects as inspiration for building AI systems that are collectively smart, but using individually dumb, but active components. For example, how do wasps build nests? Or how do ants find paths to food? It turns out that a lot of these insect behaviors have common properties that can be used to build computer algorithms. One concept that is particularly useful is “stigmergy”, which means marking the environment as communal signaling in a larger, emergent algorithm.

Ants, for example, mark their trails with pheromones. As other ants explore for food, they sometimes follow existing trails, other times not. As more and more ants find success along one particular trail, it gets reinforced, and even improved as some ants’ explorations discover a slightly better route. This natural feedback loop uses the environment in a simple way to allow a bunch of ants to find food in an incredibly efficient way. The last time I looked into it, the Ant Algorithm was in fact the best known algorithm for a particular version of the “Traveling Salesman” problem. Amazing. All without any “active” part of the algorithm actually knowing or thinking about the entire area being mapped–which is what other mapping algorithms basically do.

For an excellent discussion of Swarm Intelligence see Eric Bonabeau’s Swarm Intelligence: From Natural to Artificial Systems.

Einstein, Ants, and User Centrism

So what the heck do a bunch of ants have to do with VRM? With a bit of a solipsistic twist and topological imagination, quite a bit.

Albert Einstein helped the world understand the truth that all velocity is relative. That me running at 15 mph towards a stationary car is the same as the car traveling 15 mph towards me. The important thing is the relationship between the parties, not which one is standing still.

Now apply that sense of relativity to “stigmergy” and invert the ant and the environment. (And don’t hurt your brain!)

Instead of thinking of humans as the active element, think of humans as the environment and Vendors as the ants. Instead of humans visiting a bunch of isolated data silos, invert it so that vendors are visiting stationary users–or their stationary data stores.

Now, instead of a bunch of individuals running around leaving a disparate data trail which is hard to keep track of, the individual represents the digital environment where data is stored by vendors. When the next vendor comes along, the data is there, available for use, without the need for complex integration, processing, or systems maintenance, just like the environment is there for the next ant to come along, allowing that ant to do what they do without a complicated brain or sophisticated map of the territory.

It doesn’t matter that Doc was physically moving around in his example. From Doc’s perspective, he was always right there. “No matter where I go… there I am.” This is more than just a solipsistic view of the universe, it is perhaps the most critical insight of the VRM user-centric gestalt. When you put the user at the center, it makes it trivially easy to manage and integrate the entire digital experience of the user. Because it is all right there, all the time.

It is hard for me to judge if that makes any sense to the average person, but when it clicked in my brain yesterday, it was like a mega-watt flash bulb going off. This is a profoundly different way to think about systems architecture. Just like the ant algorithm, it shifts the problem from one of a complicated system that has to know and integrate everything, to one where all the vendor needs to know is which data store goes with which user. The rest follows.

Sure, there is still a lot of work yet to be done. We have to figure out the protocols and technologies for what data vendors actually share in that data-store and how we assure reliable, always-on access in a secure and privacy-protected manner. Fortunately, as I mentioned earlier, the user-centric Identity meta-system is addressing a huge portion of that. In short, we are building on the shoulders of giants, which stand on the mountains of Moore and Gates and Postel and Berners-Lee and Andreeson. Sounds like fun to me.