Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Data Warehouse Development: Version 0 Expand / Collapse
Author
Message
Posted Thursday, April 7, 2011 12:01 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, July 21, 2014 12:44 PM
Points: 389, Visits: 1,041
Comments posted to this topic are about the item Data Warehouse Development: Version 0

Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard
Post #1089698
Posted Thursday, April 7, 2011 1:59 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 10:20 AM
Points: 558, Visits: 1,471
An interesting article for a Data Warehouse newb. I'm very much looking forward to reading the follow up articles in this series. Thanks.
Post #1089714
Posted Thursday, April 7, 2011 5:03 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, July 18, 2014 9:09 AM
Points: 870, Visits: 2,385
Andy,

An intersting article and of great interest having being a DW developer for the last 8/9 years, and I would always describe version 0 as a Proof of Concept that shows the CxO's what they can get if they invest in the development of a DW.

However in my experience most CxO's dont really know what a data warehouse is, let alone what they want from one, execpt the obligatory 'every thing we currently have, and more'. They also have a tendancy to think that there is nothing wrong with thier data, and so when you produce a single report that doesnt match expectations, its your problem.

Even when you explain that the data is correct, and its different because Annie in accounting manually combines Figures X and Y in a spread sheet so that it looks better.

Often the biggest issue I come across is that there is a disconnect between the requirements of actual users and the CxO's and other senior managers. Who are generally only interested in pretty graphs, and the visualisation part, were as those lower down the chain (departmental heads, analysts etc) are interested in being able to dive around the data and look at the anomolies.


_________________________________________________________________________
SSC Guide to Posting and Best Practices
Post #1089759
Posted Thursday, April 7, 2011 6:52 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, August 11, 2014 6:34 PM
Points: 157, Visits: 290
Thanks for posting this article. I am new to DW project and in learning stage. I think the series of this article takes me in the right path.

Please suggest if any of you have posted anyother DW article to start with.
Post #1089837
Posted Thursday, April 7, 2011 7:01 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, June 13, 2014 3:47 PM
Points: 14, Visits: 110
Great article. But I'd take it one step further. While automating a manually produced report that takes days if not weeks to produce might be the ultimate goal, a report could consist of information captured in multiple business processes from multiple systems. The danger of letting a report or a small set of reports guide your requirements is that you run the risk of creating a series of spreadsheet marts that each contain data that cannot be easily integrated. While gathering requirements, data sources need to be classified into two categories, business actor (dimensions) or business process (facts). And the Kimball data bus matrix (or SSAS cube editor Dimension Usage tab) needs to be the final product of the requirement gathering stage. From those results, the data warehouse can be constructed iteratively and incrementally, one source, one business actor, one business process at a time. And as the business changes, so will the data bus matrix.
Post #1089845
Posted Thursday, April 7, 2011 8:16 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, April 21, 2011 7:56 AM
Points: 85, Visits: 70
This is an excellent example of pressing the right buttons. You bring up a fantastic point about the 'environment' of relatioinships and getting to know WHO and WHERE to start. By starting at the 'C' level, you maximize your ability to obtain management buy in. Decision makers will push the project on the business side. To add to your intro article, it is important to understand the business entities and focus on one at a time. Break your staff up so each is point for a different business unit. This helps build rapport with users by putting a familiar face to the data warehouse. Then cross train your developers to insure they can support one another. Finally, request subject matter experts from the business units. This allows your point developer to be part of a cross functional team and insures an actionable end product from the warehouse. Great intro article!
Post #1089928
Posted Thursday, April 7, 2011 8:23 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:43 AM
Points: 1,434, Visits: 721
Interesting article Andy, thanks! Interesting in the sense that the organisation I work for is currently looking at developing a BI solution, and the approach that's being taken by those leading the development is contrary to the approach I think should be taken (which I think is more in line with your recommendations).

Their approach seems to be to take what's currently in place, and simply use SSIS to transfer the data from its various sources in to a data mart of some description (the schema of which is more or less being defined by the customer).

I'm trying to encourage them to look at this from the end user perspective, and try and establish what it is the user wants to see at the end of this process in their reports and what they want to be able to query. Then those with the experience and knowledge of data warehouse solutions can model the BI solution around that. Unfortunately, the concept of using SSAS or SSRS to support the overall requirement appears to be lost on them.

Someone build me another brick wall to hit my head against please - I've already knocked down the last one!
Post #1089933
Posted Thursday, April 7, 2011 9:56 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, February 6, 2014 9:39 AM
Points: 420, Visits: 487
This is a great method to get started, but make sure you are answering a relevant question. It may not always be "What do you use to measure how your business is doing?". If you're working with a CIO and the CIO wants to improve change management processes, the question might be something like "What runs where?". In that case, you would dig through the spreadsheets to find which applications run on which servers and so on. Being able to easily answer a relevant question is what makes the DW valuable to management.

Joshua Perry
http://www.usesage.com
Post #1090020
Posted Thursday, April 7, 2011 10:05 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 1:46 PM
Points: 1,649, Visits: 4,697
There are a series of canned questions that should always be asked upfront, and these should be documented in the requirements. However, I also find it essential to ask the business to provide a mockup of the end product. Let them actually draw a picuture (preferably in Excel with real numbers that add up) of what the report or dashboard screen fed from the datawarehouse should look like. This Excel sheet is something that should be passed around to all the stake holders and end users so they have an opportunity to input. As a reality check, compare that mockup back to the original requirements document and you'll be amazed how many critical holes it fills, especially if the requirements were written by a 3rd party or were pre-written before you were hired on the project.
Post #1090037
Posted Thursday, April 7, 2011 11:37 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, May 29, 2014 8:51 PM
Points: 855, Visits: 95
Thanks, Andy!

This is a topic that has come to the forefront for me lately, specifically, we have an operational database, and we want to get to the point of being able to use cubes. The missing piece for us is a data warehouse.

I already have a degree of familiarity with development methodologies, SQL Server BI stack, our institutional culture with regard to data, etc. I really like your approach, and look forward to the rest of this series.

I am specifically interested on any tips for getting our operational data into the needed fact/dimension format.

Thanks!
Dan



Post #1090105
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse