Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

17.3. Summary

This has been a fairly short journey. However, we've covered the main points required to provide effective reporting. Reports will be identified throughout the lifecycle and it is therefore good to be prepared for this. Maintaining the right level of information in the application (or the architecture) will help reduce the amount of "additional" work that's required when implementing reports.

The following are the key points to take away from this chapter:

• Include lookup tables in the data model. The data in the database should be self-describing. Reports are much more meaningful when they contain decode values.

• Record dates and times. It is important to record dates and times in the database so that reports can be generated based on these values. Reports often include data "over time" for trend reporting.

• Maintain transaction counts. You should think about how the application can record transaction counts, such as failed login attempts so that reports can be generated against these values.

• Consider "Active" vs. "Passive" processing. Active processes are good candidates for writing information to the database as they are already writing to it. Passive processes are good candidates for updating performance counters because they are not specifically writing to the database.

• Define the master data set. It is important that the reports are based on a single set of master data. The master data set needs to be defined clearly to avoid potentially conflicting information.