Affiliated with:

Data Architecture and Packaged Implementations Part Two


Every organization should follow a set of guidelines for implementing packaged applications to ensure architectural harmony and avoid numerous problems.

Previously I discussed some issues that a client encountered when trying to implement a packaged application.  They were convinced that the business would make the decisions and IT was not going to interfere in their packaged implementation.  There was a mistaken impression that the increased usage of packaged applications meant a decreased role of data architecture.

There are many inevitable problems with this approach.  Many of these problems can be avoided by following some basic guidelines.  In the initial article, the following basic guidelines to consider when converting to packaged applications were outlined:

  1. Pick a system of record for each business attribute
  2. Define business attributes that cross packages as close to the system of record as possible
  3. Avoid embedded meaning in keys and codes
  4. Avoid misusing fields for other than their intended purpose
  5. When setting-up user defined fields use the same rules as would be applied when defining new data elements
  6. Involve the right people
  7. Document all business requirements and decisions
  8. Define the architecture before purchasing and configuring the packages

In this article, we will focus on guideline 1 “Pick a system of record for each business attribute.”  First, I would like to share a little story.

Once upon a time there was a quite friendly suburban neighborhood. Everyone lived happily but it seemed like something was missing.  “We need a dog!”  Mr. Smith down the road said.  Everyone quickly agreed.  Rex Johnson immediately pictured hunting trips and a dog chasing down his kills.  The Jones children could not wait for a dog to run and play with.  Old widow Myers was excited about the extra protection from a guard dog. Everyone wanted the benefit of a dog but no one wanted the responsibility.  They decide to get a dog that they will all share; it would be easy because there would not be one true owner. No one would be overburdened they thought.

The problems arose almost right away.  All the needs were not evaluated before a decision was made. The first people who had the extra time and money were the Jones family so they went out and bought a Golden Retriever.  Because Rex Johnson is very loud and intimidating they made sure that his input was heard.  They picked a dog they liked that Rex could also take hunting.  Mrs. Myers didn’t voice her opinion because she would rather sit back and criticize any choice after it is made.  She loved to complain about having been ignored.  If one person was appointed the owner of the dog and assigned the responsibility of picking the best dog for everyone all the input would have been weighed and evaluated. However, unfortunately the puppy’s place in the neighborhood is already off to a bad start.

The next problem is the dog’s name.  Who names the dog?  The Jones kids called the dog Butterscotch.  Rex wanted a manlier name so he called the dog Killer.  When someone in another neighborhood complained that Butterscotch was chasing a cat up a tree Rex doesn’t think it’s anything he needs to worry about because his dog isn’t named Butterscotch; it’s Killer.

So now they may or may not have gotten the dog they needed and everyone called him something different.  In addition to the dog being very confused, who will make sure he is taken care of? Who will make sure he is walked and fed?  One would think that with all those people to watch out for him this wouldn’t be a problem.  However, the problem occurs when everyone feeds him or everyone thinks someone else must be feeding him.  The poor dog was malnourished one week and overfed the next.  No one is really looking out for his best interests; everyone only does what is convenient.

With all these problems, the likelihood of the dog getting sick seems high.  What will they do then?  Will everyone assume that someone else is handling it or will multiple people each try to treat the dog they way they thing is best?  The dog either will be ignored or over-medicated.  Someone needs to take control.

Like an entire neighborhood trying to share a dog, it is the nature of data that a single business attribute will live in many different systems and many different data structures within those systems.  Like poor Butterscotch (or is it Killer?) in the story, sometimes data gets lost without a home.  An easy example that applies to many business models is an account number.  An account number will appear in the billing system, marketing system and in the historical reporting warehouse.  The customer’s account number exists in each of these systems, even if it is named differently, it still represents the same thing. It is one business attribute despite the fact that different packages or systems may call it different things.  It is therefore very important that one system becomes the system of record or owner for the account number.

One system must be the system that maintains, validates, and assigns account numbers.  When there are issues with how account numbers are assigned or discrepancies in determining what a valid account number is there should be one system of record to go to.  There should be one place that is considered an authoritative source.  If we have many systems assigning account numbers issues begin to arise. We may end up creating incompatible or overlapping numbers.

This story may have been silly but there are a lot of lessons that apply to data attributes.  A single owner will ensure that:

  • All input is collected and the right decisions are made. It will be the owner of that systems’ job to make sure all voices are heard, not just the loudest.
  • One and only one name will be applied to the data attribute. If we search for customer_acct_ID we can find all occurrences of the account number on any system or file structure.
  • The data element is properly maintained and evaluated, and all metadata will be recorded and accessible.  Any issues with the usage or contents of the data will have one source to go to for resolution

Picking an owning system is usually obvious.  It doesn’t take a rocket scientist to know that the line item shipping and handling charge amount should be owned by the order processing system that assigned it.  Other attributes may be a little trickier. In these cases some negotiation may be needed.  An owning system may be assigned, but the process owner must ensure that all the voices of the other affected systems are heard.


In another article, we will discuss “how to define business attributes that cross packages as close to the system of record as possible” and the issues that arise when we don’t adhere to this guideline.


Daniel Roth

Daniel Roth is an Information Architect with experience in health insurance, warehouse/distribution, banking and manufacturing. He has many years of data processing experience as an application programmer, technical support specialist, DBA, and most recently as a data architect. He has been the lead architect on large OLTP and OLAP projects.

© Since 1997 to the present – Enterprise Warehousing Solutions, Inc. (EWSolutions). All Rights Reserved

Subscribe To DMU

Be the first to hear about articles, tips, and opportunities for improving your data management career.