User talk:Zha Ewry/Scoping

• I've been trying to find some way in which this page could be extended, or gently modified, in order to make it reflect the banner goal of the AWG -- "Making the grid a scalable place" --- but I can't find a way. The problem is that, as presented, the page distorts that expressed goal into something completely different.

• A split has been made into normative and informative work products, as if the first were primary. And yet, the first is merely a means to an end, a mechanism that we want to use in the solution of the scaling problem, and as such is entirely derivative, not primary. If we knew of a better mechanism for reaching that goal, we would use it. At this time we believe that REST services are the best tool in our toolbox for this, but they're not the actual goal itself. They're a solution preference.

• It's the final section, "Out of scope", that I least understand. It seems to suggest that actually designing the REST services for scalability is out of scope ... yet that's the primary task of AWG! You cannot avoid considering the structure of the resources which are encapsulated as REST services, because those are the bottlenecks to scalability. Merely attaching a massively scalable HTTP-based access mechanism onto the front of a non-scalable resource doesn't give you a scalable REST service. It gives you a massively congested resource and a largely wasted scalable access mechanism. I've explained this at length in Brainstorming#Illusion of scalability (abstracting resources into clouds).

• Perhaps I can explain this better from a different angle. Sure, when implementing a REST service then the functional viewpoint does not require you to consider the implementation of the resource in question. But the functional viewpoint is only one of the viewpoints of interest to AWG: the other, and a very very big one, is the scalability viewpoint, and that requires examining the resource flow bottlenecks, decoupling them, and then recombining (or restructuring) them in such a way that the front-end REST mechanism can harness the now scalable resource. Both viewpoints are equally valid, and important, when designing a scalable REST service, but the former can be done while treating the resource as a black box, and the latter can't. (See IEEE-1471 for more.) --Morgaine Dinova 21:09, 10 October 2007 (PDT)

• This issue is now bypassed through the use of Viewpoint Advocacy Tasks (name still in flux). What you called normative concerns simply become the viewpoints of your particular VAT, which I expect you'll call something like REST Service Interfaces. Since everyone agrees that we're using REST, it doesn't need to be elevated to some special rank ... it becomes "core" simply because it's part of everyone's architectural worldview. --Morgaine Dinova 00:18, 12 October 2007 (PDT)

• I've added justifications for any work products being claimed as normative. My single entry is justified on the basis of being the primary stated goal of AWG. Everything else is pretty much a detail from that perspective, and could be discarded. This is why I believe that the whole idea of normative work products is ill-founded. System architecture (particular a huge one like this) is far more complicated than a simple division into normative and informative allows. --Morgaine Dinova 02:01, 14 October 2007 (PDT)

• I wish to make clear that my additions do not imply support for this Scoping approach: they are intended to highlight how it is not helpful to use the straightjacket of "normative" in large-scale system architecture (especially ours), as it doesn't reflect the (very clear) banner goals of AWG, and is massively biased towards what is really an implementation detail. --Morgaine Dinova 02:08, 14 October 2007 (PDT)

• Maybe an example will help. If we were delivering the architecture for a national cellphone provider, any list of normative work products would necessarily have to include the definition of network topology, peering systems, cellphone services, and customer support systems. It couldn't claim that network signaling was the only normative work product, just because it's so fundamental. It might be the normative work product on the worksheet of the signaling engineer ... but then, he has a very specific viewpoint. This is why I like the workgroups idea: they can all define their own normative elements. --Morgaine Dinova 02:46, 14 October 2007 (PDT)