Peter,
Osellus has a favorable view of the EPF initiative. EPF brings
collaboration between the industry players and draws focus to a space that that
is of tremendous interest to us. It is to that end, that right from the
beginning, we have espoused an approach that would base EPF on an open industry
standard as opposed to a proprietary metamodel.
In our view, it is best to leave the development and evolution of
standards to consortiums such as OMG, ISO and the like.
In an earlier communication, we suggested to adopt the open industry
standard of SPEM 1.1 for EPF. SPEM 1.1 has assumed a significant
following among many corporations in North America, Europe and Asia. Many, if not most, methodologies have
been successfully modeled using SPEM 1.1. By basing EPF on SPEM 1.1, the
process investment made by content and tool providers and users would be
preserved and everyone would benefit from greater interoperability.
Since then, we and a few other stakeholders have developed the SPEM 2.0
proposal. This proposal will be considered by OMG in its upcoming
meeting. We feel it has a number of significant merits that make it more
suitable for adoption as the EPF metamodel. We feel that there is a good
chance that this proposal will be ratified as the SPEM 2.0 specification, but
it is too early to know for certain.
One of the key benefits of this proposal is that it is a natural
extension of SPEM 1.1, providing a smooth migration path for the existing and
ever expanding SPEM users. Our proposal includes the input of many
existing SPEM users and is not tied to a specific tool or methodology. We
are open to taking the EPF team through the other benefits of our proposal.
I share your view that there has been some confusion amongst some of
the involved parties and we are committed to clarify the picture to the extent
we can. I believe the main confusion is that many organizations had the
perception that what IBM had proposed as an EPF metamodel is the same as the
SPEM 2.0 metamodel, whereas, in reality, this is far from being the case.
The SPEM 2.0 metamodel is far from being ratified and is likely to be different
from the current EPF metamodel. This is exactly the point we are trying
to address in this dialogue.
I would like to address your concern that perhaps Osellus is not doing
real work by not being a committer to EPF or by adding committers to the
project. My understanding is that one can either contribute code to EPF
(tooling) or content (OpenUp). As we have indicated to the IBM team in
the past, we simply don’t have more bandwidth at this time to extend EPF
from a tooling perspective. I don’t believe many organizations have
been able to do so yet. Of course, as an ISV, we don’t have any
meaningful content to contribute. This is why we are offering to do the
closest thing, which is offer resources to verify our proposed SPEM 2.0
metamodel with the contents of the EPF contributors. I hope you agree
with our assessment that arriving at an optimum metamodel for EPF is important
and beneficial to both the tooling and content sides of EPF. Conversely,
the whole tooling and content streams in the Eclipse/EPF movement will likely
not benefit the industry without being based on an open industry standard.
Thanks
Kamal Ahluwalia
Osellus Inc.
kamal@xxxxxxxxxxx
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Haumer
Sent: Tuesday, June 13, 2006 11:40
AM
To: Eclipse Process Framework
Project Developers List
Cc: epf-dev@xxxxxxxxxxx;
epf-dev-bounces@xxxxxxxxxxx
Subject: Re: [epf-dev] Alternate
SPEM 2.0 submission
I was asked to comment on this by other EPF committers
who seem to be confused about the fact there is a second proposal.
The
specification the Eclipse Process Framework is built on is available at
http://www.omg.org/cgi-bin/doc?ad/06-06-02
The
Adaptive/Fujitsu/ESI/IBM/Softeam et al spec is technically sound and proven by
implementing most of the concepts in EPF Composer. As EPF and SPEM evolve, our
submission team will continue to help drive convergence of open source and open
standards.
Eclipse
(and the EPF project) has a community driven process in which only people
who do real work on real code can make a difference. We encourage the SPEM team
led by Osellus to directly influence EPF the way in which all Eclipse
projects are influenced - by adding committers to the project.
Thanks and best regards,
Peter Haumer.
______________________________________________________________
PETER HAUMER, Dr. rer. nat.
Rational Method Composer | Eclipse Process Framework
Rational Software | IBM Software Group
Tel.: +1 408 863-8716
______________________________________________________________
|
"Kamal Ahluwalia"
<kamal@xxxxxxxxxxx>
Sent
by: epf-dev-bounces@xxxxxxxxxxx
06/09/2006 17:19
|
Please
respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
|
|
|
To
|
<epf-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[epf-dev] Alternate SPEM 2.0 submission
|
|
Hi EPF Content Committers
I wanted to take this opportunity to update you on SPEM 2.0 progress at the
OMG.
As I had indicated in an earlier post to this newsgroup (http://dev.eclipse.org/mhonarc/lists/epf-dev/msg00312.html),
Osellus, with support from Sun Microsystems and Microsoft had asked for a
single meeting cycle extension (about 3 months) at the last OMG Technical
Committee Meeting in St. Louis.
The OMG unanimously approved this extension to provide an opportunity for the
presentation of an alternative SPEM 2.0 submission. Borland who was a
co-submitter of IBM-led submission also decided to join us as a co-submitter of
this alternate Borland/Osellus/Microsoft/Sun submission. This proposal
uses some concepts of the previous proposal co-submitted by Adaptive, Borland,
ESI, Fujitsu, IBM, Osellus and Softeam.
A copy of this alternate submission is attached. It has also been uploaded to
the OMG server, http://www.omg.org/cgi-bin/doc?ad/06-06-01.
We are seeking the feedback of software process experts and end users on this
submission. We would like to invite EPF content committers, and in particular
the OpenUp committers, to provide your feedback on this meta-model. We
are more than open to consider your suggestions and recommendations to make
this proposal more applicable and meaningful. We are prepared to commit
the necessary resources to take a representative sample of the processes and
methodologies of your choosing to validate our proposed SPEM 2.0 meta-model.
To the extent that you may be open to this idea, we would like to
incorporate parts of your methodologies as examples in the next draft of the
proposal.
Our goal in this submission is to avoid unnecessary complexity. The
submission maintains a balance between process content and process workflow, is
backwards compatible with SPEM 1.1, is completely methodology agnostic, and
addresses the increasingly strategic differentiator of process enactment. Our submission
is not restricted by the capabilities of any existing commercially available
tool in the market. However, Osellus is fully committed to offer the
required toolware to model and enact SPEM 2.0, once the specification is
ratified, irrespective of the form it takes.
Thanks,
Kamal.
kamal@xxxxxxxxxxx
[attachment "SPEM 2.pdf" deleted by Peter
Haumer/Cupertino/IBM] _______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
