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