User:Zha Ewry/Proposed AWG Process

From Second Life Wiki
Jump to navigation Jump to search

Proposed process

This is a very tentative proposed process, based on an attempt to sum up discussion at the AWgroupies informal meeting on October 16. Please note that this is deeply a open, collaborative, collegial process, see IEEE 1471 for some perspective on the overall approach we are trying to pursue. - Zha October 16, 2007 12:05 PM, PDT Updated October 18, 2007, 5:49 AM PDT, to try to capture comments from talk... - Zha

Please comment on this, a shared, consensual view on this is really important!

This is a collaborative, collegial process. We will work From a multiple viewpoint perspective, informed by IEEE 1471 and industry best practices.

The overall flow of the effort is roughly: in parallel:

  • Enumerate use cases
  • Coalesce into Viewpoint Advocacy Groups
  • Lay out common formats for various work products such as use cases
  • Examine and, informed by code and analysis, validate the architectural assumptions and overall approach proposed in High Level Architecture proposed by Linden Lab
  • Enumerate and describe all the current services within SL
  • Enumerate key crosscutting concerns such as performance, security, scalability, possibly via a VAG, or as a side effect of one or more VAGs

Once we have coalesced, the VAGs will, in parallel work through the following steps

  • Work to get a set of use cases, in a common agreed format, with enough detail to drive design discussions
  • Propose basic approaches in enough detail to drive the next major steps
  • Surface concerns to other VAGs and the overall community
  • Code sample implementations of illustrative designs

Ideally, at this point, we will have:

  • A validated set of architectural assumptions
  • A large set of proposed solutions, tied to use cases by the VAGs
  • A core group of people advocating the various viewpoints
  • An enumeration of the current SL services
  • A set of key crosscutting concerns to be used when looking at our work
  • Working code samples to help validate designs and raise concerns


From this, we will need to forge a broad consensus on the overall approach, informed by the work in the first step. The broad consensus would permit us to move into a more detailed round of design, again driven by VAGs.

  • Define the full set of formal entities in the architecture
  • Define the full set of services, protocols, workflows and any other implementable components in the architecture
  • Produce sample implementations of key services and components (Broader, larger efforts than in the first phase)

At this point.. in theory.. we have the simple task of

  • Define each service in sufficient detail to allow an implementation to be built
  • Define each protocol in sufficient detail to allow messages to be constructed and parsed
  • Define each interaction pattern in sufficient detail to allow complete interactions to be tested
  • Define any profiles/subsets in sufficient detail to permit the profiles to be implemented
  • Describe any other materials we identify which would be necessary to allow the creation of conorming components, and

oh yes and "Code it all and test it"

Please observe:

  • Much of our actual work will be delivered in a service delivery environment. In many cases, that code and test, will likely happen over the course of the project, not as a final waterfall step.
  • As several major stakeholders have existing implementations deployed, allowing our results to be deployed in a stepwise evolutionary process, is 'highly' desirable.
  • While we explicitly plan to code throughout the process, the code produced through these steps, will be written according to our current understanding of the architecture, and will likely have to be re-written from time to time to account for changes in our understanding. We will strive to make this as easy as possible, but expect us to break early code when we have to, and be more concerned about a good end result than compatibility with preliminary code.
  • As we move through the phases in this process, our work products will, of need, become more formal and rigorous. Our end goal is a set of specifications which can serve the entire internet.