Get higher-quality street-level address data and save time, with a dynamic model and a database

Is There a “Right” Address Model?

Terry Moriarty and Dwight Seeley                

When people ask me about basing their enterprise model on a dynamic one, my usual answer is, “I have good news and bad news for you.” The good news is the dynamic model is very flexible.

As soon as your application portfolio’s architecture changes to incorporate the power of a dynamic model, you can change a large majority of the business just by altering the database’s business-rule tables’ data.

The bad news? The dynamic model is very flexible. The model is so abstract that its diagrams do not clearly depict the details of your specific business. Your company’s business vocabulary is masked behind more general terms such as Business Party, Locator, Agreement, and Point of Contact. Furthermore, the dynamic model can be so flexible as to represent one set of business concepts multiple ways, each satisfying the enterprise’s business rules but with varying degrees of flexibility. Your challenge is to determine how much flexibility is right for your enterprise.

To explore how different models provide different levels of flexibility, let’s delve further into Address. In the previous issue (“How Do I Find You?,” Oct. 5), Dwight Seeley and I showed that you should separate the data you use to locate something or direct communications to a business party from the data identifying the thing or party being located. We introduced the business concept of Locator, which includes everything needed to manage communication addresses such as postal and email addresses, phone numbers, and geographic locations. Now, I will cover various approaches to representing the postal address.

The billing application is one of the first systems a company develops. For the billing business environment, names and addresses of customers and suppliers are used primarily to produce mailing labels, ensuring that correspondence reaches the intended party. Addresses also enable the product or service’s delivery to a specific geographic point.

For delivery purposes, the address may take the form of driving or locating instructions. The address you use for correspondence is often the same as the one for locating a specific geographic point: 123 W. Main Street, Bishop, CA 99999, for example. However, the mailing address can be unrelated to the addressee’s location. For example, the postal address “Route 1, Box R” might be adequate for mail. But to get to the people who use that mailbox, you need extensive driving instructions including landmarks and other unpredictable elements.

Text capture is perfectly acceptable for address information used only for sending mail or locating a geographic point. You know you have a good address if the post office does not return the mail, the intended recipient sends an acknowledgment (such as payment), or you find the location you seek.

Although the address may suffice, however, it is not necessarily strictly correct. It might include numerous typographical errors or misspellings. These imperfections can be surmounted by a human deliverer, who can interpret the information, make intelligent assumptions, and carry out the mission.

But what if there’s no human intervention? Free-form text obviously cannot aid demographic analysis, for example. Business functions needing com- puterized analysis demand better data. The business areas that capture the data, possibly telemarketing or teleservicing, must do so in a format that is useful to the downstream users, such as marketing.

As companies focus more on the customer, address takes on new importance. To manage its customer relationships effectively, an organization must know each customer’s total purchase history; knowing the relationship’s full value requires an enterprisewide view. Unfortunately, many companies know only the value of individual accounts because they don’t know what other accounts involve the same customer.

To compile customer portfolios, organizations might match names and addresses across product and billing databases. This business function requires ex- posure of the address components, down to the street level, for this reason: A computer probably can’t discern from text that “3101 S. Flowers Road, Apt C” and “3101 C Flowers Road South” represent the same location. Unlike city, state, and ZIP code, which have a fairly standard format across the United States, the street-level locator is a catch-all for address components with widely varying formats, such as building names, box numbers, and rural and military addresses.

Help is available for exposing and maintaining street-level address components buried in text, at least for U.S. postal addresses. The United States Postal Service (USPS) published its standards for mailing addresses at www.usps.com/ncsc/ products/products.htm#publications. There, you can find record layouts and complete definitions of each address component.

Because mailing addresses’ constructions vary, one large entity containing all the possible address components is difficult to manage. Few if any addresses use all the available address components. By generalizing the address with Locator, Locator Component, and Locator Component Category, you can capture only those components relevant to each address.

An organization reaps the greatest benefit when it uses structured addresses in applications supporting customer-facing employees. Customers do not come with a predefined identifier to help you determine whether you already know them as a business party. Although you can locate a business party’s data through candidate references such as a tax ID or credit card number, the party won’t necessarily have one or be willing to share it. Your company may assign a unique identifier to each customer, but you can’t make the customer remember it. So, information people tend to remember and are more willing to share, such as addresses and phone numbers, is commonly used to locate that party’s information in your organization’s database. Accuracy of matching improves when locator data is fielded.

Managers may initially think that fielding addresses in the operational systems will slow data entry, thereby reducing productivity. The fact is, if the systems supporting customer-facing staff understand the relationships between address components, it will save key strokes while ensuring accurate address capture.

First, you must implement the Locator subject area as a database storing each address only once. The system will use relationships between address components to facilitate the user’s entry of address search data. For example, a city is in only one state, a ZIP code identifies a specific set of cities, a specific street address falls within only one city.

The data capture form’s design is the key to streamlining the search function. Instead of entering the address components as if you were collecting a mailing label, capture the data backwards. Dan Tasker outlined this approach in his classic book Fourth Generation Data (Prentice Hall, 1989). You start by entering the ZIP code, as it will uniquely identify the state and, in most cases, the city. If a ZIP code covers multiple cities, the user should be able to select one from a drop-down box. You can also identify the streets that fall within the ZIP code. Once again, populating a drop-down box with the list of valid street names lets the user type only the first few letters of the name to find the right street. This method lets you eliminate text entry of city, state, and much of the street name. It also improves the accuracy of addresses you record.

For the highest accuracy, you can purchase the USPS’s database of accurate addresses and prepopulate the Locator database with them. Alternatively, you can subscribe to an address validation service that verifies addresses in real time.

You can search the Locator database after entering the desired address’s information, to determine whether that address is already known. Using the locator’s internal identifier, you can then link the address to the business party through the Point of Contact table. Information about how the business party uses the address, such as home, office, or vacation home, becomes a property of the Point of Contact, not the locator.

FIGURE 1 Evolving address models.


You can see how business functions, from mailing bills to customer relationship management, affect address structure. (See Figure 1) So far, I’ve discussed the topic from the domestic perspective of the United States only. However, each country idiosyncratically formats its locators. The second part of this article, in a future issue, will examine how the locator model continues to change to support international business.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. You can reach her via email at terry@inastrol.com.