Viewpoint Advocacy Groups

(This is an early draft document, created for feedback purposes. It does not reflect a consensus recommendation, or statement of policy at this time.)

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.

Here is the organizational layout of the VAGs:

Here is a conceptual layout of the VAGs:

• 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. --Morgaine Dinova 18:07, 18 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. --Morgaine Dinova 18:07, 18 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. --Morgaine Dinova 18:07, 18 October 2007 (PDT)

Purpose of Viewpoint Advocacy

The core goals of the AWG are as follows:

• Document rationale for architectural decisions.
• Integrate the requirements of each viewpoint group.
• Negotiate and document conflicts between each viewpoint.
• Integrate feedback from the various viewpoint advocacy groups.
• Produce a coherent architecture.

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
• 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

• Geometry and Physics VAG
• Grid Interoperability VAG
• Quality Assurance VAG
• REST Services VAG
• Scalability VAG