Mapping an Integration Landscape

An alternative way of mapping your Integration Landscape.

Kristine Marhilevica avatar
Written by Kristine Marhilevica
Updated over a week ago

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.

Ardoq mapping integrations

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

  1. Integrations and third parties (Who built or is responsible for maintaining the integration?)

  2. Processes (Which processes depends on this integration?)

  3. Integration software (e.g. MuleSoft or IBM Integration Bus)

  4. Infrastructure (Where is this integration deployed?)

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.

Example of questions this model can answer:

  1. What are my integrations?

  2. Where in the life cycle are they?

  3. Who is the technical owner for each of them?

  4. Which data paths are they a part of?

  5. What are my integration properties?

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

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

  8. An employee has left the company. Which integrations was she/he responsible for?

  9. An integration is failing. Who needs to be notified?

Meta model:

Component types:

  • Integration

  • Application

  • Database

  • Data Object

  • Data Path

Reference types:

  • Data Path (Application/Database/Integration → Integration → Application/Database/Integration)

  • Data Input (Data Object → Integration)

  • Data Output (Integration → Data Object)

  • Integration Enables Data Path (Integration → Data Path)

Field types:

Applies to the reference types Integration Source and Integration Target:

  • Integration Content Format

  • Integration Frequency

  • Integration Protocol

  • Integration Mode

Applies to the component type Integration:

  • Lifecycle Phase

  • Technical Owner

💡 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.

Ardoq integration catalog pages view

Frequently Asked Questions

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.

Ardoq table view

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.

Ardoq integration catalog pages view

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.

Ardoq 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.

Ardoq quick filters

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

Ardoq adjust degrees of relationship

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.

Ardoq advanced filter

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:

Ardoq components data flow

Data Entry

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.

Ardoq data entry

Additional tips:

  • Naming convention: Make it easy for your contributors and avoid duplication by defining an intuitive naming convention for your integrations, something like

  • Use the Result Filtering-feature in the Survey Builder to allow respondents to filter the integration catalog by data path.

Ardoq result filtering in survey builder
Ardoq survey mapping

Logical and Physical Integrations:

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.

Ardoq dashboard

Expanding the scope:

Additional component types:

  • Middleware

  • Integration Platform

Additional reference types:

  • Uses Data (Application → Data Object & Integration → Data Object)

  • Stores Data (Database → Data Object)

  • Accesses (Application → Database & Integration → Database)

  • Contains integration (Middleware → Integration)

  • Platform (Integration → Integration Platform)

Additional fields:

  • On references of type “Uses Data” (Application → Data Object & Integration → Data Object) and “Accesses” (Application → Database & Integration → Database): CRUD (Create/Read/Update/Delete) or similar

  • On references of type “Uses Data” (Application → Data Object & Integration → Data Object): “Master”/”Owns”.

  • On components of type “Integration”: Criticality

Did this answer your question?