Fundamental Benefit of Model Driven Reporting
I have used the term "model-based reporting". Someone else uses the term "model-driven reporting". The graphic below shows the benefits of modern model-based or model-driven reporting as contrast to traditional presentation-based reporting:
- The presentation oriented software application has an excellent understanding of the presentation information; but no understanding of the meaning of the information within the presentation.
- Therefore, (a) the software cannot really help the software user work with the information other than organize the presentation and (b) down stream processes cannot parse the presentation information reliably.
- It is difficult to take one presentation and convert that presentation into some other presentation format.
- You are dealing with "strings", and not "things". String based reasoning only goes so far.
- To understand model-based or model-driven reporting, you first have to see it work within a specialized application build for that specific purpose.
- The model-based or model-driven software application does, in fact, have the capability to read, interpret, and understand the model and information reported per that model at both the level of the model/report and also at the level of the information conveyed within the report.
- Down stream processes can reliably use the report information. Why? Software can reliably get at all the information in the report reliably.
- It is trivial to convert report information and model from one technical format to other technical formats because you are working with the logic of the report and you can work with the report information at an appropriate level.
- You are dealing with "things" (as opposed to strings). Semantic reasoners can therefore be leveraged.
- Entirely new capabilities can be created that leverage the "model" nature of these reports. One example is a system such as "Git" for not computer code, but for financial reports.
There are two possible downsides to model-based or model-driven reporting. The first is that you need that specialized software that understands the model and enables subject matter experts (SMEs) to work with the report model and report at that logical level and the machine-readable metadata that drives that software. General tools are far too technical for the average business professional to make effective use of. The second downside, which may really not be a downside at all, is that to convert the machine-readable technical format into a format readable by humans, you might not be able to get the exact "pixel perfect" human readable report format that you want WITHOUT doing one additional step which is to map the report information into a document format that gives you precisely the human readable representation you want. That "mapping" is more work, but might be worth it if you need a pixel perfect representation. Alternatively, you could be given a style sheet and then simply configure the human readable representation you want by setting rendering parameters. I guess this all depends on what your definition of a "good enough" rendering looks like. An auto-generated rendering can get the job done, but the result might not be to your satisfaction. The more configuring that is provided, the more complicated the configuration process becomes. Mapping is not a game stopper, but it is additional work.
Effectively, a "model-based" or "model-driven" report is modern spreadsheet or a powerful knowledge graph. To understand this in more detail, please read the Overview of the Seattle Method.
Additional Information:
Comments
Post a Comment