Introduction
Straight out of the box, Sparx Enterpise Architect provides support for multiple modeling notations. Using a synergy of notations can result in a better description of business architecture. This article considers how ArchiMate, BPMN and UML can be combined into a model that is focused at a high-level of abstraction, whilst still allowing for some critical details to be explored.
Revealing layers of abstraction
As explained in Marc Lankhorst's book Enterprise Architecture at Work (third edition, p. 117), modeling notations provide a way to represent knowledge. The process of building, sharing and transforming the model can foster a new level of understanding amongst the participants. This refined knowledge is (at least) as valuable as the resulting model artifacts (the representation). Effective communication of that knowledge requires consideration for the target audience and an appropriate level of detail.
ArchiMate is good for:
- People who have a job title like Enterprise Architect or Business Architect.
- Presenting high-level and layered abstractions of the business itself, along with the software and technology that are used to support it.
- Tracing and illustrating how the motivating strategy is realised by the business.
- Planning the evolution and transformation of a business.
- Supporting concepts that are similar to those found within TOGAF.
By design, the ArchiMate 2.1 specification does not (explicitly) provide for detailed:
- Business process modeling
- Data modeling
Meanwhile:
- BPMN (Business Process Modeling and Notation) is focused on the detailed modeling of business processes; naturally enough, BPMN is increasingly used amongst the Business Analyst community.
- UML Class diagrams may be used to detail data types, along with the relationships between data types; they are widely recognized amongst software developers, and a good alternative to using entity relationship diagrams for logical data modeling.
Coordinating multiple notations in a single model repository
UML is the native metamodel and notation of Sparx Enterprise Architect. Each additional notation (such as ArchiMate and BPMN) is provided as a MDG (Model-Driven Generator) technology within the tool. The UML specification provides for semantic extension of the UML through the mechanism of Profiles, Stereotypes and Tagged Values. Profiles are the heart of each MDG Technology, enhanced with Sparx tool specific details supporting new types of diagram notations and diagram toolboxes.
Using multiple notations within a single repository requires a disciplined approach in order maintain clarity. In brief, the best practice is to:
- Restrict the elements of each notation to a separate root node.
- Use the UML «Trace» dependency to provide an elegant way of relating elements belonging to different notations.
Add root node to your Sparx Enterprise Architect repository
You might not have realised that the File|New Project… menu option is something of a misnomer. Both EAP and FEAP files are actually self-contained model repositories, and can therefore contain multiple root nodes (just like a RDBMS hosted shared repository, whether accessed through an ODBC or Cloud connection). As a reminder, you can add a new root node into a repository by performing the following steps:
- If necessary, click View|Project Browser to open the Project Browser window.
- Right-click inside the blank (white) area of the Project Browser window and then click Add|Add Root Node….
- The Create New Model (root node) window is displayed. Type MyCorporation (ArchiMate) into the Model Name field.
- In a similar way, create root nodes for:
- MyCorporation (BPMN)
- MyCorporation (UML)
Create a «Trace» dependency between elements belonging to different notations
As stated in the Unified Modeling Language 2.5 specification (p246):
"Models can have Abstraction Dependencies between them: refinement (stereotyped by «Refine» from the Standard Profile) or mapping (for example stereotyped by «Trace» from the Standard Profile). These are typically represented in more detail by Dependencies between the elements contained in the Models. Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete. However, they are useful for tracing refinements and for keeping track of cross-references between models."
ArchiMate for an architectural understanding
For example, an ArchiMate Business Process Viewpoint diagram for Purchase Item might look as follows:
This provides a high-level overview of a core business process, with enough detail to inform stakeholders and decision making at a whole-enterprise level of abstraction.
BPMN for detailing business processes
BPMN can be used to detail the ArchiMate Business Process concept, as follows:
UML for detailing the data entites
UML Classes can be used to detail the ArchiMate Business Object concept, as follows:
Usually, diagrams should only contain a single notation. In the examples above, multiple notations are deliberately used to visualise «Trace» dependencies between the ArchiMate, BPMN and UML elements.
How-to add «Trace» dependencies between elements model elements
Best practice for adding «Trace» dependencies using a diagram is to:
- Temporarily add the required elements of the foreign notation to a diagram.
- Draw the «Trace» depencies between elements.
- Remove the foreign notation elements from the diagrams, whilst retaining the traceablity links within the model repository. (So, delete the foreign elements from the diagram, but NOT the repository).
Alternatively, you could use the Relationship Matrix functionality of Sparx Enterprise Architect (click Tools|Relationship Matrix to get started).
Summary
The UML specified «Trace» dependency (relationship) is an elegant way of tracing between different modeling notations. Sparx Enterprise Architect provides a wide coverage of modeling notations, by leveraging the UML Profiles mechanism, and enhancing it with MDG technologies. In practice, this enables a synergy of the ArchiMate, BPMN and UML notations. Models can be constructed as layered abstractions, moving from one notation to another to suit the level of detail required by the user and intended audience.