Re: [payment agent] Payment architecture feature priorities

I agree with the approach to break the architecture into different 
levels. However, I think we need to be careful about narrowing our focus 
too quickly on Level 1. We certainly want to be able to focus on the 
individual levels, one at a time, however, we may also want a 
higher-level framework to use to make decisions about the technologies 
and designs we employ at each level.

It's sounding like one way to go about making decisions, at a high level 
is to do this:

1. Get a general idea for what features may go into an MVP as Level 1.
2. List out other features into reasonable groups for other levels, but 
don't get into much detail.
3. Then, for each level:
3.1. Strictly focus on the level's requirements, picking technologies, 
doing design work, publishing specs, etc. (lengthy process)
3.2. Move on to the next level.

If we take this approach, I think it will be very easy for us to produce 
levels that are built on technologies or designs that have 
incompatibilities with one another. I recommend instead:

1. Gather all of the requirements/features from the use cases for every 
architecture level. The feature list doesn't have to be perfect, but 
should be fairly comprehensive.
2. List out the features for each level, where Level 1 is an MVP.
3. Based on the entirety of the requirements list, determine the 
technologies required.
4. Then, for each level:
4.1. Strictly focus on the level's requirements, using a set of 
technologies from #3, doing design work, publishing specs, etc. (lengthy 
4.2. Move on to the next level.

With the latter approach, we'll have better confidence that the 
technologies we're picking will work for the *overall* design of the 
system, even if we only use a subset of them (or a subset of their 
features) at any particular level. We can still build the architecture 
in a layered, prioritized fashion, but the layers will be less 
susceptible to unintentional incompatibility leading to awkward design 
workarounds. It seems like this approach may be somewhat similar to what 
was done with the use cases document, where Ian developed a very helpful 
overall framework for organizing use cases and for understanding the 
*overall* concept of the payment process.


On 04/24/2015 12:55 AM, Manu Sporny wrote:
> I took an action today to try and attempt to figure out how to
> prioritize payment architecture features and map them to use cases:
> Here's the rationale that was used to create the payment architecture
> feature list:
> * Split the Payment Architecture into "levels":
>       Level 1 - The minimum viable product
>       Level 2 - Make architecture compelling for retailers
>       Level 3 - Extend architecture to mobile/wireless devices
>       Level 4 - Faster clearing/settlement
> * We would suggest that W3C creates technical working groups to
>    implement the levels in order... level 1 is highest
>    priority, level 2 is next highest, and so forth.
> * Map features in each level to use cases
> Caveats:
> * I only really focused on Level 1, expect Levels 2-4 to change
>    quite a bit if we decide that this is a good approach.
> * I don't think just doing Level 1 is compelling enough. It's there
>    merely to illustrate the minimum necessary to accomplish a
>    Web Payment round-trip.
> Here's the document so far, we could discuss Payment Architecture Level
> 1 on the Payment Agent call tomorrow.
> -- manu

Dave Longley
Digital Bazaar, Inc.

Received on Friday, 24 April 2015 19:32:04 UTC