Challenge
A variety of factors are considered when assessing the success of a project. Naming standards are an important but often overlooked component. The application and enforcement of naming standards not only establishes consistency in the repository but provides for a developer-friendly environment. Good naming standards ensure the MDM SaaS repository can be easily understood and easily accessed by all developers.
Description
Implementing standard naming conventions facilitates smooth migrations and improves readability for anyone reviewing or carrying out maintenance on IDMC platform assets. It can help in understanding the processes that are affected. If consistent names and descriptions are not used, significant time may be needed to understand the workings of mappings and transformation objects. If no description is provided, a developer is likely to spend considerable time going through an object or mapping to understand its objective.
This document offers standardized naming conventions for various IDMC platform assets used for MDM SaaS. Whatever convention is adopted, it is important to make the selection very early in the development cycle and communicate the convention to the project team. The policy can be enforced by peer review and at test phases by adding processes to check conventions for testing plans and for testing execution documents.
MDM SaaS Naming Standards
Business Entities
In Customer 360 (C360) SaaS, the naming conventions for new groups and fields for an existing entity are somewhat enforced. When working in MDM SaaS, since there are no existing entities, a naming convention is more important.
Compared to the MDM Multidomain Hub, the length of entity and field names in MDM SaaS is a generous 255 characters. There is less of a need to shorten names by removing vowels. Therefore, use reasonable terms with no abbreviations for entity names.
The suggested naming standards are:
| Object | Display Name |
Physical Name |
| Entity | The display names should have a meaning to the business users, such as for the data stewards. Where possible this name should be the full unabbreviated name and in title case capitalization. Spaces, dashes, and underscores are allowed. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Entity Field Groups |
The display names should have a meaning to the business users, such as for the data stewards. Where possible this name should be the full unabbreviated name and in title case capitalization. To emphasize the repeating nature, the name should be in the plural form (e.g., Addresses instead of Address.) Spaces, dashes. and underscores are allowed. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Entity Fields |
The display names should have a meaning to the business users, such as for the data stewards. Where possible this name should be the full unabbreviated name and in title case capitalization. If the field is in a group, there is no requirement to prefix or suffix the field name with something to represent the field group and distinguish the field from another in another field group.
For example, Field Groups of Addresses and Phones each have a Start Date field. It is not required to name the fields Addr_Start_Date and Phone_Start_Date. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
Fields in a group field will be referenced using the Group Name in JSON and XML (e.g. Addresses.Address Line 1). |
Job Definitions
In C360 SaaS, Job Definitions are used to execute MDM processes like loading data into MDM (ingress) and extracting data out of MDM (egress). Other jobs include generating search indexes, match & merge, generate merge tasks, and publishing events.
The suggested naming standards are:
| Object | Display Name |
Physical Name |
Ingress job |
The display names should start with “Ingress”, followed by the name of source system and then the business entity being loaded. If there is more than one source system table being loaded to the same entity, add that table name after the source name. Spaces, dashes, and underscores are allowed. Examples: Ingress Salesforce Organization – this would load data from Salesforce into the Organization table. Ingress Salesforce Contact Person and Ingress Salesforce Lead Person would both extract data from different Salesforce tables to load into the MDM Person entity. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Egress job |
The display name should start with “Egress”, followed by the business entity being extracted and then the name of the source or consuming system. If there is more than one target in the source or consuming system, it is not necessary to have different job definitions. Entity data should be extracted from MDM once, and then bifurcated in the CDI mappings to two (or more) target tables. Spaces, dashes, and underscores are allowed. Examples: Egress Organization Salesforce – this would extract data from the Organization entity and update the Salesforce system. Ingress Person Salesforce – this would extract data from the Person entity and update both the Contact and Lead tables in Salesforce. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Generate Index |
The display names should say “Generate Index” followed by the business entity name. If all entities are being regenerated at once, use “All” instead of the entity name. Example: Generate Index Organization Generate Index Person Generate Index All |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Match & Merge |
The display name should start by indicating which process is running, followed by the Entity Name. For Match & Merge and Match, add the Match Rule Set. For Match & Merge, use prefix “MM”. For Match only, use “Match”. For Merge only, use “Merge”. For Resetting records, use “Reset”. Examples: MM Person Initial Rules Match Organization USRules Merge Organization Reset Person |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Generate Merge Tasks |
The display name should say “Generate Tasks” followed by the business entity name. Example: Generate Tasks Organization |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Publish Events |
The display name should say “Publish to ” followed by the target system name. Example: Publish to Salesforce |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Cloud Data Quality
Cloud Data Quality assets are used in mappings to load data into MDM and are also attached to business entity fields.
To be attached to a business entity field, a Rule Specification must be used. For CDI mappings, all types of DQ Assets can be used.
Suggested naming standards for those assets are listed below.
| Object | Display Name |
Physical Name |
Rule Specification |
Object name should begin with “RS_”, and then identify the MDM field name being altered and indicate something about the nature of the check. If the check is only used for one type of entity, add the entity name between the “RS_” and the field name. If used for the same field in multiple entities, leave the entity name out. Examples: RS_org_name_standardized This rule spec would be attached to the MDM Organization field name for the purpose of standardizing the value. RS_phone_number_format This rule spec would be attached to the phone number field in both the Organization and Person entities to properly format the phone number. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
| Verifier | Object name should begin with “Verify” and then be followed with what is being validated. Examples: Verify_address Verify_email |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
| Dictionary | Object name should begin with “Dictionary_” and then be followed by the name of the object which is using it. If more than one object uses it, then refer to the contents of the dictionary Examples: Dictionary_rs_org_name_standardized (for the Rule Spec attached to the org name field) Dictionary_name_noise_words (for use by multiple fields) |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
| Cleanse | Object name should begin with “Cleanse_” and then be followed by the name of what data element is being cleansed. Use underscores. Uppercase first letter only. Examples: Cleanse_address_line1 Cleanse_corporate_name |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
| Parse | Object name should begin with “Parse_” and then be followed by the name of what data element is being parsed. Use underscores. Uppercase first letter only. Examples: Parse_full_name Parse_delivery_addr_line1 |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
| Profiles | Profiles name should begin with “Profile_”, and then indicate the name of the entity field being profiled. Next, the name should identify the source system and which source object (table) is being used. Example: Profile_address_salesforce_account |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
|
Cloud Data Integration Mappings
In the IDMC platform, MDM SaaS operations rely on assets built in other services – Cloud Data Integration (CDI), Data Quality (CDQ), Cloud Application Integration (CAI) – to get data in and out of MDM. Applying naming standards to those assets will help to identify them as being used with MDM SaaS, versus being used for other applications.
CDI Mappings, Mapping Tasks, Taskflows
CDI Mappings are required to process data in bulk to and from MDM.. Those Mappings are executed using Mapping Tasks and Taskflows.
Suggested naming standards for those assets are listed below.
| Object | Display Name |
Physical Name |
| Mapping | Mapping name should begin with “m_”, and then indicate whether data is going into or out of MDM SaaS by using “in_” or “out_”. Next, the name should identify the source system and which source object (table) is being used. Examples: m_in_salesforce_account would be the mapping to extract data from the Salesforce source’s account table and bring it into MDM. m_out_marketo_contact would be the mapping to extract data from MDM and send to the Marketo source’s Contact table. |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Mapping Task |
These should follow the same standards as the Mapping, except the prefix is “mt_” instead of “m_”. Examples: mt_in_salesforce_account mt_out_marketo_contact |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_) |
| Taskflow | These should follow the same standards as the Mapping, except the prefix is “tf_” instead of “m_”. Examples: tf_in_salesforce_account tf_out_marketo_contact |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_) |
Cloud Application Integration
Cloud Application Integration assets can be used to create an orchestration workflow for running the MDM SaaS Ingress and Egress processes.
Processes, Service Connectors, App Connectors
Suggested naming standards for those assets are listed below.
| Object | Display Name |
Physical Name |
| Process | Process names should begin with “p_”, and then indicate the action that is being performed. Next, the name should identify the source system and which source object (table) is being used. Example: p_FullRun_SalesforceAccount |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
Service Connector |
Service Connector names should begin with “svc_”, and then indicate to which system or application it is connecting. Example: svc_B360SaaS |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
App Connector |
App Connector names should begin with “app_”, and then indicate to which system or application it is connecting. Example: app_B360SaaS |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |
| Service | Service names should be descriptive and the same as the action name as defined in the service connector. Example: app_B360_Login app_B360_Get_Person app_B360_Search_Org |
The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_). |