When I take a step back and view my two worlds, home and work, I realize the similarities between my children, system users and IT. Every day, I deal with the fun and turmoil of growth as I watch my children mature. As they learn, their questions become more complex and their actions more concrete.

In one sense my children are much like users in that I want them to explore new avenues, be creative and take ownership for their outcomes. In another sense they are like a data warehouse, given the level of management and oversight their mom and I have to apply to their lives. The more I reflect on that, the more similarities I find between raising kids and developing a data warehouse community.

Thus, I offer a guide to raising your data warehouse solution.

1) Every data warehouse is different.
Congratulations, you have just gone through a tough, laborious process and now you have your new bundle of joy. Your data warehouse is not going to be like any other; while plenty of people are willing to give advice, your experiences, methods and procedures depend upon many circumstances. Of course, there are general guidelines, but there is no step-by-step process that works for everyone. Given the executives' commitment to the organization's goals for leveraging a functional and mature data warehouse, your users' knowledge, and the level of cooperation between IT and the business groups, you will need to constantly adjust your actions and expectations.

Fortunately, there is enough advice in common that can be tweaked to your particular situation, making a great deal of success achievable. The most important point to remember is your long-term objective; do not concentrate solely on the pressing needs of today. With your data warehouse, you want a well-behaved environment that is productive and useful to the organization. This means the data warehouse must interact with all groups equally, be available for analytics across the enterprise, and allow users to create change as needed. Of course, you cannot run before you walk, so always remember that this is adapting to a way of life and not to a particular event.

If you lose focus on those objectives for achieving long-term goals you will end up with a data warehouse that requires continuous remedial action and is isolated and unwanted. So heed the lessons you can learn from others and adapt those principles to your environment. A large portion of what works and how well it works depends on your organizational structure, culture and company politics.

2) Have rules and enforce them. Sometimes you have to say NO!
One of my favorite family memories is when my 6-year-old nephew was acting unruly and I cautioned him that he needed to stop. He did not, and my son, then 4 years old, said to him: "Do you know what a consequence is? Because you are about to get one!" He did get the consequence for his actions (a five-minute time-out), and we had no problems the rest of the day. My nephew learned quickly that I mean what I say and that I follow through on what is promised.

The same issue of consequence exists in many business situations: Organizations often do not follow through with their established rules and guidelines. Even as they drive toward a data warehouse for data consistency and a single view of the business, companies still allow business groups to extract data into disparate and conflicting data marts. Or they allow data that has not passed the corporate standards to be brought into the environment. Or new applications are created, but the old systems are left running.

The bottom line is, everyone needs to understand that all actions have consequences. After deciding on a particular course, have a plan in place and be prepared to take that action. Nothing ruins your credibility faster than policies that are never carried out or positions and rules that are never enforced.

Conversely, once it is established that your policies, commitments and actions will be enforced, people will quickly respond to that mind-set. After they learn the new practices, people throughout the enterprise typically become willing and active participants in accomplishing the corporate goals.

This was well-demonstrated at an international telecommunications company. In the past, new systems were brought in under the guise of replacing the old, yet the old systems were never retired. Later, when the data warehouse was implemented, the company followed through on removing the old systems. Establishing a plan and sticking to it leads to a greater acceptance of the corporate goals and more rapid integration of the data across the enterprise. This in turn led the company to greater success at an even faster turnaround time than in the past, because everyone knew the direction and knew it would be enforced.

3) Fill the users with wonder and encourage questions.
The growth of your data warehouse is directly related to its use. Just as you can say "Because I said so!" only so many times, you do not get cooperation and growth by edict. The user community must move forward on its own initiative, not by your constant prodding. The best way to ensure healthy growth is by instilling a sense of pride in the results and a desire to ask the next question.

There are several ways to accomplish this, although incentives and rewards probably work best. As executives start to ask the business community why something happened rather than what happened, the users will anticipate the question and search for answers in advance. The user community will understand that those who come forth with explanations and possible solutions to trends and exceptions are the ones who are rewarded with recognition and monetary incentives.

This by no means needs to be a large reward, either. Night-on-the-town awards, nominal gift certificates or public recognition at quarterly meetings will make the users want to explore and be the next one to find gold.

Not all analytics and exploration will bear fruit, however. Make sure that when that happens, users are not punished for following a prospective lead. Otherwise, they may learn to fear failure rather than cherish exploration.

4) A failure to learn is usually a failure to teach.
As my children work on their homework, they often ask for my help. I learned there are two ways to help: I can give them the answer, or I can teach them how to get the answer. While it's harder on both of us, the latter is better for everyone.

Likewise, you cannot expect the user communities to learn new techniques, explore new vistas or use new tools unless you are willing to spend the time and money necessary to educate them. Furthermore, you need to give them reasons to apply that education to real-world situations in order to reinforce the lessons. This is pertinent not just for end users but also for application developers and systems management groups, as well as the extract, transform and load groups. Once they are educated to do their job, they can be held accountable for the jobs they do.

The failure to teach is typically manifested in two ways. The first is most obvious: inadequate or no training. Too many corporations consider training a luxury and a costly expense. They do not think users need annual refresher courses, or they assume users get trained by reading manuals and through hands-on experience. While users may get some experience this way, usually they get the experience only for a particular situation or limited exposure from the person or team with whom they are working.

Training is about learning how to analyze situations, exploring the options available to help solve a problem and applying the most relevant solution. It is also about understanding the longer-term pros and cons of actions or techniques.

A second consideration to untimely, inadequate or no training is the lack of relevance to users' particular needs. Many companies will run "education mills" where users are trained on a specific product or process. Then they return to their daily lives where there is little, if any, practical application of what they've learned.

It is very important that training is related and timely to a person's need and job role. We all learn better when the subject has meaning to us and is further reinforced when we implement the learned tasks.

5) Expect better and you will get better.
This is a corollary to one of my favorite parenting tips: You get more of what you tolerate. Oftentimes we write off children's improper behavior and recklessness as going through a phase or acting their age. Unfortunately, children do not grow and mature unless someone expects them to do better.

Likewise, it is up to the executive community to hold the user and IT groups accountable for their roles in nurturing a mature system. The users and IT groups must build justifiable business cases for growing the data warehouse, for creating and managing the environment to meet the business demands, and for measuring the service levels and business output of the total environment.

I am always surprised when executives cannot understand why the data warehouse is not providing the promised value. Typically, I ask whether the business case was clearly articulated (yes, it was) and whether the metrics from the business case are being measured (no, they are not). In some cases, the user community—and, to an extent, the executive community—is apparently not expected to provide better business results once the data warehouse is implemented. So I'm not surprised when those results do not materialize. If the results are not being measured, who is to say the results are not really there and are just being missed?

A good example of users expecting better results came early in my career. At the account I was supporting, the executives and business leaders would use the same tools available to the users, and then they would question those users about the various business results. The executives were demonstrating a few key principles. The first was that since the data was available, it was inexcusable for the users not to know the business situation. The second was that since the users should have been aware of the situation, they should have devised responses before the executives became aware of it and had to ask the questions.

The underlying theme is that the users had to migrate from simply looking at things to looking for things. This strategy worked well in moving this company to a leadership position in its industry.

6) To have responsibility, you must have accountability.
Recently, two lessons my wife and I have been trying to teach our children are that they must be accountable for their behavior and that by showing trustworthiness they earn more responsibility. This is true in the evolution of the data warehouse environment as well. As users want more flexibility for analytics and exploration, they must also assume more accountability for the resources consumed and for the actions that result from those processes. The user community must come to understand that the data warehouse exists to fulfill their needs and, ultimately, they are the owners of the environment.

Likewise, the purpose of the IT community is to ensure the technology and processes are running as designed and agreed upon. However, IT cannot define the requirements for disaster recovery timelines, specifications for data loading service level agreements, response time for tactical queries, or prioritization of the multitude of user requests. All of this must be defined and refined over time by the user communities working together for a common good. If system conflicts arise because definitions and service levels do not exist, it is up to the users, not the IT community, to correct the situation.

Once this ownership is identified, then the users can consider how the environment is used and determine the value derived from that usage. For example, is it sensible to generate thousands of reports every day when only a small percentage is used in decision making and subsequent actions? Commonly, the additional reports are generated in case something happens or because they have always been run. As users are held accountable for the total picture rather than half of it, they will start to work together as a group rather than as individuals.

The last point to make is that once users have accountability, they start to have power over their destiny. That power is what should be instilled when developing a healthy data warehouse.

Teach them, guide them, let them make mistakes and learn, and then give them ownership and trust you did a good job. This is what raising a strong data warehouse community is all about. T

Teradata Magazine-September 2007