Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the third blog post in the Data Management series. Last time we discussed the notion of subject areas and entities. This time we zoom in on the realization of these entities in applications.
One of the things we should be able to do is to create views that show which systems have data about a certain Entity. Similarly, we want to link our Entities to Processes. Going forward, we will use the term ‘Data Object’ to differentiate between the Entity in a business context and its data-counterpart. The ‘Attributes’ of Entities (see also our previous post), are reflected as ‘fields’ in their Data Object counterparts.
A “coverage analysis” will be the tricky part: suppose that we have a Subject Area called ‘Customer’. The key Entity in this Subject Area is also called Customer with Attributes such as name, social security number etcetera. Other Entities are such things as shipping address, E-mail address, etcetera. There are two things we want to visualize for business stakeholders:
Which information with respect to a customer is relevant from a process perspective? Only name? Only Social Security Number? Both?
Which information about a customer is stored in a system? One system may store the E-mail address of a customer, whereas the physical address may sit in another system
We have call this a “coverage analysis” because: from a data governance perspective we want to make sure that all Entities in a Subject Area, as well as all Attributes of an Entity are represented somewhere in a System!
This type of modeling is quite ‘standard’ in ArchiMate. There are separate concepts for BusinessObjects and DataObjects. Also, there is a standard way of relating the two, using a RealizationRelation.
The fact that DataObjects have Fields is modeled using a CompositionRelation and more DataObjects. This is not a very ‘pretty’ solution. Especially when a data object has many fields, the visualization will quickly become cluttered. For example, 4 DataObjects with 3 Fields each ads up to at least 12 concepts and 12 relations which has a high visual complexity. Using graphical nesting will result in a much cleaner visualization.
The standard way of modeling the relation between a system (ApplicationComponent) and a DataObject uses the behavioral concept of an ApplicationFunction. The idea is that an ApplicationComponent has (internal) behavior to manipulate DataObjects. While it is correct, and often useful to model Application Functions, for most visualizations it is equally useful to hide them and use a short-cut notation as follows:
With respect to the coverage-type analyses mentioned previously, this could be done and visualized in many different ways such as:
Select a Subject Area or an Entity and list (color view) all Data Objects that are associated with it
Select a Subject Area or an Entity and show (color view) all Systems that manage a data object that is associated with this Subject Area or Entity.
Select a Subject Area and highlight (color view) the entities that have an associated Data Object that is managed by some system
Generate a CRUD-matrix that lists which Entities are accessed by which Process. Use the CRUD notation in the cells to show the nature of the access relation
Select a Subject Area and create a CRUD-matrix as listed above
Select a Subject Area and create a CRUD-matrix that shows which System manages (!) a Data Object that is a realization of an Entity that sits in that Subject Area. At the intersection of the columns and rows we should list the name of the Entity
Modern tools such as BiZZdesign Architect make these analyses fairly straightforward and reusable. We mentioned techniques such as creating color views and generating tables. This functionality is available in our Enterprise Architecture tool BiZZdesign Architect, which can be downloaded here (30-day free, fully featured, trial license). If you would like a demonstration, please leave us a note!
As a final thought for this posting: note that this list has a mix of different types of visualizations, such as diagrams and matrices. This is partly because of communication preferences of key stakeholders, but also because some results are easier to interpret in different formats.
In the next posting we will dive into Data Governance with a strong focus on data stewardship (Data Stewards are generally considered to be the heroes of the field), so stay tuned!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: