Dataflow visualization in Archi

[TEK]

Hi
I'm trying to create a integration overview for a several integrated applications.
My current plan (I'm all open for input) is to create a data flow view that will just focus on how data flow between applications.

However, I'm running into issues with Archi on this. It might be because I do not use Archimate as intented, or it might be that it is due to a weekness in Archi visualizing the models.
This is a overview, so there will be a lot of integrations - but to simplify and give a clear example of the issue, let say that I want to visualize the following;
- Vessel voyage information flows from the Vessel system to the Financial system
- Crew information flows from the Vessel system to the Financial system
- Billing information flows from the Financial system to the Vessel system

My idea is to use a "Flow relation" and add name to each relation that tells what data is flowing.
This should be a easy overview with a lot of information regarding data flow and be really valuable for the team to see all integrations.

This is the flow of data: See integration1.png
However, the result in Archi is not possible to read: See integration2.png

So, does anyone have a good idea about how to make a integration overview that shows this flow of data between systems?
(we have like 20-30 systems and a lot of integrations that I really would like to visualize in one view, and right now I'm wondering if I will need to change tool to something else to make it)

[Jean-Baptiste Sarrodie]

Hi,

You can change the position of relationship by adding bendpoints and/or by changing the label's position to target or source (this is described in Archi user manual that you can access from within Archi of find as a PDF on Archi's website).

But creating such single view containing dozens of relationship is not the best way to do it as whatever you do you'll end up with something that nobody can understand. It is usually better to do it in two steps: an overview of the whole (information) system with few relationships expressing some kind of logical grouping (e.g. in you case one single relationship from Vessel to Financial system with a label such as "Voyage, crew and billing info."), and then provide per-system views with more details.

Regards,

JB

[TEK]

Hi

Thanks for the input!
My computer locked up - so I'm not getting to test this right now, but I will as soon as I get it fixed. I'll get back on how it went then.

[rchevallier]

if the flow (link) is important to show, I would then reify it:
I'll use passive structure (either data object or application event -- depends on the semantic to pass) to express them, and use associated relation "access" (reps. trigger) to link them to the function or as an derived relation to the service/component

[TEK]

The situation is that we're to moving or dublicating all applications from one company to another (actually one domain to a new domain) and we're moving one-by-one.
It's important to know what applications is dependent on what applications to understand what would be affected if we move or dublicate an application.

The usage is:
- getting a overview of what is connected to what (to make a common understanding on a non-technical level
- knowing what applications is accessing other (so that we know what will be broken when one application is moved)
- know what integrations to test, by knowing what data that flows from one application to another

Any example of tried visualizations is very appriciated!
If the application is accessed by other applications we

[rchevallier]

Using passive structures, the schema below
Otherwise, if the goal is mostly dependency management, interfaces are also very nice to represent flows

See example attached

[Jean-Baptiste Sarrodie]

Hi,

Using passive structures, the schema below
Otherwise, if the goal is mostly dependency management, interfaces are also very nice to represent flows
See example attached

Some remarks:

• "Access DataObject Access" doesn't have the same meaning as Flow: it only means that both applications are able to read/write the same data structure/format, but not necessarily the same "instance" of that data. This is somewhat suggested, of course, but this doesn't mean the same thing. If you want to really express the flow of information and describe the Data Object that is "flowing", you have to use a Flow relationship and create an association from this Flow to the Data Object.
  
• Using an Event between Flows is also misleading because, 1) an Event is behavior and not a passive structure (in event-streaming architectures, what is flowing are not the events but the descriptions of those events, ie. passive structures, ie. data objects), 2) Flows are not transitive. So a possible workaround would be to use triggers instead of flows (hidding the data aspect but focusing on the fact that the first application is in fact triggering some behavior in the second application.
  
• Using an interface is a good solution, but if you use a trigger, don't label it "flow x" as this is misleading. In this context the triggers models the call/solicitation of some service through its interface, independently of the direction of the data (you can call a service to extract or insert some data).
  
• If you want to model some kind of (kafka or MQ) topics/queues, then the Path is another option (the Path aggregates software that runs it).
  

The situation is that we're to moving or dublicating all applications from one company to another (actually one domain to a new domain) and we're moving one-by-one.
It's important to know what applications is dependent on what applications to understand what would be affected if we move or dublicate an application.

The usage is:
- getting a overview of what is connected to what (to make a common understanding on a non-technical level
- knowing what applications is accessing other (so that we know what will be broken when one application is moved)

For this you have to limit yourself to one Flow per couple of applications and use "generic" labels (e.g. in you case one single relationship from Vessel to Financial system with a label such as "Voyage, crew and billing info.").Such flows can be the basis of different kind of views depending of your need:

• One view per application, with a focus on Flows that are needed for this application to work
  
• One view per information system.This provides a good overview of what's going on as a whole, but this can quicly become "busy" and unreadable.
  
• One view per "use-case", with a focus on Flows needed to run the use-case.
  

- know what integrations to test, by knowing what data that flows from one application to another

For such need I would link data objects to flows. Depending on your exact goal, this could be done by simple attributes on Flows, or by modelling each Data Object and creating an association between these data objects and Flows.

Regards,

JB