Sparx EA: Matrix Viewpoints Across Multiple Relationships


Series Overview

I’ve been working a lot with Sparx Enterprise Architect and ArchiMate over the past few years, and although I am a big fan of formalized modelling using ArchiMate I’ve found myself frustrated with some of the limitations of the Sparx EA tool.

Over a small series of posts I’m intending to share a few of the tricks I’ve developed over time to address these frustrations.  These posts are fairly technical in nature, and address the usage of Sparx EA as an architecture tool, as opposed to the practice of defining the architecture itself.  The other posts in this series are below;

Overview

In this post I’m going to discuss how the production of the following matrix viewpoint, building a simple visualization of the multiple relationships involved in navigating between business roles (in the column on the left) through to application components (in the columns on the right).

Problem Statement

One of the difficulties I find particularly challenging with Sparx EA & ArchiMate is that often the default views that can be produced get complex very quickly, so a lot of value in having the architectural model is lost because the views I want to produce to describe stakeholder viewpoints are not easily available.

Let’s take a fictitious model as an example, which is intended to describe the sales and dispatch process for MyOrg, and company responsible for the distribution of bespoke widgets for high value customers.   As part of describing the relevant parts of the architecture, a number of stakeholder viewpoints are required that leverage the knowledge stored within the architecture model.

For this example, let’s assume that the stakeholder responsible for service availability is likely to require a viewpoint that demonstrates what business functions will be impacted if an application component is unavailable, and who within the organisation needs to be informed about outages.

Relevant ArchiMate Elements

In order to build a view to meet this requirement, we must first consider the elements involved in the ArchiMate model to determine what application components are dependencies for the business function.

  • The “Dispatch Customer Ordersbusiness function is served by the “Manage Dispatch” application service
  • The “Manage Dispatch” application service is realized by the “Managing Customer Ordersapplication function
  • The “Managing Customer Ordersapplication function is assigned to the “MyOrg Dispatch Systemapplication component

These relationships result in a derived serving relationship (based on the ArchiMate Derivation Rules) between “MyOrg Dispatch System” and “Dispatch Customer Orders” – however this isn’t physically represented in the Sparx EA model.

 

Note: for the purposes of this discussion, I’m taking a couple of shortcuts on the ArchiMate syntax;

  • Bypassing the application service element, with ‘served by’ links direct from the application function to the business function.
  • Utilizing “serving” for all relationships between the Application Functions and Business Functions, whereas in reality this would be a mix of realization (e.g. in an instance of full automation of a business function) and serving.

Out-Of-The-Box solutions

Using Sparx EA tools, there are two options to build views that satisfy this requirement;

  • Matrix
  • Diagrams

Unfortunately we cannot rely upon the built in Sparx EA Matrix view, as this only supports directly related components – and as discussed above there are several elements modeled between the business function and the application component.

Equally providing the output as a diagram quickly becomes impractical as even with fairly simple architecture models the required diagram to include all the intermediate elements between the business function and the application component gets too large to easily consume in diagram format.

In addition to the number of elements being displayed, this output requires the stakeholder to have an understanding of the syntax involved;

  • Understanding the different ArchiMate elements & relationships
  • Understanding the concept of composition (as demonstrated with the “Managing Customer Sales Dataapplication function)
  • Following potentially multiple overlapping relationships, as demonstrated with the bold-blue serving relationship between “Customer Website Based Customer Leadsapplication function and “Managing Customer Leads and Opportunities” business function. Only a single example of this has been included on this diagram, but in reality there are likely to be many instances of crossing-line relationships, making the diagram look a bit like spaghetti.

Customised Matrix View

The solution I’ve found is to build a matrix viewpoint that can demonstrate the derived relationships within the architecture model and produce a report that can be easily consumed by stakeholders, without requiring that they understand the semantics of ArchiMate.

Implementation Detail

Producing an output like this is fairly straight forward, though it does involve a bit of PowerShell scripting (as outlined on my previous post), and the production of a custom SQL statement that builds the desired derived relationships for each viewpoint being produced.

I’m not going to go into the technical detail, but I have included a sample below that will produce a basic CSV output for the matrix demonstrated in this post – all that is required is a bit of Excel formatting to make this presentable to stakeholders. Alternatively with a bit of XSLT magic, the output could be produced as pre-formatted HTML.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s