I’m a Solution Architect trying to understand and use the TOGAF artefacts that could benefit us.

Now I’m stuck on Application/Data Matrix and none of my Googling ninja skills have helped: I want to visualize how each data element (with classification) is used by each application in a way that you get a good overview.

I have found examples that show how data elements are used, but they don’t show classification (master data, reference data, transactional data, content data, and historical data.) Matrix but no classification

Then I have found other examples where the classification is shown, but the data is not on the x-axis (as claimed) so there is no real overview. It’s not a matrix over Application/Data. Classification but no matrix/overview

How should/could I create the artifact so that it enables me to get the maximum insigts and still be maintainable?

  • 1
    Please clarify "all that it promises". What all have you been promised? You've only mentioned "data is not on the x-axis" and "classification" as far as I can see. May 8, 2020 at 11:54
  • Last sentence updated so that the purpose is easier understood. @Christophe covers the promises nicely.
    – Björn
    May 11, 2020 at 12:05

1 Answer 1


How to present it?

The TOGAF link that you provide tells it all:

The Application/Data matrix is a two-dimensional table with Logical Application Component on one axis and Data Entity on the other axis.

Your first example does exacly that. The problem of enterprise architecture is however complexity. For an architectures mainly build on an ERP with a dozen of modules, such a matrix is just fine. However, industrial architectures have often several hundreds components. In this case, the number of columns make such a presentation completely unsuitable.

Your second example just addresses this issue. It is not 2D a matrix, but a one-dimensional list. It is too short to notice, but you fill find the same Data Entity for several lines with different Applications. Think of it as the base table with which Excel would do a pivot table to show a large unmanageable matrix.

Personally, I use the second form which is much more practical for large systems. You can just filter per application, or per data entity, to have quickly get a cross cutting overview on a specific topic.

What about classification?

You want in the matrix the classification of the type of data, it is more challenging, since the TOGAF seems to makes this categorization dependent on the component:

The data entities in a package/packaged services environment can be classified as master data, reference data, transactional data, content data, and historical data.

I tend to see the classification of the data entity as a property of the entity at enterprise level, and would just show it at the level on the Data Entity axis of a matrix.

However, a contextualisation can be more accurate: While a vendor would in general be master data across the landscape, and good movements or invoices transactional data, the classification is not always clear cut. A framework contract can for example be seen as a master data in the context of an MRP ordering system (because it exists for a long time as reference) whereas a sourcing application that aims to conclude contracts may see it as transactional data. A similar example is projects. Project management software may see them as master data, whereas some financial software could consider that it's just transactional data. And all data is sooner or later historical data. A more prudent approach is therefore to show the classification in the matrix cells. In the list presentation, this is absolutely not an issue.

The promises

I have some doubts about most of the promises made by TOGAF:

  • "assign access of data to specific applications": in most cases, the data access is driven by needs identified by the business analysts. The matrix may facilitate the job of new analysts by providing an inventory of what is managed where.
  • "understand the degree of data duplication": in my experience this matrix is often misleading in regard of this promise. Very often, different systems manage the same data but with different level of details (e.g. product may bear different info for a marketing application than for a production managing system) because they address a different reality. Sometimes application even use different entity names (see bounded context in the DDD terminology) so that the overlap is missed (e.g. prospect vs. customer or vendor vs. contractor). Sometimes unrelated entities have the same name (e.g. task in a project management system, task in a production planning system, and task in an administrative to-do app)... No data architecture is not easy ;-)
  • "Determine whether any of the applications are missing and as a result need to be created": I never ever have seen any application created as result of such matrix. Honestly: if an entity is updated and never created, or the contrary, it's missing feature in one of the application: wouldn't the users have reported this issue during the development, long before the matrix is created or updated ?

But on the positive side, the matrix is very useful and worth to be undertaken:

  • the matrix may help specific enterprise projects, such as enterprise master data manangement i
  • the matrix may also significantly ease impact assessment of changes or evolutions, by showing all the other applications (and therewith interfaces) that deal with the same data and might need adjustment.
  • "Support the gap analysis": indeed, the inventory of all the available entities help to analyse gaps when new applications are introduced (i.e.missing interfaces?), or when one or more applications are replaced.
  • "understand where the same data is updated": the matrix certainly facilitates this task. However, this assumes that the overlaps and the naming conflicts are well understood (see previous item).
  • Thanks for the thorough answer. Do you create one row per application and data entity ,for the second form, so that an application could have multiple lines?
    – Björn
    May 22, 2020 at 9:06
  • @Björn yes, that's it.
    – Christophe
    May 22, 2020 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.