Data Management 2: Subject Areas and Objects

This is the second blog post in the Data Management series and we will dive straight in with a discussion about subject areas and (information) objects, often called Entities. We start with a high-level overview of the theory and then dive into ArchiMate modeling.<img alt="Subject Areas and Objects. Data Management blog series" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-subject-areas-objects_424x283.png" style="width: 424px; height: 283px;" title="Data Management blog series. Part: Subject Areas and Objects"/><h2 class="p1">Theory</h2>A subject area model is used to differentiate between areas of interest from a data/ information perspective in the organization. These are called Subject Areas. Examples of subject areas are: customer, product, and supplier. This is not a new concept; it seems that it was introduced by James Martin in his books on Information Engineering in the late 1970s/ early 1980s. A Subject Area typically consists of 12-20 Business Subjects. These are the key areas of interest in the business domain. Simplifying slightly from the <a href="http://www.amazon.com/Guide-Management-Knowledge-DAMA-DMBOK-Edition/dp/1935504029/" target="_blank">DMBOK</a> best practice, we use the concept of an Entity as a synonym for a Subject. Note that in fact we are talking about Entity Types rather than Entities (see the work of <a href="http://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215/" target="_blank">Kent</a> for an extensive discussion of why this distinction is important). We focus on the type level, not the instance level. For purposes of readability, we will consistently use the term Entity rather than Entity Type. The following ORM diagram illustrates this point:<img alt="Entity types related by means of a fact type" class="left" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/data-management-entity-types.png" style="width: 202px; height: 110px; float: left;" title="Two Entity Types (Person and Company) related by means of a fact type (“works for” with the inverse reading “employs”)."/>Here we see two Entity Types (Person and Company), each identified by their na,e. These are related by means of a fact type ("works for" with the inverse reading "employs"). The purple dot signifies the constraint that "each Company employs at least one Person"The population of this scheme in terms of Entities is visualized by the supporting table. Here we see for example that the label "Bas" identifies an Entity of the Entitiy Type "Person". Business Entities are the ‘things’ we talk about in a business context. For example, the Subject Area ‘Customer’ would be decomposed in Entities such as customer, address, and purchase history, etcetera. One would typically make an ERD to show the relations between entities as well as constraints on these entities (for each order the customer supplies a shipping address and a billing address). This may be a bit too much at the architecture / ArchiMate level, but we should at least be able to tie in to an ERD.<h2 class="p1">Modeling</h2>In summary: we introduced and defined two concepts for information modeling that we will be using throughout this blog post series: <ul><li class="li2">Subject Areas, which are used to structure areas of interest from an information perspective, for example customer, or product; and,</li> <li class="li2">Business Entities (or just short: Entities), which are the key concepts or “things” that are part of a Subject Area, e.g. for the Subject Area customer: address or purchase history;</li></ul>In this part we describe how these concepts could be modeled in ArchiMate. This makes it possible to integrate model support for Data Management into the overall Enterprise Architecture expressed in the ArchiMate standard. Also, tool support such as BiZZdesign’s modeling and analysis tool for Enterprise Architecture, BiZZdesign Architect, can be leveraged for Data Management. It seems to make sense to model the Subject Area concept with the BusinessObject concept. In BiZZdesign Architect, we could add a profile to this concept so that we can distinguish them from regular BusinessObjects in the sense that they could have a different graphical shape. Along the same lines: Entities should be modeled using the BusinessObject concept. This does not require any further profiles, except for cases where the model also captures other types of business objects (i.e., non-informational objects) and we want to be able to distinguish between the two types. Two challenges remain:<ol class="ol1"><li class="li1">Entities have Attributes. It may be very important to be able to represent the fact that we distinguish between “first name” and “last name” rather than simply using “name”. Since ArchiMate does not have a concept for Attribute, we propose to simply use a CompositionRelation to decompose BusinessObjects into its attributes. Domains, cardinality and optionality are not modeled at the ArchiMate level.</li> <li class="li1">Many organizations choose to explicitly model meta-data about Entities. For example: definition of the concept, relevant business rules and legislation, stewardship (as we will describe in a later posting) and so on. It seems to make sense to use the ‘Meaning’ concept for this. However, this quickly becomes tedious and will crowd the model. Also, some meta-data is represented by the fact that BusinessObjects are linked to other ArchiMate concepts in the model. We will get back to the meta-data discussion in a separate post! </li></ol>To provide a link with the design level, it makes sense to relate Subject Areas to more detailed ERD models. To do this, we have recreated the basic Chen ER diagramming notation as a separate meta model in Architect which allows us to do the following:<ul><li class="li2">A Subject Area as modeled in the ArchiMate world is refined in an ERD view</li> <li class="li2">An Entity as modeled in the ArchiMate world is equal to an entity in an ERD view</li></ul><img alt="Subject area and entity modelled in ArchiMate " src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-ArchiMate-model-package_599x274.png" style="width: 599px; height: 274px;" title="Subject Area as modeled is refined in an ERD view in ArchiMate. An Entity is equal to an entity in an ERD view in ArchiMate"/>In the next posting in this series we will describe how entities are realized in applications. As always: if you have questions or suggestions, please drop us a note. Stay tuned!