Re: Thinking about Web Services Architecture

Daniel,

Please see below.

Cheers,

Chris

Austin, Daniel wrote:

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


I agree that f2f is the best, but we actually have to deliver the
requirements document coming out of the f2f (I'll be discussing
this on today's call) as per the schedule in our charter[1].
We'll actually need to start driving the process via tel-con and
email and we can finish the work at our f2f.


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


See above, we need to get the process started like yesterday:)


> 
> 	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."
> 



[1] http://www.w3.org/2002/01/ws-arch-charter#schedule

Received on Thursday, 14 February 2002 10:41:00 UTC