Realize information flow, how does it work?

[Kristofer]

Hi!

I am in the process of documentating our existing IT systems. I want to do this on two levels, a higher level with only the information flow, and then a little bit more detailed level on how two systems interact with each other (for example what other systems use a REST service provided by a system). The first image shows an example of the higher level (information flow diagram), and the second image shows an example of the lower level (component diagram).





The question is however how to best do this in EA, without messing up with unnecessary connectors all over the place.

Since a few questions araise, i am not sure if i do this correctly, so i would appreciate if someone could tell how to best accomplish what I have described above.

Questions (assuming i have created the information flow diagram):

A)
I drag a dependency relationship from required interface Customer to provided interface GetCustomer. I select "Information Flows Realized" and get two options "Order, Customer" and "Order, Customer" (the two information flows already between the components). The information item here is obviously only Customer (Order is to another interface).

I can select one of the options in the list, and click on the ellipsis button to select Customer, but this changes the information flow connector to only convey Customer.

I can also click on the "Click to create new information flow" to add Customer, but the list will now have three items. This also actually adds two connectors between the interfaces, one dependency and one information flow connector.

What should I do? The benefit of selecting one of the options in the list is that the information flow connector will be "hidden" in that diagram (the two connectors lies on top of each other) and I don't have to manually hide it. But I also don't want to create one information flow connector for each information item.

B)
The interface CreateOrder is a delegated interface provided by an internal component of "Some System", so the interface is attached to a Port. If I do the same procedure as in A above, the list will be empty. Does this mean that I have done something wrong in my modelling?


Or am I doing this completely wrong?

[Geert Bellekens]

B) The delegate should go the other way.

Geert

[Kristofer]

Thanks, you are correct, it should go the other way!

Any ideas on the other questions?

[Glassboy]

Hi Kristofer, I might be being really stupid but can't you just right click on the Information Flows in your second diagram, select Visibility, and then Hide Connector?

[Kristofer]

Hi!

Of course this is possible, and I am starting to think that perhaps we need to do that. But if there is a "proper" way to do this, I would like to use that way, so we don't end up with unnecessary connectors that we cannot maintain over time. If people forgets to change/delete/add connectors in one diagram, what should we consider the truth? If the information flow diagram says there is an information flow between two applications, but the information flow is not realized, which diagram is showing the reality? Which diagram was forgotten when something was changed?

So I am essentially trying to, as long as possible, have "one source - one update", without duplicating things just because it is necessary to show it visually.

[Paolo F Cantoni]

Hi!

Of course this is possible, and I am starting to think that perhaps we need to do that. But if there is a "proper" way to do this, I would like to use that way, so we don't end up with unnecessary connectors that we cannot maintain over time. If people forgets to change/delete/add connectors in one diagram, what should we consider the truth? If the information flow diagram says there is an information flow between two applications, but the information flow is not realized, which diagram is showing the reality? Which diagram was forgotten when something was changed?

So I am essentially trying to, as long as possible, have "one source - one update", without duplicating things just because it is necessary to show it visually.

We handle similar problems by the use of adornments onthe connectors.
For example, if we have a many-to-many relationship betweeen two objects, but the intersector object has not be defined (or attached to the connector) then the connector is in it's original state.  Once we conect an intersector, the line gets an adornment (a small lozenge) to indicate this.  Thus, if we show the connector on a diagram, but the intersector is not, there is still some indication that an intersector exists (that is, there is a materialization of the relatlonship).

Paolo

[Uffe]

Hi Kristofer,


"Information flows realized" adds an information flow if there isn't one, then automatically hides it. If you only want an information flow, delete the original connector and draw the information flow instead.

The whole drill-down thing doesn't work very well in EA. The reason, I think, is that the composite diagram is intended to show the inside of its parent, but what you're trying to do is show the inside and outside at the same time.

In similar situations, what I usually do is draw the connectors between the systems not directly but between two ports. This way, presentation of the connectors are controlled by the selections you make in the structural elements dialog.

However, auto-hiding a connector based on some semantics (is the "detailed" connector present in the same diagram) isn't possible because there are no relationships between connectors in UML -- the "detailed" relationship between two connectors can't be expressed, and so EA can't decide to hide one connector based on the presence of another. You might be able to get something working with an Add-In shape script, but it seems like a long way to go for a minimal payoff.


/Uffe

[Kristofer]

Thanks for your answers!

Uffe, you are probably right, the problem arises when we need to show both the outside and inside at the same time.

Our situation is this; we have about 150 applications communicating with each other, and we need an overview of how these are connected and what information items are flowing (1). These applications may have one or many interfaces, and we also want to know "who" is using a particular interface in case it will be changed in the future (2). These two are the the main needs (at this moment).

In some cases, we cannot really agree on what an application/system/component is, hence in some situations we need to make a more detailed view (the inside) to be able to communicate with different groups of people. If you say "System A", it has different menings to different people.

We actually used ports in the information flow diagrams when we started, but realised after a while that it has a visual drawback.  If you have one application with 5 interfaces/ports, and you have another application using all 5 of these, you end up with 5 connectors, just between these two applications. Put in another few applications and you end up with a diagram with a lot of connectors.

So I am trying to find the best way to document (1) and (2), and still have it maintainable over time with as little risk as possible for it to become contradictory.

[qwerty]

What I did is to create overview diagrams with only the outside ports connected to each other. Each component itself has a composite diagram showing its guts.

q.

[Kristofer]

Hmm, perhaps I misunderstand ports, or did not use it properly.

When I used ports i thought of it as one port equals one interface. So if another application used several interfaces/ports on the same application, several connectors was created. Essentially, it resulted in that each diagram was focused only on one application, and the overall information flow (the flow of information items through systems for receiving, storing, maintaining and making data available to others) was lost. The diagrams became too cluttered that it was not readable anymore.

Do you have any example diagram?

[qwerty]

Basically a port is a "container" for interfaces. This is just like in hardware where you have plugs that combine power and data (USB is a simple example; trains have rather complex plugs; the diagnostic port of your car is another example). I always use a port between component and interfaces, even it's only a single interface. But often you find that a number of interfaces belong to each other. So they go into the same port.

q.

[Kristofer]

Thanks for the explanation!

That might give me some new insights, on monday.  :-)