Just for the record I wanted to place the
response we have given in the SPEM forum:
>>>>>>>>
Hi Peter,
Our decision of proposing an alternative solution
should in no way be a reflection of anything you have done personally.
Our team has much respect for the dedication and thoroughness that you have
brought to this project.
We simply need to have some leeway to articulate the
concepts we have in mind in the context of a holistic solution that is not
limited by seemingly arbitrary constraints. You have clearly indicated in
the following email and on other occasions that what we are proposing is not in
the context of the current specification document and therefore cannot be acted
upon. We simply want to put a comprehensive solution forward that is
freed from that limitation.
I hope you don’t view this as a last minute
effort by Osellus to impede the progress of SPEM 2.0. Process modeling
and enactment is all we do and every week of delay in the ratification of SPEM
2.0 has an impact on us. This is why we have attended nearly every
conference call and meeting right from the beginning of the project.
I am reluctant to quote all the instances where we
have raised specific issues that were ignored or put to the side because I
don’t believe a confrontational approach would be productive.
Suffice it to say that when we finally sent out a documented collection of some
of the high level issues we were told by IBM: “Can you agree with this
proposal or would you prefer to work on your own specification? Please,
let me know as we still intend to submit this specification next Monday as we
promised to the OMG in Atlanta.
Would you like to be on the submitter list for that document or do you want to
work on your own model instead?” We are simply responding to that
call.
We are very interested to work with the current
submission team that is led by IBM and, in any case, see this as inevitable if
we are going to arrive at a single meaningful proposal that is ready for
ratification. However, based on our experience to date, we feel it would
be more efficient if you first give us an opportunity to document our proposal
in its entirety before we can put the two solutions side by side and work on
discussing the differences collaboratively. I am confident that we will
gain and not lose time.
In regards to SPEM’s relationship to EPF, I am
at a loss as to how the two projects can be separate when IBM maintains such
tight dependency between the two. Peter, the perception--and I really
only mean perception-- that IBM is leaving with us and many other players is
that the product is out in the market, and now every effort is being made by
IBM to force the specifications of an open industry body to be the same as that
of the product. If this is just a wrong perception, I apologize for even
stating it. If it is not, we would greatly appreciate IBM’s support
in allowing this specification to evolve into a meaningful and relevant
specification.
Thanks,
Kamal and Osellus SPEM Team.
<<<<<<<<
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Peter Haumer
Sent: Tuesday, April 18, 2006 3:48
PM
To: Eclipse Process Framework
Project Developers List
Cc: epf-dev@xxxxxxxxxxx;
epf-dev-bounces@xxxxxxxxxxx
Subject: Re: [epf-dev] Looking for
SPEM2 supporters
Well, I do not see any sense to have this discussion in
this forum as well; as we already replied to your points in the SPEM forum. This
was about the EPF support for the specification and not about your concerns
with our work. Here the reply we posted in the SPEM forum:
>>>>>>>>
Hello
Kamal.
We
have tried very hard to address the proposals and concerns you issued. I
have commented on every single one of your concerns, including a 2000 word (!)
reply to the slides you sent to this emails list as your adjustment proposal. I
have yet to receive any concrete response to my reply, and you have explicitly
said that you refuse to discuss your proposal over the phone. Pete Rivet
also sent you his comments embedded into the PDF file you provided and you did
also not reply to these (at least not to this email list).
Some
of the proposals you made we communicated clearly as not feasible or their
usefulness was not clear to incorporate them. For example, your
suggestion on how to model "extensibility" Pete Rivett and I both
replied indicating why it will not work (as extensibility passes on property
values and is not inheritance of property definitions).
The
proposals you sent were not in the context of the current specification
document. They were just slides without any written specification text
and not related to the meta-model packaging that we decided upon as a whole
group (based on Borland's feedback after the first submission). Hence,
there was no way to incorporate these into the submitted specification.
The
submission team members and this email list were able to review the
specification before submission. I followed exactly the process we
defined for this submission in Tampa
which was documented in the minutes and I sent out the document for everyone to
review on March 17th. This was a week later than I promised, but I
apologized for that and we did not get any emails from anyone with concerns
about that delay. Feedback received, such as Softeam's requests for a
SPEM 1.1 example as well as the 1.1 stereotype icons, were incorporated, but no
substantive changes were done since the 17th.
Regarding
your comments on EPF and SPEM2: IBM and many other OMG members have
collabaratively worked on OMG specs as well Eclipse open source projects where
it made sense. These two are indpendent projects.
In
summary, we would not like to loose you as a submitter and value your input. However,
we have requested that you a) present your ideas as change requests to the current
proposal’s meta-model packaging, rather than start from scratch, b)
provide semantically valid proposals or at least reply to our doubts about
their validity, c) are prepared to discuss your proposals in a collaborative
fashion, rather than refuse to discuss them. The above are all key criteria for
meaningful collaboration around standards and you participating and rejoining
in the submission. Otherwise, we wish you good luck with your endeavor.
Thanks and best regards,
Peter Haumer.
<<<<<<<<
Thanks and best regards,
Peter Haumer.
______________________________________________________________
Rational Software | IBM Software Group
PETER HAUMER, Dr. rer. nat.
RUP Development, Cupertino,
CA
Tel/Fax: +1 408 863-8716
______________________________________________________________
|
"Kamal Ahluwalia"
<kamal@xxxxxxxxxxx>
Sent
by: epf-dev-bounces@xxxxxxxxxxx
04/17/2006 12:24
|
Please
respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
|
|
|
To
|
<epf-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[epf-dev] Looking for SPEM2 supporters
|
|
Peter,
I am not sure where the assumption that Osellus would be negatively impacted by
a successful EPF project has come from. Perhaps we have said something
that was misleading. I can use this opportunity to clarify our intent and
plans.
Osellus is a methodology agnostic company and we are looking forward to
offering the capability that would allow the OpenUP content to be made
available to our customers. We sincerely appreciate what IBM and the rest
of the EPF team have done in brining focus and attention to this important
area. Osellus will be one of the resulting beneficiaries.
We have decided to propose an alternative SPEM 2.0 submission in partnership
with Fujitsu, Microsoft, and Sun. We are doing this to deal with a number
of concerns we had expressed but for whatever reason were not being addressed.
We were concerned that the IBM proposal was geared primarily towards RUP,
its approach of base content variability and application in process workflows
was inadequate and fails in many scenarios, was not forward compatible with
SPEM 1.1, could not be enacted, and was unnecessarily complex.
The alternative SPEM 2.0 proposal will address these issues. It is not an
anti-IBM proposal and we plan to build on some of the excellent work IBM has
done in this area. At any time, we welcome the opportunity to use the
OpenUP content in our proposal submission. We also plan to validate the
concepts in our proposal with Macroscope content from Fujitsu, Microsoft
Patterns and Best practices and MSF, and a number of SPEM 1.1 processes from
Sun and other organizations that have modeled their processes in SPEM 1.1.
As you know, we tried very hard to incorporate meaningful changes into the IBM
proposal. At first we were told that we are slowing down the process and
not presenting any concrete and meaningful changes. Then we were depicted
as an organization that was stuck in SPEM 1.1 and does not want any change to
the specification. When we proposed a number of concrete changes to the
current proposal, IBM asked why we don’t pursue our own proposal.
By pursuing a separate proposal, we are simply trying to present a
solution in an atmosphere that is free of arbitrary constraints.
At the outset of the EPF project, we suggested that EPF uses the ratified SPEM
1.1 specification so we would have the time and flexibility to make SPEM 2.0
into something that addresses the industry needs as outlined in the SPEM 2.0
RFP. This is the link for the newsgroup discussion on this topic: http://www.eclipse.org/newsportal/article.php?id=1944&group=eclipse.technology#1944
. Once the specification is ratified, the next version of EPF can be based on
it. Our suggestion went unheeded.
In closing, I would like to reiterate that Osellus as an IBM partner is an EPF
supporter and is keenly interested in seeing the OpenUP open source content on
whatever emerges to be SPEM 2.0. We are confident that IBM would let the
process evolve naturally, irrespective of what products and content it may have
already developed.
Thanks,
Kamal
Peter Haumer wrote:
Hello.
I am presenting our latest SPEM 2.0 submission (get the document at http://www.omg.org/cgi-bin/doc?ad/06-04-05) to the OMG
on April 26th at the OMG meeting in St.
Louis.
This specification is very close to the meta-model that we implemented for EPF
Composer. However, it also already incorporates some of the changes and
future directions that we discussed in Atlanta (e.g. around the modeling of
Tools), simplifies the usage of categories having no standard ones, but
allowing modelers to define their own, additional associations for Activities
to allow process without method content, etc.
As we discussed in Atlanta,
EPF might go into different directions in the future, but it would be good for
EPF to state that is currently based on an OMG specification. In that
respect, it would be very helpful to our submission if most companies working
in EPF would actually officially support it.
I have not asked this before, because the submission process seemed to go
smoothly and this submission was intended to be the final one. However,
in a new development companies who seem to be negatively impacted by a
successful EPF project come forward and want to start their own specification
work. This initiative is started by Osellus and Fujitsu. They claim
support from Microsoft and Sun. Thus, it would be good if we could add
your names on our side as supporters.
Thank you so much for your positive or negative reply by Thursday 20th.
Thanks and best regards,
Peter Haumer.
______________________________________________________________
Rational Software | IBM Software Group
PETER HAUMER, Dr. rer. nat.
RUP Development, Cupertino,
CA
Tel/Fax: +1 408 863-8716
______________________________________________________________
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
