Process

From Project VRM
Jump to navigation Jump to search

This page is a draft proposal. Please send any comments to [1] or to the Project VRM mailing list.

(On 19 May 2008, Adriana Lukas suggested that the process described here is "identity-based VRM", and should be distinguisted from "feeds-based VRM". So, a note to selves: these should be distinguised in this wiki as well. - Doc)

VRM Process

One thing that I’ve been noodling lately is how we, as a community, can organize our efforts around VRM.

Microformats Inspiration

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.

A Standard Process

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*

Scenarios

It turns out that Usage Scenarios could be an important part of this process, meaning Scenarios in the context of Use Cases and user-driven development. Chris Carfi has started an excellent thread about future VRM Scenarios, using a subtly different meaning of the word. I’ll generally stick with Usage Scenarios to clarify my use.

Usage 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 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, Usage 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.

Protocol as VRM Output

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? Perhaps Protocol would be appropriate:

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

Protocal seems to work. However, I would definitely appreciate feedback and alternative suggestions for such a term.

Draft VRM Process

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 Scenarios
    Brief prose descriptions of actual instances of the problem.
  3. Desired Scenarios
    Brief prose descriptions about how it might all be made better.
  4. Existing 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.
  11. Reference Implementation
    Create a reference implementation of the standard, to provide a sandbox against which implementers can test their implementations, and to provide a baseline for interoperability.
  12. Implementation Directory
    The standard is added to a directory of the different people and/or services who claim support for the standard. (This could also include external points-of-view/reviews of how well that person/service supported the standard.)

Feedback is definitely welcome. Joe.andrieu 09:28, 23 January 2007 (EST)

Retrieved from "http://cyber.harvard.edu/projectvrm/?title=Process&oldid=4233"