I am attempting to model the current state of our Customer MDM solution; eventually, I plan to model the steps required to accomplish the operational vision of the Customer MDM solution.
Modeling the application layer is a natural activity for me based on my experience, but I have not had to work in the information layer before. As I have been reading the meta-model documentation as well as several posts in this forum, I am starting to form a clearer understanding of how to work with the information layer. I would appreciate any feedback on my thoughts!
Due to system implementations in siloed environments, I have identified 5 major systems acting as SoR's for Customer data in addition to the MDM solution which serves more as a registry for customer data today. For illustrative purposes, lets say that two of the SoR's are the CRM system and Sales system. These SoR's update the Customer MDM in real-time and batch, respectively.
The easiest business view of information to identify is "Customer" itself, so I have represented "Customer" as the Information View. Subsequently, I have multiple Information Representations for each SoR's version of "Customer": "CRM Customer" and "Sales Customer". The purpose of these representations is to be able to define which Application Provider is the SoR of the Information Representation.
"Customer" is an abstract collection of information about a person or business, so I have further represented the Data Objects of "Customer" as "Customer Name", "Customer Address", "Customer Phone", etc. In our MDM, each person or business may have multiple "Customer Name", "Customer Address", "Customer Phone" Data Objects. Subsequently, I have multiple Data Representations for each SoR's version of "Customer Name": "CRM Customer Name" and "Sales Customer Name". The important aspect of this approach is that while the ideal view of Customer ought to include each of the Data Objects, the reality is that neither the CRM system nor the Sales system implement every Data Object and thus is an incomplete representation of a Customer. For example, since the Sales system is only concerned with Customer as it relates to a Sales Order, there was no need to include a "Customer Phone" Data Object in the Sales system. (No, this isn't actually true! I just made that up for the example. ).
What do you all think? Is this a reasonable approach to modeling the current state?
After completing current state, I would like to use this as the baseline for a roadmap which will show the required tasks to map the remaining SoR Data Objects to the MDM solution as a registry. Thereafter, I would like to show the required tasks to reverse the implied hierarchy and subjugate each SoR's create, update and delete processes to the Customer MDM.
Thank you for taking time to read my lengthy post!!!
- Hunter
Wow! It's hard to believe that it has been 2 weeks since my original post. Unfortunately, modeling the current state for our Customer MDM solution has been a part time job for which I have volunteered, so my time is shared with my "day" job.
Since my original post, I had a couple of meetings with our newly formed Customer Data Governance council as well as some conversations with our Data Architect. As a result of the feedback that I have received from these team members, I have worked through 3 revisions of my Customer model. I wanted to share some of the updates about my current model in the event that the information will help others who are just learning to use the Essential Model, too.
First, I have come to a better understanding of the differences between Information and Data which caused me to throw out my first attempt to model Customer. Specifically, I had Customer as an Information View because I thought the Information View was the way in which an abstract concept was represented. Now, I have Customer as a Data Subject. "Things" on the Data side of the Essential model remain unchanged despite being viewed from multiple contexts. Meanwhile, "Things" on the Information side of the Essential model make use of the "Things" on the Data side and have a context. Contexts can be provided by an area as broad as the Business Domains defined in the Business Conceptual Layer or by an area as focused as a software vendors implementation of a web page to permit the users to work with the data displayed on the web page.
Second, I have expanded my list of Data Subjects and grouped my Data Subjects into Data Domains. There was not an attribute for a Data Domain, so I renamed the Data Category in the EA_Support >> Utilities >> Enumeration list to be the Data Domain. I left the original Data Categories (Master Data, Conditional Master Date, etc.) and added those that I needed, such as Customer, Finance, Employee, Location, Product, Vendor, etc. I then used the Customer domain to group the Data Subjects which include items such as Customer, Customer Order, Customer Delivery, etc. This grouping was useful in the meetings with the Customer Data Governance council to define those items that are in scope for their governance. We settled on just dealing with the Data Subject of Customer in order to establish the practice; we might take on additional items as the practice grows.
Third, I have expanded the Customer Data Subject to include multiple related Data Objects, such as Customer Name, Customer Address, Customer Demographics, Customer Segmentation, etc. This expansion also proved useful in the meetings with the Customer Data Governance council to define those Data Objects that are in scope for the practice. In order to create a consolidated view of Customer across our multiple existing SoR's, we limited the scope to identifying a golden Customer record comprised of Customer Name, Customer Address, Customer Phone, Customer Email, Customer Identifier.
Fourth, I have begun to work with the Information side of the Essential Model. For example, the Customer Relationship Business Domain (defined in the Business Conceptual Layer) is concerned with Information about all Customers. So, I defined an Information Concept (among many others) named Customer List which is related to the Customer Relationship Business Domain. An important attribute of the Information Concept is to list which Data Subject(s) is supported. In this case, the Customer Data Subject is the only one required for the Customer List. Generally, I have found that the majority of my Information Concepts support more than one Data Subject since a lot of the basic Information Concepts are about the relationship of two or more Data Subjects. For example, the Information Concept named Customer Purchases combines the Data Subjects of Customer and Product and Sales Transaction. A list of Customer Purchase by Store might additionally bring in the Data Subject of Location.
Fifth, I defined Information Views which refine the Information Concepts. I have found that when a filter is used, it is a good sign of an Information View based on an Information Concept. For example, the Customer List may be filtered by a criteria such as last names beginning with the letter B. The Customer Search Results then is identified as an Information View which is a refinement of the Customer List.
My next steps will be to identify the possible Information Representations of the Information Views. For example, the Customer Search Results might manifest in the form of a Customer Search Results Web Page. Finally, I would be able to identify the possible Information Representations used in an Application Function from the Application Logical Layer. For example, a CRM application (such as Siebel) may implement a Customer Search Results Web Page named Siebel Customer Search Results.
I might be off the mark regarding the next steps, but I accept that as part of the process of conceptualizing our IT systems into a model. I find that the Essential Model has proven itself on more than one occasion, but the challenge is in learning how to identify and apply the concepts!
If you made it to the end of this post, then "Thanks, again!" for taking time to read through my long-winded post. I hope that documenting my process here will benefit others who are seeking to use the Essential Model. Of course, I would deeply value any insight from those who have blazed down this path before me.
-Hunter
Thanks for your post - all makes sense and it's great to hear about how you plan to use Essential.
We have done very similar things for some of our clients, in particular looking at Master Data Management. I think the only significant difference from your approach is that we used the Data Object metaclass rather than Information View to manage the data that we are managing in the MDM activity.
We manage Information and Data together but separately in the Information Layer, with information defined as being 'data in context'. In MDM scenarios, it's the data (Data Subjects, Data Objects, Data Representations) that we tend to work with to get a grip on the data that is being used to deliver the information things.
In a recent piece of work, we defined a Data Subject called 'Customer' to group all the Data Objects about Customer, for example things like 'Customer Master', 'Customer Hierarchy'.
Each of these Data Objects can have any number of attributes defined and each attribute can either be a simple, primitive type (e.g. string, integer, and so on) or of the type defined by another Data Object. So, maybe we've got an Address Object that we use to hold the customer address in the Customer Master Data Object.
We can define the System(s) of Record for each of these Objects (multiples because we might not yet have sorted our MDM out, or maybe we need multiple SoRs!) using the 'Data Object System of Record' field of the Data Object.
To represent what's actually going on in our systems, we define the Data Representations that exist for each Data Object - and it's perfectly normal to have multiples. e.g. we can define a Data Representation of the 'Customer Master' Data Object in the Sales System and another for the CRM System, e.g. 'Customer Master in Sales System', 'CRM Customer Record'. It's good to use the names / terms that are used in that representing system to make them easy to recognise.
There are a number of out of the box Views that will help to understand where data is being used and how it is being sourced.
To show how Data is being shared or provided between systems, we define Static Application Architectures, which capture the dependencies that exist between systems and on the arcs of these models, we can show the Information that is being exchanged. We recommend that these are defined using a 'nearest neighbour' approach as the Views will query across all of the relevant models and this makes things much easier to manage.
I won't go into these application dependencies further at this stage.
In terms of roadmaps, we can define a roadmap using the Strategy Management classes. We can define the Information Strategic Plans to describe what we plan to do (to move from one state to the next) and the Data elements that these plans relate to, e.g. Data Objects, Data Representations.
I think these Strategic Plans probably map to what you describe as 'required tasks'. For completeness, if we want to understand HOW we are going to make these changes, we can map the Strategic Plans to the Change Activities (Projects, Programmes, etc.) that will make the changes happen.
In summary, all sounds good but for MDM things in particular you might find that using Data Objects and Representations rather than Information Views and Representations works better.
Thanks again for posting.
My last reply was actually to your first - I think our posts must have crossed in the ether.
Sounds like you are very much on the right track - much of what you've just described e.g. using the Data classes, is what I would recommend.
A quick point of caution in terms of changing the name of the Data Category Enumeration class. As you've no doubt found, it is very easy to modify the model and meta model to fit your needs - and this is one of the powers of the toolset. However, we strongly recommend that you take an "extend" approach to modifying the classes - adding the things that you need - rather than rename or repurpose the OOTB classes. This is purely to make it easier to apply update and upgrade packs to your repository going forward and also because the OOTB Views expect to see specific classes and slots as per the baseline meta model.
In the scenario you describe - the Data Domains - if you need to introduce something new, I would recommend creating a new Enumeration class (it will inherit all the default behaviour) and introduce a new slot on the Data Subject to connect to that new Enumeration type.
Having said all that, the examples you describe for your Data Domains sound very much like Data Subjects (Customer, Finance, Employee, Product, etc.) and things like 'Customer Order', 'Customer Delivery' and 'Customer Master' as Data Objects connected to the Customer Data Subject.
As I mentioned in my last post, we use the Data Representations to capture how these Objects are represented in our systems (still at the logical level).
We recognise that there are some terminology issues in terms of things like Conceptual, Logical, Physical - especially with terms commonly used by DBAs and data modellers. However, it's important that we maintain consistency across the EA layers for our abstractions, so there may be some terminology mapping required in particular in the Data layer!
Thanks again for sharing your experience - I hope you don't mind some comments
Hi, Jonathan!
Thank you for all of the feedback! I greatly appreciate all wisdom that you can dispense to guide me in using the tools in the best possible manner! Therefore, I have heeded your advice and have reverted the Data Category Enumeration class to its original state. I used the Wizard Tool for Creating a Subclass in order to create my new Enumeration class named Data Domain. (I could not find another way to create a subclass. The Wizard is very simple though.)
Having just learned how to create sub-classes, I had the bright idea to create a subclass of Data Subject and add the new slot to my new subclass so that I did not modify the Data Subject from its original state. Shortly thereafter, I learned that the Essential Viewer reports would all need to be changed to specifically reference the new subclass. My simplistic fix was to revert back to using the Data Subject with the new slot for Data Domain added to it. Reports fixed!
However, I am wondering what is wrong in my thinking to subclass Data Subject. Is there a simple way to have the reports use the class and sub-class? After taking an update to the model, will I have to remember to add back any and all slots that I have added to the original classes?
I have much more work to do on our model. Later this week, I am meeting with a number of system SME's to define their Data Representations for each of the Data Objects which are considered in the scope of governance by our Customer Data Governance council. I also hope to capture some of the major Information Representations, such as specific user interface web pages, XML data layouts employed in system interfaces, existing reports, etc.
Thanks, again for you support on this venture!
- Hunter
I think you are right with your use of subclassing. FYI : some days ago, I asked for a new feature that would allow to use subclasses in reports. Jonathan answered it will do some experiments.
You are certainly taking the right approach in terms of adding new things to the meta model.
However, it is also perfectly fine to add additional slots to the existing classes - just avoid changing the out-of-the-box ones. You can do this by activating the Classes tab in Protege (Project->Configure) and then creating and adding your new slots to the class. Our update packs are careful to preserve any extension slots when we make updates.
Once you have added a slot to the class, you will need to update the relevant View Template (XSL) files to render your new slot. You can do a file->save as on the OOTB template and save it to the "user" folder in Viewer to ensure that a future update does not overwrite your custom View but that then requires a bit of configuration of the Viewer environment in the Protege repository.
Apologies J.-M., we have completed the experiments that we discussed and the addition of the class inheritance tree to the XML snapshot was simple to code and although it does increase the amount of XML being generated, we felt that this was acceptable - especially in terms of the payback for improved querying in Viewer. In particular the ability to query against all subclasses of a specified type.
I'll post a follow up on that thread but in short this is something that we will add to the platform in the next release of the Reporting Tab Protege plugin.
A final note on this: Many of the out-of-the-box views actually do not use the type as part of the query. The catalogues almost certainly do, but most Views that are accessed via a link know the specific instance we are interested in and do not worry about the type of that instance. What this means is that you can still use your Subclass and many of the existing Views should pick up instances of that new class correctly.
).
