Every organization I've worked at has reporting needs. To be more specific, data-reporting needs.

Systems exist. People want to see the information in those systems in specific ways so that they can ultimately make decisions based on the data.

When I worked in government (2001 - 2010), I went out of my way to evangelize the basic capabilities of software systems to executives who did not understand the "technical" aspects of the systems that supported their operations.

Basic things like databases, tables, fields, queries, and joins. User interface vs. backend. The If data is in a system, we can get it out always got a rouse from the audience and seemed to be a lightbulb moment for many execs who had a different understanding based on their experiences with IT staff. Many would proclaim that they had systems where getting at data was not possible. I could never validate this proclamation. Even in legacy mainframes, I found ways to CRUD (Create, Read, Update, Delete) data programatically.

More Recently

Fortunately, I no longer have to espouse such basic capabilities to public leaders, as the industry, talent, and tools have mostly evolved to a point where data-reporting is common functionality and common knowledge.

But, I have been working on data-reporting needs in more complex domains. I started my career writing financial reports for a County's financial system (or ERP). This type of reporting was mostly after-the-fact. "How much did we spend this month?" "What is our budget for the next quarter?" "What is the balance of X Grant or Purchase Order?" These are trailing metrics. This data doesn't tell you what to do, rather it tells you what you have done.

I moved on to writing dozens of bespoke scripts to monitor a school's systems and infrastructure. Here, I started to move beyond trailing metrics and began experimenting with actionable scripts. For example, the school's antivirus software would report a list of infected files, along with a button that would quarantine the files. So, even though the report of the files was after-the-fact, the results were immediately and easily actionable.

Primitives

I've seen dozens of tools and technologies that comprise a data-reporting stack. They vary greatly in size, quality, and usability.

And, surveying the many options, what stands out to me is the similarities in approaches. The commonalities these tools share. It got me thinking about the primitives of data-reporting.

• Data sources - a system, a database table
  • Table = Object
  • Fields = Attributes
  • attributes change State over time
  • triggers that fire when an attribute changes
  • Relationships eg: joins
  • also, relationships to Business Processes (workflows)

In a simple situation, the result of this query to the Model layer is some type of primitive data structure; either an Array of records, or a Hashed object with a records array.

In a more complex situation, additional transforms or lookups may be performed on joined data. Examples: populating a geocode field based on a text address, or creating historical trend data based on transactional data (think: daily, weekly, monthly totals).

This data object is what should be passed along to the view layer.

So, from a data standpoint, we should be able to rely on a standard data structure to model the data. This puts us in a good situation where we can have a front-end that has a small bit of intelligence to digest such data objects and project it into various views.