Cubegeek

Deep Variances in Essbase

(from the archives - Fall 1996)

In my travels, I have just come upon a neat trick. I've never seen it posted anywhere and it solves a problem I remember being unable to solve a few years ago.

Consider a simple model with a geographic dimension 5 levels deep, a measures dimension of sales, and a scenario dimension with actual, plan and variance. How can I get the model to indicate 'deep variances' without having to drill down to them if my high level variances are within spec?

Create 'red flag' and '%red flags' in the scenario dimension.

Let's say that I have a 10% absolute value variance tolerance set.

The member formula for redflag would be

if (@abs(variance%>=10)
    redflag = 1;
else
    redflag = 0;
endif

Create a 'neutral flag' member in the variance dimension and hardcode the member formula to be 1;

redflag% = redflag % neutralflag; (two pass)

geo	actual	plan	variance	variance%	redflag	redflag%
NY	100	115	(15)	(15%)	1	100%
NJ	100	97	3	3%	0	0%
CT	100	85	15	15%	1	100%
East	300	297	3	1%	2	67%

Notice that even though your high level variance is only 1%, 67% of your lower level forecasts are out of bounds with two red flags.

simple, neat.

Beyond BI

This is my blog, but it's also a kind of unofficial blog for Full360. Very interesting things are going on.

About a year ago, at a hotel room in the Venetian Hotel, we began a discussion about what we wanted to build into the Full360 elasticBI platform. We have been very successful. This year, we've had more time and people put into that process and in consideration of what we want, what our customers have had us build and what's happening in the market, we have a very different outlook than just a year ago.

It's really time to say that BI is just a part of what we're all about. It's a big part, but..

I think the simplest way to understand is to know that we have responsibility to funnel information to executive decision makers. That means, as systems integrators, we get to know a lot about all of the different kinds of source data in enterprise data flows. We have made it our business to re-architect enterprise paradigms to the AWS cloud. Our success in understanding and implementing that has far reaching consequences for what we can do, and therefore who we are.

This year at AWS Re:Invent, Amazon introduced several groundbreaking products, not the least of which is their new BI tool, QuickSight. As we have been talking to people and prospects, we've heard them say 'slice and dice, bar chart blah blah blah', and we get that. So we've always said that we are the cloud architects on the back end, which we are. We thought that by saying, "We are next-generation data warehouse', that it would be quite enough to distinguish us. It does but only when you start looking closely at the technology and what we're doing with it. I'll fill you in on that later. The point here is that our DWAAS platform and methodology is forcing us to invent new terms that the market can understand. I am continuing that responsibility. Fingers crossed. 

Our experience is that we have been two steps in front of Amazon and four steps in front of the industry. This year we are only one step in front of Amazon and expect that they will start formalizing products around technology integrations we have done next year. What is that technology integration? Let's call it ETL. We have taken ETL to the next level - higher performance, lower cost. But we haven't launched it as a product, rather made it available as a service. Everything we do is a service in a systems integration and managed services framework. That's how we do business. We are focused on function in the context of the AWS cloud environment and architecture. That's not software you load on servers so much as it is API calls in an highly customized environment configuration. The bottom line is that with the elasticBI Framework we can get data from complex source to high performance destination at a scale and speed unthinkable in traditional architectures.  While I'm on that point let me describe Multi-Tier DW.

Multi-Tier Data Warehousing is what we all our practice of combining multiple data storage and database technologies in a single analytic application.  Imagine this example. A Full360 client has a website that generates 1 million unique customer hits a day from customer interactions. We use our Dragonfly realtime rules engine to score these customers as they use the website and add new attribute data at peak rate of  30,000 REST API transactions per minute. This is powered by VoltDB, our fast data in-memory database partner. This data is staged into a multi-node Vertica cluster that integrates internal financial data and industry benchmark data purchased from a third party. Additionally we have added custom widgets to the website to capture additional data. It is made immediately available through our custom IOS app to mobile employees around the globe. History is automatically archived to S3 for low cost high availability and then efficiently batch loaded into Amazon Redshift to process billion row queries on demand. We serve this data on one or more of our BI partner tools, perhaps Tableau, perhaps TIBCO Spotfire, perhaps Jaspersoft. That's a multi-tier DW solution. 

But notice how we have extended back by providing our own  microservices in our client's website. Notice how we have extended forward into our client's user base with IOS apps. Notice how with Dragonfly we have added a new dynamic dimension of data to our client's CRM. Now we could stop there and say, as a systems integrator we have demonstrated a larger aegis of control. We could stop there and say by employing in-memory, object-store and column store data management we have evolvled into next-gen Data Warehousing. But that would be incomplete, because we have done more than that. 

So it leaves us with something of a marketing problem. Let's talk about the more.

One of the first operating principals of Full360 was that we are a DevOps company. We have reduced the cycle time of our data management. We can move applications from development to production in a matter of hours. Need to double your database staging mechanisms? Right away, sir! One of the things we do in our standard delivery is employ Cloudwatch to not only monitor server performance (remember everything isn't a server these days) but service performance. So we monitor the latency of the data process and can dynamically scale when necessary. We know when our customer's data sources are choking long before our customers do. 

Another principle is that we will use Open Source and be vendor agnostic using the best technology and best architectures available for our client's projects. Architecturally speaking, nobody holds a candle to AWS. Azure might be worth consideration in a couple years time, but right now we're all about AWS. They are thought leaders as well as innovators. For Full360 that means we incorporate excellent technologies like Hashicorp's Vault, Terraform and Consul, to help secure, configure and communicate in the elasticBI platform.  For our virtualization, we've been using  combinations of Vagrant, Docker, veewee and Virtual Box. For our orchestration we've been using Chef and CloudFormation and Terraform is next. 

This is just the beginning, but I need to keep this blogpost bite sized. I'm going to help you understand in the short term. 

Data Analytics: What I Do All Day

What I do all day is put everything in boxes. I am a compulsive organizer. (Yes I subscribe to Things Organized Neatly) My organized things are data and the boxes are systems. I'm trying to figure out the best way to put all the data into all of the systems, but at the end of the day I'm a tour guide. I help people find the data they want in the systems they can afford. Sometimes the boxes they want are too big, most of the time they don't have enough time or interest, or they find the whole matter too confusing and would rather just guess.

What's interesting is not the techniques and methodologies of building data systems and the attendant analysis. What's most interesting is understanding how it is that people come to understand the data they feel is most important to them. What do people want to know badly enough so that they'll pay me money to organize it for them? You're a sailor, what does a sailor want to know? You're a security guard at the front desk of an office tower, what do you want to know? You're the buyer for oak barrels in a distillery in Kentucky, what do you need to know to do your job better? You're a doctor for a major airline trying to figure out the rate of respiratory infections for flight crews.  You're a car dealer that is thinking about fleet sales. These are all functions of running a business, or any operation that requires some stream of data that changes. A guy like me finds a way to turn a static pile of data consumed just once, into a reliable flow of  information that informs your work over time. 

It still comes down to counting things, figuring out percentages, risks, keeping track of assumptions, proving that numbers tie out in audits. It requires persistence, an obsession for perfection when people would rather be sloppy, a head for logic, and the ability to communicate what it all means. It means keeping track of a million moving parts and using compute & network tools to do so. It means being economical about which tools to use and why. It means listening patiently to people with half an idea. It also means never knowing enough because people are always unsatisfied. 

It's a field that will always be around as long as somebody is building the machines, because people will always want to know something and we've pretty much figured out how to make them trust machines. TV paved the way. People will want to know then they'll change their minds and want to know something else. Human curiosity is not infinite, but it's pretty large.

Barriers to Added Value in Data Analysis

There are also Five Primary Barriers to value add.

NR - Not Relevant
NA - Not Actionable
NS - Not Sufficient
NE - Not Efficient
NI - Not Interested

Imagine, for example, that your automobile has 100 sensors and each sensor creates a datastream of 1GB per mile. That's going to generate BIG data. But what do you really care about when it comes to your car? What you might care about is how many chicks you can pickup. In that case, none of the big data adds value. = NR

You might care about how quickly you can stop in the rain. You have brake sensors and you have wet weather sensors. So you can use your big data to calculate your braking distance in wet or sunny weather. The problem is that you are 500 miles away from anyplace (or anybody) that can install new brakes or tires. = NA

You might care about trunk capacity. You have sensors on all four wheels but they all combine into one number. You can't disambiguate between weight in the front seat from weight in the back seat or shifting weight in the car.  = NS

You might care about gas mileage on steep roads as compared to straight roads. However to get an adequate sample size, you have to drive so many steep roads (and you live in Kansas) that it costs more to find the steep roads and then calculate the savings, (and add sensor 101, an inclinometer), than you could possibly save. = NE.

Notice in all of these, I am talking about what you care about. If you don't care, then you certainly aren't going to pay somebody to care for you. If your answer to all of this is 'so what?', or 'maybe later', then you clearly are not going to add value. This happens more often than you might expect. A BI project might just be seen as something tangential to the business, or as a special gift to the dorks in accounting and IT. 'Buy him an iPad to shut him up'. Such systems do not contribute value. = NI

---
Understand the goals of the business. Find out who has responsibility for what that can be expressed in dollars. Everybody has to know *something* to make the organization work. Determine what the computer can know.

 

The Four Pillars of Business Intelligence

BI - What is it?

BI is business intelligence. It is the art and science of getting computers to know and think in ways humans do not do well, but need to know in order to better run their businesses. It involves the capture, management and presentation of structured data for use by decision makers. These data are usually organized into multidimensional hierarchies of key performance indicators. The aims of Business Intelligence systems are decision support and performance management.

Business Intelligence is my preferred term for this activity because it is the broadest, but various aspects of BI have gone as

• Data Warehousing
• Decision Support
• Analytics
• Big Data
• Data Science

The origins of these practices are found in the lessons of Operations Management in the growth of multinational corporations during the 1960s, 70s and 80s. Some thought leaders that led to the creation of this multidisciplinary field include the following:

• Peter Drucker
• Walter Wriston
• Ralph Kimball
• David Liddle

PECCC

The benchmarks for decision support and performance management are as follows:

• Productivity: Increase output.
• Efficiency: Reduce costs.
• Competence: Add capability.
• Confidence: Improve satisfaction.
• Communication: Deliver consistency.

Business Intelligence systems are all about improving one's ability to know, and helping one assess the impact of the changes made because of that knowledge. It is cyclical, so that new discoveries are added and the consequences of those results are measured as well. Business Intelligence systems enable a framework of iteration to quality and maintenance of compliance.

Application Scope

BI systems include a selection of IT tools, technologies and practices arranged for the delivery of applications. Each application should be implemented as an independent project which is determined by the aegis and impact of the key decision makers for the company's operational goal. One should ask, who is responsible for the execution of X, what do they need to know, how often do they need to know it? A proper BI application delivers actionable data. You cannot manage what you cannot measure. A proper BI application delivers the knowledge necessary to improve a specific area of the business.

The Four Pillars

There are four areas of expertise for a BI practitioner.

• Front End
• Back End
• Governance
• Inference

The Back End - Architecture & Process

Back end work is primarily about data management, and data modeling. There are two primary sort of tools one uses in the back end. The first is an ETL tool. The second is a database. ETL stands for extract, transform and load. It is a tool or a suite of technologies used to identify data sources, gather them up, translate them into a standard format and load them into a database. A database is a tool that has a store of data and gives it a particular structure so that it can be queried in part or in its entirety. The database makes the data 'live'. The way the data in the database is stored is called a model. The most important task a BI practitioner can have is designing a proper data model, because this determines the ease and speed with which the data becomes accessible for many years to come. When data stored in a database is not easily or readily available we call it a 'data jail'. All data that serves no purpose to humans is, relatively speaking in a data jail. The job of a BI practitioner is to free data from that jail so it can be part of productive society.

The Front End - Visualization & User Experience

Front end work is all about presentation. It is the arrangement and display of data to the end user in a compelling, accessible manner so that the meaning of the data can be readily communicated. A front end designer is responsible for the user's experience in navigating and interpreting the data. There are a wide number of graphical tools that are used in front ends. They are generally, tables and charts. But they are also alerts. They can be text, graphics, sounds and multimedia. They can be presented online via desktops and mobile devices or offline to paper reports. They can be delivered interactively or according to schedules. The front end designer must know his audience and insure that users do not become confused or frustrated when accessing data. Data presentation must be precise and crisp and encourage habitual consumption.

Governance - Security & Lifecycle

Governance work is about the meta process of business intelligence delivery. It starts with metadata management by considering the provenance and security of the data over the lifespan of the application. Who is authorized to use this data? Who is authorized to change this data? What are alternative sources of the data and how are they reconciled? How long will the data be live, when and where will it be archived? When and how must it be destroyed. What happens when something changes? Governance also can include resolving questions about the cost of maintaining the application and the scope of technologies used to deliver it with regards to upgrades and deprecations.

Inference - Statistics & Practices

Inference is the term I use to describe 'data science'. This is a new aspect of Business Intelligence that manages the interpretive aspects of data itself. It is necessary because the scale of BI application datasets have grown exponentially. So particular care needs be taken when imputations and complex composite metrics are made over these large sets. For certain metrics, direct interpretation is straightforward. How many cars? "159". For others more care must be taken. How much to people like those cars? "3.5". A BI practitioner in this specialization assures that the data is taken only as seriously as it can be, and helps balance decision makers' instincts and understanding against what the computer system is saying. They must understand the business goals and the application of statistical analysis to management. They must always draw the clear distinction between the map and the territory.

All of these areas of expertise must be engaged for a holistic integration of a BI system into a business process of continuous quality improvement. 

Waterfall Process Mapping

I found this perusing through visualization blogs. This particular method is used generically to measure webpage download performance, but it could measure any number of processes. The 'Waterfall Chart' is a cool way to visualize parallelization bottlenecks, and simple too. I don't know why Excel sorts the chart backwards, but..you'll find it under custom charts as 'Floating Bars'.

Obviously, you can tag each process multidimensionally depending how you want to go through attribute tagging. The metrics for this example is simple. However you could also consider a multistage process as a contiguous stackbar. 

In this example, Process 9 is the bottleneck as no other process can start before it finishes, and the visual clue is very easy to see with this sort by start time. 

To create this data would be simple, given some conversion into UNIX time, or seconds since x, indexed to an arbitary start date of the first process. 

The Five Types of OLAP Calcs

From the old Arbor graveyard, I found some interesting docs that may be of use to people new to the arena.

In OLAP we think about 5 types of calculations:

Aggregations
Matrix Calculations
Cross Dimensional Calculations
OLAP Aware Functions
Procedural Calculations

Aggregations are simply addition. Adding days into weeks, weeks into months, and so on. Or individual customers into customer groups, customer families, customer categories, etc.

Matrix calculations are like what you would do in a spreadsheet, with arbitrarilly complex relationships (+,-,*,/,sum, count, and more) both across the rows and down the columns. Calculations like variance, variance %, total, count, inventory balances, etc for example.

Cross dimensional calculations are like what you would do in linked spreadsheets, or in a multidimensional spreadsheet. In these, calculations can refer to numbers elsewhere in the cube, across difference dimensions or different hierarchies, not just on the same spreadsheet you are sitting on. Calculation examples include product share, market share, etc.

OLAP Aware Functions are like spreadsheet formulas that have been entended to understand OLAP. These include statistics, forecasting functions, financial functions, time calculations. Just like a spreadsheet, most OLAP servers have several hundred OLAP aware formulas provided. For example with a single OLAP Aware function I could calculate a standard deviation, a variance, an interest payment, an NPV, etc across all dimensions. Beyond what a spreadsheet does these functions work across dimensions and understand OLAP concepts like parents, children, ancestors, financial intelligence, time intelligence, etc.

Procedural calculations require a multidimensional calculation language. We call this our calculation script language. For any applications that requires procedural calculations, implementation of business rules within the calculation, arbitrarily complex calculations etc you need this. This is the equivalent of stored prodedure languages in RDBMSs, extending the capabilities of SQL, except in OLAP these languages are all highly specialized and OLAP Aware. Applications include allocations, activity based costing, forecasting, goal seeking, modeling, etc. A relatively large percentage of Arbor's customers use our calculation scripts for procedural calculations in addition to the other types of calculations.

MDX has arisen as the new procedural OLAP-aware language. I've avoided it like the plague, but I'm sure it does what it's supposed to do.

On The Trail of OBIEE

I'm officially on the trail of OBIEE and figuring out its strengths and weaknesses. This is going to be fun. I'm meeting with a bunch of Oracle guys in the upcoming weeks and, who knows, I might even bump elephants. (That's a term from the Warren Buffett biography I'm reading from some meeting of the big dogs in Sun Valley).

One of the elephants is clearly Mark Rittman. The more I get close to finding out what OBIEE is and how it works, the more his name appears. So today I just ingested this piece of his over on the Oracle network. Basically he shows, for OBIEE folks, how to build an Essbase cube. It's a very good introduction to how to think of Essbase if you come strictly from the relational world, or if you're new to BI.

It's kind of astonishing to me how small the overlapping sets are of relational experts and multidimensional experts. Funny, I remember thinking to myself, in my 8th year of the profession how I'd like to start a company called 3DB with relational, multidimensional and object oriented database guys. Come to think of it, I started way back with hierarchical databases, so it shows you how old I am. But the idea of 3DB was that we could conceive of any model of reality and stick it into the most efficient place. Now these webby mash-up guys are saying even database technology is passe. Well, we'll see about that. In the meantime, there is still some great advantage to be had if one truly understands best practices in relational and multidimensional. The OBIEE stuff is all about what it looks like on the front end.

Speaking of which, I hope I get to use my iTouch client of Oracle Indicators with all this. I'll be a walking advert, just like I was for the Palm and AvantGo a decade ago. (sigh).

Anyway, that's the update. I should be signed into a server this week and get some hands-on. In the meantime, I will try to contain my bulldog proclivities about the superiority of Essbase especially given my involvement on the losing team of selling Essbase technology to the guys at Siebel back just before nQuire was purchased by the Siebel guys.

A History of BI: The 80s

BI is Business Intelligence. At this particular moment in history, BI is seen as the more technical aspect (tools & techniques) in Management Computing.

So let's start at the beginning.

Back in the mid 80s, before the advent of the Pentium class computer and the acceptance of pre-emptive multitasking operating systems in the business world, a cat named William Bowen (no relation) published a cover story on Fortune called 'The Puny Payoff from Office Computers'. He started off:

HAVE THE MILLIONS of computers purchased by U.S. businesses brought any overall improvement in productivity? Surprisingly, the best information available says no.

This collides with many people's beliefs regarding computers. Without computers, present-day credit card operations, check processing, and airline reservation systems would be unthinkable. But the figures indicate that, on a national scale, business's investment of hundreds of billions of dollars in computers and computer-aided communications has failed to bring about a discernible improvement in productivity. ''The puzzling thing,'' observes economist Martin Neil Baily, a senior fellow at the Brookings Institution think tank in Washington, D.C., ''is that the computer revolution has not yet paid off in productivity growth as did the earlier generations of innovation.''
So far productivity has grown more slowly in the computer age than it did before computers came into wide use.

The accepted wisdom was, at this time, that the typewriter business would remain profitable, business managers did not want to type and would not learn to use a mouse, and that any computer with more power than a pocket calculator could only be useful to engineers and scientists.

This contradicted the expectations of people like me, who were invested in the ideas of 'informating' the workplace. These ideas basically originated out of the theories expounded in The Rise of Managerial Computing, by John Rockart. Along with the other cats at CISR and the theories of John Seely Brown, there was a technical vanguard of folks who believed passionately that computing could bring efficiency to business decision making. Technically, there was a distinction made between Strong AI and Weak AI. Weak AI was also known as the 'Augmentation School' as proposed by Doug Englebart.

In my own career, fortunately cutting my teeth at Xerox, I was in direct contact with the tools and technologies that were enabling these theories. I played enough with tools like LOOPS and XDE (and even the HUMBLE Expert Shell) to recognize the great potential. I actually did some Viewpoint programming in Mesa back in those days.

As we at the Xerox Systems Group looked to make the 'office of the future' we experimented with any number of support strategies and tactics. The one that managed to stick was the idea of the 'IC', the Information Center. But one thing was immediately clear, if the IC was going to function properly, we had to address Bowen's complaint. What emerged from the work done in the mid-eighties was an interdisciplinary approach dedicated to improving business via the judicious use of computing technology. Principles I developed with these things in mind are still valuable to this day.

It bears repeating that in those days, most computing was done on mainframes via subserviant terminals. Most corporations understood this paradigm, but they did not understand the value of distributed peer networks. Napster is not the first group of upstarts to encounter resistance. At XSG, our calling card was decentralized, client server, object oriented, networked computing. Each of those qualifiers was fought tooth and nail, and our noses were rubbed into every failure. But we were still all about End-User Computing. How could we make it win? By breaking it down to cases, application by application. I won my first crystal trophy building a system adhering to my now golden Pledge.

We were determined to make productivity gains in the 'front office', among analysts, managers and those we called 'knowledge workers'. This followed Englebart's ideas about augmenting human intelligence with tools that aid thinking. Back office computing was dreary and boring to us - cutting payroll checks, keeping track of telephone bills, these were things that could be done on stupid mainframes with primative languages like COBOL and elementary data structures like VSAM. We were were trying to get people to work smarter through advance user interfaces. We had to think of data in more ways than just fields & sorts. We were engaging people at their desks in order to make people more productive.

The Cubegeek in 1988 at Xerox Systems Group in El Segundo. Note the 6085 workstation with the 19 inch monitor on the right.

A lot of time and effort was spent understanding how people approached their work, how they organized their physical work, how they would interact with the computer. We were engineering things in real-time. Over time all of these disciplines came to be known as Executive Information Systems.

At Xerox, and certainly most other corporations, the new front office productivity efforts centered around Finance organizations. Numbers were something we could do. Memos were something we could do. Reports were something we could do, and so we expected our first payoff would be in Finance and Accounting. In various ways, these corporate staffs already knew that computing could save them time and money. Backoffice computing was already calculating payroll, etc. Plus, these guys held the pursestrings. They could buy systems when they felt like it. Sure there were many advances in CAD/CAM during this same period. In particular at Xerox, we were undergoing a complete transformation of the management culture from top to bottom. Xerox' CEO David T. Kearns had hired McKinsey & Company to instigate a program called Leadership Through Quality. The most important thing about the Xerox reorg with regards to BI is that they implemented a practice of cascaded management objectives. The point was that employees throughout the organization should understand at every moment how their work contributed to the priorities of the company.

Without getting too deeply into it, Quality Improvement struggled through the 90s against something called Re-engineering. Among the management consultants, there were two schools of thought. The Deming School and the Hammer School. Coming from Xerox, I was part of the Deming School. With regards to a systems implementation philosophy a quality improvement perspective means learn from what you know and get better. It's about evolution rather than revolution.

So by 1990 I had a very clear picture of what I was doing in Managerial Computing. I was building EIS and EIS was about putting LAN enabled computers in front of managers, analysts, and other knowledge workers. It meant having a strong set of productivity benchmarks to insure that the investment would be worth it. It meant taking what people know already and improving upon that by augmenting their intelligence. Not making the computer think for them. Not putting simple rows and colums of numbers on paper (hell you could do that with greenbar). Not saying everything you know is wrong, here's how we're going to re-engineer your function. EIS was part of the inevitable evolution of computing from all the knowledge being centralized in the mainframe to taking the knowledge from the people of the organization and leveraging their ability to do the company's business.

So for me the theory and tasks were clear. Now it was all about communicating that, and waiting for the technology to grow up.

BI Basics: MDBMS

I've been hanging out at the comp.databases.olap group for a hot minute and there seems to be something of a need for some terminology. I think this is a good idea considering that I actually have used both MSAS and Essbase (And Pilot Timeserver, but let's not go there).

There's Wikipedia for a start, but I feel more comfy editorializing here. I'm always going to editorialize because I'm all about results, and I've gotten my best results over the past 17 years with Essbase and I see no sign of that changing. So you'll please forgive my bias as I state it clearly. I have been using Essbase for 9 years.

Anyway, let's start with Multidimensional Database. I know this is a controversial place to start because there are basically only a few vendors who make them even though there are lots of people in the OLAP and DW arena.

As far as I know, there are:

Hyperion Essbase

Microsoft Analysis Services

SAS

TM1

Oracle Express

Neteezza

The rest are off brands. There's also a specialty indexing offering from Sybase, but then again, that's Sybase - meaning if you don't already know about it, you're probably never going to buy it. It ain't cheap. Same thing with Teradata.

A multidimensional database, is by definition, proprietary. There are basically two standards and none of them is ODBC or JDBC. They are MDX and XMLA. MDX is rather like an SQL variant, and XMLA is something I don't really understand. What I do understand is that both Hyperion and Microsoft support both of those standards as does SAS. This industry is not about a lot of standards, primarily because there is only deep knowledge about it in a relatively few companies. Nobody just jumps into the BI arena, although there are some up and coming Open Source players.

Multidimensional queries are generally accepted as the best way for users to navigate through numerical data which allows them to come to some analytical understanding of their business. That may not be categorically true, however there are some tried and true methodologies that support the industry. It's not just theory, it works.

All of the above listed products can be thought of as Multidimensional Database Management Systems, more or less. SAS, Essbase & MSAS are the fully featured systems. The others are a bit more specialized and narrow. I didn't mention SPSS/Showcase or IBM's DB2 OLAP because both of them are OEMs of Hyperion Essbase.