Best practice of extending a modeling language

[EA_enthusiast]

 Hello EA experts,

I want to get your views on the best practices for extending modeling languages, especially ArchiMate.

Scenario: If I want to model the strategy layer in an organization, which uses these elements: vision, mission, goals, objectives and initiatives.

Out of these 5 elements, ArchiMatr has only one, that is “goal”. In this case, which one of the 2 options below is considered a best practice?

Option 1: Use “driver” (already available in ArchiMate) and stereotype it as “mission” and “vision”, Use “goal” (already available in ArchiMate) and stereotype it as “objective” and Use “work package” (already available in ArchiMate) and stereotype it as “initiative”.

Option 2: create totally new 4 elements for vision, mission, objectives and initiatives.

Thank you!

[dge98753]

Hello,

I am not an expert and I found your question really relevant.
I would also be interested to have some expert point of view on that topic.
In between I have found some interesting thoughts into the EA COMPENDIUM first chapter "Why modelling, and why with EA ?".
https://sparxsystems.com/resources/booklets/ebook_list.html
Perhaps it could help your thought too.

[EA_enthusiast]

Perhaps it could help your thought too.

Thank you for sharing this.

[sjf]

I have used the same concepts in our metamodel. I have used Initiative from BizBok, goal from Archimate, the rest I have used from a standard UML Class and then added the connectors that we wanted, for instance an Initiative Produces an Outcome (Archimate)

[EA_enthusiast]

Thank you, sjf, for your input.
There are 3 potential issues with this approach.
(1) Having a collection of perspectives and modeling languages within the same view. If you are modeling the Architecture of the Enterprise and sharing the model with other Architects, the expectations are that you are using ArchiMate.
(2) the look and feel of each perspective and modelling language are different, which will make the view lacks homogeneity.
(3) creating relationships between elements (from different perspectives/modeling languages) may be challenging, and you may end up using non-standard relationships to link the elements. 

What I found to be more practical is using the existing ArchiMate elements to cover your architecture needs. For example, in order to model initiatives, you could use ArchiMate "CourseOfAction" and stereotype it as "Initiative". Similarly, you could use ArchiMate "Goall" and stereotype it as "Objective", and so on.

[sjf]

In answer to your points:
1.) Your perspective can contain different modelling languages, it is upto you in the definition of your metamodel what is included in  your toolboxes and what relationships between the elements are allowed. I would also argue that many Business Architects are used to using BizBok rather than Archimate (as per https://www.businessarchitectureguild.org/)
2.) You can define the look and feel of your new stereotypes to match (using ShapeScript, inheritance and icons)
3.) You will always face this as a challenge, for instance moving from a high-level Archimate view to going to a lower level BPMN view or moving from a Strategic Business Architecture (BizBok) model to an Archimate view (Archimate acknowledge this challenge).

We found that just allowing Archimate without restriction meant that we had the same concepts modelled in different ways, we therefore decided to create a metamodel to restrict the stereotypes & relationships that would be allowed.

We also wanted to utilise the Gartner TIME Framework for Application Portfolio Management which meant adding tags to the stereotypes and this was easier to do by implementing our own metamodel.

[EA_enthusiast]

Thank you, Sif, for sharing your perspective.