From Ledgers to Intelligence Part 1: Before the Dashboard Decision Support Systems and the Origins of Business Intelligence

Digital Transformation | May 2026

Before there were dashboards, before there were data warehouses, before there was even the word “analytics” applied to business data there was the ledger. Double-entry bookkeeping, invented in fifteenth-century Venice, was humanity’s first systematic attempt to capture operational data in a structured, queryable form. The ledger was a database. The year-end balance sheet was a report. The merchant reviewing it was performing what we would today call business intelligence.

The gap between that merchant and the modern data analyst spans five centuries but the most dramatic transformation happened in the sixty years between 1960 and 2020. This series traces that transformation in full: from mainframe batch jobs to autonomous AI-driven pipelines, from printed reports to natural-language dashboards, from the silo to the mesh. We begin at the beginning: the era before the dashboard existed.

The Mainframe Era: Computing as Batch Processing

In the 1960s, computing meant mainframes. IBM dominated the market with its System/360 family, introduced in 1964 a watershed moment that established the concept of a compatible family of computers spanning a range of price and performance. These machines were expensive, physically enormous, and shared across entire organisations. They were operated by specialist staff and programmed in assembly language or, increasingly, in COBOL.

COBOL the Common Business-Oriented Language, standardised in 1960 was specifically designed for business data processing. It could read records from sequential files on magnetic tape, perform arithmetic operations, and write formatted output. This was, in essence, the first ETL (Extract-Transform-Load) workflow: data was extracted from operational records (purchase orders, sales invoices, payroll transactions), transformed through calculation, and loaded into printed output the report.

The defining characteristic of this era was batch processing. Data was not processed in real time. Transactions accumulated during the business day and were processed in a single overnight run the “batch window.” The sales report you received on Tuesday morning reflected Monday’s transactions, which had been processed between midnight and 5 AM. The idea of querying live operational data was not merely technically difficult; it was architecturally inconceivable.

Management Information Systems: Formalising the Concept

The academic framing of what computers could do for organisational decision-making emerged in the late 1950s and accelerated through the 1960s. The term “Management Information System” (MIS) was codified during this period, representing the idea that computers could produce structured information not merely processed data that would support management decisions.

The MIS concept was hierarchical. Operational systems processed transactions (order entry, inventory movement, payroll). MIS extracted summaries from those systems and produced standardised reports for middle management: weekly sales summaries, monthly inventory levels, quarterly financial statements. The flow was strictly top-down: data went up the hierarchy in the form of pre-defined reports; decisions came back down.

The limitation was inflexibility. If a manager needed to know something that was not captured in an existing report, they submitted a request to the IT department. The IT department estimated the development effort typically weeks wrote COBOL programs to extract and summarise the relevant data, tested the output, and delivered a new report. By the time the report was ready, the business question was often moot.

Decision Support Systems: The First Revolution

The intellectual challenge to the MIS orthodoxy came from MIT’s Sloan School of Management. In 1971, G. Anthony Gorry and Michael Scott Morton published a landmark paper “A Framework for Management Information Systems” that drew a crucial distinction between structured decisions (routine, rules-based, delegatable to MIS) and unstructured decisions (novel, complex, requiring human judgment). They argued that computerised systems had only addressed the first category and proposed a new class of systems Decision Support Systems (DSS) designed to assist with the second.

A DSS was interactive. Rather than producing pre-defined reports, it allowed managers to interrogate data through a conversational interface posing “what if” questions, running sensitivity analyses, exploring scenarios. The first DSS implementations were modest by later standards standalone minicomputer applications with hardcoded models but the conceptual breakthrough was profound. Data was not just a record of what had happened; it was a resource for exploring what might happen.

Peter Keen and Michael Scott Morton formalised the DSS concept further in their 1978 book Decision Support Systems: An Organisational Perspective, which remained the defining reference for a decade. They emphasised that the value of a DSS lay not in its technical architecture but in its ability to extend a decision-maker’s analytical capacity without replacing their judgment.

Executive Information Systems: Data for the C-Suite

By the mid-1980s, a variant of the DSS concept had emerged specifically targeting senior executives: the Executive Information System (EIS). EIS products such as Comshare’s Commander and Pilot Software’s Command Center offered graphical interfaces unusual for the time that presented key performance indicators in a format accessible to non-technical users. The EIS was the direct ancestor of the modern executive dashboard.

EIS deployments faced a fundamental problem that would persist for decades: data quality. The metrics displayed in an EIS were only as reliable as the operational systems feeding them. When two systems reported different figures for the same KPI a chronic problem in organisations that had grown through acquisition or organic expansion the EIS merely made the inconsistency visible at the board level rather than resolving it. The “single version of the truth” became an aspiration that organisations would chase for the next forty years.

Edgar Codd and the Relational Foundation

The technical foundation for all subsequent analytical systems was laid in 1970 when Edgar F. Codd, a mathematician working for IBM, published “A Relational Model of Data for Large Shared Data Banks” in the Communications of the ACM. Codd’s relational model organising data into tables with rows and columns, related through shared keys was initially resisted by IBM’s commercial division, which had substantial investments in hierarchical and network database products. It was instead implemented by competitors: Oracle (then Relational Software Inc.) in 1977 and IBM’s own DB2 in 1983.

The relational model did not immediately transform analytics, but it established the conceptual vocabulary tables, joins, queries that underpins every database system in use today. SQL, the query language derived from Codd’s relational algebra, would eventually become the universal language of data analytics.

The Architecture of the Era

The data architecture of the 1960s–1980s was defined by its physical constraints. Data resided on magnetic tape stored in sequential format to retrieve record 10,000, you read records 1 through 9,999 first. Random access disk storage existed but was expensive and limited in capacity. The batch architecture was not a design choice; it was an economic necessity.

Data silos were structural, not accidental. Each functional department finance, operations, sales operated its own dedicated applications on separate hardware or partitioned mainframe capacity. Integrating data across silos required physical data exchange: a weekly tape exchange between systems, a monthly reconciliation procedure performed by the accounting department, a quarterly management report assembled from multiple sources by a team of analysts.

The people performing this integration were the original data professionals: management accountants who reconciled figures, operations analysts who consolidated production reports, financial analysts who built models in primitive spreadsheet tools. Their work was manual, laborious, and irreplaceable. When they left, the institutional knowledge of how the numbers fitted together left with them.

What This Era Got Right

It is easy, in retrospect, to characterise the mainframe era as primitive. It was not. It established principles that remain valid: data should be structured, decisions should be evidence-based, and the role of computing is to amplify human analytical capacity rather than replace it. The batch processing model, for all its latency, was reliable and auditable in ways that later distributed systems would struggle to replicate.

The DSS concept, in particular, anticipated nearly everything that followed. The tension between structured (repeatable, automated) and unstructured (novel, human-assisted) decision-making is not a solved problem in 2026; it is the central preoccupation of AI-augmented analytics. Gorry and Scott Morton identified the right question in 1971. The next fifty years of data architecture was the engineering community’s extended attempt to answer it.

---

References

1. Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6), 377–387.
2. Gorry, G. A. & Scott Morton, M. S. (1971). A Framework for Management Information Systems. Sloan Management Review, 13(1), 55–70.
3. Keen, P. G. W. & Scott Morton, M. S. (1978). Decision Support Systems: An Organisational Perspective. Addison-Wesley.
4. IBM Corporation (1964). IBM System/360 Principles of Operation. IBM Form A22-6821.
5. Martin, J. (1976). Principles of Data-Base Management. Prentice-Hall.
6. Rockart, J. F. (1979). Chief executives define their own data needs. Harvard Business Review, 57(2), 81–93.
7. Dresner, H. (1989). Business Intelligence: A term coined by Howard Dresner at Gartner Research.