9
Standards and Naming Conventions
Nothing stirs up absolute boredom in the hearts of data processing professionals like the very mention of the word standards. There have been enough words written on the subject to outnumber War and Peace in terms of sheer volume. However, there is no use denying that without them, there is absolutely no hope for improving productivity; all you will accomplish is to mechanize your confusion faster.
Why Standardize?
There are several fundamental reasons why an organization truly requires standards and naming conventions. The primary reason is inherent in the manner in which almost all systems are developed; except in very rare instances, none of us develop systems alone, and thus all the work we perform is just a portion of the whole. A typical scenario might be the development of a new payroll system and some of the work breakdown might be as follows: One group might be responsible for the user interface which will be used in the business office, while another is defining, designing, and implementing the employee database; still another group will be working on the subsystem that will format and produce the paychecks. It is clear there is a reason for the entire staff of each group to adopt common methodologies and naming conventions for the development of the payroll system. It would not make any sense if the user interface defined employee as a 4 character login id, the database group defined it as a 7 digit randomly generated number, and the paycheck group used the 9 digit social security number. But in our scenario that is exactly what did happen; unfortunately, as we all know from experience this does not occur all that infrequently (see Figure 9–1a).
Figure 9—1a Development of the New Payroll System Evolved Without the Benefit of Standards.
Let’s expand our example further, because the impact of not establishing naming conventions will extend beyond the payroll system. Across the hall is a group that is developing an on-line work scheduling system for the service centers. It so happens that this system will have a batch interface to the database to provide data about exception time reporting. The work scheduling system plans to identify employees by first and last names.
Figure 9–1b contains a data flow diagram depicting the relationship between the work scheduling system and the three subsystems of the payroll system. Let’s imagine how the development story might unfold. At some point during the software development life cycle, the problem will become glaringly apparent. If the collective individuals are fortunate, this will occur early in the process, possibly during a design walk through. If they are very unlucky, the inconsistency will be detected during system test, and many people will work substantial and unpleasant overtime.
The solution may take the form of conversion programs that translate one form of employee id to another. Figure 9–1c graphically depicts the complexity of the situation due to lack of standards. After the systems have gone into production, since there will be multiple translation tables, there will be multiple occurrences of inaccurate data. People’s paychecks will be incorrect much more often than if there had been a common identifier. Furthermore, since there are differences in length and data type, and even variations in the meaning of employee data field, there will be ongoing and increasing problems for the systems analysts who will maintain and enhance these systems. The bottom line is that if data is representing the same thing, it must have the same name, length, storage type, and meaning.
Figure 9–1b Incompatible Batch Interface Compounds the Problems of the New Payroll System.
Figure 9–1c The Solution Imposed Results in an Unnecesarily Complex Environment.
All the problems described in this scenario relate to the data side of development, but the problems are exactly the same for the functional side. It would not facilitate a system’s development if the same process depicted on two different data flow diagrams had two different names or was even represented by two different icons. Compare Figures 9–2a and 9–2b, and consider the probability of an individual recognizing that CRU and Master File Refresh represent exactly the same function. Just as in the data example, the problems were caused because the same thing (the employee record update process) was represented by different names as well as different shapes. In this case, the confusion could have been averted by a combination of a standard methodology and naming conventions.
Let’s summarize the primary purpose of establishing standards and naming conventions:
• The manner in which systems are developed requires that we share information as we proceed.
• It is much easier to share information that represents the same thing if it always has the same name.
• This requirement is true for both the data and functional sides of development.
• If we do not abide by this principle, the progress of development will be slower and personally painful.
• The maintenance of systems will also be more difficult and painful.
Classification Facilitates Analysis
Once you have utilized standards for the purpose of identification, the second benefit of establishing these standards can be understood. For thousands of years, human beings have utilized the principle of classification to enable them to better understand their environment. Classes allow us to subset information, and this subsetting makes the information more manageable and thus easier to understand. If you set the naming conventions with intelligent foresight, you can build classes of whatever it is you are naming, and then you can analyze the subsets much more easily.
How to apply the concept of classification may not be obvious, so let’s look at a few examples. Suppose you set a convention that all employee data will begin with the letter e, all customer data will begin with the letter c, and so on. After all the data has been defined and named, you can gather data from all the systems your organization supports by the classes (employee, customer, etc.). Then you can begin analyzing and identifying redundancy within and across systems. Of course, you can always search for, analyze, and identify redundancies without classes and subsetting. However, considering the quantity, the analysis would be substantially more complex and dramatically slower if you were dealing with all the data in your organization’s systems at one time.
Figure 9–2a CRU (Customer Record Update) Performs Nightly Updates to the CRDB (Customer Record Data Base).
Figure 9–2b MFR (Master File Refresh) also Performs Nightly Updates to the CMF (Customer Master File).
You can provide yourself with similar opportunities on the functional side. For example, you might establish the following convention: Each process will begin with the first alphabetic of the system of which it is a part. This alphabetic will be followed by a dash (—) and then there will be a character that represents its function, such as u for update, a for add, and d for delete. The final componen of the process name will be an English name, such as employee record. In our system development scenario, this convention might translate to the following:
P-A-Employee__Record
W-A-Employee__Record
where the P represents the payroll system, the W represents the work scheduling system, and the A represents the add function. The advantage in this case is that possible common functionality across systems can be identified. These potentially redundant functions can be analyzed with the objective of developing reusable code. Upon examination, it may be clear that although these functions are not identical in the two systems, there are opportunities for the two systems to use some of the same routines.
On the other hand, you may determine that the functionality is exactly the same, and then you might prefix the process with a C for common. Once all the common functions are identified and the corresponding processes are tagged with a C, it becomes possible to begin reusing code. Specifically, whenever a new system is being designed, the analysts can review all the processes that begin with a C which represents all the existing common code. It would have been very difficult for these development opportunities to become apparent without subsetting via classification and the subsequent analysis.
Before we proceed to the next reason we need standards and naming conventions, let’s summarize our observations about reason two:
• Human beings use classification to help make sense of their environment.
• Intelligent planning during the establishment of naming conventions allows you to classify functionality and data.
• The components of your systems will be subsetted and so you can search for opportunities to eliminate redundancy.
Common Language as a Legacy
The third and final reason we will offer to convince you of the importance of establishing standards and naming conventions has to do with the people. If there is a common understanding of what is meant by employee, customer, update, delete, and so on, then it is much more likely that people will be able to communicate effectively on a given project. Moreover, you have also selected a common set of methodologies and techniques, for the life cycle, structured systems analysis, and data modeling. The sum total of the commonalty can be favorably compared to a language, where the naming conventions are the vocabulary and the methodologies are the syntax. Indeed, this “common language” will extend beyond individual projects and will afford benefits across projects as well as time. In other words, people on different projects will be able to understand each other better. In addition, the next project will begin with the rich inheritance of this common language. The benefits can be summarized as follows:
• Common names and standard methodologies enable people to communicate more effectively.
• People can transition to other projects more easily.
• The task of assimilating projects will be simplified for people new to the organization.
• Certain tasks performed as part of the development process may not have to be redone.
Negative Attitudes Toward Standards
Given that there are such substantial benefits to be realized by utilizing standards and naming conventions, we must now seriously question the negative attitude most of us have when they are even mentioned. A great deal of our abhorrence is related to creativity, because there has always been an emphasis in data processing on the creative aspects. In fact, one of the attractions the profession holds for many of us is the almost infinite diversity; there is so much to learn and the technology is constantly changing. We may be frequently overworked, tired and behind schedule, but we are seldom bored. Since we appreciate and even thrive on a high degree of creativity, we do not view the prospect of conforming to standards with enthusiasm.
A more tangible reason for our resentment is associated with the burden that adhering to standards represents. We are (as has been stated many times) very busy, and incorporating the standard names and complying with the rules of the methodologies is perceived as one more burden. These extra steps require substantial work during all phases of development, and we are already working more than full time. Moreover, these steps are not even interesting, but tend to be somewhat repetitious and even tedious. A corollary to this reason for resistance is the possibility that the standards may be in opposition to names or methodologies that already exist. If this is the situation, then not only are we dealing with “extra” work, but we are dealing with the possibility of “redoing” work that in our minds is already complete.
The last theory we will propose for resistance to standards has to do with negative connotations of authority. None of us is thrilled when an “authority” enters the scene and suggests numerous ways for us to improve our current situation. We are even less happy when the methods proposed by this self-proclaimed authority require a lot of work on our part. In general, it is also unclear to us what advantage we will gain after all this extra and tedious work has been completed.
Before we proceed with advice and suggestions on the subject, let’s recap the traditional causes for resistance:
• Data processing professionals take pride in their creativity, and thus conforming to standards is offensive to them.
• Adhering to standards entails substantial extra work on the part of already overworked people.
• Since names and methodologies may already exist, the extra work may take the form of redoing work already completed.
• We resent the possibility of some authority arbitrarily imposing standards.
Role of the Project Team
It would seem indisputable that judicious planning and incorporation of standards and naming conventions are essential to any data processing effort. Moreover, in spite of all the problems you will encounter, it is in fact possible to establish them and encourage their use. There are four fundamental commandments to which you must adhere if you want to establish standards that are robust enough to endure and humane enough to be used. First, you must formulate both standards and naming conventions within the framework of the project team. Since we have been advising you to prepare all deliverables in draft form and then approach the team for input, this may seem like a contradiction. However, your group is simply not in a position to make determinations that will have profound ramifications for everyone else; they simply do not have enough insight to arrive at even a draft document that is appropriate.
On the other hand, we are not suggesting that you begin this particular project team meeting without having given some thought to the subject; you should have some idea with which to start the discussion. But it is paramount that you be even more open-minded than usual when this topic is addressed. The objective is to poll the individual perspectives of the various team members because they represent the diverse functions of the development life cycle. The deliverable that results will be a collection of their expertise, and thus should be hardier than one devised by any single group.
During our implementation of Excelerator, we had a particularly grueling meeting to develop the naming convention we would use for elements. At that project team meeting we had many different aspects of data processing represented; in attendance were planners, systems analysts, programmers, system testers, and a data dictionary expert. In addition, there were several team members with extremely strong personalities and very definite opinions. It was not a very pleasant morning. However, time does tend to dim pain, and what I am left with in terms of the experience is the fact that we arrived at a superb naming convention.
The morning began with the data dictionary expert, Joe, stating unequivocally that the only way to ensure the integrity of the Excelerator dictionary was to utilize a four-digit number that is randomly generated for the element name. Before the words were fully uttered, the systems analyst, Betty, replied that there was no possibility that numeric element names could be used when dealing with users. Joe reemphasized his point with the following example:
Suppose the element we are trying to describe is type of equipment…
According to Joe’s suggestion the name given to type of equipment might be:
6357
According to Betty’s request for an English name, any of the possibilities listed below might be used:
type of equipment
type of equip
type of eqpt
equipment type
equip type
eqpt type
Moreover, the names listed above are but a few of the ones that individual people might develop.
Betty became increasingly upset, and claimed she could not live with numbers. Then she threw out the ultimate threat; she was just going to have to report all this to her supervisor, since we obviously did not want her input. Joe became more adamant about uniqueness and data dictionary research studies. The rest of the team became quiet and noticeably distressed. We were all subjected to this torture for what seemed an eternity. Other team members made tentative suggestions, such as why not use the name marketing has officially adopted since its system is the origin for most of our data?
The outcome was the following standard for naming elements in our Excelerator dictionary:
For each logical data element that served a unique business function, there would be a randomly generated four-digit number.
Appended to that number would be a dash ’-’, followed by the English name that was most commonly used.
There would be no white space (blanks) embedded in names with more than one word.
The words would be separated by underscores ’—’.
There would be no lowercase letters; everything would be capitalized.
An example might be: 6357-EQUIPMENT_TYPE
One of the lessons I learned from this experience is that even under adverse conditions, it is possible to arrive at a compromise. In fact, the convention served so many diverse requirements that it survived many years. Let’s examine the requirements that were met by the standard. The need for uniqueness dictated by data dictionary practices was satisfied by the randomly generated four-digit prefix. Four digits were selected as the number required, because that will allow for 9,999 distinct elements. Since this count does not include the hundreds of aliases we all apply regularly to our data names, in theory the 9,999 should fully describe the data environment for any business. The human factors side of data processing was addressed by appending a common business name.
The selection of the English name was left open on an element by element basis and was to be supplied to our group at the time a request for a new element was initiated. This is a fact that is well worth noting: As change agents, we never assumed we had any particular insight for setting standards or establishing naming conventions. Throughout the entire process, we remained open to suggestions from our users, and wherever possible we utilized whatever standards they recommended. Our philosophy was that if it was working for or desired by even one group, and we had no reason to believe it would adversely affect any other group, we would abide by the suggestion.
Provide Opportunities, Not Edicts
This philosophy harks back to the orientation of the change group we discussed earlier; the people must understand that this is a service group and thus must make every attempt to cooperate. On the other hand, you must ensure that by honoring an individual user’s request, there are no negative implications for other groups. If other users cannot abide by the convention or two different users propose contradictory standards, then you as the leader must make the decision. In either situation, you cannot cooperate and you must be prepared for a confrontation if necessary. Do not forget that you have been given the job of implementing the change, and thus you also have the authority to mandate solutions when obliged by circumstances.
In Chapter 3 we discussed the inappropriateness of a centralized group performing the evaluation of the tool or technique. However, we did indicate that there is a very important role for these centralized groups in terms of coordination. In the area of standards, the role of centralized coordination is something you cannot afford to ignore. Optimally there will be available for your use a document that provides corporate guidelines for establishing standards and naming conventions that have already been defined. We stress the word guidelines because if the corporate policy extends beyond that, then there is a fundamental problem.
Similar to our view about who performs product evaluation, we are also firmly convinced that the people who will be utilizing the productivity product should also set the standards. They will be the ones who have to live with the results of the decisions, and so it is perfectly clear that they should make the decisions. On the other hand, no one wants a situation where every group is establishing separate and distinct standards. Remember our example about the two departments that were both developing a standard employee id. In that case, a disaster was averted by the involvement of the corporate group. The ideal situation occurs when there is flexibility for each individual organization within a framework of centralized guidelines.
When we were establishing the conventions for element names described above, we were not networked into our corporate standards group. It was over a year later, when we were finishing our implementation, that we began to exchange information with them. We were quite fortunate, because their policy matched our own and thus they were extremely flexible. They had a corporate data catalog that contained the official names of the data elements deemed to be critical to the corporation. Their only request to local groups such as ours was that we retain the ability in our dictionary to map their name to our own.
We added an “ideal” name to our element naming conventions, and that name was the official corporate one. We also established a guideline that this ideal name would be our goal, and we recommended that whenever programmers were modifying or enhancing code that contained names which were aliases for this one, they should consider changing all occurrences to the ideal name. Figure 9–3 displays the relationships between the dictionaries and the software.
We assessed possible areas for improvement within the actual software itself, but we were appreciative of the tremendous amount of work that would be involved in changing program names. There was a planner on the project team who recommended we mandate all program names be changed to this standard, but we never for a moment considered this suggestion seriously. Although well intentioned the planner did not understand the magnitude of her suggestion because she had never been a programmer. The team did realize the impact of this type of software modification not only on the programmers and on system test, but also the problems related to scheduling this into existing release plans. Moreover, we already understood a great deal about implementing productivity improvements. We knew that this type of far-reaching recommendation must be born in the project team arena, and that it must be an objective that all team members can be comfortable with. Even more important, we knew that any recommendation must be something that had a chance of success. Since not one of those ingredients was present, all we did was to point out an opportunity. We did not present an unreasonable edict for the people who would have to do the actual work. This type of interaction substantially increased our credibility and greatly enhanced our implementation.
Figure 9–3 Through the use of Appropriate Naming Conventions, it is Possible to Maintain Relationships Between Dictionaries and the Software Itself.
Let’s pause and relate this case study to some of the causes of resistance described in the beginning of the chapter:
• We as the change agents did not impose seemingly arbitrary naming conventions on our users.
• The naming conventions we ultimately applied represented the collective input of many diverse groups (including corporate and programming).
• We did not attempt to exert any undue authority on any of the people who would have to perform the work.
• We did not suggest that anyone should redo any work that had been completed.
• We did recommend that the standards be incorporated whenever there might be opportunities in the future to do so without disruption.
• By conducting the change process in this manner, we gained substantial credibility.
Build on Existing Standards
The second fundamental commandment for setting standards is never to disregard a naming convention that already exists. If people have consciously or unconsciously established even something as modest as a pattern for naming any type of item (files, records, user ids, processes, etc.), it behooves you to incorporate the pattern in your standards. There are several reasons why you should defer to any prior work in this area. The first one is that you have no reason to believe you have any more talent for evolving conventions than anyone else. Therefore, based on your commitment to cooperation, it will be helpful to use anything already developed.
These reasons can also be directly related to the resistance issues discussed earlier in the chapter. This type of accommodation avoids the change agents being viewed as self-proclaimed authorities; this is often the negative perception of people trying to establish standards. You will also gain credibility because you will not precipitate extra work, nor will you cause any work that has been done to be redone. What you will do is to utilize names, standards, and even patterns that are already in use. This creative establishment of standards will contribute to what we call “creating the proper environment” in which change can take place.
In our Excelerator implementation, we were able to follow some of this advice in connection to naming conventions for interface records, as the following tale illustrates. It was during the planning period, and we had already decided that prior to utilization of the tool by the existing maintenance systems, we would load all their interface records and elements into the dictionary. Since we had already set an element naming convention (during the infamous meeting described above), we were prepared to set some standards for the record names as well. What occurred, however, was that upon examination of the names that were currently being utilized for both the physical and logical views of the systems, we discovered a definite pattern. Every record began with two alphabetic characters: the first character was the first letter of the sending system, and the second character was the first letter of the receiving system. In other words, all the records from Service Order System (SOS) to Equipment Repair System (ERS) began with SE. The third and fourth characters were numeric, and it turned out that their combination indicated the type of record. For example, any record that had 47 as the third and fourth characters contained equipment information. Thus SE47 was the record sent from the Service Order System; the destination was the Equipment Repair System; and the information on the record was about equipment (see Figure 9–4).
We adopted that particular naming convention without the slightest modification or hesitation. There was even one interface that did not follow this pattern, and for some reason (lost to modern history) began with an alphabetic character different from the sending system. We debated about whether to change the name of the records or to diverge from the convention. We decided to proceed with the actual record name, even though it would break newly set precedent. Our reasoning had, once again, to do with the issues of resistance and disruption. As we have mentioned previously, there will be a tendency for people to view the change agents as disruptive, but we do not accept that this negative view is inevitable. Bearing in mind our objective of avoiding this view and hence minimizing resistance, we carefully considered our options. Everyone in the organization was used to the existing record names, so we balanced the pros and cons of adhering strictly to conventions against allowing our users to be comfortable. This was, in reality, not even a slightly difficult decision for the team to reach, and to my knowledge only one individual ever questioned why that set of records was named differently.
Figure 9–4 On the Data Flow Diagram the SE Interface Between SOS and ERS Explodes to the SE data Model Diagram where the Entity, eqpt. Explodes to the SE47 Record.
Enforcing Standards
The third commandment in reality addresses the difficulties associated with enforcing standards once they have been established. None of us has a desire to play the role of police officer, and yet that is frequently the role people adopt after they have set standards. It is a fact that the difficulties you encounter when you are establishing standards can be negligible compared to the difficulties you can face trying to enforce them. Notice that we used the word can, because it is our belief that if you utilize the techniques we have described, you will not have too much trouble. Because you will be establishing your conventions from within the team arena, you will listen effectively to team members and utilize the benefits of their expertise. You will also capitalize on any work already accomplished. In addition, you will arrange things so that it will be easy for your users to adhere to the standards. This ease of use is the heart of the third commandment.
The most dramatic application of ease of use involves the creation of templates. A friend of mine worked for a corporation whose upper management had wholeheartedly adopted a life cycle methodology. When the company became committed to the need for a project planning and tracking tool, he was given the responsibility for implementing Project Workbench. He immediately created a template that contained all the phases and activities proscribed by the methodology. (Figure 9–5 is a sample, which for the sake of simplicity contains phases only.) Whenever a project manager was ready to begin using PW, he supplied that person with the template. Before the manager even began planning the project, considerable work had been completed. It is not hard to believe that in this case not only was there a high rate of adherence to the standards, but there was also an impressive display of consistency from project to project.
Figure 9–5. Templates do not Enforce Standards, but Rather Encourage Adherence by Reducing the work Effort.
Never Set a Standard Before Its Time
The fourth and final commandment is simply never to set a standard before it time. Keep in mind that the purpose of any standard is to streamline life; it should never impose additional burdens on already harassed users. If what is being done with the tool or technique during any phase of the change process does not warrant a specific standard, wait. Not only does it avoid unnecessarily burdening your users, but it saves you, your group, and the project team time and effort that can be gainfully employed in a more critical area.
If you find yourself with the luxury of some not too terribly overworked people, do not be tempted to establish conventions and save them for the right time. You will discover that the right time may never come. As the change process progresses, the environment will begin to evolve, and the premature standards may no longer apply.
A Case Study
Our Excelerator implementation was, on the whole, a very pleasant experience. The way we developed our standards was characteristic of the entire productivity improvement (even the grueling meeting takes on a rosy hue as the years pass). We established some basic and minimal standards during the planning phase, as follows:
• Selection of methodologies to be followed in order to avoid having one project use Gane & Sarson while another used Yourdon.
• Adoption of element naming conventions.
• Selection of ideal element names, which would be the one name we would use in all future programs in order to provide consistency in the physical systems.
• Adoption of record naming conventions.
• Adoption of coding scheme to accommodate functional aspects of development (as described in the payroll example).
What happened next was that at various points in the implementation we were approached by users who requested additional standards, procedures, etc. In the last chapter, we shared the story of how change control was user-initiated and was included toward the end of the planning phase. Another occurrence of this type of user-initiated establishment of conventions is related to version control. During the planning phase, we had provided some ground rules for handling the versions of each system as they moved through the release cycle. However, these rules only covered the roles and responsibilities that would exist between my group and the users. Many months later, when we were finishing our implementation, our most sophisticated user recommended that we include version as part of our element, record, and process naming conventions. The proposal was to append a version number to each element, record, or process that was being added or modified at any given time. Using the examples given earlier, if SOS was changing the equipment type element’s length on the SE47 record in their 1.7 release, the following names would be used:
SE47_1.7 | for the record |
When the SOS 1.7 release went into production, the 1.7 would be dropped as a suffix in the name of the record, element, and process. Since at that phase there was no longer an active interproject team, we socialized this suggestion with a number of other project managers to obtain a preliminary readout, and then we published a draft form for comment to our user community.
We did not start our implementation by presenting a road map with predetermined routes all laid out for the course of the change process. Instead, we were open to everyone’s recommendations for the implementation of our productivity improvement. In the early stages, this easy method of interaction between ourselves and at least some of our users about standards and conventions already indicated some measure of success. At least we were laying the foundation for what we term “the proper environment.” There was no doubt that we had established a certain degree of credibility: They believed we were sincere about acting in their best interests because we were willing to take our cues from them. Never did we dictate how things were going to be done or the correct name for anything, although we were not afraid to make decisions and provide needed leadership. Over the course of the implementation, as this free exchange of ideas increased, so did the environment of trust and confidence, which without a doubt resulted not only in a major success story, but also a nontraumatic path to arrive there.
Summary
• Since many people develop a system, we need to share information. Standards afford a consistency that facilitates this sharing.
• Naming conventions enable us to classify information, which provides a capability to subset, analyze, and identify redundant data and functionality.
• We resent standards because we are creative as well as overworked, and they are often arbitrarily imposed by self-proclaimed authorities.
• Standards must be established by project team members who represent the diverse functions of the development lifecycle. Then the resultant deliverable will be hardy enough to stand the test of time.
• Standards should be easy to use, capitalize on existing naming conventions, and must never be established until users deem there is a need for them.