Consider the Report Writers When Designing Applications

Something I learned early on in the world of IT and programming.

People spent a lot of time up front designing the web application and designing the database.

And then the system goes live.

And whoops, we forgot about the reports.

"Here Mr. Report man, figure out how to get the data out of the database."

Oh by the way, the requirement is to merge our data with all the other data in the company.

Except we didn't think it through well enough to put hooks into the database to allow for this.

So we'll just throw it over the fence and let you figure it out.

And there you have the world of reporting, at least from what I've seen.

It would be great if the people designing the system considered the report writers in architecture and design by looking at the entire ecosystem.

Databases used to exist in silos.

And we paid high priced consultants to converge the data into a Data Warehouse.

Which was rigid, slow and costly with steep upfront costs, software costs and maintenance costs.

We really need to think things through about how the data will be handled downstream.

With tools like Tabular Model and Power Pivot, we can now easily mash data across distant data sets.

However, without a "hook" on common fields, this is still a difficult task.

So going forward, include the lowly report people into your design sessions.

It will save time downstream and the insight obtained will be invaluable.

Not sure if the application people have realized the transition, but the lowly report writer has always had a direct link to the top executives to get the data out of the database.

More so now trying to get ROI and insights.

The org can easily outsource the front end programming and even the database maintenance and support.

Except Data Engineers / Report Writers / Data Scientist will still have jobs long after you've been outsourced.

So get with the program and play nice.

And that's about it!