Well-defined Data Part 6 – Attributes that Name
In this article we focus on people-oriented identifier attributes — ones intended to record the name by which the person or thing is known, addressed, or referred to.
Unlike the business entity identifier attributes discussed in Part 5, name values may change over time, and values may not be expected to be unique, e.g. names of persons.
There are instances of things that an organization establishes internally, and therefore has the right to name. These things include positions within its organizational structure, its general ledger accounts, the products it produces, the services it offers, and the locations it manages for operations and sales purposes.
Things that an organization does not have the right to name include its staff members, customers, and suppliers.
Full, Abbreviated and Coded Name Attributes
When a business entity is the type of thing that has named instances, there is a good chance that there will be requirements for more than one name attribute. Wherever names consist of a number of full words, the organization will most likely have a shorter version of the name that it uses in its business processes.
And where a name is used frequently, and keystrokes are to be minimized, there is likely to be an extra-short code version of the name.
Non-word Names
Not all names consist of words or abbreviations. Street names are a good example. The majority of street names do involve words like ‘Main’ or ‘Maple’, or are named after people or places. But there are also street names based simply on numbers or letters, e.g. ‘1st Avenue’, ‘2nd Avenue’, ‘A Street’, ‘B Street’.
Another example of non-word names are floors within a multi-story building. The floors will have full names, such as ‘Ground Floor’, ‘Fifth Floor’, ‘Parking Level One’, or ‘Penthouse’. But the organization may only require the coded versions of floor names (e.g. ‘G’, ‘5’, ‘P1’ ‘PH’).
Person Names
Person names are different again. One difference is that there is seldom an expectation that a person name will be unique. Another difference is that a normal part of life involves individuals changing their name, either legally or simply to the latest way they prefer to be addressed.
For entities that represent persons, such as Staff Member or Customer, there are four basic name-related attributes that may be necessary to support an organization’s business processes:
- Legal Name — (1) Required to support business processes that involve regulatory organizations, where those organizations require identifying individuals (and companies) by their full legal name, e.g. tax authorities. (2) Required during business processes initially verifying a person’s identity, when that name is used to match with other organizations that also maintain a person’s legal name for such purposes, e.g. ‘Thomas Albert Jones’.
- Contact Name — The name a person wants to be recognized by at their points of contact, such as when receiving snail mail or when contacted by phone. It’s expected (but not required) to include one or more ‘given’ names plus a family name, e.g. ‘Tom Jones’.
- Preferred Name — The name a person prefers to be addressed by within the organization and/or by customers, e.g. ‘Tommy’ — displayed on the employee’s ID badge. For customers, it’s the name that the person prefers to see as part of their online user experience, e.g. ‘Welcome back, Tommy’.
- User ID — The name chosen by or assigned to an online user of an IT-based system. Typically it’s some version of the person’s name. These names are required to be unique within the context of the system (but can change over time if required), e.g. ‘TJones’, ‘[email protected]’.
When the legal and/or contact names are expected to be sorted by family name, the family portion of the name would need to be its own separate attribute.
NOTE: Some organizations choose to prefix a person name with a title such as ‘Mr’ or ‘Mrs’. Similarly, an organization may want to present a person’s name followed by one or more recognized qualifications, such as ‘MD’, ‘Ph.D.’, or ‘QC’. Such before and after values should be maintained as separate attributes, as they are classifications rather than an actual part of a person’s name.
Well-defined Name Attributes
From a well-defined data perspective, there must be an existing business entity that the name is an attribute of, e.g. Position, GL Account, Staff Member, Customer. For entities whose instances have just one name, the attribute can simply be called Name. Ideally, the attribute definition would include one or more examples that make it clear what is expected in the way of values for instances.
Name values that originate from within the organization can be made to fit within whatever length limit the organization specifies. Ideally, externally-sourced name attributes would allow for enough characters to accommodate the longest possible value. If not, then the process of capturing a name needs to allow for the value to be abbreviated or truncated to fit the available space.
Each name attribute should have a maximum length specified (testers will test this). A subject matter expert should be able to give an indication of how many characters will be sufficient. In the cases of codes, the organization may also want to specify a minimum number of characters.
In terms of restricting allowable characters within a name, internally-created names can be restricted if there is a business reason to do so (e.g. only alpha characters and spaces). Externally-sourced names are best left unrestricted unless there is a business reason to restrict allowed characters. The question becomes, “What should the IT system do if a valid external name is received that contains one or more restricted characters?” Leaving them unrestricted eliminates this question.
Name Values — The Bottom line
The majority of internally-sourced names come from the organization’s decision makers. If there is a technical reason that one or more special characters should not be allowed within a name, then validating to avoid them is a reasonable thing to do. Externally-sourced names, if they are from valid sources, simply are what they are. The organization that needs to support them within an IT system should not be told by that system (in an error message) that they can’t. It’s just as possible for the value of a name to be entered incorrectly using allowed characters, e.g. ‘Tom Bones’ entered rather than the actual name ‘Tom Jones’.
There should be a system-supported business process that allows an incorrect name to be corrected.
Coming in Part 7 — Attributes that Quantify