Re: [epf-dev] OMG, SPEM, SEMAT, and EPF

["chris.armstrong@xxxxxxxxxxxxxxxxx" <chris.armstrong@xxxxxxxxxxxxxxxxx>]

Bruce, as you know, APG has built a very comprehensive and detailed SPEM2 models for TOGAF 8 and TOGAF 9 and subsequently used the SPEM2 models as the design specs for implementing TOGAF in EPF. Also, one of our associates is also working on capturing OOSEM (Object-Oriented Systems Engineering Method) in EPF. APG also has numerous clients who have adopted EPF (or RMC) and have used it to extend base content (such as OpenUP, RUP, TOGAF, etc) or have created their own methods from scratch. It's really hard to say exactly how many people have used SPEM/EPF/RMC, but I think it's safe to say there are likely hundreds, if not thousands, of organizations that have already made this commitment.

With respect to the notion of a SEMAT kernel (which I'm still not sure what elements are in it -- couldn't seem to find a list of candidate elements), it seems to me that a potentially easy way to do that in SPEM would be to create a new "base" method plugin for SEMAT kernel elements, similar to the SPEM 2.0 Base Plugin defined in the SPEM2 spec (chapter 18).

It puzzles me when I look at some of the SEMAT blogs (in particular, http://sematblog.wordpress.com/2010/10/23/semat-a-status-report-on-the-kernel/ Section 5: Key solution) that the SEMAT folks claim that "Our solution as outlined here is fundamentally different from earlier approaches, such as SME, SPEM, OPF, EPF, UP, SWEBOK and CMMI." I certainly can't speak to all of these, but having been involved in SPEM and EPF, I certainly disagree. While the language used might be different, it seems pretty clear that what the SEMAT group is up to is VERY similar to our intentions with SPEM and EPF (see SPEM section 6.2).

Most troubling is, that while I disagree (which is a subjective opinion, likely biased by my unfamiliarity with SEMAT objectives), the authors of the SEMAT blogs do not provide any rationale or justification on why they feel their approach is "fundamentally different". Their claims would be better substantiated if they had attempted to use SPEM/EPF to do "SEMAT stuff" and had actual evidence regarding its insufficiencies.

In any case, don't want to ramble to much more here, but certainly count on me to help with the formal EPF (and SPEM) response to the RFP. Don't know what your schedule is like next week, Bruce, but I could do a call with you and other interested parties either Monday or Tuesday...

Have a great weekend!

Thanks, Chris ~:|


From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Bruce Macisaac
Sent: Thursday, April 28, 2011 2:08 PM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] OMG, SPEM, SEMAT, and EPF


Dear EPF community,

The ESSENSE/SEMAT RFP is moving forward in OMG, and if we in EPF want to influence that standard, we need to provide an official response, preferably in the next week.  There will be further opportunities to comment on the RFP, but I would like to provide
an initial response to make it clear that this is important to EPF and we do plan to engage in the discussion.

I have attached the most recent version of this RFP that I have, and will post any updates as they become available.


I am working on an official response, but I need input from the community.
Specifically - it would help to have a list of who is using EPF content?  Who has extended the tool and content, or built new tools or content based on EPF or SPEM?
Who would be impacted by a change to the underlying meta-model of EPF?
Please send a note to me at bmacisa@xxxxxxxxxx so that I can compile comments.

Since EPF is based on SPEM, another OMG standard, it's in our best interest to make sure that any new OMG process standard fits
with SPEM and moves in a direction beneficial to EPF.

If there are changes you would like to see to SPEM, the meta-model on which EPF was based (http://www.omg.org/spec/SPEM/2.0/) let me know.  Also if you have specific comments on the RFP, or have feedback on the comments I expressed in my initial email on this topic (attached), please let me know in the next few days preferably.

Thanks to those who responded to my initial email on this topic:
John Allen, Diwant Vaidya, Chris Armstrong, Bob Palank, James F Tremlett.

I will add you to a "EPF/ESSENSE" interest group, and will copy you on my proposed official response to the RFP and solicit your input.
Anyone who wants to be added to this list, please send me a note.

Thanks,

Bruce MacIsaac
bmacisaa@xxxxxxxxxx
408-250-3037 (cell)




----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Dear EPF community,

There was a recent submission to OMG to propose a new process standard.
It is not based on SPEM or any of the work we have done in EPF, but rather is based on the SEMAT kernel work.
(For those who don't know this, EPF was originally based on SPEM http://www.omg.org/spec/SPEM/2.0/ )

Some  reasons given for why the proposal ignores SPEM is:

1. "lack of enactment support"
If this is a significant concern, then a set of requirements for what would be appropriate enactment support should be described in the RFP.
A goal to what people actually do vs. what they are supposed to do isn't a sufficient set of requirements.
There are some hints in the RFP, but they aren't clear:
"Methods can be queried to get guidance based on where you are and where you want to go"
- this seems to be about describing how the processes evolve during enactment - this could be a natural extension to SPEM

2."The notion of composable practices is not explicitly defined as a core concept in the SPEM metamodel"
This seems to be a gap which could be addressed by a SPEM update.  Note that both SEMAT and EPF have gone beyond SPEM and
added support for practices to their method offerings.  They both use similar concepts and provide similar capabilities, but not identical.
This kind of divergence is exactly the kind of problem that standards organizations like OMG strive to avoid, so the time
is ripe to add practices support to SPEM.

3. "UML profile ... might be more complex and not as user-friendly as a more domain-specific language"
There is also a MOF representation of SPEM, but in any case, any approach for simplifying is welcome, but doing something completely unconnected
doesn't make a lot of sense.

4. SPEM does not specify a kernel of "essential elements"
Both SEMAT and EPF define such a kernel, but use different terminology and have made different choices regarding those essential elements.
Again, this is where standards are valuable - they align the best of divergent ideas so that the entire community can benefit.
The EPF kernel has been defined and publicly available for some time.   It is well supported by both the EPF Composer and Rational Method Composer tools.
It is based on an extension to SPEM.
A natural path forward would be to take the EPF kernel and formalize it in an extension to SPEM, reconciling differences with the SEMAT kernel to the benefit of the entire community.  I propose an extension, because I think SPEM should remain capable of modeling processes that don't use a kernel, or
that use alternative kernels.

If this is a topic that interests you, and you would like to be involved in this discussion, please drop me a note.

Bruce MacIsaac