Archive for the ‘Naming Convention’ Category

Stick to a Naming Convention – It’s not Rocket Science!

June 23, 2008

Wikipedia has one of the best definitions on the net for a “naming convention”: A naming convention is a convention for naming things. Awesome!

In the Enterprise Incentive Management and Sales Performance Management world, this means naming all plan objects in a consistent way. Naming will vary from tool to tool and there is not a single set of best practices that can be followed. Most vendors provide some recommendations, but it’s up to the implementers to decide which naming format will be used. Since there is no generally accepted “convention”, it may be more accurate to call this a naming strategy.

Why is sticking to a naming strategy important:
Incentive Compensation Management is not difficult. What makes ICM systems complex is the volume of plan elements (plans, rules, formulas, tables, variables, etc..) A large implementation can quickly become a jungle if not everybody agrees on a common way of naming different objects. Not only will it make building and testing the system easier, a good naming strategy will especially be important once the original implementation team is gone and others have to understand the logic of the system. Finally, aside from clarity, a naming strategy will also help search for plan components more efficiently.

Choosing a naming strategy
As I said, since all applications do not share the same objects, and also because each application works differently, I cannot provide a silver bullet for all situations.

Generally, I try to stick to these principles:
  • Make the name descriptive
  • Use abbreviations to identify object type
  • Begin object name with its object type abbreviation

For example, a credit rule could be called CR_AE_description. Some systems could have a direct credit rule and an indirect credit rule; in such case my abbreviation could be DC and IC instead. In some systems I may want to prefix a formula with F (if all objects can be displayed in the same view), if not, then it would not be necessary to explicitly say that a formula is a formula.

Naming of output is also important: The importance of naming an object may be obvious, but in the case of rules, the output of such rule should also be named carefully. A result name that makes sense can often by “Rule name _ result” or something similar.

Getting Started…

It is important to define a naming strategy early on in the project – before any detailed / technical design documents are created. The strategy should be illustrated on one page to enable the implementers to quickly see how to name the different objects. This “page” should be distributed to everyone involved in the implementation and be given to new joiners as well.

The first steps in defining the naming strategy is to find out if the application being used has a set of best naming practices or standards. In the case of an upgrade, it is important to stick to previously used naming strategy.

Happy Naming!