Person/Organization Schema – Why Reinvent The Wheel?

Almost any enterprise SOA effort begins with an attempt to define XML schemas for key entities used by organization’s business processes. These entities inevitably include “person”, “organization” and associated information such as contact data with addresses, phone numbers, etc. While not every organization needs to support (and model) all CRM-related functions, person/organization (sometimes a term “party” is used to refer to these entity types) is almost always present in some aspects of a business (usually to represent customers and partners).

Of course, the need for these common data definitions goes far beyond just SOA; any integration/EDI effort has to rely on a language that can be understood by all participants of this effort. This is why many industries and government agencies try to define standard schemas that can be used for information exchange between multiple organizations (and not all of it is implemented using Web services). Examples in US include ACORD for insurance, MISMO for mortgage lenders and the Department of Justice JXDM XML schemas. All such schemas have to be able to represent customer/organization data.

I find it surprising that with all the effort that has gone into modeling shared schemas there is still no universally accepted standard that would once and for all define common XML data types.

At the same time, companies large and small continue reinventing the wheel. For example, there are no business-specific elements in an Address schema. Any address schema represents the same information (street, city, postal code, etc.). Yet the effort to create the Address schema with good support for international addresses could be quite substantial (even if there is no need to deal with the most exotic address systems, such as the one in Nicaragua). In today’s global environment, even local companies have to be able to deal with customers that used to live in another country (for example, there are around 4 million Americans living abroad ).

But there is hope. OASIS Customer Information Quality (CIQ) standard is a comprehensive, modular and very well documented standard that addresses this very issue. CIQ consists of several specifications:

• extensible Name Language (xNL)
• extensible Address Language (xAL)
• extensible Name and Address Language (xNAL)
• extensible Customer Information Language (xCIL)
• extensible Customer Relationships Language (xCRL)

Each specification has its own namespace and can be used independently from others (where it makes sense).

As an example, an address may look like following using xAL (xAL supports several different ways of representing addresses):

<xAL> 
    <AddressDetails AddressType="Residential">  
        <Country>  
            <AddressLine>Australia</AddressLine>  
            <AdministrativeArea>  
                <AddressLine>NSW</AddressLine>  
                <Locality>   
                     <AddressLine>Chatswood</AddressLine>  
                     <Thoroughfare>  
                          <AddressLine>23 Archer Street</AddressLine> 
                     </Thoroughfare>  
                     <PostalCode>  
                         <AddressLine>2067</AddressLine> 
                     </PostalCode> 
                </Locality>  
            </AdministrativeArea>  
        </Country>  
    </AddressDetails> 
</xAL>  

It’s a bit verbose for my taste, but this approach supports a complete range of international addresses.

Most organization will probably want to customize CIQ schemas (my understanding is that OASIS license allows it). The schemas are pretty lax meaning that most of the elements are optional, there are multiple ways of representing the same entity type and there are extensibility points everywhere, which may be undesirable in many environments. In my view, most large organizations should strive for strict schemas and tight WSDL contracts as this makes the initial implementation much easier (after all, each schema permutation has to be supported in code somewhere), but that’s a topic for another post.

In any event, CIQ provides a viable alternative to creating yet another home-grown person/organization XML schema.