[Management] [Product Council] The product life cycle and Sakai 3

[Michael Feldstein]

Fair enough. This isn't a comprehensive solution to the problem, but how 
about asking product teams that want to leave R&D to produce a map of 
proposed services for review by the Product Manager/Product 
Council/community at large? Get the project teams thinking about 
services early and trigger a broad discussion about how their pieces 
might be useful to others or even what pieces they're not thinking of.

As an aside, what we're running into here strikes me as a relatively 
generic challenge of doing SOA across organizational/product boundaries. 
There must be some best practices out there. Amazon.com, here we come....

- m


Clay Fenlason wrote:
> [Sending to both product-council and management while that list
> discussion is still going on]
>
> On Thu, Jul 16, 2009 at 9:07 AM, Michael
> Feldstein<michael.feldstein at oracle.com> wrote:
>   
>> Once again I find myself drawn to a distinction between services
>> and...vignettes. (I hate that term, but I guess we're stuck with it.)
>>     
>
> I don't think we're stuck with vignettes as a term. I've seen it so
> generally panned that I'd be happy to see an alternative emerge.
>
>   
>> Vignettes are low-impact and can be developed roughly similarly to the
>> tool-centric process up until the moment that they require new services that
>> we believe are likely to be re-used by other vignettes or until they require
>> modification to existing services that are being used or are likely to be
>> used by other vignettes. At that point, John and Clay's concerns kick in. So
>> it will be important to identify any new cross-cutting service requirements
>> or any modifications to existing services at a relatively early stage in a
>> project. If that flag goes up, then we'll need to trigger an extra
>> sub-process (the specifics of which are TBD) that would address the
>> coherence and coordination questions.
>>     
>
> Well, ok, but I think part of the issue is what 'the moment that they
> require' means, and how it's introduced into the reckoning.  Required
> by whom or what, and when? Product coherence may often introduce
> requirements that the project team hasn't anticipated, and even at the
> level of page widgets this will generally be the case.  But then I
> think it wouldn't be especially helpful to project teams to start with
> the position "if you're doing a widget, the old tool model should be
> fine until someone raises a flag."  So I think your point makes sense
> as a way of slicing up the concepts, but it's less successful as a
> suggestion for process and practice. Rather, I think we need a fairly
> good set of cross-cutting considerations that project teams should
> bear in mind at the very beginning - even in R&D - and then if some
> can be ruled out early or late, well, great, but I think it needs to
> be worked that way 'round.
>
> This is what I had in mind when I say product visioning will often
> need to be out ahead of projects, rather than playing catch-up and
> imposing new considerations late in the game.
>
> ~Clay
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>   

-- 


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/management/attachments/20090716/5320477e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/management/attachments/20090716/5320477e/attachment.gif