Broken shells

Broken shells

A great way to sharpen our analysis and modeling skills is to continuously address real-world scenarios. A modeling scenario along with suggested solutions will appear each month in this Design Challenge column. The scenario is emailed to more than 2,000 modelers up to the challenge. Many of the responses, including my own, are then consolidated into this column.

The Challenge

I was about to go for a run on the beach when my 4-year-old daughter asked, “Daddy, can you bring me back some shells? It’s ok if the shell is chipped or missing a piece but I don’t want any shell pieces.” Although it was easy for her to distinguish a chipped shell from a shell piece, I had a much more difficult time separating the two while jogging along the beach. Where do we draw the line between a chipped shell and a shell piece? That is, at what point does a shell change so dramatically that it is no longer a shell but now a piece of a shell?

After returning home completely ‘shell-less’, I started thinking about how this shell story relates to a challenge we sometimes have to face in capturing requirements. William Kent in “Data and Reality” raises a similar dilemma on replacing parts in a car. If you replace the windshield wipers, it is still the same car. But what if you replace the car engine and car body? Is it then still the same car? In your organization, if a customer moves to a different location is it a new customer? If no, is there anything about a customer that could change (name, tax identifier, or even gender) that could turn an existing customer into a different customer? What about a product or employee or any other concept important to your organization?

Have you ever had to analyze or model a concept in your organization where enough changes could occur to create a completely new concept?  How did you handle it?

The Response

Norman Daoust, Requirements Modeler, uses the term ‘morphing entity’ to describe a concept that changes to the point where it becomes a new concept. Morphing entities can be addressed through a combination of learning the business perspective and identifying those entity properties that must never change.

Learning the business perspective

A department or business area can create morphing entities based on entity lifecycle or level of granularity. Janus Camarata, Information Architect, says that often times when you define a concept there are other concepts with closely related definitions.  “The challenge is then to determine where does one concept end and another one begin.”
Bruce Baum, Global Data Architect, says in the Power Generation industry, “If the gas turbine (i.e. engine) is replaced in a power plant, is this a new plant? Unfortunately, it is often a matter of one’s perspective.  Sales may count this as a new plant (boosts the count of plants sold which is a key metric for Sales), while Engineering or Service says it is still the same plant, just with a new component.”

 

Bruce gives another example of the importance of perspective: “When is a country not the same country but a new country?  Think of the former East and West Germany?  Did the physical land change?  No, but the defined geopolitical boundaries certainly did.  Some guidelines should be stated, from the perspective of the business not IT, as part of any database design which clearly identifies when a new instance of an object should be created.”

Identifying entity properties that cannot change

Dave Hay reminds us that Aristotle also struggled with the morphing entity issue, realizing there is a distinction between accidental attributes whose values do not affect the identity of the entity, and fundamental attributes whose values are crucial to the identity of the entity. Steve Turnock, Database Engineer, supports this distinction through this story: “When I was working for the Department of Corrections, it was very important to correctly identify repeat customers.  As you might imagine, mistaken identity could result in a life and death situation.  The key we came up with for a customer identifier was a hash code created by the State Police based on analysis of fingerprints.   All other attributes of a customer are considered variables.”

 

Norman Daoust discovered in one organization that when one department needed a new account category they just updated an old entry they no longer used by changing the name, definition, and code of the item. “I was shocked when I heard of this, but it was too late to do anything about that occurrence. To prevent the situation from recurring, we made the critical data items (name and code) for each entry ‘add-only’, so they couldn’t be changed. This prevented anyone from reusing the same entry to represent a different concept.”

 

0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*