Its purpose is to uniquely identify an instance of a business entity. Users of an IT-based system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with a specific business entity instance.
The concept of business entity identifier is like, but not exactly the same, as the concept primary key. Every table in a relational database is expected to have a primary key. A primary key can, however, involve combining more than one column to achieve uniqueness. It also may not be exposed to business users.
IDs and Numbers
Business entity identifiers are all around us. Our wallets and mobile phones are filled with them — values that have been exposed by the organizations we deal with. If you see an attribute name that ends in “ID” or “Number” there’s a good chance that its values are intended to identify a specific instance either of that entity, or some instance somewhere. The assumption is that we will have that value available when interacting with the organization that produced that value. These values are embossed on our credit and debit cards. They are printed on our membership cards, our discount cards, our driver’s license. Every phone number, email address, and app-specific contact we record is a business entity identifier value. We use these values when we want to ‘reach’ a specific person or interact with the issuing organization.
From the perspective of an IT-based business system, there is no doubt that given sufficient attributes, such as name, address, phone, etc., we can uniquely identify entity instances representing a person or organization. Similarly, there are attributes of a product, a sale, or a location that, taken in combination, will lead us to the instance we are seeking. The point of a business entity identifier is that it’s a ‘one stop shop’ — a single value that, if known, will get a user to the specific instance they are looking for at a given point in time.
Multi-fact Business Entity Identifiers
The simplest form of business entity identifier is one based on a numeric sequence (e.g. the last assigned number plus one). This simple form is often used where values only need to be unique within the organization, and there is no need for the identifier to be meaningful in any way. Entities such as Purchase Order, Store, and Asset fall into this category within many organizations.
An example of an identifier that contains at least one fact is Credit Card Number. It appears to cardholders to be just a number. But because that number needs to be unique across all organizations that issue similar cards, the first six digits of each value identifies the issuing organization. The digits that follow those six can be generated any way a given organization chooses. Typically, six or more of these are assigned based on the ‘last assigned value plus one’ algorithm.
The attribute Stock Keeping Unit Number (SKU) is an example of an identifier that utilizes multiple facts to make up unique values of the business entity Inventory Item. A retail clothing business might create its unique SKUs based on the combination of an item’s brand, clothing type, style, size and color. For example, the SKU Number ‘LEV-JN-ST-34-BL’ representing the inventory item Levi jeans, straight leg, waist size 34 in blue.
When a business entity identifier contains one or more facts, those facts should also be defined as separate attributes in the same or some other entity. This eliminates the need for business users to ‘pick apart’ an identifier to find a given fact. E.g. Obtain a list of all Jeans with a 34-inch waist.
NOTE: Any fact included in a business entity identifier should ideally involve values that will not change over time. Having ‘exposed’ the identifier to the business, dealing with communicating a change is not productive for anyone. If you have ever changed your phone number or email address, and needed to notify family and friends, you will have some appreciation of the resulting effort and inconvenience.
Optimizing User Experience Accessing a Business Entity Instance
Keeping the following four things in mind will help optimize the user experience when a business process needs to involve a single business entity instance:
- Maximise exposure to users
- Minimize manual entry
- Avoid finding a wrong instance
- Offer backup ‘find’ options
Maximize exposure to users — When a business entity includes a business entity identifier attribute, that value should be ‘exposed’ where it will best serve the business processes that deal with single instances. An Employee Number can be displayed on the employee ID badge, and printed on employee payslips. An Asset ID can be printed on a label attached to the asset. A retail product that has a unique Barcode value registered by the manufacturer should have that barcode and its numeric value printed on each instance of that product.
Minimize manual entry — More and more these days, business information systems are being ‘front-ended’ with data capture technology, web portals, and apps. Input devices can read a barcode, a magnetic stripe, an embedded chip, or a value broadcast via radio frequency (an RFID). The trend is also towards self-serve, where customers use web portals or apps to connect to a business information system. A user Logon ID is an example of a business entity identifier — one that requires minimum data entry effort, thanks to web browsers or mobile devices offering to remember the user's value for a given site or app.
Avoid finding a wrong instance — In situations where technology is not able to provide the value needed and the user needs to resort to manually entering the value to access a business entity, one of the most common data entry errors is transposing one or more digits. This can result in an entity instance being found, but not the one wanted. E.g. wanting the instance with identifier value 12345 but accidentally entering the value 12354. A commonly used technique for avoiding this type of error is the inclusion of a check-digit when generating the identifier.
Offer backup ‘find’ options — For every happy path there are any number of alternate or exception paths. At least one of these paths should support the user finding the desired entity instance when the correct business entity identifier value is not available. The values of one or more other attributes (or relationships) need to be able to be used to find the desired instance.
NOTE: Just as the business entity identifier is not the same thing as a database table’s primary key, ‘other attributes used to find an instance’ is not the same thing as the database concept alternate key. An alternate key value, like the primary key, is intended to find exactly one instance of a table. The business capability of searching using ‘other attributes’ is intended to reduce the candidate instances down to a shortlist from which the desired instance can be determined. For example, where Passenger “Fred Jones” has lost their ticket, and therefore does not know their Passenger ID, searching based on the Flight Number and Flight Date can return a list of passengers that may contain only one passenger named “Jones, Fred”.
So, while Flight Number plus Name would not be a valid alternate key in a database (because it doesn’t guarantee uniqueness), using those two values can turn out to be ‘close enough’ to get us back onto the happy path in a business search scenario. Typically search capabilities for business entities offer multiple filter criteria and present several attributes useful for identifying the instance being searched for.
Well-defined Business Entity Identifier Attributes
From a well-defined data perspective, an essential part of defining a business entity is identifying an attribute that can act as its business entity identifier. A business entity identifier needs a business-friendly, meaningful name. For the sake of the IT-based system responsible for creating new instances of the identifier, any ‘facts’ within the identifier need to be described and, at some point, specified in detail with regard to position, length, and valid values and/or value ranges.