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;
- Sparx EA: Matrix Viewpoints Across Multiple Relationships
- Sparx EA: Embedding Diagrams within an Enterprise Wiki
- Sparx EA: Displaying Tagged Values on Diagrams
- Sparx EA: Preview Panel for Element Rollovers in HTML Exports
- Sparx EA: Using PowerShell to script queries against the model
- Sparx EA: Bulk Updates using PowerShell
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).
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 Orders” business function is served by the “Manage Dispatch” application service
- The “Manage Dispatch” application service is realized by the “Managing Customer Orders” application function
- The “Managing Customer Orders” application function is assigned to the “MyOrg Dispatch System” application 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.
Using Sparx EA tools, there are two options to build views that satisfy this requirement;
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 Data” application function)
- Following potentially multiple overlapping relationships, as demonstrated with the bold-blue serving relationship between “Customer Website Based Customer Leads” application 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.
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.