Datahub Data Mapping Ideas

amanafirad
amanafirad
in Integrations and extensibility

Hi folks,

How would you map of what's coming to your Datahub and what data is leaving the hub to any spoke model? We have a big Datahub with over 100 processes and sometimes when we have a data mapping issue it is very challenging to have clear visibility of what data connection is missing. We use the Hypercare app that shows import/export ids run on a particular schedule but then we need to take the id search in the Anaplan model and then track it down to the data source. Any idea how we can have clear visibility of the whole process?

Tagged:

Answers

  • ryan_kohn
    ryan_kohn

    Can you elaborate on what you mean by “data mapping”? What level of information about a mapping or connection would you want to see?

  • amanafirad
    amanafirad

    Hi Ryan,

    Thanks for your comment. what I mean by "data mapping" is to know what information comes to our GDH. Let's say I have an action name that is part of a process. What's the next step to see where the data for that particular action coming from? how can I see that in Anaplan?

  • ryan_kohn
    ryan_kohn

    Unfortunately, there's no “easy button" for generating an integration schema for your entire environment, so this ultimately comes down to a combination of good governance while building your models along with cobbling together some existing data points available in models today.

    Building a schema

    In order to generate a map of your inbound and outbound data sources, you can combine data that's available within the model settings. Unfortunately, there are no APIs available today to get this information.

    1. Get a list of Import Data Sources

    image.png

    image.png

    When you create an import, you have the choice to use an existing import data source or add a new one (by uploading a file or connecting to another model). The list of import data sources is retained and this is your first stop for understanding the possible data sources for a specific model.

    Note that any model-to-model imports from within the same model will have the Source Model listed as “-”.

    There is no “Export” button for the list of import data sources, but you can highlight the entire grid to copy it, and then paste it into another tool for reference.

    2. [If Applicable] Get a list of Source Models mappings

    image.png

    For any import data sources from another model, it is possible to override the specific source model that is used. Note that in the import data sources list, the original source model name is used, and not the overridden value. It is a good idea to update your exported list of import data sources to include the overridden mapping wherever it is used.

    3. Get a list of Imports

    image.png

    The list of imports is where you begin to connect everything together. For each import, you can see the import data source ("Source Label"), along with some details about the import data source (Source Object and Source Type).

    4. Build a mapping of actions to processes

    Showing which actions are part of a process is more complicated and manual, and this is also where good governance will help you (see below).

    image.png

    It is possible to see which processes contain each individual action, but if you are looking to show a list of all actions in a specific process, you would have to compile that on your own.

    5. Build documentation / generate a schema

    Gather the above details for all your models. Since model-to-model connections in Anaplan are “pull” based, you will need to get these details from the target model side of any model-to-model imports in order to see the connections between models.

    Once you have all the information, you can use it to build your documentation in a way that is meaningful to your business.

    Governance

    Following best practices for model maintenance and naming conventions will make it easier to maintain details about the above mappings.

    1. Remove any import data sources, actions, and processes that you don't need. This will make it easier to find things, and also prevent you from documenting details about mappings that aren't being used.
    2. Follow standard naming conventions for actions (Planual rule 5.01-01) and processes (Planual rule 5.02-01). You read through Anaplan's recommended naming conventions here: https://help.anaplan.com/aeb0b95e-f7a3-4fe5-81c7-aec9a12f80be-Name-conventions
    3. By following numerical naming conventions, you can then order your actions so that related actions are together. This will make it easier to follow the sequence of actions. Also, grouping actions from the same process together in the order they occur will make it easier to build and maintain any external documentation for those action mappings.
    4. When you deploy changes to production, be sure to update any external documentation so that it stays up to date.

  • amanafirad
    amanafirad

    Thanks, Ryan. This was really helpful. As a team lead, I will first ask my team to go over the processes and add notes to each record and sanitize the processes by removing old(not used) records and doing the same with imports and actions. Then we will dive deep into putting a data map together. I will update this post when we go through the process so we can be a value-add in this community.

Categories