Talk:Viewpoint Advocacy Groups

Organizational structure of VAGs

• I moved this discussion here since point-counterpoint and attribution tagging are both inappropriate in the main namespace, and the discussion was obscuring the information on the page as well. --Morgaine Dinova 06:40, 19 October 2007 (PDT)

Here is a proposed 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)

• 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 --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. --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. 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. --Morgaine Dinova 04:34, 19 October 2007 (PDT)
• I took your suggestion on board and started composing an Events VAG. It immediately became apparent that this served no purpose whatsoever. Every gathering of people is an event, and if you look at the astronomic spectrum of possible event types, there is very little commonality indeed. I thought I might find use for an Event VAG as an umbrella group, just to simplify subgroups, but even that fell through because events vary so hugely that the only common elements are those that apply to everyone in SL. However, your idea did lead me to create one specific event-based VAG, as follows. --Morgaine Dinova 05:07, 20 October 2007 (PDT)
• The Live Performances VAG now exists to focus end-user concerns in the various areas of live performances into a cohesive viewpoint. --Morgaine Dinova 05:07, 20 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)

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. Gigs Taggart 22:37, 18 October 2007 (PDT)

• Which of course defines the existing 4 VAGs very nicely. :-) --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. --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. --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. Gigs Taggart 22:31, 18 October 2007 (PDT)

Yes, I think I agree with that. So in my example above FOO = "more easily creating better geometry". So, horizontal/vertical model is not quite right to me (sorry I'm slow Morgaine :-) There are certainly some VAG that do fit this and I agree that VAG should not purposely try to mirror the architecture. But I'm starting to feel the VAGs should look a bit more like this:

(Note: the red lines are mostly random. I'm not trying to suggest any VAGs here.) --Burhop Piccard 09:17, 19 October 2007 (PDT)

• That's fine by me, Burhop. It takes us back to where we were initially, where a VAG's concerns may address any area of the system as required, without prior constraints. In other words, system areas are enumerated vertically, and if the list is complete then it serves no purpose since it will then mean "everything", which is correct. Good luck trying to keep the list complete though. :-) --Morgaine Dinova 09:31, 19 October 2007 (PDT)

Viewpoints: the substance behind the concept

If you take a few steps back from our metadiscussion above and look at what's being happily accepted from the very relaxed guidelines of IEEE-1471 and what's being omitted, the picture that emerges is a curious one. It reminds me of Feynman's story about "cargo cult science", in which the protagonists accept the form but don't understand the function that underpins it.

IEEE-1471 deals with architectural design of systems, yet it is based on the concept of viewpoints, which at first glance have nothing at all to do with architecture --- mighty peculiar! It doesn't require a lot of reading to discover why this is so though: it's because you can't really define architecture in any other way, no matter how hard you try, and no matter how convinced you are that you are doing it objectively and independent of viewpoints. You are satisfying only one viewpoint --- your own, or multiple viewpoints of your own, or of your own interest group.

Implicit in that concept is that you can't subdivide up architecture in a single way a priori and then dish out pieces of it to various working viewpoint groups. If you could make such a subdivision then that would imply that your unique breakdown already models architecture to first order, either functionally or structurally, in which case viewpoints aren't being used in their IEEE-1471 role of delivering architectural descriptions at all, because it's predetermined.

Accepting only the process of viewpoints really isn't very helpful. Viewpoints aren't really a process in IEEE-1471 at all, just a consequence of understanding that there can be no architectural description independent of them. What this means is that accepting viewpoints yet still believing in some kind of overriding decomposition is completely missing the core point of IEEE-1471. You might as well have no explicit viewpoints at all.

Viewpoint groups define the breakdown that is most appropriate to them. That's their purpose.
--Morgaine Dinova 08:19, 19 October 2007 (PDT)

• It's worth noting that the pictures above don't necessarily have to represent a priori architectural breakdown at all, but merely a vertical enumeration of areas of interest, all necessarily intertwined because they cannot be disjoint. The intersection of vertical VAG lines with the horizontals then represents exactly the structure of the 4 existing VAGs (and IEEE-1471 viewpoints in general), in that any viewpoint can involve consideration of any area of architecture. In other words, the breakdown contributes no new information, while limiting the scope of VAGs to only those elements listed. (And if they're not limited in scope, then why bother with the list?) It achieves nothing. --Morgaine Dinova 09:18, 19 October 2007 (PDT)

Naming of Viewpoint Advocacy

• I am actually very serious about the slight rename of V.A.G. to V.A.T., as light-handedly discussed on the group chat. Dzonatas Sol 16:13, 11 October 2007 (PDT)

Could you elaborate on the reason for the name change? I see the comment "to keep focus of the right direction, keep in mind about COST, and avoid bureaucracy" but don't quite understand how the name change accomplishes this. --Burhop Piccard 17:56, 11 October 2007 (PDT)

It implies a meaning from recent events, which are significant; however, the name change alone is not a complete solution. It is a minimal change to influence the discussion. The serious point being task focused and cost effective. The Tao Of Linden already points out the need to not be political. Zero also reiterated about the need to have no ego in code. The emphasis of "groups" and "core AWG" can easily be a politicized medium, and we want to avoid that. We need to stay a team altogether. In AWG chat, we found the intention is not to actually form (sub)groups, but the intent is more to (to quote the article), "Document rationale for architectural decisions" and "Work with the core goals to document views and requirements that conflict or are inconsistent." It is inconsistent and political to form more subgroups to do what the AWG already does. JIRA is an example of a better medium then subgroups -- create tasks and subtasks. Again, COST is not something I've seen discussed. COST is an influence here. In fact, a good example of a use case is the recent event between Europe and non-EU currency transactions. Hmm, what's a good way to say it with too many details... look at ArchWG_Mtg_1_Slides and create an analogy of "mainland" to the U.S. -- and remember that the pipe between US and EU is limited. Then you'll get the notion that the "V.A.G." (as previous defined) IS the AWG. The question becomes, why change it from "A.W.G" to "V.A.G."? Dzonatas Sol 19:07, 11 October 2007 (PDT)

• I very much support the idea of working on tasks, rather than belonging to a group. I intend to work on (or have an interest in) numerous tasks, maybe all of them to some degree, so group membership isn't a very helpful concept in this. --Morgaine Dinova 23:21, 11 October 2007 (PDT)

• Dzonatas' point about "groups" vs "core AWG" potentially creating a dangerous politization is very important. By placing all concerns into their own VA task groups, including those who some feel are "core", the entire structure is flattened and all choices have to be justified equally. The "core" tasks (and the groups working on them) will then no longer be special, but simply represent those concerns that we have agreed on a priori, like using REST. This is a much cleaner and less adversarial project structure, in my view. --Morgaine Dinova 23:32, 11 October 2007 (PDT)

• I've just realized that we're editing in User:Gigs space at the moment. You might as well promote it to main namespace. It's not like on Wikipedia where you'll get 500 people screaming blue murder at you. ;-))) There weren't any dissenting voices in the AWGroupies chat against this, nor competing ideas. --Morgaine Dinova 08:54, 13 October 2007 (PDT)

• It was moved from V.A.G. to V.A.T. back to V.A.G., which shows a concern. Also, Gigs stated below "These aren't tasks" where in group chat I thought we agreed on the task perspective. That doesn't seem true (anymore?). This seems like the best place to work with this idea. We've had other pages moved to users pages on this wiki, so this is doing just likewise. Dzonatas Sol 09:22, 13 October 2007 (PDT)

• I honestly don't think that there is any effective disagreement here among the entire set of participants. Ultimately the same static pages have to be edited, and it doesn't matter how those evolving documents are viewed. Those whose view is task-based will multitask between their various pages of interest, and those who are group-oriented will see themselves as belonging to one or more groups. I think this will work! :-) --Morgaine Dinova 05:38, 20 October 2007 (PDT)

Groups

To be clear, we ARE talking about groups here. We have groups of stakeholders with their own concerns. These aren't tasks, they are groups.

You all mention "politicization" ... Groups of people will want certain things, depending on what their stake is. Trying to deny that is just going to lead to a lot of useless bickering. This is supposed to be a framework for various groups to advocate their viewpoint and to ensure that their requirements are met as best we can.

It's supposed to be slightly adversarial, in the same sense that a prosecuting attorney and a defense attorney are adversarial. It doesn't mean they can't go have dinner together after the trial, or even switch roles in the next trial. We are all working toward the same end, but that doesn't mean we all need to advocate the same viewpoints.

Membership in one of these groups isn't exclusive, and there's no reason one person can't be a member of more than one group, or a member of one of these groups and also of the core team. In that sense it isn't polarizing, since there's nothing preventing participation anywhere that someone wants to participate. It's merely a construct to provide a way of thinking about stakeholder groups, their needs, and integrate them into the design.

I'm renaming this back to groups.

Gigs Taggart 11:47, 12 October 2007 (PDT)

These groups should have their own meetings, and produce their own output. This allows for a finer grained focus than one huge group with many stakeholders all trying to pull the group in their own direction. I expect most of these subgroups to be from 3-7 people. This is an ideal size for actually getting things accomplished. Larger groups are REALLY BAD at getting anything done. Gigs Taggart 11:58, 12 October 2007 (PDT)

• I think this is a fine idea. I like the idea of having organized groups feed in specific use cases and requirements, rather than a central group needing to do a ton of heavy lifting. I don't think Linden Lab can facilitate all of this, but we certainly don't want to obstruct it. -- Rob Linden 12:59, 12 October 2007 (PDT)

• I support these well-focussed viewpoint groups because they can help reduce arguing over a single spec document, and therefore raise the spirit of collaboration. :-)

As you say, it can be seen as slightly adversarial, but I put quite a different slant on it because of my past history: engineering requirements are ALWAYS in conflict with each other, and therefore require cooperative assessment and calm, professional tradeoffs to be made. These viewpoint groups allow us to approach that structurally, but only if the structure is flat and the playing field level. One issue illustrates this: we've already seen some people express that their concerns and work are so "core" that they don't even need to describe a viewpoint because "core" overrides everything else. That approach does not create an atmosphere of collaboration, which is why I want everyone to buy into your idea rather than consider themselves above it. --Morgaine Dinova 07:58, 13 October 2007 (PDT)

Nothing is above the VAGs. The VAGs will review the work output of the core group in every way. If the core group is proposing something that a particular VAG can come up with a coherent critique on, then that should be reexamined. Gigs Taggart 22:57, 13 October 2007 (PDT)

• Sounds fine to me then Gigs. :-) If nothing is above the VAGs, then "core" must either have no hard design issues associated with it at all (since it involves no concerns/tradeoffs), or else it must be a VAG since it will necessarily express a viewpoint. :-) --Morgaine Dinova 01:08, 14 October 2007 (PDT)

• There are still concerns here that have not been addressed. If the "calm, professional tradeoffs to be made" are to ignore views as done here then how can we expect these groups to fulfill the overall requirements? How can we expect them to even fulfill the goals listed on the article when the implementation of these VAGs don't even follow such viewpoint design? We can't expect that. Again, I reiterate the need to avoid any kind of politics here by these groups. We already found problems in attempts to go forward with the current VA-groups. There is lots of thoughtful work being done that I hate to see go to waste by being misdirected or being too limited. We need a simple flat foundation to begin. Let the elements of the foundation not be limited by these groups. I understand the concern over one large group, and we obviously agree there needs to be a way to break it down. I believe it can be done by more technological method than by a need to form these subgroups. Dzonatas Sol 08:22, 18 October 2007 (PDT)

• Dzon, I agree 100% with the goals that you mention above ... yet I can't find anything here in conflict with those goals! Surely the huge problem isn't merely "group" vs "task"? I was happy with it reverting to VAG after the change to VAT because it makes no actual difference to what we're doing --- we're still going to define the viewpoints, regardless of whether this has a group or a task focus. They're two sides of the same coin, as I see it. :-) --Morgaine Dinova 13:44, 18 October 2007 (PDT)

• If you remember, Gigs even stated in group chat that this being a wiki and feel free to edit it instead of any statement to address the concerns, and that is exactly what occurred here. It was edited to express the concerns. AWG is already a "group." There is no clear viewpoint or clear view to why we need specific subgroups. The subgroups, as suggested by VAG structure, create potential politicization. I also addressed further concerns about that in the above paragraph. Where is the viewpoint that created this VAG implementation? Where do you see "core AWG" defined and why needs there be a "core AWG"? Are they a self appointed group or who appointed them or is all members "core"? I can think of several questions to ask. How are resources set up for these subgroups? What happens when a viewpoint spans several concerns from several groups? Where is the JIRA resource to individualize each issue? ...? We can create viewpoints without subgroups, but if there is a need for a subgroups then "eat your own dog food" and start with the viewpoint/use case for it and address the concerns. I also suggested on the AWG Process talk page to setup "office hour" style times that would be friendly to specific geographical area, and let those discussions work with those agendas. Dzonatas Sol 14:36, 18 October 2007 (PDT)

• I'll ignore the Office Hours timetabling here, not because it's unimportant but because that's a matter for each subgroup to define since it is a function of where their members happen to live. The ability to timetable in a manner that satisfies everyone in a group is inversely proportional to the size of the group, which is a small but not insignificant benefit of subgrouping.
• I'll try to answer your other questions though:

• AWG is certainly a group, but it's a group with such a broad remit that it functions poorly without paritioning, which I'll explain in relation to your second point.
• Your claim that "There is no clear viewpoint or clear view to why we need specific subgroups" is quite wrong: the need for subgrouping emerged out of a direct and very overt requirement. AWG started off without subgroups, and this led to a considerable amount of heat and near warfare as a result of the very different viewpoints and interests of the participants. We expressly chose to subgroup along viewpoint lines to avoid this problem, which was quite literally destroying collaboration as well as wasting everyone's time in the IM channel. That was the reason why, and it was exceedingly important.
• Re politization, VAGs don't add any more of it: at the end of the day, every non-trivial project has conflicting requirements, and they need to be reconciled in a satisfactory engineering manner through tradeoffs. The benefit of subgrouping however is that this difficult process only happens after the concerns have been well quantified, whereas without subgrouping you end up with the same discussions throughout the whole project and before anyone really knows in depth what they're talking about.
• The viewpoint that created this viewpoint system doesn't exist because we picked the nearest solution to hand that addressed our (rather bad) problem. Rather than getting involved in more divisive discussions, we coopted the basic elements of IEEE-1471 as several people seemed happy with them, and nobody else offered any alternatives. There wasn't a conspiracy nor a diktat. :-)
• I have no idea what "core AWG" means, nor what it's meant to accomplish, nor how it can do anything but cause division. The VAG model simply puts everyone's concerns into their own viewpoint groups, including those people who may have considered themselves to be "core" and thus special. With VAGs they are no longer special, yet their concerns are still met. Everyone wins.

• I can't really comment on the other issues. I am however concerned that we're spending so much wiki time on metadiscussions. VAGs aren't perfect, but they're adequate. I don't see a big problem. --Morgaine Dinova 19:23, 18 October 2007 (PDT)

More on groups vs tasks

• The implementation of these VAGs need their own viewpoint and views (not the suggested views/viewpoints from the VAG itself); however, the concerns listed on the VAG page have not been addressed. That already sets a bad example for any future views. The design and model of these VAGs just have not been completed because concerns have been ignored. Dzonatas Sol 07:43, 18 October 2007 (PDT)

• Transplanted from the main namespace of Quality Assurance VAG, where it was clearly off topic since it is not a concern within that viewpoint. It's a good point, but made in the wrong place. This would appear to be the most suitable location. --Morgaine Dinova 13:33, 18 October 2007 (PDT)
• Dzon, I didn't see your last entry in the section above, or I would have responded, sorry. As you can see in the section above though, I don't actually understand the problem that you're highlighting. I do want to. :-) The actual VAG work seems to be progressing smoothly, and I can't see any structural faults with it yet. Maybe you could describe the problem you see in the context of an existing VAG, as an illustration? --Morgaine Dinova 14:03, 18 October 2007 (PDT)

"Eat your own dog food"

I can already see the politics started with "groups" and this is one area we don't need those kind of politics. Even as Rob suggested that LL does not have the means to facilitate. If you want groups Gigs, I suggest you document this more -- "eat your own dog food." I believe there is enough on the front article to know what to include when you write your viewpoint. At this time it is not complete enough, and it be better to have more to understand each other rather than wheel war about it. I think I've written more on this discussion than what you wrote in the article, and maybe that should say something in itself, especially if I continued into further details. I'm looking for your details of your viewpoint. What I changed into "tasks" is the attempt to use modern technology that is already provided to achieve the same goal without the politics, but you don't see that. Dzonatas Sol 07:44, 13 October 2007 (PDT)

• I don't mind either way. The viewpoints are the central idea here (and I didn't invent that). Of course the people gathered around a viewpoint form a group. And what they do is a task. But it's not worth arguing about the name. Just get everyone to subscribe to one or more viewpoints (very lightweight!!), and all will be fine. :-) --Morgaine Dinova

• Yes, it can be very simplified in that view. Modern technology allows easy subscription and *bam* you have the groups automatically behind it. I see no reason to actually define the groups, but there is reason to define the tasks and worry about cost. Dzonatas Sol 08:09, 13 October 2007 (PDT)

• Good point about cost. I'll add that to the general template that's emerging for defining viewpoints. "Regions on Mars" might denote an interesting viewpoint, but its cost field might have some bearing on its viability. ;-))) --Morgaine Dinova 08:18, 13 October 2007 (PDT)

Viewpoints and the inter-VAG reference graph

In working on various VAGs, I've noticed that an interesting inter-VAG inheritance/composition/reference graph is emerging:

• Some VAGs are devolving by decomposition into sub-VAGS: eg. the Scalability VAG quite naturally decomposes into one sub-VAG per dimension of scalability. The Event Scalability VAG is already such a sub-VAG and brings together a very focussed and useful viewpoint, while inheriting many elements from its parent VAG. The resulting relationships are the usual ones found in inheritance and composition graphs.
• Some user-level VAGs express concerns that necessarily cross-cut across numerous quite different areas of system architecture, function, and performance, and so these VAGs couple by reference to any number of other VAGs. Using the Live Performances VAG as an example, it expresses highly varied user-level concerns relating to live performances, and some of these are examined in more detail in the technical Event Scalability VAG to which it refers, while others might be examined in (say) a System Performance VAG, an Avatar Control VAG, and so on. This makes me see end-user VAGs as demultiplexers for spraying concerns into technical VAGs, to form a dense dependency graph.
• The technical VAGs may each be focused on a specific viewpoint, but they're not disjoint. On the contrary, focussing on a given viewpoint necessarily implies reduced focus on other areas, which means that those other areas are open to coverage by other VAGs, to which the first VAG should refer where relevant. Furthermore, technical VAGs can be expected to refer to the concerns of user-level VAGs directly when examining use cases. The result is naturally a very complex reference graph.

One of the interests of the Quality Assurance VAG will be to determine the degree of conformance of any aspect of system architecture with the concerns expressed in viewpoints. With a bit of luck we can automate the VAG-walking to yield a nice reference graph as a byproduct of concern traceability checking. That could be visually interesting. :-)
--Morgaine Dinova 08:22, 20 October 2007 (PDT)

To put it another way, the fact that there is a wiki reference between two VAGs adds semantic information to the normal web linkage here, and we can use that fact to focus attention on areas that are critical to many viewpoints and which affect the most users. This could be powerful.
--Morgaine Dinova 08:52, 20 October 2007 (PDT)

Why don't we introduce a new concept then, the "cross-cutting issue". A cross-cutting issue would be off limits in terms of creating an explicit VAG for it, but every VAG would be required to examine their output's impact on each cross cutting issue? Gigs Taggart 18:58, 20 October 2007 (PDT)

• You can't have individual "issues" appearing from thin air, they need justification somewhere. That's why issues are first analyzed thoroughly in end-user VAGs by end-user stakeholders in the context of all the relevant areas simultaneously, which gives them justification, and are then presented as fully baked concerns for other VAGs to take as requirements and constraints. That analysis can't be done in the technical VAGs because those try to focus on one area at a time, whereas end-user VAGs will in almost all cases have concerns that span numerous areas simply because normal user activity usually spans numerous areas. As I explained further up, it's fundamental to the viewpoint concept that each set of stakeholders has to define and extract its own ADVs, because this is how the architecture expresses its conformance with their concerns. No other VAG can do that for them, because no other VAG has their scope and concerns. --Morgaine Dinova 01:03, 21 October 2007 (PDT)

There are some issues that are clearly cross-cutting. Scalability, security, possibly more. These are not things that can be designed in a vacuum. Every group must consider scalability and security issues as their output. You can't just design that stuff in a single subgroup, it's got to be part of everything. Gigs Taggart 07:19, 21 October 2007 (PDT)