The "UML Profile for ArchiMate and ArchiMate Meta-model" RFP issued by OMG

After my initial post about Archimate and UML intent to get closer, just a quick update post on the fact that the “UML Profile for ArchiMate and ArchiMate Meta-model” request for proposal (RFP) have been issued by the Object Management Group at the Long Beach technical committee meeting by the Domain TC and is now available at the URL:
The contact person of this RFP is J.D.Baker from NIST. The effort is lead by Fred A. Cummins, Donald R. Chapin, andĀ Claude Baudoin.

The RFP’s work in progress page, which contains a link to the document and all relevant deadlines is located at this URLĀ (Requires OMG access credentials):

So far, no proposals have been submitted, but Sparx Systems and HP have declared their interest and intent to submit.
The main controversy related to the RFP and subsequently to the proposals is about the role and positioning of a UML profile wrt the actual Archimate standard.

The deadline for proposals and for participating to the voting expires on May 18 (in a week!).

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Posts on BPM and UML interaction

Here are the responses I gave on Jordi Cabot blog ( on the issue of business process modeling and of the new CFP for a UML profile for BPMN.

Mixed feelings – but clear understanding Submitted on Thu, 09/16/2010.

I have mixed feelings about this issue: first, about the objective of the move; second, about the advantages it will bring; and third, about the relevance of the discussion.
1) Objective:
If the target is to flatten all the modeling to just one notation and role(the software engineer), then this is definitely a wrong direction.
BPMN and UML have two different focuses (business and software) and are used by different roles (analysts and softengs). We should not forget this… even more: bpmn itself is now perceived as not fully understandable by its target users.
2) Advantages:
Supposing we keep in mind the two focuses, the advantages
of the proposal above could be to allow the orthogonal design of different aspects of the applications by different roles, also granting integrated design of the different orthogonal aspects in a unified design vision (old story on separation of concerns).
3) Relevance:
Well, to be honest I don’t see the discussion as so relevant. In the bpm field the notation issues are more and more seen as marginal aspects (someone is already wondering what will be the fate of BPMN 2.0). I don’t see why we shouldn’t start doing the same in the softeng community.
In term of acceptance and utility of modeling notations, you can see the some lessons learned from our on the field activities here:

Rules for BPM(N) modeling Submitted on Mon, 11/08/2010

For methodological guidelines see also the online decalogue by Bruce Silver Associates:
And also this paper by Michael Zur Muehlen on empirical analysis on the usage of BPM modeling languages (basically more or less a Pareto Rule for moveling languages concepts: less than 20% of the notation and patterns covers more than 80% of cases, or even more):
This is in line with our experience too.