Naming Conventions - Informatica Platform

Challenge

The use of a good naming convention is important for all Informatica services, repository and database objects. Naming convention standards should be agreed upon and ready to be implemented at installation time. When determining naming standards, keep possible and likely future environment changes in mind so that the names will not become confusing later on.

Description

The suggestions in this Best Practice focus on the objects and services within the Informatica platform. Choosing a convention that works for an implementation and then sticking with it is the key to deriving benefits in this area.

The use of good naming conventions facilitates smooth migrations and improves readability by providing a clear understanding of the processes being affected to anyone reviewing or carrying out maintenance in the Informatica Domain. If consistent names and descriptions are not used, more time may be needed to identify all of the objects and services and their intended usage and stakeholders.

The table below offers suggested naming conventions for various domain objects and services. Whichever convention is chosen, the selection should be made very early before installation (while reviewing the installation documentation) and development cycles.

Naming Conventions

Organization Structure

An installation of the Informatica Domain may start with a focus on delivering a single project, but may grow from that point. By nature, projects are intended to be activities with a beginning and an end. Once a project goes into production and completes closing processes, project naming may eventually no longer make sense. If a domain supports multiple projects, a project-heavy naming standard quickly loses its relevance. For this reason an organizational focus and structure using standard internal abbreviations is a good idea while services within a domain may logically be named at a more functional and granular level. Informatica discourages naming services and the domain based on a project. Exceptions apply where the life of the services is limited to the life of the project. An example could be an Analyst Service used for a data migration project for a source system that will be retired as part of the project. The organizational structure is shown as <ORG> in the naming convention tables.

Environmental Notation

Informatica Domains are often set up according to a development lifecycle that they will support. Standard organization environment lifecycles should be used for the Informatica Domain suffix if they support a single lifecycle and as a suffix for the names of services that they will support if they are lifecycle specific. Refer to the Environment Lifecycle Abbreviations table below for examples. Although shown in uppercase, the examples are not intended to be a recommendation on case. Neither is an example of a lifecycle a recommendation that a particular environment be part of a development to production life cycle. Environment is shown is as <ENV> in the Naming Examples table below. Very large environments can have many nodes and the number of services can grow too. The <optional descriptors> as shown for the nodes in the Naming Examples table below can of course be added to other service names if needed depending on how large the Informatica Domain grows to be.

The naming conventions above show the service type first. For services other than Domain and Node it is perfectly reasonable to display the organization and other descriptors first and use the service type abbreviation as a second to last suffix. An element of the final convention chosen should be based on what users will see and recognize first in order to help them distinguish between the right services and easily confirm that they are using the right one.

For the naming of objects inside services (i.e., transformation objects within products) review the product-specific naming convention best practices.