How Do I Find You? (Let Me Count The Ways.)
Don’t take the information structures buried beneath simple attributes of address and phone
number for granted

Terry Moriarty and Dwight Seeley                
October 05, 1999, Volume 2 - Number 14

The daily routine of human thought involves a considerable amount of fuzzy logic. The terms used can be very vague. The meaning of words is often derived from their context rather than from their dictionary definition, of which there may be several. Consequently, the business models we initially create reflect the meaning of the words as used by our subject matter experts (SME) within their specific, and often narrowly focused, perspective of the business. In most organizations, only a few people have a perspective that is truly enterprisewide; they are rarely in the room when we are conducting business analysis sessions.

In an effort to precisely capture the business rules as the available SMEs state them, we express our models in the vocabulary of the problem domain, reflecting its hidden context. (See Figure 1.) When analyzing human resources, for example, we see name and address as employee attributes. Yet, when analyzing how the business wants to perform customer relationship management (CRM), those same properties are client attributes. And, when viewed from the enterprise perspective, it is easy to see that lurking behind the employee and client objects are people and organizations.

However, while you’re steeped in the domain of the specific business problem being analyzed, these fundamental object classes may not be exposed; their existence is so patently obvious to all the stakeholders. We are more interested in how people and organizations behave within specific business roles than we are in those entities in isolation. What is deemed inessential when only a slice of the organization is under the microscope can be significant from an enterprise perspective.

One of an enterprise model’s primary functions is to provide a framework through which you can integrate all the individual domain-specific models. Context-specific language, which loses much of its descriptive power outside its context, must be translated into a global vocabulary to facilitate identifying and documenting concepts common to all aspects of the business. The need for a global vocabulary is why many organizations are turning to dynamic business models as the basis of their enterprise models, because they reflect the information structures required just to exist in the business world. By exposing the obvious, dynamic business models can provide a bridge between business’ universal language and the collection of dialects unique to the various lines of business within a single enterprise.

The last series of Metaprise columns about the dynamic business model made the case that people and organizations of interest to the enterprise must be analyzed as though independent of the roles they assume. The “business party” and “business party relationship” subject areas resulted; they address what an organization needs to know about people, organ- izations, the names they use, and their interrelationships. The resultant model (see Figure 2) illustrates how information originally depicted about both employees and clients — such as their names, addresses, and phone numbers — are really attributes of the business party. By giving this information a common reference across all roles, the processes required to maintain and use it need to be accommodated only once; you don’t have to reinvent the wheel for each role.

Address: Not That Simple

However, in its treatment of addresses and phone numbers, this model still doesn’t recognize some context hiding in plain sight. There is an entire set of information structures that are buried behind those simple attributes of address and phone number. It is time we focus on the information we need to find things and to direct communications to business parties.

The word address is a wonderful example of how fuzzy logic is used every day in business. A whole collection exists of terms that provide the context underlying the simple word address. (See sidebar, “Address-Oriented Terms Defined,”) When used in the act or process of locating, address is seen as a coding structure associated with some thing in the same way in which name is associated with some thing. Both exist to designate and distinguish one business object from the others. There are many ways to designate and distinguish a business object; when we are locating something, we designate and distinguish business objects by address.

When one business party wishes the U.S. Postal Service (USPS) to deliver correspondence to another business party, the sending party must adhere to a standard method of locating the receiving party. This standard requires the sending party to provide the USPS with at least one (and in some instances only one type of) designator for each of several other constructs. For example, the USPS asks for the name of a city (City Name), state (State Name), and country (the country named U.S.A. is implied in the absence of a Country Name). Postal zones are identified by a coding structure called ZIP Codes. The USPS uses these codes to identify a specific postal substation. Site identifiers that further distinguish location include Street Number and Name, Room, Suite, Apartment, Building, P. O. Box, and Rural Route. Taken in some grouping, these designators act as the “written directions on mail indicating destination.” Remember that the USPS is not nearly as concerned with who or what as with where.

We purposely omitted the designator Person Name (and/or Corporate Name) to show that without this designator the USPS can still locate a destination and deliver an envelope to it. Without the Person Name or Corporate Name designator, the implied recipient is “any entity that has any association with the most discrete unit of location the sender indicated.” Any grouping of some or all of these designators, used for this locating purpose, has come to be known as a Mailing Address.

We are suggesting that Mailing Address is not an entity in and of itself, because any combination of other entities’ designators will allow locating, to some extent. It may not enable pinpoint-accurate locating, as exemplified by the following two valid USPS addresses:

Mr. John Smith

P.O. Box 4009

Atlanta, GA 30302-4009

Mr. John Smith

Georgia State University

University Plaza

Atlanta, GA 30303

The USPS will deliver mail with either of these addresses to exactly the same site: Georgia State University’s postal room. GSU employees will then have to decide which of the 37 John Smiths at the university for whom the correspondence is intended.

Forms of Address

Mailing is one application that demands the address concept. With today’s technologies, the word “address” requires even more modifiers that denote application. As detailed by the dictionary, computer science uses address as “a number that designates a specific memory location.”

A phone number is another instance of address application, but the address of what? A person may have a mobile phone programmed with an address that appears as a phone number (999-999-9999). This “phone number” is associated with a device associated with the person but is not the address of that person, nor does it indicate the geographic position of the mobile phone device. It is instead a destination address for telecommunication. Just as the mailing address never guarantees the locating of the most discrete unit of location, the phone number works like an address indicating destination but never guaranteeing location. Under what circumstances do we consider Phone Address to be a business object in its own right?

Electronic mail has created yet another addressing application. Standards exist for structuring email addresses, with the most common being <anytext>@ <domain>. Again, we must locate in order to facilitate communication. But this address does not “locate” the associated person; it allows you to put the mail in a place where the person can locate it. The message (mail) is delivered to that place by an “electronic postal service.” Once again, an address application demands to know destination. Addressing must be used to determine the location of the destination, while never guaranteeing the location of the most discrete unit that is the recipient of that communication.

Location can be accomplished through another form of Address generally referred to as geographic coordinates (latitude, longitude, and elevation). In this case, the physical environment is described by a system of fixed reference points. Each point addresses “a place where a structure or group of structures was, is, or will be located” (see Site). It is the Site that is located, while the thing that we are trying to find only exists in some proximity to that site. A person, designated by Person Name, will always hold a frame of proximity to any set of these points. A person could be located with this address.

What do these scenarios tell us about Address? For one, it is not inherently a part of a person or organization. The person designated by Name does not literally have an address. Two, with every address we attempt to identify a destination, or site, to which the intended recipient could have access or be proximate, without guaranteeing the location of the recipient. In so doing, Site is established as the thing that is addressed. By using some coding structure through which to define the domain, Address will locate Site and, so located, the site may place the sending business party’s message in proximity to the intended receiving party. Person Name and/or Corporate Name may have an association with many Addresses through their association with many Sites.

Once we understand the true nature of the address as a vehicle for enabling communication between business parties or in locating a specific geographic point, new models will emerge. Figure 3, presents such a new model; it depicts the importance of these locators as business concepts in their own right. There’s no longer an excuse to relegate them to mere attributes of people or organizations.

Dwight Seeley is president and consulting principal for Corporate Information Designs Inc., an Arizona-based information and object architecture firm. You can reach him at dseeley@CorpInfoDesigns.com or via www.CorpInfoDesigns.com.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. She authored Enterprise View (originally the Repository Report and later the Data Architect) column for Database Programming & Design. You can reach her via email at terry@inastrol.com.