Shop News Jobs WorldWide Contact Us Search C-Byte Home Page Big Open Systems That Work
CompanyCustomersSolutionsAlliancesProductsServices
 
 
     
 
   Solutions/
 
      Application/  
      Decision/
      Contact/  
      e-business/  
      Data Center Ready/  
      Whitepapers/  
     
     
     
   
 

decision advantage whitepaper  
 

Attention, Warehouse Shoppers:
The Output is in the Decision.

(continued)
 
Building the Data Warehouse
In the ranks of decision making, change is constant and often dramatic. How can changing business size, goals, and practices be managed in a Decision Support environment? The old model for building applications no longer works. In the past, you designed, built, and maintained what remained fundamentally the same application. With the business environment and technology changing so rapidly, it is more realistic to plan for a constantly evolving decision support environment and build an environment that can change with it.

The methodology presented here uses a decision-directed, iterative approach. Each iteration implements one or more Decision Support Service. Each iteration takes approximately four to six months, producing concrete results for decision makers. This process not only leads you to success, but it prevents you from investing in DSS before you have the data you need to succeed.

For companies with focused DSS goals, a unified business purpose and decision makers whose goals are fundamentally the same, it may be possible to design the entire decision-directed warehouse in one iteration.

1-Determine the Goals
The first step is to develop a list of objectives in real business terms. These objectives will usually come from executives within the enterprise. Examples might be increased revenue, increased market share, expense reduction, increased margin. Ideally, some concrete estimates should be made about how much these goals will affect the overall health of the enterprise.

2-Pick a Good Candidate for Decision Support
You do not necessarily have to implement Decision Support for everyone all at once. Pick the areas of greatest pain and concentrate on them. For example, an insurance company might choose to focus first on optimizing policy revenue before attacking claims reduction. A drug store chain might focus on point-of-sale analysis of merchandise before attempting a more complicated effort for pharmaceuticals. Implement Decision Support services where you are likely to have the greatest, quickest impact. Include other DSS Services that require the same data at the same or higher grain.

3-Identify the Targeted Decision Makers and the Data Gurus
The next step in developing warehouse services is to identify the “targeted set of decision makers”. In other words, who are the users? The classic answer to this question was always “whoever is paying for it,” rather than the actual users of the system. However, in DSS the people who are paying for the project set the goals, while the people responsible for meeting those goals are your decision makers. Compared to traditional computing, these “users” know a great deal and will help you to determine the Services Requirements. In particular they understand business processes and the measures necessary to make decisions.

Secondly, identify the data gurus. These are the people who really understand the source OLTP data. They are the people who can figure out if the data necessary to support a particular DSS analysis is present at the proper grain on the operational side. If you plan to use outside data resources, you will need a similar data guru.

4-Develop the Services Requirements Simultaneously.
Determine the Decision Support Service requirements by interviewing targeted decision makers during workshops. Requirements may be: important business attributes (like customer, product, markets, time periods) and measures (extended price, cost, margin, claim amount) by which they make decisions, access requirements (e.g. 6 AM to 12 PM), locations (e.g., local only, National offices, International), how many are at each location, the types query needed (parameterized, ad-hoc), the type of analysis (what-if, trend analysis), the historical data requirements (how far back and how detailed), and so on. Each business attribute will need to be explored to determine the appropriate grain (time periods: daily, weekly, monthly) and aggregations (time periods: quarterly, yearly) that will be needed.

At the same time you are collecting this DS Service-oriented information, you must determine if you have data to support the DS Service requirements. This is where you need the data gurus. With their expertise, you develop the mapping of operational data to the Knowledge Base you will need to support your DS Service and Information Services Requirements. After interviews with the decision makers and the data gurus, you should be able to develop the logical database design necessary for the Knowledge Base.

As you are collecting the Decision Support and Information Services requirements, the unique DS Management Services required should begin to emerge. Security levels for each targeted decision maker must be identified. Availability requirements should be defined from the location and access requirements. Data quality and version control requirements should be defined. Connectivity and networking issues must be identified and resolved.

These services must be designed to withstand change. Investigate throughout this process where changes are likely to occur and plan an infrastructure to detect and handle it. For example, you might anticipate customer accounts changing from one sales representative to another. How will this change be handled in the design? Is it desirable to reflect sales history with the old sales representative or the new one? Similar issues arise with reorganizations of any kind, such as product groupings, sales geography.

It is possible your operational systems are not collecting vital information needed by your decision makers. After all, traditional systems were not designed with Decision Support in mind. Fixing an operational system can be difficult for many reasons. It can be costly. It may be controlled by groups not needing the DS Services that require it, so they have little motivation to change it. It may require unpopular procedure changes. It may be controlled by people who fear their “failures” will become obvious when the change is made. At this point, you must have real political support from a point high enough in the organization to force the changes necessary, or you must choose to limit the DS Service effected. You need to decide if your essential goals can be met without these services. If they cannot, stop right now or you are headed for failure.

Back to Top

5-Do a Small-Scale Implementation.
With the three services requirements identified, you are now in a position to select (1) a physical warehouse architecture (warehouse data mart, operational data store, etc.), (2) the physical database design, and (3) candidates for service providers such as query tools. A discussion of the issues in making those selections is not in the scope of this white paper.

Having chosen a physical implementation strategy, do a small scale implementation to test out your provider candidates, such as your query tools, with a subset of real data. Not only will this shake out your various tool candidates, but this exercise will give you a dose of reality with respect to data quality. Now is the time to test the logical and physical database design by having your decision makers participate in the testing. Can they query the database and get the answers they need? How is the performance? Make modifications as needed.

The first time through this effort, your data warehouse physical design could be quite simple. It may look quite different after several iterations where you have many more DS Services in place. Obviously, it is best to pick a warehousing solution that is flexible. You might begin for example with a single machine, moving to several machines each supporting its own set of Decision Support, Information, and DS Management Services. If multiple extractions become hard to manage, eventually you might move to a central staging agent with multiple data marts each holding some portion of the Knowledge Base and providing a different DS Service.

6- Build the Production Data Warehouse
Now you are ready to build the production environment. Before going online, set up the DS Management infrastructure you need. Conduct training that uses your data with your business questions as examples. Set up a hotline for navigation support and data quality feedback. Implement the backup strategy that will support your availability requirements. Adjust the network to handle the incremental traffic this application will generate. Create an environment where decision makers are encouraged and rewarded for finding mistakes of the past (before they had the tools needed to do it right).

Once it is up and running, assumptions about the right logical and physical design should be continually challenged. Are aggregate tables useful? What other tables are needed? Is the historical data accessed? Can it be moved to near-line storage? Be prepared to make changes. The more you know the better you will be at designing the next iteration.

Above all, never forget to compute the effect your implementation has had against the stated objectives. This will be the real measure of your success.

Go Back to Step One.
Now go back to step 1. See if the goals are any different. Move on to the next good candidate for Decision Support. When you get to the physical design step, take into consideration the existing implementation.

Back to Top

Summary
There is no one Data Warehousing strategy that is right for everyone. Think of your Data Warehouse as a means to a goal. Focus on the decisions that it must produce to move the enterprise toward that goal. Make sure it provides the set of services (Decision Support Services, Information Services, and Decision Support Management Services) that a successful, Decision-Driven Warehouse must provide, modeled to fit your unique requirements. Develop the Data Warehouse in stages. Pick the areas of greatest pain and provide high quality decision support services whose success can be measured. Do another and another, evolving the Data Warehouse if necessary as you go. At each stage pick the right warehouse strategy for you and measure your success.

Back to Top


Previous | Table of Contents
 

 
 
 
   
   
C-Byte Company, Inc.
 
  Good Evening it is 11:42 pm in Las Vegas, Nevada, United States.    E-mail This Page  |  Digg This  |  Facebook  |  Twitter  |  Delicious

Ask Us a Question - Call Inside US 1-800-393-5804, Outside US 1-403-770-7818, or Contact Us
Copyright © 1989 - 2017 C-Byte Company, Inc.  ::  C-Byte Privacy Statement   ::   P.R.O. Program ::  RSS 1.0 Feed
This site is protected by copyright and trade mark laws under U.S. and International law. All rights reserved.
SecurityGroup Audits Systems at C-Byte Tackling...