Today I stumbled upon a blog post called Good-Bye to the “Job” by David Houle, a futurist, strategist and speaker.
In the post it is said: “In the Industrial Age, machines replaced manual or blue-collar labor. In the Information Age, computers replaced office or white-collar workers”.
The post is about that today we can’t expect to occupy one life-long job at a single employer. We must increasingly create our own job.
My cyberspace friend Phil Simon also wrote about his advanced journey into this space recently in the post Diversifying Yourself Into a Platform Business.
The subject is close to me as I currently have approximately five different occupations as seen in my LinkedIn profile.
A professional angle to this subject is also how that development will turn some traditional data models upside down.
A Customer Relationship Management (CRM) system for business-to-business (B2B) environments has a basic data model with accounts having a number of contacts attached where the account is the parent and the contacts are the children in data modeling language.
Most systems and business processes have trouble when following a contact from account (company) to account (company) when the contact gets a new job or when the same real world individual is a contact at two or more accounts (companies) at the same time.
I have seen this problem many times and also failed to recognize it myself from time to time as told in the post A New Year Resolution.
My guess is that CRM systems in the B2B realm will turn to a more contact oriented view over time and this will probably be along with that CRM systems will rely more on Master Data Management (MDM) hubs in order to effectively reflect a fast, but not equally, changing world, as the development in the way we have jobs doesn’t happen at the same time at all places.
Liliendahl on Data Quality 
Great post. Very helpful
Thanks Sydney (man or place?). Such short comments are usually filtered out as spam, but I recognize that the Data Agility site is about data management.
My point of view is that such a data model is a poor model of real life. People (contacts) aren’t attached or permanent features of organisations, so your data model shouldn’t behave as if they were. It seems like such a basic mistake to me, and yet I have seen some CRMs make it (reallysimplesystems comes to mind). On a related note, this doesn’t seem to be a problem that would occur in New Zealand, as we have such a highly mobile workforce (and have had since the country existed) that we have never had the expectation of working for the same employer for life, in fact I know very few people who keep the same employer for more than two years.
Thanks for joining Doug. Indeed the way we have jobs do vary around the world. It’s a good example on how some software may make wonders in one country but be close to useless somewhere else. However globalization increases the demand for flexible solutions.
I’m with Doug. The basic CRM model that you show is not a good model. The basic entity classes should be PARTY, with sub-types Person and Organization. Then an ACCOUNT has one or two relationships to PARTY: Each ACCOUNT must be held by one PARTY (the customer) and (optionally) Each ACCOUNT must be with one PARTY. (The company responsible for the account. This may be assumed to be the company whose model it is, but sometimes that is not so clear cut.)
Then another entity class can be CONTACT, where each CONTACT must be a role played by one PERSON and must be (a role played) for one ACCOUNT. Note that a PERSON may be in the role of one or more CONTACTS (especially over time). Note that attributes of CONTACT are “Start date” and “End date”.
See my original book (1995), “Data Model Patterns: Conventions of Thought”, or my more recent book (2011) “Enterprise Model Patterns: Describing the World” for more on this.
Dave Hay
Houston, Texas
dch@essentialstrategies.com
Thanks for commenting Dave. I agree. However the model was surprisingly good enough to make SalesForce.com one of the most successful pieces of software ever. The concept you describe is indeed better to facilitate that we may have the party behind the account or the individual person in different contact roles in focus in various situations.