Reporting Driven Data Design

By on May 17, 2009

kick it on DotNetKicks.com
We were well along in the development of Gibraltar before we started designing the reporting system and the reports within it.  I’ve made that mistake before; this time the challenge was we didn’t originally intend to have a reporting system but customer feedback from our early betas showed that it was going to make a difference.  Having been to this rodeo twice before, we were very careful in selecting the right reporting system to integrate and in designing the integration so we could easily add new reports, new data sources for reports, and customize reports for clients.  It was moving along pretty well until the first internal demonstration of the reporting system.

funny-graphs-whamDuring the demo, it became clear once we got beyond the excitement of print-ready documents showing within the application there was a bigger issue:  The data that our customers would really want to have took too long to calculate every time the report ran.  We were going to have to change the data model.  Not only that, but the data we needed wasn’t readily available; we were going to have to introduce an analysis engine into our architecture to derive the data we needed from what we were actually collecting.

Fortunately, after consulting with our beta customers we determined that we could make some breaking changes in our data format.  Still, it was a lot more expensive than it had to be.  That got us thinking again:  If you really want to be sure your data format has everything it needs, you need to focus not just on the tactical data collection that you interact with every day but the strategic reporting that drives value for the higher end user.

Much of development is focused on tactical requirements:  What has to be on this screen, what data do you need to have for a specific calculation…  What’s easy to miss is the strategic level:  If you know all of these things, what higher level insight can you get?  Usually you’ll start down this path and discover there’s a lot you could do from the data you have, but then some subtle new requirements emerge – to make things line up you need relationships you aren’t tracking, or slightly more data in certain areas.

So on your next project, put the reports up front in the design as a practical tool to test the model.  It’s a good bet that if you can feed the reports everything they need, you’ve got all the data in your model.  Additionally, your attention to the strategic value you can add for your users may win you a new set of fans higher up the management chain than you would have otherwise.
kick it on DotNetKicks.com

Categories : Data, Development

Leave a Comment