Overview
In general, the naming convention should entail enough
descriptive qualities to make it obvious to which group the content belongs. Being
able to quickly identify content context is important. The basic building
blocks should follow how the organization’s security model is structured. For
example, if the company uses Active Directory and assuming it is representative
of the security structure, the names usually follow a convention:
(Area)(Department)(Category/Function)((Sub
Function))
Not all of the above keys have to have a value. This is a
guideline which helps focus the naming of the objects and structures that
follow. Keep in mind that exceptions are always part of a naming convention.
Goals
Naming conventions give content a location and relevance tag.
It tells the User what it is and where it belongs. By consistently following a
convention, the system will be able to scale and still be coherent.
Scope
Each department has its quirks as to how they work. It is
important to hone in on how they describe their content with the enterprise in
mind. Try not to spend an inordinate amount of time splitting hairs over
details. For multipurpose departments, move the structure out to a general
level which encompasses all of their responsibilities, then work on describing
each path, but keep it simple. Think about how the names will understood by
Users who are not privy to your knowledge abbreviations.
Abbreviations
Every organization uses common and idiosyncratic
abbreviations depending on its industry. The challenge is to be concise, yet
clear. Some abbreviations can be too short and cause confusion. For all naming
conventions it is critical to be as concise as possible.
Exceptions
Focus on the core convention and structure and note the
exceptions. The exceptions should be handled by metadata or other means.
Assumptions
The main assumption is that the naming convention will be
followed and enforced. Each department should be given some control over how
they want to describe their content, however, there will be some common
structures that will be imposed.
Common Structures
Before creating your own convention, check with other
sources of content to make sure there is no convention in place. If there is,
compare yours with theirs to see if adopting theirs makes sense. Maybe the
first two levels should be incorporated, with the third being what you focus
on. The values should be abbreviations if possible and obvious in meaning.
Example
(Area)-(Department)-(Control Number)-(Doc Type Identifier)
Taxonomy
This can be thought of as a way to get to your content. It
could be a folder structure, or a cascading categories. Be careful to not go
too deep; at some point metadata will take over in describing the nuances of content.
Example
(Area)/(Department)/
(Specific
Level 1)/(Special Level 2)…/
(Doc
type)
A “Specific Level” could be a functional or category/doc
type pair.
Content
Document Types
The naming of doc types should be clear and concise. It
should be obvious what department and function they belong to.
Example
(Department)-(Functional/Category Name)-(Doc type name)
File Names
File names become important during normal file exporting and
migrations. When content is used outside of the system there should be identifiers
that help place the content in context. There could also be a reference back to
the system’s numbering system.
Example
(Department)-(Doc type name)-(Content Relevant Identifier
(for example Title or Patient MRN))(System Number).(Format)
Title and Headings within Document
The title should be concise, especially if it will be in the
filename. It should also reflect any metadata values associated with the
document.
Document Information Block within Document
A block of information as a header or footer to a document
is a feature of paper-based control documents. In the block you’d have the
Title, Doc Number, Doc Date, Doc Affective Date, and so on. This is metadata
for the printed page. If there is the need to print a footer with this
information still makes sense, but the content within the document should not
have this, it should be implemented only during printing or saving to a file
outside of the system. The properties of the exported files could also be used
to metadata population.
Metadata
System
System metadata already follow a naming convention and
usually are proceeded with “SYS” to denote them. The corresponding database
tables follow functional naming conventions which are sometime cryptic, but
logical.
Dublin Core
The Dublin Core is a common set of metadata of all ECM
systems. These include author, doc date, description, name, etc. Don’t
duplicate these unless there are naming rules that are different.
Department specific
Keeping track of which metadata is used for which purpose or
application can be challenging as the system grows. Naming metadata specific to
its purpose and project is advised.
Example
(department)(project name)(metadata name)
References or Relations
If a cross reference is needed, make sure the object naming
is consistent with the purpose of the link.
Processing
Business processes or workflows naming need to follow the
same naming conventions as all the other preceding objects. It should
incorporate the common elements as well as the specific ones.
Publishing
When the ultimate goal of the ECM workflow is to publish to
a portal, the naming conventions should follow the same conventions as the
portal. Having to map or lookup values may not scale when added to a portal’s
level of use.
Security
As mentioned above, the security hierarchy and its naming
convention are a first indication of how well organized the company’s structure
is. The naming of the groups should be considered when thinking about the
naming of projects, folders, and doc types.
Compliance
Many systems have to comply with regulations like 21CFR part
11. This type of scrutiny applies to the information architecture and system’s
content.
Regulations
Outside regulation bodies could impose certain naming
conventions which need to be followed.
Audits
Auditors need to be able to ask for information in general
with an understanding that you will know what they need. It’s vital to only
search for what they focusing on, and this requires a good naming convention
and robust metadata.
I18n
Introducing a foreign language to the system multiplies the
complexity of the solution. Not only are the metadata values multiplied, the
naming conventions are multiplied as well. Most ECM systems can accommodate
this, however, folder names and metadata might have to the duplicated with the
foreign values.
Search
Search is only as good as the metadata value quality and
full text indexing comprehensiveness.
Change Management
As organizations change, areas and departments get moved
around and new names are designated.
Regression Mapping
Keeping track of structural changes can be challenging.
Depending on the scale of the change, creating a map to previous taxonomies or
department names can be helpful.
