What is the origin of Archimate's graphical Notation?

Question

Archimate uses a specific set of symbols and notations: Archimate Notation summary

The relationships notations are based heavily on UML. Just not sure about the Core Motivation, Strategy, Implementation and Migration Elements. Where did these come from? Were they designed especially for Archimate? Or derived from another modelling standard?

Answer 1

ArchiMate is a language having its notation like UML is a language with its notations. ArchiMate visibly reuse notations from UML, UML is older than ArchiMate.

As you can see on http://pubs.opengroup.org/architecture/archimate3-doc/toc.html there is a reference to UML and other standards :

Appendix D, Relationship to Other Standards (Informative), describes the relationships of the ArchiMate language to other standards, including the TOGAF framework, BPMN, UML, and BMM.

D Relationship to Other Standards (Informative)

Concerning UML :

D.3 The UML Standard

The ArchiMate language has derived a number of concepts from UML [8]. For other concepts, straightforward correspondences can be defined.

In the Business Layer, the ArchiMate business process concept can be mapped onto UML activity diagrams, where more detailed specifications of such processes can be given (although BPMN would be the preferred language for detailed process and workflow modeling). The ArchiMate business actor and role concepts can both be mapped onto UML actors, although the latter can also be used for modeling automated actors. Business collaborations have been inspired by collaborations as defined in the UML standard [8], although the UML collaborations apply to components in the Application Layer.

In the Application Layer, the application component element corresponds to the UML component. This facilitates the direct linkage between higher-level Enterprise Architecture models described in ArchiMate notation and lower-level solution architecture and implementation models in UML in one continuous development chain. In a less direct manner, the ArchiMate application function concept can be mapped onto UML activity diagrams, and an application service to a use-case diagram. Application collaborations also correspond to UML collaborations.

Many of the elements of the ArchiMate Technology Layer correspond directly to UML. The node, artifact, device, system software, and path elements have a direct counterpart in UML (where system software is called execution environment).

In addition to these elements, many relationships in the ArchiMate language have close ties to UML as well. The ArchiMate association, composition, aggregation, specialization, and realization relationships have a direct counterpart in UML.

There are also some notable differences between the two languages. The ArchiMate serving relationship (formerly used by) is different from UML dependency. Although their notations are similar, their directions are different. UML dependency is often used to model, for example, function calls in software programs, but in ArchiMate notation, the direction of the serving relationship denotes the direction of service delivery, independent of whether this service is called by the user or offered pro-actively by the provider. At the architectural level at which the ArchiMate language is aimed, the run-time operational details of such call graphs is less important than the more stable and generic notion of service provision.

This also points to another important difference: UML does not have a separate service concept, since in its object-oriented paradigm the behavior expressed by a service is encapsulated within the interface offering that behavior (i.e., its operations). The ArchiMate language differentiates between interfaces and the services they provide to allow, for example, specifying that the same service is offered through multiple interfaces. Hence, an ArchiMate application interface does not equate directly with a UML interface.

Finally, UML has a predefined, fixed set of diagram types, whereas the ArchiMate viewpoint mechanism allows for the construction of custom, stakeholder-oriented views on an architecture.