The mere mention of ‘Y2K’ is enough to make many CIOs reach for the Pepto-Bismol. The work required to ensure the smooth transition to the year 2000 was tremendous.
“I told them so, back in 1982!” recalled one of my colleagues, while the company he worked for was spending millions of dollars to remedy the Y2K problem. His warning, and many others, were right on the money. If companies had taken steps to rectify the problem a decade or so earlier, much of the ensuing grief could have been avoided.
So have we learned a lesson from Y2K? Are we prepared to heed warnings well in advance of a similar issue?
We’re about to find out, as another wide-spread computer glitch looms. This time the culprit will be the exhaustion of the supply of 10-digit telephone numbers in North America.
This has a striking similarity to the Y2K bug, where the year field needed to be increased from two to four characters. In this case, all computer applications that store telephone numbers as 10 characters or less will need to renovate their code to support a longer telephone number.
Unlike the Y2K issue, we do not yet know when the “10TN Exhaust” (10-digit Telephone Number Exhaust) will strike. There are a number of factors that will control how quickly North America will use up its existing telephone-number supply. These factors include the number of competing telephone companies in the market place and the continued growth and expansion of new services that require a telephone number.
How much time do we have? Industry estimates predict that the telephone number will be expanded sometime in the next 10 to 18 years.
Fortunately, the telephone-number field is not as widespread in business applications as is the date. There should be no impact on financial applications and we need not fear that “10TN Exhaust” will cause aircraft to crash. It will, however, impact a large number of business and operational support applications, especially in telecommunications companies.
Why The Need For Change
The North American telephone number has been ten characters in length for over forty years. The current format is: NXX-NXX-XXXX. The first three digits are the Numbering Plan Area (NPA), commonly called the area code; the next three digits are the Central Office Code (CO Code); and the last four digits are the line number.
The first digit of the NPA and CO Code can have a value of two through nine and are represented by an N, while the remainder of the digits can be any number from zero through nine. One and zero are not used as the first digit in a number in order to allow the switching equipment to recognize long-distance and operator-assisted calls.
A number of new formats being are being discussed within the industry. Each alternative involves increasing the number to either eleven or twelve digits. The formatting options being studied will increase the length of the NPA code to four digits and will potentially increase the CO Code to four digits.
If you live or work in a large urban centre, you will have already experienced either an NPA split or overlay by your providers. A split divides a city or other geographic area that currently has a single NPA code into two or more territories. With an overlay, the same geographic territory is assigned two NPA codes. Some territories have experienced both an overlay and a split over the last ten years.
The frequency of these overlays and splits is quickly exhausting the pool of available NPA codes, resulting in the impending need for a longer telephone number.
There are some who predict that the telephone number will become extinct altogether, replaced by IP numbers and other identifiers managed through directory services. This is a possibility, but it is unlikely to be a reality before the exhaustion of the North American supply of NPA codes.
So will companies such as yours develop a policy now to introduce the new format telephone number? Doing so will avoid an unnecessary repeat of the costlyY2K situation.
Preparing For The New Format
Given that the new format is not yet known, is there anything that can be done now to prepare for it? Yes! Your organization can, over time, renovate its various software applications so that they will support both the old and new format numbers. By instructing your IT staff to observe the following six guidelines, your applications can be coded so that they can flexibly adapt to whichever format is eventually adopted for North America.
These guidelines are quite simple. They add very little cost to an application and could potentially save your organization an immense amount of money in future years.
Incidentally, telephone-number formats outside of North America are different than those described in this article. Therefore, many developers who are building applications for international use are already following some of these guidelines.
1. Set a new minimum number length
The telephone number in new applications should be defined as a 12-character alphanumeric field minimum. This will allow sufficient space to support any of the format options being studied. A longer field may be required to store a telephone number when the country code must also be captured and retained with the telephone number. Canada, the United States and several other countries currently share a country code of 1, but other country codes can be up to three characters long. Therefore, some developers are defining telephone numbers with 15 characters, depending on their anticipated use.
2. Define the number as a single field
The telephone number is often defined within an application in terms of its three elements: the NPA, the CO Code and the Line Number. The elements of the telephone number have meaning to the switching network, however for most operational support system applications there is usually no need to define or understand the individual elements of the number. It should be stored at its full length (without formatting) and not be redefined into elemental items in the database or in the business application code. In this way, you can avoid the problem of not knowing which format (11- or 12-character length) will eventually be standardized.
3. Develop an easy-to-read display format
Applications must display the telephone number in a format that makes it easier to read. (e.g. (555) 215-1234). This formatting should be localized to the reporting and presentation layers of an application.
A simple telephone-number formatting routine or template should be developed . The routine should be flexible enough to format a number in several different formats based on the length of the string passed to the routine.
4. Avoid making the telephone number a primary key
It is recommended that the telephone number not be used as part of the primary key in a database. Instead, it should always be stored as an attribute. A secondary index should be used when an application needs to access the database via a telephone number.
By avoiding the use of the telephone number as a primary key, the database migration/conversion to the longer 12-character field will be substantially simpler,
as the telephone number will not be imbedded as a foreign or parent key in multiple tables.
5. Forego telephone numbers as geographic identifiers
Up until a few years ago, the use of the NPA and CO Code to define a geographic area made sense. These six characters could be mapped to a geographic region served by a piece of switching equipment. No more.
While the NPA often still represents a geographic area, the CO Code can appear in different switches within the NPA. Further, the growth of mobile phones and
the introduction of telephone-number portability have made the telephone number a poor choice as an identifier for a geographic location. For this reason, applications that still use the NPA and CO Code to derive location-based objects should change to a more natural identifier, such as a postal code.
6. Externalize transformation routines
The migration of applications to support the new telephone-number structure will be a phased deployment over many years. Therefore, a strategy is required to permit the old and new format numbers to co-exist. It is recommended that you build telephone-number transformation routines external to the operations allocations.
There are many ways to do this. Enterprise Application Integration (EAI) tools can assist with managing the transition to the longer number. When developing a common data or object model within an EAI tool, the telephone-number attribute should be defined as 12 characters. The transformation routines in the EAI connector should then map the telephone-number structure of the interfacing applications to and from the 12-character format defined in the common object model . Creating the longer 12-character field in the generic view allows applications to build a simple transformation that can be modified as they become 12-character telephone-number compatible.
Likewise, when developing point-to-point interfaces, the telephone number should be defined as 12 characters, with an interim ‘black box’ reformatting routine put in place to migrate the number to the 10-character length in the legacy application. The black box can then be removed when both interfacing applications have migrated to the new 12-character structure. This approach permits each interfacing application to transform to the new format at its own pace.
As the old adage says, a stitch in time saves nine. Or to put it a little more relevantly, a glitch fixed today saves another Y2K.
Don Karges is Executive Consultant, Architecture and Technology, at CGI, a Canadian global IT services firm. He can be reached at don.karges@cgi.ca.
