Data dissemination diagrams

The purpose of the data dissemination diagram is to show the relationship between data entities, business services, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside in an application and access data encapsulated within the application.

In this model, data is localized either in a repository or in an entity application component

entity-componentEntity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

interaction-application-componentInteraction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

process-componentProcess application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

utility-componentUtility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

DataBaseApplicationComponent32Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

system-federationSystem federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

ApplicationApplication: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

business-entityBusiness Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

flow-linkData flow: Expresses that data (for example business entity) is input or output from a dynamic entity.


0 # GD 2013-03-12 22:54
Typically done with Data Flow Diagrams.
TOGAF is fairly generic with data architecture.

See more:
Reply | Reply with quote | Quote
+2 # graham 2013-07-26 12:54
A data flow diagram is an application communication diagram?
Data dissemination is not a data flow diagram?
Data dissemination is about which entities are created and used by which applications?
See example artefacts at
Reply | Reply with quote | Quote
0 # graham 2013-07-26 14:23
Again, it was a genuine observation (not a commercial pitch) that a data flow diagram is an application communication diagram, and data dissemination diagram is about data entities rather than data flows.

You can go to the free-to-read web site if you want to know more.
Reply | Reply with quote | Quote
0 # phil 2013-07-26 14:52
In the example below, there is no data flows, but indeed business entities (Entities identified at the business level).
"deployed" business entities to be more accurate, such as ":client", ":order".
The definition of Data Dissemination Diagram is taken from the standard document.

We take the different types of artifacts & diagrams from the TOGAF standard, in particular :
>>> 35.6 Architectural Artifacts by ADM Phase

"Data Flow Diagram" is not mentioned by the TOGAF standard, and I do not see why you introduce this here : it is not the subject, and since there are many definitions and usages of such diagrams, it is hard to see what you are mentioning. May be a proprietary approach?

Anyway, we make the exercise here to stick to the TOGAF standard (complex enough) as much as we can.
Reply | Reply with quote | Quote
0 # graham 2013-07-26 16:32
The diagram show data flows between components that send and receive data flows, and between components and data stores. Classically, that is called a data flow diagram.

In TOGAF, it is called an Application Communication Diagram, the data flows are recorded in the Interface Catalog, and the components are recorded in the Application Catalog.

The purpose of a Data Dissemination Diagram is rather to show the replication and ownership of data entities.
Reply | Reply with quote | Quote
0 # phil 2013-07-29 07:58
See the Application communication diagram presentation in this site for that kind of diagram.
The purpose of the presented diagram here is to show the ownership of data where we see here that "CC" and "Customer" own several types of data.
The "flow" mention in the diagram is very vague, and does not mention specific data flows. The different arrows in this picture recall the dependency context between application component. In a more complete data dissemination diagram, each component will swho its "owned" data.
This is one means to do so. Specialized dependencies is another way to do it.

>>> The purpose of a Data Dissemination Diagram is rather to show the replication and ownership of data entities.

Agreed, that is what it does.
Reply | Reply with quote | Quote

Add comment

Security code


Sign in to use the forum and be informed of the latest news.

Latest comments