Modelling with Archimate 2: File Interfaces

This is the second in a series of posts regarding the use of the Archimate Modelling Language. For more posts on Archimate including the other posts in this series click here.

This post is about file interfaces. Specifically about a process where a script dumps a file in a directory which is then read at a later time by an application. Here is the situation we are trying to model:

A downloader script logs into a bank interface and retrieves payment transactions made by customers. It then writes these transactions into a directory. The receipting application then reads the transactions from the file and imports them.

One way of modelling this in Archimate is as follows:

File Interface

A few points:

• The “bank to receipting file interface” Application Collaboration is used instead of an interface owned by the receipting application because there isn’t an interface that could be used to represent the structural dependency. The receipting application doesn’t offer an interface to it’s environment and the bank downloader script doesn’t care if the receipting application isn’t available.
• The file interface isn’t shown because that is an infrastructure service and this is an application level diagram.
• There is no Application Service associated with the Receipting Application because the receipting application doesn’t offer anything to its environment, it simply goes and collects the files.

I don’t like this model and here’s why:

• If I am trying to query the dependencies between applications at a structural level I need to query both the “Used By” relationships and the “Aggregation” relationships from the collaboration.
• I have to model down to the application function level in order to show the interfaces and data flows. I would much rather show flows at the Application Service level between applications.
• The collaboration seems very artificial and jarring but there really isn’t an application level construct I can use to show the data flowing between the applications.

Here are two of alternatives that we tried and rejected to solve this problem:

• Model application services at both ends of the interface. This ended up just plain weird with the necessity to create application interfaces and services for behaviour/active structure that was never called by an outside entity.
• Model the dependencies only at the infrastructure level and leave them off the application level viewpoints. This is possibly the most correct view of the problem however it makes analysis of application dependencies much more difficult, requiring the traversal of many more relationship types and the parsing of patterns in those relationships rather than looking at them directly. This also means that application layer diagrams aren’t showing the whole picture.

This is what we ended coming up with:

The file interface is nominally owned by the receiving application (even though it isn’t in reality) which then lets us show the dependency clearly. We do need to model a function on the sending side but we are already modeling active structure at that level with the application component so adding the behaviour performed by the component isn’t a huge stretch.

This isn’t a perfect solution but it is the best of a bad lot for us. Other teams may make different decisions using one of the other patterns I have mentioned.