Difference between revisions of "Viewpoint Advocacy Groups"

From Second Life Wiki
Jump to navigation Jump to search
 
(17 intermediate revisions by 6 users not shown)
Line 1: Line 1:
(This is an early draft document, created for feedback purposes.  It does not reflect a consensus recommendation, or statement of policy at this time.)
{{Template:AWG_NavBox}}
[[Image:slarch.jpg]]
(This is an early draft document, created for feedback purposes.  It does not yet reflect a consensus recommendation, or statement of policy at this time.  However, a number of VAGs have been [[Viewpoint Advocacy Groups#List of VA-Groups|defined]] and are in active use.)


Stakeholders in the Architecture have various agendas, goals, and viewpoints.  These views are critical to the design of the new grid.  This proposal is to create groups to focus on specific requirements.  The list of Viewpoint Advocacy Groups may grow and shrink during the course of this project.  The idea here is to provide a framework to address specific concerns in a systematic way.
The general approach is that recommended in [[IEEE_1471|IEEE-1471]].  Stakeholders in the Architecture have various agendas, goals, and viewpoints.  These views are critical to the design of the new grid.  This proposal is to create groups to focus on specific requirements.  The list of Viewpoint Advocacy Groups may grow and shrink during the course of this project.  The idea here is to provide a framework to address specific concerns in a systematic way.


"Membership" in a group is not exclusive.  Anyone can participate in as many or few groups as they deem appropriate.  Participation in a Advocacy Group does not imply lack of participation in the core AWG, which is merely an umbrella for all working subgroups.
"Membership" in a group is not exclusive.  Anyone can participate in as many or few groups as they deem appropriate.  Participation in a Advocacy Group does not imply lack of participation in the core AWG, which is merely an umbrella for all working subgroups.


Here is the organizational layout of the VAGs:
== Organizational structure for Viewpoint Advocacy Groups ==
 
Proposed organizational structure and definition of VAGs is under discussion on the [[Talk:Viewpoint_Advocacy_Groups|Talk page]].  All contributions welcome.
[[Image:vag-org.png | 400 px]]
 
Here is a conceptual layout of the VAGs:
 
[[Image:vag-concept.png | 400 px]]
 
:* The above picture places areas of concern into separate boxes, and then defines groups which cross-cut over one or more of them. This makes it topologically identical to the structure of our existing VAGs, except for the fact that the layout of the boxes (which may have been only for simplicity) is flawed because it shows the areas of concern as disjoint, which they most certainly are not.  In contrast, the existing VAGs reflect the reality that concerns are intertwined in extraordinarily complex ways in any non-trivial system like SL. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:07, 18 October 2007 (PDT)
::* It's easy to demonstrate how the existing VAGs achieve exactly what you want but without the incorrect disjointness in the model.  The [[Scalability VAG]] highlighted right from the start that further subgrouping was expected, so I'll do that for you now as an illustration.  Event scalability is ''exactly'' the kind of user-oriented concern which you advocate, so it now has its own [[Event Scalability VAG]]. -- '''DONE''' --[[User:Morgaine Dinova|Morgaine Dinova]] 20:37, 18 October 2007 (PDT)
::* The benefit of having an umbrella parent is immediately apparent, since only the new and more specific concerns of the new sub-VAG need to be defined, and everything else can be inherited.  What's more, the more technical working group of the parent can supply the traceable documents/views required by the sub-VAG, even if this is beyond the competence of the (possibly non-technical) members of the latter.  I see a lot of benefits to this structure. --[[User:Morgaine Dinova|Morgaine Dinova]] 19:47, 18 October 2007 (PDT)
:: So you'll have Event Scalability sub-VAG, Event Security sub-VAG, Event Physics Sub-VAG... Since event people have concerns in all those areas.  My proposal is to just have "Events VAG", and they will touch on all the issues. [[User:Gigs Taggart|Gigs Taggart]] 22:28, 18 October 2007 (PDT)
::* Oh, I'm all for an Events VAG, since that reflects a particular viewpoint.  However, that is such a colossal area that it will split very rapidly into Mass Events VAG (focus on crowd packing), Interactive Events VAG (focus on speed and control), Spectator Sports VAG (focus on non-interactive events in stadiums), Observer Mode VAG ([[Use_Cases#SecondlifeTube]]) and many others, mostly referenced to their parent for sanity.  And that's precisely the structure I set up for the scalability-oriented VAGs, so no disagreement there, except for the matter of disjointness of architectural areas which is simply incorrect. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:34, 19 October 2007 (PDT)
 
Note these groups are just examples of what a group might be.  Notice that high level architectural issues are not VAGs, rather, all VAGs will consider high level architectural issues from their unique viewpoints.  For example, "Security" is not a viewpoint, so a "Security" VAG would make no sense.  All viewpoints will consider security in their own unique way, and provide input.
 
:* It's precisely to avoid the "everyone considers everything in the architecture" problem that we have subgroups.  We actually started off without subgroups, you may recall, and there was a huge amount of heat verging on warfare because the different viewpoints of different people prevented collaboration --- this is why we defined VAGs with cohesive interest sets in the first place. It wasn't out of our love for paperwork. We found a desperate need for isolation of concerns. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:07, 18 October 2007 (PDT)
::This isn't "Everyone considers everything", it's "Everyone considers all the parts of the architecture that are relevant to their stake, from the point of view of that stakeholder." It's a subtle but important difference. [[User:Gigs Taggart|Gigs Taggart]] 22:37, 18 October 2007 (PDT)
:::* Which of course defines the existing 4 VAGs very nicely. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 04:43, 19 October 2007 (PDT)
 
VAGs can be a way to bring less technical people into the fold and get their valuable input.  You do not need to understand the technical issues to provide input into a VAG. The VAG delegates, however, should understand the technical issues involved in fulfilling the architectural requirements of a viewpoint, as this will be required in their participation in the core AWG.
 
:* I'm fine with that, although the hierarchy implied by "delegates" admitted to the inner sanctum of "core" isn't helpful. I would expect the flatness of a VAGs-only model to work better in our non-corporate workgroup.  I don't fee strongly enough about it to object though. My other two points above are much more fundamantal. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:07, 18 October 2007 (PDT)
 
:* Gigs - thanks for putting this together. I like the VAG being more "user" oriented than "programmer" oriented. In my mind we ultimately need clear set of use cases. I would see each VAG responsible for defining these use cases and synthesizing them into something the architects can use. So, in theory, having a "Builder" VAG seems closer to the user than a "Geometry and Physics" VAG. Now here is where I start to have a harder time because there are so many builders with very little in common. We have prim builders using the SL tools, numerous Sculpted Prim tools, people using Maya and blender, people wanting to "build" by exporting from other tools (i.e mechanical CAD), people wanting to build from different viewers, and people eventually wanting to import from other VWs. You would also have viewpoints from programmers wanting to do this with an API and users wanting better UI. So really, you would need a number of VAGs for building and probably a couple more for other types of creation (maybe that is ok). Maybe being a programmer, I can't separate myself so completely from the architecture. Its hard not to think from the stand point that we have a geometry sub-system and what are the use cases for interacting with it.  --[[User:Burhop Piccard|Burhops Piccard]] 20:12, 18 October 2007 (PDT)
::Well, in my vision, you'd have to decide what level of granularity is appropriate there.  The VAGs aren't going to be without internal differences of viewpoint, but in the end the stake should be the same: You all want to do "foo", where "foo" is whatever the VAG is about.  You'll still have to consider all the use cases to accomplish "foo" that you are aware of, even if no one in the group does it ("it" being that particular use case to accomplish "foo") personally.  [[User:Gigs Taggart|Gigs Taggart]] 22:31, 18 October 2007 (PDT)
 


== Purpose of Viewpoint Advocacy ==
== Purpose of Viewpoint Advocacy ==


The core goals of the AWG are as follows:
The purpose of Viewpoint Advocacy within the AWG includes the following:


:* Document rationale for architectural decisions.
:* To base architectural decisions on use cases via viewpoints.
:* Integrate the requirements of each viewpoint group.
:* To establish requirements from the concerns in each viewpoint.
:* Negotiate and document conflicts between each viewpoint.
:* To integrate the work of the separate viewpoint advocacy groups.
:* Integrate feedback from the various viewpoint advocacy groups.
:* To document, negotiate and resolve any conflicting concerns.
:* Produce a coherent architecture.
:* To produce a coherent architecture that conforms with the above.


A successful Viewpoint Advocacy Group requires:
A successful Viewpoint Advocacy Group requires:
Line 59: Line 36:
::* Name of the viewpoint
::* Name of the viewpoint
::* List of stakeholders holding this viewpoint
::* List of stakeholders holding this viewpoint
::* A statement of areas included and excluded from the viewpoint
::* List of concerns addressed by this viewpoint
::* List of concerns addressed by this viewpoint
::* Language, modeling techniques, representation method or tools used within this viewpoint
::* Language, modeling techniques, representation method or tools used within this viewpoint
Line 70: Line 48:


== List of VA-Groups ==
== List of VA-Groups ==
<!-- Put these in alphabetial order -->
In alphabetical order:
* [[Event Scalability VAG]] (illustration)
* [[Accessibility VAG]] (ensuring Second life is accessible to users with disabilities)
* [[Core Grid Services, Protocols, and Structures VAG]] (REST, c-http, escrow, capabilties, and core protocols)
* [[Event Scalability VAG]]
* [[Geometry and Physics VAG]]
* [[Geometry and Physics VAG]]
* [[Grid Interoperability VAG]]
* [[Live Performances VAG]]
* [[Quality Assurance VAG]]
* [[Quality Assurance VAG]]
* [[REST Services VAG]]
* [[Scalability VAG]]
* [[Scalability VAG]]
* [[Communications VAG]] (XML-RPC, email, HTTP requests, bots, etc.)
[[Category: AW Groupies]]

Latest revision as of 13:15, 2 October 2008

Open Source Portal

Slarch.jpg (This is an early draft document, created for feedback purposes. It does not yet reflect a consensus recommendation, or statement of policy at this time. However, a number of VAGs have been defined and are in active use.)

The general approach is that recommended in IEEE-1471. Stakeholders in the Architecture have various agendas, goals, and viewpoints. These views are critical to the design of the new grid. This proposal is to create groups to focus on specific requirements. The list of Viewpoint Advocacy Groups may grow and shrink during the course of this project. The idea here is to provide a framework to address specific concerns in a systematic way.

"Membership" in a group is not exclusive. Anyone can participate in as many or few groups as they deem appropriate. Participation in a Advocacy Group does not imply lack of participation in the core AWG, which is merely an umbrella for all working subgroups.

Organizational structure for Viewpoint Advocacy Groups

Proposed organizational structure and definition of VAGs is under discussion on the Talk page. All contributions welcome.

Purpose of Viewpoint Advocacy

The purpose of Viewpoint Advocacy within the AWG includes the following:

  • To base architectural decisions on use cases via viewpoints.
  • To establish requirements from the concerns in each viewpoint.
  • To integrate the work of the separate viewpoint advocacy groups.
  • To document, negotiate and resolve any conflicting concerns.
  • To produce a coherent architecture that conforms with the above.

A successful Viewpoint Advocacy Group requires:

  • To present a set of related concerns about the system in the form of a clear viewpoint.
  • To document architectural specifications that stem from this viewpoint.
  • To consider the architectural needs of likely implementations that fulfill the specifications.
  • To operate in a way that allows for alternate implementations that satisfy the viewpoint.
  • To work with the core goals to document views and requirements that conflict or are inconsistent.
  • To review the core goals against the work output to ensure that the view's requirements are met.
  • The end result of the above is an architectural description which reveals the architecture from this viewpoint.

Defining a Viewpoint

A good viewpoint might include the following elements: (borrowing freely from Emery):

Required:
  • Name of the viewpoint
  • List of stakeholders holding this viewpoint
  • A statement of areas included and excluded from the viewpoint
  • List of concerns addressed by this viewpoint
  • Language, modeling techniques, representation method or tools used within this viewpoint
  • Source for the viewpoint
  • Use Cases
Optional:
  • Consistency/completeness tests for the viewpoint
  • Evaluation/analysis techniques
  • Heuristics, patterns, other guidelines
  • Estimation of associated cost in resources

List of VA-Groups

In alphabetical order:

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Viewpoint_Advocacy_Groups&oldid=94265"