When to consider the use of ArchiMate?

The Open Group recently released the ArchiMate 2.1 specification; I think that there are five principle reasons to consider using the notation to describe the architecture of your enterprise. By design, ArchiMate is focused toward:

• Providing a high-level of abstraction
• Facilitating the construction of a layered enterprise architecture
• Illustrating how business concepts are supported by IT systems, comprising both hardware and software
• Tracing stakeholder concerns through to their realization by the enterprise architecture
• Showing the possible, and actual, evolution of an enterprise architecture through a number of recognizable intermediate states.

How does ArchiMate handle these things?

Approaching abstraction

In a similar way to modeling notations such as the UML and SysML, ArchiMate relies on a simple but powerful approach to creating a useful abstraction of a complex domain:

• Identify the specific types of things that are pertinent
• Identify the relationships between the types of things
• Provide a graphical notation to illustrate the above

Types of concept

ArchiMate divides the specific types of things to be modeled into three core layers:

• Business concepts (including actor, role, function, process, service and interface)

Figure 1: A subset of the business layer concepts

• Application concepts (including component, function, service and interface)

Figure 2: A subset of application layer concepts

• Technology concepts (including device, system software, function and interface)

Figure 3: A subset of the technology layer concepts

ArchiMate supplements the core types of things with two extensions for:

• Motivation (including driver, goal, requirement, principle and constraint)
• Implementation and migration (work package, deliverable, plateau and gap)

Relationships between concepts

ArchiMate specifies ten types of relationship that may be used between elements:

• Composition
• Aggregation
• Assignment
• Specialization
• Realization
• Used by
• Access
• Association
• Triggering
• Flow

Direct relationships

ArchiMate specifies the set of valid relationships that may exist between concepts. Relationships are restricted for both concepts belonging within a single core layer or extension, and also across layers. The detailed specification of all valid relationships between types is tabulated in Appendix B: Relationship Tables of the ArchiMate 2.1 specification (ISBN 978-94-018-0003-7).

Figure 4: A syntactically (but not necessarily semantically) correct example showing all the available ArchiMate relationships

Derived relationships

ArchiMate also specifies rules for abstracting over a chain of relationships between three or more concepts:

Transitively applying this property allows us to replace a “chain” of structural relationships (with intermediate model elements) by the weakest structural relationship in the chain. – p. 94, ArchiMate 2.1 specification

Figure 5: A chain of relationships, along with the derived relationship

How using an ArchiMate modeling tool can help

In theory, it is not necessary to use a dedicated modeling tool in order to draw ArchiMate diagrams. You could create a custom stencil with Microsoft Visio (for example) containing all the basic shapes of the elements and relationships. However, a good modeling tool can be used to positively enhance both:

• Productivity in creating models
• The correctness of the models

Both enhancements depend on automated model validation, at either the syntactic or semantic level.

Checking for errors in direct relationships [enhance correctness]

Ideally, your modeling tool should not allow you to draw an invalid relationship between two concepts in the first place. This can be prevented a priori whilst creating the initial drawing, by greying out or eliding the options to create invalid relationships. Alternatively (or additionally), the modeling tool can validate the relationships between elements within each diagram, highlighting where invalid relationships have been made, and suggesting valid alternatives.

Automatically deriving relationships between elements [enhance productivity]

Due to ArchiMate’s rules for abstracting over a chain of relationships, your modeling tool should be able to insert a correctly derived relationship between any two elements in a diagram, or at least inform you that no relationship can be derived at all.

Automating ArchiMate viewpoints

ArchiMate specifies twenty-six viewpoints that may be constructed using different combinations of element types and relationships. Ideally, your tool should be able to:

• Validate any viewpoint(s) that you have already created. [enhance correctness]
• Provide automated assistance with creating new diagrams through re-using existing model elements and their relationships. [enhance productivity]

How to do it? Let us help you!

The existing functionality of Sparx Enterprise Architect provides a good basis for fully automating the validation of ArchiMate models. Please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. if you would like to discuss how you can gain access to our solution.

Following on from my previous post on creating and simulating state machines in Enterprise Architect (EA), I will walk through the process of adding a UI to prototype and further interactivity to your model.

If you recall the previous article, I walked through the process of setting up ‘Triggers’ to run scenarios through your state machine and set simulation variables at state or sub-state level to better represent your application. All of this information was available using the EA ‘variables’ or recording to the Console. We can go a step further and prototype a quick UI to represent our application and/or provide a ‘dashboard’ view of states and variables.

Setting up the state machine

Using the state machine I used last time, we need to create a place-holder ‘state machine’ element so we can reference it as a simulation start point.

Add a ‘User  Interface’ diagram to the appropriate place in the package browser.

This will be our place-holder to put the state machine and User Interface elements.

On the diagram create a new state machine element.

Then right-click the newly created element and select your existing state machine diagram we created in the previous example.

Locate the state machine diagram in the package browser.

Now we can create a new User Interface diagram and add that as a frame on to the current diagram (keeps it neater and modular).

And drag that on to the Model Default (or whatever you named the original) diagram canvas.

To complete the process of linking a UI to a simulation, we want to open the Execution Analyser and create a script. If you don’t have the window open, select ‘Analyzer’ - ‘Execution Analyzer’ to bring it back up

From the Execution Analyzer window, select to add a new script

And they key step for us is the last tab, ‘Simulation’ and defining the ‘Entry Point’ and Input behaviour.

Select the ‘..’ icon to locate your state machine element for the Entry Point.

That sets the entry diagram we want to use for the simulation.

To connect the User Interface to the simulation, we need to define a behaviour (in JavaScript notation) to display the correct UI element.

The format of this command is as follows:

dialog.CreateOrder.Show = True;

where ‘CreateOrder’ is the name of User Interface we created earlier (‘CreateOrder’ in my example above).

As you may have guessed from the above JavaScript, the model simulation script will start the simulation on the ‘Validate Example’ state machine and as it’s first point of business, it will display the ‘CreateOrder’ User Interface we created.

Note: Another method of displaying the UI is to assign the same command (above) to the first transition of the state diagram (e.g. Initial –> Created in my example). Whichever method works for you!

Creating the UI and assigning actions to things!

So now we have a model simulation that will give us an actual rendered screen we should probably put something on it!

Open up the CreateOrder User Interface  we created earlier and lets start adding elements.

Using the Toolbox you can add standard UI elements or use the Win32 elements to add things onto your prototype. Here is a horridly rushed example of some text and a button (note the list of Win32 UI control types in the toolbox)

So now I’ve added a UI to the model and hooked it up using a simulation script, what happens if I run it? Well let see.

Going to back to the ‘Execution Analyzer’, right click the script and select ‘Start Simulation’

What do we get?

A ‘nicely’ rendered (I use the term nicely loosely of course!) dialog box that we mocked up but the button doesn’t do anything – lets fix that!

Adding Signal behaviours to Button and making our UI interactive

Head back to our CreateModel user interface and view the properties of the ‘No More Items’ button. On the ‘tagged values’ tab we want to add a new tagged value.

The naming of this tagged value is very specific and must always be named ‘OnClick’ with the following value ‘BroadcastSignal(“ “)

When the simulation is interpreted, EA will parse the above tagged value as a JavaScript function and attempt to fire the trigger “Signal Name”. So what we were doing before manually using the ‘Simulation events’ and ‘Waiting Triggers’ window in EA, we can no build into our interactive prototype to reasonable something more alike our application!

It is important to note that the trigger type must be ‘Signal’ for this to work. To check this, return to our state machine and find an appropriate transition. In my example we are using a button called ‘No more items’ which corresponds to following transition on my state machine.

Bringing up the properties of this transition will allow me to view the Triggers associated with it.

Notice the type is ‘Signal’. Had this been one of the other trigger types our simulation would not register the event.

So when we run the simulation again, we can actually use the button on the UI to progress the simulation.

Selecting the button progresses us further into the state machine as if we had used the ‘waiting triggers’ window in the bottom right of my example.

So you've now added some interesting tricks to your model but at this point you still might be thinking – “that's all very well, but that isn't all that useful to me”. Well the initial driver for me to head down this path wasn't to create a prototype application based on my state machine but was in fact to provide a better view of the variables and states I was assigning throughout my model.

Introducing the Model Simulation Dashboard!

So go along with my very basic prototype I built an even simpler dashboard view which sits along side the prototype and displays the variable states (as recorded in the EA ‘Locals’ window) and any additional info I want to record in my simulation.

To this all I do is create a second UI diagram, and call this at the first transition (from Initial –> Created in my example)

dialog.Screen1.Show=true;
dialog.CreateOrder.Show=true;

In the above example, Screen1 (horribly named I know!) is my dashboard view and CreateOrder is the first UI screen from our example above.

What does that look like?

I have my dashboard running alongside my UI screens to give an alternative view of things I need to track at any given time.

Protip: You can change the stereotype of a Screen element to be a Win32Dialog and get additional properties, such as setting the window to be in the centre – very useful when using multiple Screens.

All done!

Well thats the basics covered of adding a prototype UI to your model simulations and if there is further interest I can share some tips on making a more dynamic prototype in EA, hiding elements until required – but I shall save that for another day.

Hope that was useful to someone!