jason w. jones

software from the trenches

What Is Hyperion?

For almost twenty years, this site was called jason’s hyperion blog. If you worked with the software, that name probably told you roughly what to expect. If you did not, it required some explanation.

Hyperion was a software company, a brand, and the name attached to a collection of business applications. In the part of that world where I spent most of my time, it also became shorthand for Essbase, a multidimensional database used to analyze business information, and for applications such as Hyperion Planning that used it. Those meanings overlapped in conversation, even though the products were distinct.1

My own introduction came through QFC, where I had started working in 1999, in one of the smallest stores in Kroger’s smallest division. In 2005, I was promoted to the regional office in Bellevue. The previous Essbase guy had abruptly quit, and I became the new Essbase guy. The assignment amounted to: go figure it out.

I knew Excel as part of the Office suite, but I was hardly a formula wizard. Apparently, someone decided that a guy who had been stocking grocery shelves could figure out a multidimensional database. They sent me to Santa Clara, California, for a week of Hyperion Bootcamp—my first flight for work.

Since then, I have worked with Essbase as a user, consultant, developer, and software vendor. Today I am CTO of Applied OLAP. My perspective on Hyperion comes from that particular corner of the industry, and especially from the people who used it to understand their businesses.

Occasionally I would meet one of those people outside work and outside the annual conference. A conversation about what we did for a living would lead to finance or software, and eventually I might mention Essbase or Hyperion. Sometimes the other person would recognize the name immediately. They used it too.

Usually, what they meant was the Excel add-in.

What I enjoyed was their enthusiasm. Here was someone outside the usual professional circles who knew this fairly specialized software and had something good to say about it. They understood what made it useful because they worked with it themselves. For them, Hyperion meant something they could do in a spreadsheet.

Hyperion in Excel

The Excel experience was, to me, the heart and soul of the system. Essbase supplied the analytic engine, while the add-in put that engine within reach of people who were already comfortable working in Excel.

The classic client, documented as the Essbase Spreadsheet Add-in, provided commands to retrieve data, expand or collapse a view, retain particular members, and move dimensions between rows and columns.2 A user could explore a business model from the worksheet, changing the question as the answers suggested something else worth investigating.

The kinds of questions I associate with that experience come from the grocery business. What were produce sales by day at a particular North Seattle QFC? How did the picture change across stores or districts? What was the average hourly rate for a store, for a district, or over a different period?

Each question involves familiar business concepts: stores, departments, measures, and time. A multidimensional model organizes information around dimensions like these. With the appropriate data and business logic in place, users can examine different combinations without having to specify a new report from the beginning every time.

The combinations matter. A quarterly district total may prompt a question about individual stores. A store’s result may prompt a comparison between departments or a closer look at particular days. The next useful question often becomes apparent only after seeing the first answer.

Relational databases can answer aggregated questions too. There is nothing exclusive to a cube about grouping sales by department or calculating a measure over a period. What stood out to me was how accessible that process became through the combination of the model and the spreadsheet interface. The business user could keep asking questions in a familiar environment.

You could ad hoc it again

People called this ad hoc analysis. I remember being amused by how readily the expression became a verb, usually written as one word. You could “adhoc” something. I eventually looked up the expression myself, curious about the language we had all adopted.

It was a good description of the way people worked. They needed an answer for a particular purpose, and they could put together a view to get it.

The contrast I have in mind is the more formal reporting process: define the request, explain it to someone who can produce the report, wait for the work, and then review the result. That process has its place, particularly when a report needs a consistent definition and presentation. But it introduces friction when you are still figuring out which question to ask.

Ad hoc analysis made room for that uncertainty. You could start with one view, discover that it was not quite what you needed, and adjust it. There was less reason to decide every detail before looking at the data.

It also changed how precious the result needed to be. A report that takes considerable effort to produce is something you save, print, turn into a PDF, or email around. You want to preserve the work that went into obtaining it.

An ad hoc retrieval could be much more temporary. You could get the answer, use it, and close the spreadsheet. If you needed it again, you could ad hoc it again.

I see a parallel with some of today’s AI-assisted workflows. When producing something useful becomes easier, you can afford to make it for a narrow purpose and move on. The comparison is about the effort involved in obtaining an answer, rather than the underlying technology. In the Hyperion world I knew, that freedom was part of what made the experience feel almost magical.

One name and several products

The corporate history helps explain why the terminology became complicated. Essbase came from Arbor Software. In 1998, Arbor and Hyperion Software combined under the Hyperion Solutions name; Hyperion’s later filings describe the transaction as Arbor acquiring Hyperion Software. Oracle acquired Hyperion in 2007.3

That history left the Hyperion name attached to both an analytic platform and packaged applications. Hyperion Planning, for example, was described in the company’s 2002 filing as a budgeting, planning, and forecasting application built on Essbase XTD.1

The formal names could become elaborate: Hyperion Essbase XTD Platform Services and Essbase XTD Administration Services are two examples.10 XTD presumably meant “extended.” The product names certainly were. In everyday conversation, people around me generally continued to say Essbase or Hyperion.

I wish I had a photograph of my old desk. The printed manual for the version 7.0 software occupied four binders; the fourth was the index alone. Beside them was a small wooden box in which Temtec Executive Viewer had been delivered, an application I remember costing $30,000. It was another time.

In my experience, “Hyperion” could therefore mean different things depending on who was speaking. One person meant the cube they queried from Excel. Another meant the Planning application used for budgeting. An administrator or developer might be thinking about a broader installation and its supporting components.

System 9 made that broader vocabulary particularly memorable to me. The product names included Planning, BI+ Analytic Services, and Shared Services.4 I remember HSS, Hyperion Shared Services, becoming part of the language around the platform. The name could encompass considerably more than the piece a finance user saw in Excel.

Those distinctions matter when explaining the software. They were easier to overlook in an ordinary conversation where both people already knew which part of the system they used. The old blog title worked in much the same way: it located the site within a recognizable community without spelling out every product covered by it.

Names that survived

Some people who had been around longer than I had still called it Arbor. That name belonged mostly to the period before I started, but traces of it remained in the software. Hyperion left similar traces, including in interfaces used long after Oracle’s acquisition.

The Hyperion name also remains in some product names, including Oracle Hyperion Planning in Oracle’s on-premises documentation.5 For developers and administrators, the history turns up in some more practical places:

Name that survived Where it appears A trace of the history
ARBORPATH Essbase environment-variable settings in Oracle-era documentation The Arbor name remained in the configuration vocabulary.9
com.hyperion.css A Java package identified in Shared Services documentation Developers implementing custom authentication encounter Hyperion in the code’s namespace.7
/HyperionPlanning/rest/ The documented Planning REST API in Oracle Cloud EPM Even a cloud request can carry the old product name, capital H and P included.6

These details appeal to me because they connect different periods of the software’s life. A product’s presentation can change while an interface continues to carry a familiar name. The spelling alone does not explain the decisions behind its retention, but it makes the history visible.

The spreadsheet experience continues as well. Oracle Smart View for Office connects Excel and other Office applications to on-premises and Cloud EPM data sources. Smart View and the original Essbase Spreadsheet Add-in are distinct tools; Oracle has documented how they can coexist.8 I also remember considerable resistance to Smart View from users who found it slower than the classic add-in. That transition deserves a closer account of its own. The continuity that interests me here is the ability to work with business information from within Excel.

When I think about what Hyperion meant, I come back to those occasional conversations with finance users. They were pleased to meet someone who knew the software, and I was pleased to hear what it meant to them.

The name on the blog referred to a company and a collection of technologies. It also referred to that shared experience: being able to ask a business question, explore the answer, and ask another one without leaving the spreadsheet. That is the part of Hyperion I remember most fondly.

If you have memories of working with Arbor, Essbase, or Hyperion, I would love to hear them. Old screenshots, photographs, manuals, and stories about the people and tools are welcome too. Please get in touch. And if you still have one of those wooden Executive Viewer boxes, I would particularly like to see a photograph.

Notes and sources

  1. Hyperion Solutions, Form 10-K for the fiscal year ended June 30, 2002, Item 1, General and Business Performance Management Applications. Distinguishes the platform and applications and describes Planning’s use of Essbase XTD. ↩ ↩
  2. Oracle, Essbase Command Summary, Spreadsheet Add-in documentation, 11.1.2.2 library. Retrieve, Zoom In, Zoom Out, Keep Only, and Pivot entries. ↩
  3. Hyperion Solutions, 2002 Form 10-K, Item 1, General; Oracle, Form 8-K reporting acquisition completion on April 19, 2007, Item 2.01. ↩
  4. Oracle, Supported Platforms Matrices, Release 9.2 product labels. ↩
  5. Oracle, EPM System 11.2 Planning and Profitability documentation, Planning guide titles. ↩
  6. Oracle, Get REST API Versions for Planning, REST Resource. ↩
  7. Oracle, Security Configuration Guide 11.2, Prerequisites, CSSCustomAuthenticationIF and com.hyperion.css. ↩
  8. Oracle, Smart View for Office documentation library; Smart View and Spreadsheet Add-in, User’s Guide 25.200. Mutable documentation accessed November 1, 2026; current technical references in notes 4–7 were also accessed that day. ↩
  9. Oracle, Setting Environment Variables, Essbase documentation in the epm.1112 library. Lists ARBORPATH and example settings; accessed November 1, 2026. ↩
  10. Hyperion Solutions, 2003 Form 10-K, Item 1, p. 7; Hyperion, Essbase XTD Administration Services Release 6.5.3 Start Here, archived on IBM’s site. ↩