Sounds to me like you're oversimplifying. Insisting on a single model element to represent some real-world entity, MySystem say, is a bit like writing a Word document where the word MySystem is only allowed to be typed in once and everywhere else you want to use that word you have to place a cross-reference to that single occurrence. Technically it works, but it just doesn't make sense to do it that way.
For my opinion BPMN and Archimate are just notations. They are using Shapes to "show" something. Archimate "shows" a Process resp. Process Step in a different way than BPMN. But they a both using the same model, the Process resp. Process step. It's like the MVC-Pattern. A number can be shown in a viewpoint as a column or as a cycle (the size shows the amount in comparison to other numbers). Both views (Shapes) represent the same model, the number.
That may be your opinion, but it's not shared by OMG or the Open Group. Both standards use shapes to show "something"s, but the "something"s that are being shown are not the same "something"s. This is what gets you into trouble. Just because the two standards organizations happened to pick the word "process" for one of their respective concepts, that doesn't mean that an ArchiMate process is the same thing as a BPMN process.
Continuing your MVC analogy, there is no single universal definition of "a number". In a mathematical model, it can refer to the set of integer (or fractional, or real, or imaginary...) numbers -- but in a model of musical theatre it refers to a song-and-dance routine. You're trying to mix two models which are not quite as far apart as all that, but they are not one and the same.
Secondly, a process in ArchiMate is not the same thing as a process in BPMN. They are two completely different standards, from two different (and in part, competing) standards organizations.
Both are notations.
Both are notations
with semantics. There is a lot more to them than the mere shapes, and if you ignore the defined semantics of your chosen notation, you're missing the point of using a standard in the first place.
If you have created a BPMN process, you have made a conscious decision not to display a certain shape but that you mean this element to represent a BPMN process. If you have created an ArchiMate process, you have made a conscious decision that you mean this element to represent an ArchiMate process.
Looked at a different way, what you're trying to do appears to be to create a new modelling language which extends both ArchiMate and BPMN. Which is no small task.
No!!! I am using different viewpoints showing different aspects of an Enterprise Architecture. I am using Archimate to show a system landscape and Process Steps using it. And I am using BPMN to model these Process Steps in a flow. Two different viewpoints, to different notations. Nothing merged. The are just using the same elements in the project browser which should be shown according the the standards used for the respctive viewpoints.
If you want to show two aspects of the same entity in your architecture, the best way is to let each EA element represent one aspect of that entity, not the entire entity. The same goes if you want to show the same entity in two different models using two different notations. So if a process in your architecture has some BPMN characteristics and some ArchiMate characteristics, model those as two different elements and connect them (if necessary) with a trace or realization.
I would say, that's plain wrong. It's either the one or the other and does not depend on the viewpoint. If you have some "Jekyll and Hyde"-element your design has likely a flaw. q.
O.K. So I have to create a shapescript for each shape and for each property of the shape (e.g. for an BPMN "Activity": loop, subprocess, etc.)? This would be about 20 shapscripts only for "Activity".
And if the Business Analyst want to change the property of the shape (e.g. from loop to subprocess), he has to replace the shape with a new shape and redrawing all connections?
What we're trying to say is that you're taking the wrong approach with a single element for a single real-world entity. If you instead use one element for each aspect of the real-world entity, the problem goes away.
/Uffe
