...
However, YOUnite's primary focus has been to make this process as easy and non-intrusive as possible.
...
Start by Analyzing the Use Cases
If instead you start by analyzing the data, you will data and building data dictionaries of all the systems you plan to work with MDM (source systems) you will quickly feel like you are trying boil the ocean. You will be adding to an already exceedingly arduous process of normalizing data -- by analyzing data that isn’t relevant to your MDM process .
Example: A college system uses a Learning Management System (LMS). The LMS also has features for Ed Planning however, the college system uses a separate system for Ed Planning so a data analyst would be wasting their precious time if they were to catalog the entire LMS schema since the Ed Planning system in the LMS is not used.
Think in Terms of REST
Asking use case questions in terms of RESTful operations (HTTP GET, PUT, POST and DELETE -- following REST principles) can help keep focus on what can become a very convoluted process of analysis -- if the analysis deviates from this it almost always leads to paralysis. Ultimately YOUnite breaks transactions down into RESTful operations and if you know which operations to avoid then a lot of time can be saved.
Example: The College Application systems never wants to delete a student once they have been added to the system. Since this is the case, analysis for the DELETE request can be ignored with this application.the time to complete the data analysis phase can grow exponentially.
Generally its best to lead with the use cases and limit the initial deployment to just a few use cases and gradually connect more and more of the organization's ecosystem to MDM. Use cases often equate to storyboarding but keep in mind, this is not application storyboarding but data synchronization and notification storyboarding. We want the stakeholders of the applications and data in the organization to specify their realtime needs for "the truth. This includes the following:
- What are the source systems tied to the use cases?
- Who are the stakeholders for the use cases e.g. Data and Application Architects, Business Managers, etc.?
- How do the source systems connect to their data
- What data elements in the source systems matter to the stakeholders.
- Start building data dictionaries of how the various source systems model the data
- Stakeholder descriptions: For each stakeholder, describe the systems where the "truth" data elements live (see next step) and what notifications they need to receive
- Data synchronization and notification storyboarding. We want the stakeholders of the applications and data in the organization to specify their realtime needs for "the truth. This includes descriptions of how the data will be used and which applications need to be notified when changes occur.
From the data dictionaries and stakeholder descriptions a clear picture starts to take shape for:
- Data domains
- Adaptor development and capabilities
- Governance
Establish the Truth
Out of analysis you discover the truth i.e. which systems hold the truth values for a given domain. As you catalogue the entities data elements in a data dictionary it is important to note which systems hold the truth for the various stakeholders since knowing this reduces the amount of analysis required.
...
Knowing this, you no longer need to worry about what issues may arise from sending data from the LMS to other systems and focus primarily on how data will flow from either the Application System or SIS into other systems such as the LMS.
Think in Terms of REST
Asking use case questions in terms of RESTful operations (HTTP GET, PUT, POST and DELETE -- following REST principles) can help keep focus on what can become a very convoluted process of analysis -- if the analysis deviates from this it almost always leads to paralysis. Ultimately YOUnite breaks transactions down into RESTful operations and if you know which operations to avoid then a lot of time can be saved.
Example: The College Application systems never wants to delete a student once they have been added to the system. Since this is the case, analysis for the DELETE request can be ignored with this application.
The MDM Process is a Multi-Dimensional Cross-Cutting Concern
...
Example: A college system uses an Ed Planning system that tracks meetings between the student and college faculty and staff. Others systems may use the Ed Planning data but if no other systems in the systems use the scheduling system, then the schedulng data can be ignored in respect to modeling student, faculty or college data domains.
The Process is Iterative
Start small and gradually conect more applications and services in the organization to the MDM ecosystem.
A Couple of Additional Points
...