RE: Thinking about Web Services Architecture

Hi Joel,

     You are right that the CSF analysis takes some time and concentrated
effort. Having been involved in several projects that used this technique
I've found it to be very useful and effective. There is a well-defined
series of steps that lead to the end goal: a set of requirements for a
successful software project. I'll try to outline them here. In reality, I
was trying to begin going through these steps with my original email. 
	I'd also like to see if Chris F. would be willing to set aside some
time during the first f2f for this, as it is most useful when everyone is
together in the same room, concentrating for a period of time, to achieve
the necessary 'groupthink' that makes for good teamwork.

Steps for critical success factor analysis:
1. Identify the overall objective and use it as your mission statement. I
took a stab at this earlier: a proposed mission "to create a standard
reference architecture for web services". we should thrash this out and get
it settled among ourselves so that we know where we are going.

2. Brainstorm among the group and identify a set of top level goals...these
can be recognized by asking ourselves "if we do these things, will we have
achieved our mission?" This is what I was trying to get started with my
discussion of the list of goals/objective in the first email. I think we are
off to a reasonable start.

3. Once we have the list of 6 or so top level goals we can start to add to a
(probably long) list of CSFs for each goal. Along the way we make a list of
problems that we are attempting to solve, as well as assumptions (conditions
that we think will remain constant). Then, once we've captured the CSFs into
a heirarchy (by importance) we can make a matrix of problems vs. CSFs. Every
problem should be addressed by at least one CSF, and maybe more. The lowest
level of CSFs will be the requirements for our system. 

If only it were as easy as 1 2 3...

	This is just a brief outline, there is more to it but the good thing
about this process is that it is pretty much ensured to result in a set of
requirements that meets the project goals. That sort of closure is rare in
the requirements gathering world, which is why I like this technique.

	As far as a fixed time limit, perhaps we should try to get the
requirements phase done by 2 weeks after the f2f, which would allow us to
collate the material from the meeting?

	As always, just my $0.02+tax.

Regards,

D-





> -----Original Message-----
> From: Munter, Joel D [mailto:joel.d.munter@intel.com]
> Sent: Wednesday, February 13, 2002 2:08 PM
> To: Austin, Daniel
> Cc: www-ws-arch@w3.org; Carroll, Tom; 'mchugh.m@grainger.com';
> 'davoren.m@grainger.com'
> Subject: RE: Thinking about Web Services Architecture
> 
> <jdm>I strongly agree.  I would like to add the following: so 
> that we can
> deliver in a timely manner, we must define a reasonable but 
> enforced period
> of time in which to capture these mission statements, goals, success
> factors, etc.<jdm/>
> 

***********************************************************************
Dr. Daniel Austin, Sr. Technical Architect
austin.d@ic.grainger.com (847) 793 5044
Visit: http://www.grainger.com

"The will is expressed through the hands."

Received on Wednesday, 13 February 2002 18:57:16 UTC