Before AI and the Data Intelligence Layer
How Oracle Data Browser in the early 90s paved the path to the modern era
AI and the data intelligence layer that powers it are hot topics right now in tech. However, many of the patterns that exist today were visible back over 30 years ago when I was at Oracle. Just as a previous post explored how Latitude’s data-enabled voice conferencing in the 1990s was a precursor to the web conferences we do today with Zoom, I wanted to examine how our work at Oracle in the early 1990s established key foundational principles behind AI and the data intelligence layer: access on preferred end-user platforms, SQL abstraction, and interactive data exploration.
Democratizing Data Access
For context, my role at Oracle from 1990-1993 was product manager for "decision support systems." This term sounds quaint now, but it represented a critical idea: enabling business analysts to explore data and make decisions without programming skills.
This wasn't just about building tools. It was about fundamentally changing who could access organizational data. Before this era, data analysis required either SQL expertise or lengthy requests to IT departments. We were building the bridge between databases and business users.
Oracle Data Browser: The Breakthrough Product
Among my portfolio of one new product and three legacy ones, Oracle Data Browser was the game-changer. It offered a new graphical user interface (GUI) front-end to Oracle data. We developed the base code on Sun-4 workstations using native X Windows, then ported it across every major GUI platform at the time: Windows, Mac, and various X Windows variants including Open Look and OSF/Motif.
This portability across multiple client platforms was strategic. On the server side, a key tenet to Oracle’s strategy was its ability to run software across a variety of operating systems and network protocols. As such, Oracle chose to invest in portability on the client side, investing in a technology called Oracle Toolkit, which would provide the necessary software abstraction across different GUI environments. Oracle Data Browser was the first of many Oracle client products to ship on this Oracle Toolkit technology.
The timing was ripe for change. I joined Oracle in 1990 when VMS led our revenue. By 1993 when I left, UNIX servers dominated, driven by client/server architectures and TCP/IP networking. Outside of Oracle, Microsoft Windows 3.0 came out in 1990 and Microsoft Windows 3.1 came out in 1992.
(I wrote before about a demo disk from 1992 for Oracle Data Browser for Windows that I found in a box of old stuff. I’ve uploaded a video of it running on auto-play to YouTube, and I remain amazed at how much could fit on a 1.44MB 3.5” floppy disk back then! I’ve also included screenshots from this demo disk in this post.)
Three Foundational Innovations
1. End user access on a preferred platform
The shift to Windows point-and-click interfaces was an important catalyst. Users became comfortable accessing data directly rather than relying on database administrators. Oracle Data Browser capitalized on this by providing the first intuitive graphical interface to Oracle databases.
At the time, Oracle Data Browser had the most successful first year revenue for a product on a single platform (Windows) in Oracle’s history.
2. SQL Abstraction That Actually Worked
While every Oracle employee learned SQL (even new hires went through mandatory training), we recognized this was unrealistic for the broader market. Oracle Data Browser's query builder let users select, filter, and sort data without writing code.
For example, the query below allows an analyst to look at all orders in 1991 greater than $1,000.
We also built in a number of intelligent shortcuts for more complex operations that business analysts requested which would normally require more complex SQL statements to write.
For example, consider the situation where an analyst might want to see orders larger than the average amount of all orders. In this case, the analyst could simply enter a condition AMOUNT > AVG(AMOUNT).
In SQL, this would have required a subquery. (If you don’t know SQL, you can skip this!)
SELECT SALES_OFFICE, SALES_REP, ORDER_DATE, NAME AS "Customer", AMOUNT
FROM CUSTOMER_INFO, ORDER_PRICING
WHERE ORDER_PRICING.CUSTOMER_ID = CUSTOMER_INFO.CUSTOMER_ID
AND ORDER_DATE BETWEEN TO_DATE('01-JAN-91', 'DD-MON-YY') AND TO_DATE('31-DEC-91', 'DD-MON-YY')
AND AMOUNT > (SELECT AVG(AMOUNT)FROM ORDER_PRICING);
Extending on this example, analysts could also easily filter to only see orders greater than the average for the office that it was placed. In this case, the analyst could simply modify the condition to include the column SALES_OFFICE in the expression like this: AMOUNT > AVG(AMOUNT, SALES_OFFICE).
In SQL, this would have required a correlated subquery. (If you don’t know SQL, you can skip this!)
SELECT SALES_OFFICE, SALES_REP, a.ORDER_DATE, NAME AS "Customer", a.AMOUNT
FROM CUSTOMER_INFO, ORDER_PRICING a
WHERE a.CUSTOMER_ID = CUSTOMER_INFO.CUSTOMER_ID
AND a.ORDER_DATE BETWEEN TO_DATE('01-JAN-91', 'DD-MON-YY') AND TO_DATE('31-DEC-91', 'DD-MON-YY')
AND a.AMOUNT > (SELECT AVG(b.AMOUNT) FROM ORDER_PRICING b
WHERE a.SALES_OFFICE = b.SALES_OFFICE);
These were simple examples, but they are illustrative of the types of operations that require machinations in SQL that are unfamiliar to most business analysts.
3. Interactive Data Exploration
The breakthrough was our Results window's interactivity. Users didn't just retrieve data. They could refine queries by manipulating the results themselves. For example, they could remove a column to "roll up" summary data.
Here is an example of a summary where the orders are grouped by sales representatives.
By simply removing the sales representative column from the results window, the sums would just roll up interactively by the sales office instead.
Users could dynamically link results to Excel via DDE (Dynamic Data Exchange) for real-time spreadsheet updates by copying to the clipboard and using Paste Link from Excel.
Once linked, updates to the query results window would automatically be reflected in the spreadsheets and graphs that referenced them.
This approach of manipulating data directly from a Results window offered a significant departure from past workflows where users had to spend time specifying query requests of database administrators, analyze reports, and then spend time specifying query modifications. With the ability to interact directly with the data, there were new ways to work with and explore the data in real-time.
Why It Mattered: Then And Now
Oracle Data Browser didn't fail; it evolved. The progression from our decision support systems to Executive Information Systems (BusinessObjects, Cognos) to modern Business Intelligence tools (Tableau, Microsoft Power BI) to today's data intelligence platforms (Databricks, Snowflake) follows a clear lineage.
The core requirements remain unchanged:
Platform: Running where users work
SQL abstraction: Hiding complexity without limiting capability
Interactive exploration: Enabling discovery, not just reporting
What we built in the early 1990s established the template for every successful data tool since: meet users on their preferred platforms, hide technical complexity without sacrificing power, and make data exploration feel like conversation rather than interrogation.
Looking forward
At a personal level, I remain grateful for being part of this industry in the early days, as many of the problems we faced with our customers at Oracle are ones that informed the rest of my career in tech. I went on to do other things in tech outside of data access, including scanners, conferencing, cybersecurity, and several other tech fields that I haven’t written about yet on this Substack. That said, being a part of the world of data access taught me about how ongoing advances made on the technology side don’t solve problems we have on the human side.
For data access even today, we still face problems with data security, as we always have to balance the desire for self-service with the need for governance. We still face problems with siloed data, as data fragmentation can still exist with organizational and governance boundaries, even when technical integrations are possible. And there still remains a communication problem about what the data really means across different user communities, sometimes at the level of business context all the way down to what data means at the individual data field level.
To sum this up, I find the lessons of Oracle Data Browser from over 30 years ago still relevant today!