This article details how to map an integration landscape focussing on dataflows rather than technical integrations. There are many ways to map integrations across an organization using Ardoq, and several factors to consider when deciding which approach to use. Ardoq's Application Integration Management (AIM) Use Case is based on the technical integration oriented approach. The dataflow oriented approach described in this article is a valid alternative but is not implemented in the AIM Use Case. The distinction between the two approaches, and the rationale for our decisions in the AIM Use Case can be found in the Application Integration Management: Purpose, Scope, & Rationale article. We strongly recommend reviewing this document prior to starting your integration management journey.

With integrations representing an increasingly more critical part of enterprise architecture, and also a more likely cause of service disruption, there is a need to lift this part of the architecture documentation to the forefront. This model focuses on creating documentation that is easy to maintain via Ardoq surveys and that will provide answers to the most important business-critical questions.

The model can be expanded to cover more integration attributes, as well as dependencies to:

This model is easily deployed through a single survey that catalogs integrations with their own set of attributes and maps dependencies to applications, databases, data objects, and data paths.

You should consider whether your integration catalog should reside in the same workspace as the application catalog or whether it deserves a workspace of its own.

If your integration- and application catalogs consist largely of microservices, it may be difficult to tell them apart and therefore easiest to bunch them together. It might nevertheless be different teams owning the two, in which case mapping applications and integrations in two separate workspaces might be preferable after all in terms of enforcing ownership and permissions.

Component types:

Reference types:

Field types:

Applies to the reference types Integration Source and Integration Target:

Applies to the component type Integration:

💡 Pro-tip: If you don't have your master data mapped out, you can reference your integrations to the level of abstraction that suits you. The model works equally well, irrespective of whether you've referenced your integrations to data objects, information objects or even subsets of data relevant to each data path.

Should I model the integrations in a new workspace?

There are a couple of advantages of having integrations modeled as components in a workspace of their own.
​
The first is that your integrations become first-class citizens. This also allows you to pull a complete list of all your integrations simply by opening the workspace without applying any filters and selecting the Table-view. The Table-view will also display all of your data sources, data targets, and data objects in a single grid, in addition to the life cycle status and technical owner.

What are my key integration properties?

The second advantage of having integrations modeled as components is that it allows you to capture when the integration is connected to more than two applications, as the integration component can have multiple incoming and outgoing references.
​
If an integration pulls data from two different sources, the way in which this happens might not be the same for both sources. For instance, the content format might be .json for one source and .xml for the other. The integration protocol might be SOAP for one and REST for the other. The frequency might be hourly for one and daily for the other. Therefore these types of properties must be captured on the references between the integration-component and the integration sources and integration targets.
​
Set your context to the integration of interest and select the Pages-view for a one-stop-shop with all the properties of all the dependencies of that integration.

I plan to replace system "X". Which integrations will need to be updated? Which applications might be affected down the line?

By selecting a view that displays several degrees of dependencies, such as the Block Diagram view, you can see more than just direct dependencies, both when looking “up” or “down” the data path.

Set your context to the application of interest and select the Block Diagram view.

Make sure to filter away reference- and component types that are not relevant. You can do this in the Quick filters in the bottom left corner.

Also, make sure to adjust the degrees of relationship settings so that indirect dependencies also are shown.

What does a given data path look like end-to-end (visual representation)?

In this model, we suggest modeling data paths as components in their own right, much in the same way as you might model a process as a single component. This high-level abstraction is beneficial in more than one way.

Firstly, it serves to build a catalog of all your data paths. If relevant, you can also expand the model to include fields on the data path component, for instance, to attribute life cycle status to data paths.

Secondly and most importantly, because all the integrations that constitute a data path are connected to its component, you can easily use these references to exclude everything not relevant to that data path. You'll do this by creating an advanced filter in the Manage Perspectives window.

Such a filter as the one illustrated above will exclude all integrations that don't belong to that specific data path, while including applications and databases, irrespective of whether these also feature in other data paths:

All the information in this model can be collected and updated via a single Ardoq survey, including the data captured in the fields on the references between the integration component and the application- or database components.

Additional tips:

In this model, all integrations are abstracted into individual components, including integrations that one might have visualized as an arrow, e.g. integrations that connect two APIs directly to each other.

As long as the model is instantiated strictly via a survey such as the one above (one that creates and updates integration components), this will happen automatically.

However, if adding data in the core app, it is important that a reference of type Data Path always has a component of type Integration either as a source or as a target. Or else the above-mentioned filter that allows the visualization of a single data path will not work as intended.

Build a dashboard to track your progression and the quality of your data.

Additional component types:

Additional reference types:

Additional fields: