11 years, 1 month ago

Data Management 3: Realization of Entities in applications

<p class="p1"><span class="s1">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.</span></p><p class="p1"><span class="s1"><img alt="Content. Data Management part 3" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-realization-of-entities-in-applications.png" style="width: 501px; height: 334px;" title="Data Management part 3: Realization of Entities in applications"/></span></p><p class="p1"> </p><p class="p1"><img alt="Data Management. Coverage analysis" class="left" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-Coverage-Analysis.jpg" style="width: 150px; height: 114px; float: left;" title="A “coverage analysis” will be the tricky part"/></p><p class="p1">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.</p><p class="p1"> </p><p class="p1"> </p><p class="p1"> </p><p class="p1"><span style="font-size: 11px; line-height: 19px;">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:</span></p><p class="p1"> </p><ol class="ol1"><li class="li1"><span class="s1">Which information with respect to a customer is relevant from a process perspective? Only name? Only Social Security Number? Both?</span></li> <li class="li1"><span class="s1">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</span></li></ol><p class="p1"><span class="s1">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!</span></p><p class="p1"><span class="s1">This type of modeling is quite ‘standard’ in ArchiMate. There are separate concepts for </span><strong><span class="s2">BusinessObjects </span></strong><span class="s1">and </span><strong><span class="s2">DataObjects</span></strong><span class="s1">. Also, there is a standard way of relating the two, using a </span><strong><span class="s2">RealizationRelation</span></strong><span class="s1">. </span></p><p class="p1"><span class="s1">The fact that </span><strong><span class="s2">DataObjects</span></strong><span class="s1"> have Fields is modeled using a </span><strong><span class="s2">CompositionRelation</span></strong><span class="s1"> and more </span><strong><span class="s2">DataObjects</span></strong><span class="s1">. This is not a very ‘pretty’ solution. Especially when a data object has many fields, the visualization will quickly become cluttered. For example, 4 </span><strong><span class="s2">DataObjects</span></strong><span class="s1"> 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.</span></p><p class="p1"><span class="s1">The standard way of modeling the relation between a system (</span><strong><span class="s2">ApplicationComponent</span></strong><span class="s1">) and a </span><strong><span class="s2">DataObject</span></strong><span class="s1"> uses the behavioral concept of an </span><strong><span class="s2">ApplicationFunction</span></strong><span class="s1">. The idea is that an </span><strong><span class="s2">ApplicationComponent</span></strong><span class="s1"> has (internal) behavior to manipulate </span><strong><span class="s2">DataObjects</span></strong><span class="s1">. While it is correct, and often useful to model </span><strong><span class="s2">Application Functions</span></strong><span class="s1">, for most visualizations it is equally useful to hide them and use a short-cut notation as follows:</span></p><p class="p1"><span class="s1"><img alt="A model of application functions" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-model-application-functions.png" style="width: 599px; height: 262px;" title="model Application Functions"/></span></p><p class="p1"><span class="s1">With respect to the coverage-type analyses mentioned previously, this could be done and visualized in many different ways such as:</span></p><ul><li class="li1"><span class="s1">Select a Subject Area or an Entity and list (color view) all Data Objects that are  associated with it</span></li> <li class="li1"><span class="s1">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. </span></li> <li class="li1"><span class="s1">Select a Subject Area and highlight (color view) the entities that have an associated Data Object that is managed by some system</span></li> <li class="li1"><span class="s1">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</span></li> <li class="li1"><span class="s1">Select a Subject Area and create a CRUD-matrix as listed above</span></li> <li class="li1"><span class="s1">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</span></li></ul><p class="p1"><span class="s1">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!</span></p><p class="p1"><span class="s1">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. </span></p><p class="p1"><span class="s1">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!</span></p>