Fwd: Thoughts on the OGF Technical Direction and Roadmap Document
Folks, Some thoughts from our leader of our little project Begin forwarded message:
From: "Linesch, Mark" <mark.linesch@hp.com> Date: 3 August 2006 21:39:18 BDT To: "David Snelling" <d.snelling@fle.fujitsu.com>, "David Snelling" <Dave@ThePlateau.com> Cc: <scrumb@ggf.org> Subject: Thoughts on the OGF Technical Direction and Roadmap Document
Dave,
I promised you a few thoughts to think about during vacation ;-) See attached and hope you have a great and productive time off!
Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
Hi David, all, I tried to come up with some productive comments and suggestions for the 'strategy and roadmap' document, but some points are still somewhat unclear to me. I see quite some difference between, for example, the OGSA roadmap, and the TSC/OGF strategy and roadmap. That does not neccessarily mean difference in terms of content, but in approach: the OGSA roadmap is made by those people who are going to follow it, and who will make it a reality. If the TSC writes down a roadmap, who will care? Remember, OGF is a volonteer army, which will not, or only with resistance, follow any advise or roadmap not created by the very volonteers which are supposed to implement it. So, is the TSC strategy and roadmap supposed to merely _describe_ what the areas and groups plan to do anyway, or is it in fact trying to do real steering, as it tries to plan ahead for what _should_ be done by the areas and groups? The descriptive approach may be somewhat disappointing to the intended target audience I assume. The prescriptive approach may, as said, be overpromising, and hence would counter the OGF motto 'under-promise -- over-deliver". What do you think is the right balance between these points? What are the mechanisms for the realization of a potential prescriptive roadmap? Thanks, Andre. Quoting [David Snelling] (Aug 04 2006):
Folks,
Some thoughts from our leader of our little project
Begin forwarded message:
From: "Linesch, Mark" <mark.linesch@hp.com> Date: 3 August 2006 21:39:18 BDT To: "David Snelling" <d.snelling@fle.fujitsu.com>, "David Snelling" <Dave@ThePlateau.com> Cc: <scrumb@ggf.org> Subject: Thoughts on the OGF Technical Direction and Roadmap Document
Dave,
I promised you a few thoughts to think about during vacation ;-) See attached and hope you have a great and productive time off!
Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org
-- "So much time, so little to do..." -- Garfield
Andre, On 8 Aug 2006, at 05:21, Andre Merzky wrote:
Hi David, all,
I tried to come up with some productive comments and suggestions for the 'strategy and roadmap' document, but some points are still somewhat unclear to me.
I'll see if I can help.
I see quite some difference between, for example, the OGSA roadmap, and the TSC/OGF strategy and roadmap. That does not neccessarily mean difference in terms of content, but in approach: the OGSA roadmap is made by those people who are going to follow it, and who will make it a reality.
Right.
If the TSC writes down a roadmap, who will care? Remember, OGF is a volonteer army, which will not, or only with resistance, follow any advise or roadmap not created by the very volonteers which are supposed to implement it.
I agree with you here. This is one of the challenges we face. The overall approach that I hope will work is that we set the roadmap to point in the direction we are already heading. Then the TSC roadmap acts as an affirmation to the troops that they are doing the right things. However, I do expect that there will be places we can identify where there will need to be some rallying of the troops. Here we have an important role to play. If there is some gap in the overall picture that does not appear to be on the informal agenda of the existing troops, then the TSC's relationship with key stake holders can help to generate more effort aimed at those goals.
So, is the TSC strategy and roadmap supposed to merely _describe_ what the areas and groups plan to do anyway, or is it in fact trying to do real steering, as it tries to plan ahead for what _should_ be done by the areas and groups?
There is also the possibility that some steering can take place. Remember our volunteers are actually paid by someone. If the organizations see a need then the troops might be encouraged to change focus partially. But over all, we need to be mostly descriptive, with an overall aim to unify the directions of any mostly parallel activity.
The descriptive approach may be somewhat disappointing to the intended target audience I assume. The prescriptive approach may, as said, be overpromising, and hence would counter the OGF motto 'under-promise -- over-deliver".
I'm inclined to promise little; offer much more, subject to increased involvement from stake holders; and deliver as much as possible. We will also need to identify that guaranteed delivery.
What do you think is the right balance between these points?
Again, mostly descriptive, hence using the OGSA technical roadmap as a starting point. The second focus should be on unifying what else there is. Third focus on gaps and other priorities to motivate increased involvement.
What are the mechanisms for the realization of a potential prescriptive roadmap?
1) Use it to generate new effort already dedicated to the prescribed direction, 2) Rallying cry for faster progress. 3) Slight changes in direction motivated by technical justification (we are the Technical Strategy Committee after all). 4) Ideas welcome.
Thanks, Andre.
Quoting [David Snelling] (Aug 04 2006):
Folks,
Some thoughts from our leader of our little project
Begin forwarded message:
From: "Linesch, Mark" <mark.linesch@hp.com> Date: 3 August 2006 21:39:18 BDT To: "David Snelling" <d.snelling@fle.fujitsu.com>, "David Snelling" <Dave@ThePlateau.com> Cc: <scrumb@ggf.org> Subject: Thoughts on the OGF Technical Direction and Roadmap Document
Dave,
I promised you a few thoughts to think about during vacation ;-) See attached and hope you have a great and productive time off!
Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org
-- "So much time, so little to do..." -- Garfield _______________________________________________ Tsc mailing list Tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
Thanks David, those answers help. Cheers, Andre. Quoting [David Snelling] (Aug 10 2006):
Andre,
On 8 Aug 2006, at 05:21, Andre Merzky wrote:
Hi David, all,
I tried to come up with some productive comments and suggestions for the 'strategy and roadmap' document, but some points are still somewhat unclear to me.
I'll see if I can help.
I see quite some difference between, for example, the OGSA roadmap, and the TSC/OGF strategy and roadmap. That does not neccessarily mean difference in terms of content, but in approach: the OGSA roadmap is made by those people who are going to follow it, and who will make it a reality.
Right.
If the TSC writes down a roadmap, who will care? Remember, OGF is a volonteer army, which will not, or only with resistance, follow any advise or roadmap not created by the very volonteers which are supposed to implement it.
I agree with you here. This is one of the challenges we face. The overall approach that I hope will work is that we set the roadmap to point in the direction we are already heading. Then the TSC roadmap acts as an affirmation to the troops that they are doing the right things. However, I do expect that there will be places we can identify where there will need to be some rallying of the troops. Here we have an important role to play. If there is some gap in the overall picture that does not appear to be on the informal agenda of the existing troops, then the TSC's relationship with key stake holders can help to generate more effort aimed at those goals.
So, is the TSC strategy and roadmap supposed to merely _describe_ what the areas and groups plan to do anyway, or is it in fact trying to do real steering, as it tries to plan ahead for what _should_ be done by the areas and groups?
There is also the possibility that some steering can take place. Remember our volunteers are actually paid by someone. If the organizations see a need then the troops might be encouraged to change focus partially.
But over all, we need to be mostly descriptive, with an overall aim to unify the directions of any mostly parallel activity.
The descriptive approach may be somewhat disappointing to the intended target audience I assume. The prescriptive approach may, as said, be overpromising, and hence would counter the OGF motto 'under-promise -- over-deliver".
I'm inclined to promise little; offer much more, subject to increased involvement from stake holders; and deliver as much as possible. We will also need to identify that guaranteed delivery.
What do you think is the right balance between these points?
Again, mostly descriptive, hence using the OGSA technical roadmap as a starting point. The second focus should be on unifying what else there is. Third focus on gaps and other priorities to motivate increased involvement.
What are the mechanisms for the realization of a potential prescriptive roadmap?
1) Use it to generate new effort already dedicated to the prescribed direction, 2) Rallying cry for faster progress. 3) Slight changes in direction motivated by technical justification (we are the Technical Strategy Committee after all). 4) Ideas welcome.
Thanks, Andre.
Quoting [David Snelling] (Aug 04 2006):
Folks,
Some thoughts from our leader of our little project
Begin forwarded message:
From: "Linesch, Mark" <mark.linesch@hp.com> Date: 3 August 2006 21:39:18 BDT To: "David Snelling" <d.snelling@fle.fujitsu.com>, "David Snelling" <Dave@ThePlateau.com> Cc: <scrumb@ggf.org> Subject: Thoughts on the OGF Technical Direction and Roadmap Document
Dave,
I promised you a few thoughts to think about during vacation ;-) See attached and hope you have a great and productive time off!
Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org
-- "So much time, so little to do..." -- Garfield _______________________________________________ Tsc mailing list Tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- "So much time, so little to do..." -- Garfield
Dave, I think it's great that we're having this discussion - I'll throw in my perspective, coming to OGF from EGA, which had a technical *steering* committee (as opposed to a technical *strategy* committee). GGF has been very much a grassroots, bottom up organization - there was very light steering by the ADs, mostly in attempting to keep people to charters and timelines. But before a WG or RG could get started, there was an approval process - which meant that there was some sort of roadmap or concept of overall scope of work appropriate for the GGF. I think that OGF's TSC is an attempt to formalize that scope of work - to translate the overall goals of OGF (as stated by the OGF Board) into a concrete technical avenues of interest. The TSC charter says as much in 4.1. It is also an attempt to drive the standards process more directly (section 4.2) - providing leadership and direction to the army of volunteers, rather than just hoping they will do work in the areas that are critical to progress in the world of grid computing. Rather, the strategy that the TSC delivers is the source of decisions around "what should OGF work on?" - an active effort to communicate direction and progress. Andre asks - "If the TSC writes down a roadmap, who will care?" I think that everyone in a WG or RG will care, because the acceptance or non-acceptance of their charter will depend on the degree to which it fulfills items on the roadmap. This will be something of a culture shock for many members. As Mark L says in his thoughts about our output document, "It is one of the most important documents for us to deliver". This tells me that the OGF board is not content to continue the "business as usual" bottom up structure of the past. The structure of OGF makes this clear, as well. That said - I am uncomfortable with the prospect of naming OGSA as the "flagship architecture". The survey Dave put out showed that the a large majority of respondents agreed that OGF should have a small number of different architectural approaches to grid. There has been a moderate amount of ... dissent about OGSA in recent GGF meetings ("people are building perfectly functional grids without OGSA - why are we waiting for it?"). In addition, the EGA/GGF merger team agreed on Day 1 that OGSA would not become the defacto "flagship architecture", and that it would be positioned as one architecture, noting that most enterprise customers and may science/research customers were NOT using OGSA or the Globus TK. To some extent, yes, it makes sense to point in the direction that we're headed for the transition. I don't believe that includes simply proposing the OGSA technical roadmap, especially given the disparities shown in the survey results between the gaps, priorities, and OGSA. We might benefit from 'proposing' to make it a/the flagship architecture, air it out and give the members a chance to comment on that idea. That's different from declaring it. Our volunteers are paid by someone, as Dave points out - someone who has paid to participate in this organization. Some of those people did *not* choose to be part of GGF, and have been convinced to join OGF with the promise that it will not just be more of the same. Our job, in part, is to figure out how to make that happen - to highlight the critical issues facing the community, to provide some direction and focus to solve those critical issues, so the organization can be perceived as one that produces outputs other than meetings and documents. Trying to produce a "moon shot" statement is a good exercise. I'm not convinced that
The Open Grid Froum should commit all its available resources to the goal, that before this decade is out, commercial and academic organizations will build real operational grids using OGSA based components!
No other single technical goal will more completely focus the activities of our newly united organization or more clearly define its success or failure … and no other goal will be more challenging or difficult to achieve.
is the right one - nor that it does much to meet the Board's goal of showing tangible results in a 12-18 month timeframe. Best, chris
Chris: I have a couple of comments in response to your remarks, that may perhaps spur some useful discussion. 1) The role of the roadmap. You write: Andre asks - "If the TSC writes down a roadmap, who will care?" I think that
everyone in a WG or RG will care, because the acceptance or non-acceptance of their charter will depend on the degree to which it fulfills items on the roadmap. This will be something of a culture shock for many members.
I'm a big fan of a roadmap and of proactive attempts to engage the right people in producing the right specifications at the right time. I don't think that we will get where we want to be if we don't do that. That said, I don't see why, if a group emerges "bottom up" with a well-argued and technically strong case for a specification that isn't in the roadmap, we would want to forbid that group from forming. E.g., maybe some comes forward and says that we need to define this particular XAMCL profile, so that we can share this particular set of policies. I doubt that's in the roadmap, but it could well be important to some group. Allowing for that possibility will avoid alienating valuable OGF members, and avoid the technically and politically difficult challenge of having to capture in the roadmap everything that anyone might need to do. 2) The role of OGSA You express some concerns about OGSA. I think these are important issues to discuss. However, before we do so, we need to be clear about what we mean by the term. Is OGSA: a) A grand, top-down, boil-the-ocean attempt to define all possible service interfaces needed in current and future grids? Or: b) A principled approach to define, in an incremental but consistent manner, simple Web Services-based interfaces for the most important things that people need to do in grids, like job submission and management, data movement, etc.? We've debated this in the past, and I guess you can tell which side I come down on (-:. I firmly believe that (b) is the approach we have to pursue. I also note that it is the approach that we are pursuing in practice. Now it may be that there are people in OGF who just aren't interested in Web Services, and for them, OGSA (because of its Web Services focus) may not be appropriate. However, I would hope that for everyone else, it can be. And I think not only will be very important to get engagement from players like Oracle in pursuing (b), but that you will find that your inputs will be welcomed. Regards -- Ian.
participants (4)
-
Andre Merzky -
Chris Kantarjiev -
David Snelling -
Ian Foster