VRM Process

Chris Carfi at The Social Customer Manifesto recently posted a thought provoking romp into the future of VRM:

Accompanying this visual, he writes:

So, the two big questions:

• Q1: Who controls the interactions between vendor and customer?
• Q2: Are the interactions focused on transactions or relationships?

It’s important to note that the object of this exercise is most emphatically NOT to “predict” which of these four areas will “win.” Instead, it’s to draw a vivid caricature of each world, and determine its key traits. Doing this allows us to better plan for, and recognize, instances of that particular scenario when we run across it in the future.

It’s a great read and great stimulus for the upcoming VRM Meeting. I particularly like the use of scenarios to push the boundaries on our thinking. I think the issues are not necessarily counterpointal–both vendors and customers can control their own information, for example, and transactions and relationships, in fact, go hand-in-hand. But it is an excellent break down of potentially bipolar forces and good food for thought.

One thing that I’ve been noodling lately is how we, as a community, can organize our efforts around VRM. It turns out that Usage Scenarios could be an important part of that, although I mean Scenario in a different sense, in the context of Use Cases and user-driven development. I’ll stick with Usage Scenarios to clarify my meaning of that term. Scenarios are, for me, a simple, short, narrative description of one or more specific and detailed interactions with the current or proposed system. The idea is, for me, to keep it real, to keep it colloquial, and to capture the essence of the situation rather than a detailed list of all possible variants. In my projects, Scenarios have proven to be a great bridge between the problem domain and a technical specification. And when kept to just a paragraph or so, they are easy to write, too.

In a recent exchange with Colin Henderson at BankWatch, he asked about microformats and VRM. I replied that I think there is a lot to learn from their efforts. In particular, microformats has a great ironclad process, established in the early days, that continues to serve as a corral and assembly line for new microformats proposal. It is the foundation for how they forge community consensus. Along with the principle of paving the cowpaths, the process severely cuts down on distracting hypothetical conversations and assures a wiki-documented evolution towards a community consensus. Many newbie questions have been productively answered by a link to the process page and a polite invitation to read it and start working their ideas through it.

Establishing such a standard process could have a great positive influence on VRM, especially as Project VRM has the potential to become a clearinghouse for different approaches in different domains, each requiring independent investment, development, and consensus. For example, VRM solutions for vendor selection are likely different from those for Personal Health Records and those for Banking.

Early community norms about how we go from “A great idea” to something people can start implementing, would, I believe, help more ideas reach critical success more quickly, as people spend more time doing the work rather than debating hypothetical design points and process issues. A good process would also let people know how to contribute and assure that good ideas are fully fleshed out as they develop. Of course, concrete design issues, grounded in context, goals, and constraints, are good topics for conversation.

This actually dovetails, nicely I think, with Chris’s comments earlier on putting the cart before the horse in VRM development. As he said so concisely:

Before diving into creating a new technical spec, step outside and look around a bit.

So, here is a strawman proposal for how we might, as a community, organize a process for developing VRM systems. The idea is that each of these steps helps elucidate the details of a problem that could be solved by VRM. Each step is itself straightforward, building upon the steps before hand, and once complete, moving to interoperable implementations should be fairly simple. *grin*

In writing this, it became clear that we might benefit from having a specific noun for describing the output of our work. Microformats produces microformats. Pretty straight forward. What does VRM produce? Since we are dealing with exchanges, both in terms of transactions and relationships and in particular how the Internet enables new forms of exchanges, perhaps Interchange would be appropriate:

• To develop a new VRM Interchange, one would shepherd it through the VRM process on the Project VRM wiki.
• To implement a component of, or software that connects with, a VRM Interchange, one would implement the interfaces and protocols of that Interchange.
• The VRM Loan Interchange currently supports mortgage applications.
• The VRM pRFP Interchange allows for the secure, identity-controlled digital requests-for-proposals in an open marketspace.

Interchange works for me, so I’ll use it in the rest of this post. However, I would definitely appreciate feedback and alternative suggestions for such a term.

The proposed process follows. The idea is that each section would have its own wiki page, preceeded by the name of the Interchange. Eg. http://projectvrm.org/Interchanges/pRFP/Domain and http://projectvrm.org/Interchanges/pRFP/Current_usage_scenarios

1. Problem Domain
   A discussion of the problem domain, in the nature of a real-world problem that is containable, i.e., a specific solvable problem. This becomes the charter for this particular Interchange.
2. Current Usage Scenarios
   Brief prose descriptions of actual instances of the problem.
3. Desired Usage Scenarios
   Brief prose descriptions about how it might all be made better.
4. Current implementations and efforts
   A review of what has already been done in this area and who (organizationally) is still working on this problem. This will serve both to incorporate existing efforts and to learn from past mistakes.
1. Software
2. Protocols
3. Formats
4. Initiatives
5. Organizations
5. Users
   A quick run down of who the system must support at various different levels. This should list both categories of users and some specific examples in each category. There may be many subcategories under each of the following major categories.
   The idea here is not to build the system to be perfect for each of these users, but to make sure we have all the stakeholders in context as we flesh out the design. Ultimately just a handful of target users will be the focus.
1. End users
2. Vendor users
3. Supporting Users (retailers? regulators?)
4. Implementors
6. Use Cases
   These are specific, complete transactions between users and the system. All critical use cases should be listed, along with various incidental or support cases that could influence overall design. Ultimately, a handful of defining use cases will drive system design.
1. Abstract, High-Level Use Cases
   Single sentences describing a use case. When done well, they become the name of the use case. For an ATM, you might have “Withdraw Cash” or “Transfer Funds” as abstract high-level use cases.
2. Concrete Detailed Use Cases
   Detailed use cases describe the chronological back & forth (action/reaction) between users and the system to realize a particular transaction. Concrete use cases are free to use specific design and implementation choices. This is useful either at the very beginning when transcribing scenarios (when the specifics help you understand what is actually happening) and at the very end (when the specifics represent design decisions).
3. Abstract, Detailed Use Cases
   Abstract use cases are stripped of the design decisions to more completely and accurately describe the critical steps while also freeing up the design process to innovate. For example, a concrete use case for the ATM might include the concrete steps of inserting a bankcard, prompting for a PIN, entering pin on keypad, and verifying PIN. And abstract version of that same use case could be “identify user, authenticate user.” It’s easy to see how the abstract version allows for alternative implementations where the first one presumed a bankcard, keypad and PIN.
7. Brainstorming
   Free-form inspirations and ideas about how to realize one or more of those use cases.
8. Draft
   After some brainstorming, a basic system design will emerge, either meeting all the use cases or accepting the loss of some use cases as part of the design choices in the draft.
1. Entities
2. Communications
1. Protocols
2. Formats
3. Transactions
9. Proposal
   Once the draft is bandied about and improved on by the community, the group who has taken stewardship of the domain can propose it to the entire VRM community as a standard VRM Interchange. This would expose it to more feedback and improvements and engage the entire VRM universe in the final stages of development.
10. Published Standard
    After the community as a whole has had a chance to contribute, the Interchange would eventually either be approved and published as a standard or disbanded. I don’t see any reason for a specific timeframe for any of these steps in the process, but there may be efforts that get proposed that ultimately are better served by other means or by breaking them into smaller Interchanges. It is at the publication stage that a standard becomes “official” and earns a version number. Amendments or revisions to the standard would go through some related process and be published with a later version.

That’s it for now. I’ll put this up on the Wiki and will definitely look forward to criticism, refinements, and alternatives.