Basic Decisions
When designing any information system that includes some form of contact management system there are a common set of decisions to be made before you get very far:
(1) How will we handle peoples' alternative contact details, work, home etc?
(2) How will we handle addresses?
Over the last ten years my approach has developed from the keep it simple, home and work details in a contact record approach, essentially a flat architecture linking into a related work "Organisation", to our current approach where:
(a) every contact has unlimited different personalities [ie different personas for home work and other activities]
(b) every organisation has unlimited different locations [ie different offices etc]
(c) every personality can relate to a specific organisation location or not as required
(d) every personality and/or location can relate to a specific address if required
(e) every different address comprises a record in the address table but no address is ever duplicated
Pros and Cons
The advantage of our earlier approach was simplicity, always a virtue, and it took very little time to produce.
The downside is its very severe limitations. Generally with this sort of approach there are never enough places to put the new information users want to store and you end up with address data in the notes field. It offers no means of retention records of previous employment, always useful when analysing social and business personal networks or considering employment history.
The downside of our more sophisticated approach is the time and work involved in developing the model so that it actually offers users what they expect to see. The work was been a great deal more than I had originally envisaged. The investment in pursuing and completing this aspect of our system design has been significant.
The upside is that we do now have an amazingly flexible powerful but easy to use contact management system which through its relational structure offers the ability to record whatever information our users wish and also offers lots of real added value. Now, for example, our users can see who shares an address, who used to work together or do work together, how far apart are different people and/or organisation locations, which contacts and/or offices are any given country, region, county/state, city, town - ie all the "natural" questions that are not so easy to answer using post codes.
Automatic Address Cleanup
We have necessarily had to create address cleanup procedures which is able to take the various forms of address data in legacy systems, from everything in one address field upwards, and correctly parse the different elements out into Country, PostCode, County/State, Place, subPlace, Road etc fields.
This gives us an enormous advantage when starting to work with a new client - since our ability to take their existing legacy contact data, which is seldom in good order, and automatically create from it a full relational address structure has significant value add from their perspective.
UK Geographic Address Structure
As a consequence we have created our own UK structure for all the main geographical elements in the UK including postcodes which has proved a very useful resource.
Useability
In terms of useability - always the key measure of successful design - our approach is to give the user with a simple requirement a simple interface which merely stores and displays the required single name, address and other contact information. On input they can select from existing addresses or input a new one. If they input an existing address the system identifies this and gives them the existing address.
It is only when they want to create a further address that more options appear and it becomes evident that they can store many more different addresses.
Future Proof
The long term upside for us is that our investment in creating this level of sophistication future proofs our data architecture since its completely relational and extensible structure can easily accommodate any conceivable future requirement and hence we will have to do very little to it for the forseeable future.
===ENDS===
Comments