Connecting entity relationship with information flow?

[ty.newton]

Hi,
I may get the terminology wrong in my description so please try and interpret me; sorry.  I am creating a UML component diagram with information flows to describe an application integration architecture.  My data architect colleagues are creating entity relationship diagrams to describe a logical data models for data being processed in the solution.  I'd like to associate the two together but I'm not sure what the best way is to do it in EA.

The information flow relationship seems right for the component diagram, but it requires an information item to define what data is moving.  The logical data model in EA doesn't seem to have an element that represents the entire model; just the diagram itself.  I assume I need to get to a point where a single element represents the data model and that element is also able to be assigned to an information flow i.e. either be an information item or be compatible with an information item.

Does anyone know if this is a reasonable approach and/or how to do it?

oh, forgot to mention I'm using v15.1 (build 1526)

[Geert Bellekens]

This depends a bit on what you actually want to achieve.

If you want to know exactly which classes, attributes and associations flow over this relation, you don't have enough with the diagram.
Diagrams are not really a part of your model, they just show part of it. On top of that, in EA you can't rely in diagrams to stay the same.
Adding or removing attributes or relations will affect what your diagram shows.

If you are serious about tracing which information exactly is sent where (as we are) then you need model with exactly these classes, attributes and associations, not a diagram.

We use the EA Message Composer for this purpose.
With this add-in we can create subsets of data models.
We also define a top-level "message" class that links to the main class of our subset, and use this message class as the representation of the whole dataset.

This allows use to answer questions such as
- On which systems is the User first and last name used
- Which data might be compromised if this particular system is breached
- Are my security measured appropriate for the sensibility of the data handled
- Which processes touch this data element before I use it in my financial reports.

It's quite a bit of work to get it all formalized like that, but in some highly regulated business areas, you don't have another choice.

Geert

[Richard Freggi]

My 2 cents is that yes there is a way to show this in an over-complicated wall-to-wall diagram, but you don't have the information to do it correctly.
Think about it.  Entities are not sent from one system to the other.  Systems exchange messages, not entities. 

These messages are in every way different from the entities in the source system.  Messages are encoded according to some protocol and typically the mix dozens or hundreds of entities together. Messages relate to entities but are not the entities.

My recommendation would be to just use a component diagram showing the key interfaces and dependencies, and SEPARATELY show a data model (class diagram or ERD) of the relationships of entities regardless of messages, interfaces etc. (you may make subject area data models by database schema if it helps you).  If you need to show a lot of details about the messages, you can use a sequence diagram with the components as participants. 

Good luck!

[ty.newton]

Thanks Geert and Richard.  I really appreciate you taking the time to think about my problem and respond.   Geert, I like the look of the EA Message Composer.  It seems like a good start for what I am looking to do and it sounds like we both work in industries with similar governance needs.  Are you able to elaborate on "We also define a top-level "message" class that links to the main class of our subset, and use this message class as the representation of the whole dataset."

I am thinking of using an Information Item element and linking it to the "main class of the subset" with an Realization relationship.  Is this what you mean?

Also, I am assuming that the "main class" is a feature of using the EA Message Composer.

[Paolo F Cantoni]

My 2 cents is that yes there is a way to show this in an over-complicated wall-to-wall diagram, but you don't have the information to do it correctly.
Think about it.  Entities are not sent from one system to the other.  Systems exchange messages, not entities.

These messages are in every way different from the entities in the source system.  Messages are encoded according to some protocol and typically the mix dozens or hundreds of entities together. Messages relate to entities but are not the entities. 

[SNIP]

(my emphasis)
Richard's point is vital to correctly model what is happening.  You need to model the messages and the entities from which they are created (at the origin) and, ultimately, populate (at the destination).  It is the messages that are conveyed as information items in the various "flows".

Paolo

[Geert Bellekens]

I am thinking of using an Information Item element and linking it to the "main class of the subset" with an Realization relationship.  Is this what you mean?

Yes

Also, I am assuming that the "main class" is a feature of using the EA Message Composer.

Not really. You can define a root class in the Scheme Composer, but that doesn't really do anything but give you a visual clue where to start.

The link to the "main class" is there to be able to find the contents of the message subset based on the message element (in your case an Information Item)

Geert