RE: Harvesting experience as well as architectures

Mike, you said ...
 
>>>So, we have to focus on the "must have" requirements of the greatest
number of participants<<<
 
This begs two questions:
1. What are the "must have" requirements and how do you prioritize them
2. How do you define the "greatest number of participants" ... it really
depends on your perspective
 
If we put the solutiohn to all the functional requirements into one
specification in order to try and meet "everybody's" needs, then I don't
think we won't succeed as:
* you can never please 100% of the people 100% of the time
* how do you update just part of a spec because of new technology
developments.
 
One initiatives that tried was ebXML. This specification included its own
way of signing a SOAP envelope . But what's going to happen now  that WS
Security (in OASIS) is going to start. You can't have two ways of signing a
SOAP message, so either ebXML has to migrate to WS Security or the two have
to live together.
 
So what does this mean?
 
I think it means that we have to identify individual bits of useful
functionality, e.g. for reliable messaging or security, and then work out
how to combine them in a way so that:
1. We have one way of doing something ... it avoids reinventing the wheel,
and
2. We define how to use each piece of functionality so that each
specification can evolve as the technology in each area evolves
3. We put in place "control" mechanisms so that define how each piece of
functionality is used in combination to meet specific needs, so that, at any
point in time, there is at least a reasonable chance of realizing
interoperability ... which is what this game is all about.
 
David

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Sunday, July 14, 2002 6:24 PM
To: www-ws-arch@w3.org
Subject: RE: Harvesting experience as well as architectures


 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Sunday, July 14, 2002 7:24 PM
To: 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: Harvesting experience as well as architectures



 

The problem is that I don't think that one size fits all. So even if we want
to go for the 80/20 rule (which I agree is a good idea) which 80% do we go
for as one person's nice to have is another's must have ... thoughts? 

That's a very good point.  There's clearly an art to finding the right
balance between having enough features to be useful and being simple enough
to be understood.  http://www.4hb.com/08jcparetoprinciple.html
<http://www.4hb.com/08jcparetoprinciple.html>  and
http://library.shu.edu/HafnerAW/awh-th-math-pareto.htm
<http://library.shu.edu/HafnerAW/awh-th-math-pareto.htm>  (or Google for
"pareto principle" for a lot more) describe the idea here in more detail.

I think the point of the 80/20 rule for us is to seek the set of features
that give the most power in return for the least cost in complexity.  Or to
put it differently, to add those features that can be easily accomodated by
minor tweaks to the rest of the architecture, and to resist those that
require major new components to implement.  Of course, it's just a
heuristic: there's no guarantee that one can even minimally satisfy everyone
without a lot of complexity.  Also, both SOAP and REST appear to be textbook
examples of the Pareto principle in practice, but there may not be a clean
way of combining them.  (I personally think that there is ...but that's
another discussion!).

So, we have to focus on the "must have" requirements of the greatest number
of participants, and we can add "nice to have" features that cleanly fit in
with the others with only minor tweaks to the architecture.  But when we
find ourselves spending most of our time for a few weeks debating the
relatively small details or relatively minor requirements, it's time (again
in Tim Bray's words) to determine the "least we can do and still declare
victory."

I think Tim's point about HTML "changing the world" even though it just has
one-way links with no metadata and no redirection is the kind of thing to
look for and look out for.  If we find that we have got the big issues
nailed down but are beating our heads against the wall to get consensus on
the small ones, then it's time to simply revise the requirements document,
or whatever else it takes to "declare victory."   This probably seems
overwhelmingly obvious, eh?  But my point in bringing this up is that it is
a sad truth that a number of standards efforts, within and outside of the
W3C, have gotten stuck on this kind of thing.