Data Warehouse Development: Version 0

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by Andy Leonard » Data Warehouse Development: Version 0

25 posts, Page 1 of 3

1 2 3 »»»

Data Warehouse Development: Version 0

Rate Topic

Display Mode

Topic Options

Author

Message

Andy Leonard

Posted Thursday, April 07, 2011 12:01 AM

Old Hand

Group: General Forum Members
Last Login: Yesterday @ 12:35 PM
Points: 376, Visits: 953

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

Chris Houghton

Posted Thursday, April 07, 2011 1:59 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, June 06, 2013 5:57 AM
Points: 557, Visits: 1,365

An interesting article for a Data Warehouse newb. I'm very much looking forward to reading the follow up articles in this series. Thanks. Smile

Post #1089714

Jason-299789

Posted Thursday, April 07, 2011 5:03 AM

SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 10:57 AM
Points: 838, Visits: 2,200

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

Gopi S

Posted Thursday, April 07, 2011 6:52 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Sunday, June 02, 2013 3:31 AM
Points: 151, Visits: 278

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

Martin Mason

Posted Thursday, April 07, 2011 7:01 AM

Grasshopper

Group: General Forum Members
Last Login: Wednesday, January 23, 2013 7:07 AM
Points: 13, Visits: 96

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

jmonk 57451

Posted Thursday, April 07, 2011 8:16 AM

SSC 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

SQLPhil

Posted Thursday, April 07, 2011 8:23 AM

Ten Centuries

Group: General Forum Members
Last Login: Wednesday, June 12, 2013 11:35 PM
Points: 1,413, Visits: 663

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

Joshua M Perry

Posted Thursday, April 07, 2011 9:56 AM

Old Hand

Group: General Forum Members
Last Login: Monday, June 17, 2013 4:30 PM
Points: 388, Visits: 419

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.kerry.com

Post #1090020

Eric M Russell

Posted Thursday, April 07, 2011 10:05 AM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 2:09 PM
Points: 1,185, Visits: 3,420

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.

"Winter Is Coming"

Post #1090037

dan-16162

Posted Thursday, April 07, 2011 11:37 AM

SSC Eights!

Group: General Forum Members
Last Login: Monday, January 14, 2013 12:49 PM
Points: 855, Visits: 91

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 »

25 posts, Page 1 of 3

1 2 3 »»»

Permissions