Data Architecture and Packaged Implementation - Part II
by Dan Roth

In a previous issue of RWDS (Oct. 2002 Vol. 1 Issue 17) I discussed some issues that a previous 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 means 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. I discussed, at a high level, the following basic guidelines to consider when converting to packaged applications:

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 - document -document
8. Define the architecture before purchasing and configuring the packages

Over the next few issues we are going to begin to look at each of these guidelines in a little more detail. In this issue we are going to focus on guideline 1 "Pick a system of record for each business attribute." But 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 couldn't 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 the choice after it is made. She loved to complain about being 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. But 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 their 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. Besides 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. But 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 will either 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. 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. But 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.

Check back next issue where we will discuss "how to define business attributes that cross packages as close to the system of record as possible" and the issue that arise when we don't.