TANGRAM's original approach to OLAP applications.

The main claim of DSS-OLAP systems is that they allow problem analysts to quickly react to unanticipated changes in the company environment.

This claim, if taken at all seriously, implies that DSS-OLAP systems are in a class of their own, and for several reasons:

	The distinction between users and developers is not clear-cut but very blurred. There is a continuum, ranging from the shy, passive user to the poweruser. The latter should ideally be able to disassemble the whole DSS-OLAP application and modify it to reflect a new business situation.
	Software tools for the "OLAP emergency team" should work no-matter-what and depend on their (software and network) environment as little as possible.
	Programming (a.k.a. coding, in VBA, C++, Pascal and the like) can hardly be regarded as an adequate tool to quickly reconfigure an application. New uses of existing (versatile, dependable, general-purpose) tools seem a better approach.

And yet, sooner or later, every OLAP installation will be faced with the task of extending the power of the OLAP tool with some kind of customization or programming.

The next questions are: how painful will it be ? What means are provided to integrate the custom programming into the OLAP architecture ? And then - what level of programming ? A powerful, specialized scripting language or 4GL or SQL or a low-level notation like the C language ?

Unfortunately, you will discover the answers after you are committed to a particular OLAP (when you reach its ceiling, maybe after months of investment).

And now TANGRAM.

TANGRAM is built on top of a high-level multidimensional notation called APL. The APL interpreter handles TANGRAM code on a par with user extensions.

Main advantages:

In case of need, all the power of APL is available "under the hood". It is complete, general purpose, high level and powerful beyond your expectations.

The interpreter translates user answers to TANGRAM. This means that straight answers (like mouse clicks) can gradually give way to expressions and keyword oriented circumlocutions. For example, instead of manually picking certain products in a list-box, you want to express a selection rule, like, say, "pick those products that have decreasing Gross Margin in at least two periods" or, "pick the same products that I used in the cost allocation exercise" These circumlocutions are typically expressed in a keyword language and represent the most elementary customization.

TANGRAM's tightly knitted relationship with APL has other advantages:

	TANGRAM offers several specialized keyword languages (for element selection, computation, queries, ...) that make system extensions easy and natural. APL use is just a further, seldom necessary, possibility. TANGRAM keyword languages are pervasive, meaning that they can be used anywhere in the application and are freely mixed with guided TANGRAM use on the one hand and APL use on the other.
	Building blocks (programs) at all levels are available to the fearless developer and are specially easy to combine.
	The APL notation that you may want to learn to customize TANGRAM has a validity on its own as a general purpose language. This is important to protect your learning investment.
	APL is a masterful multidimensional notation. It is concise, rigorous and complete.

Let us explain all this from a different point of view.

Suppose you bought and installed a software package (OLAP+application) that was adequate at the time you adopted it.

What happens when your requirements change, or you need an extra feature?

This new feature might be the handling of the Euro currency, or a new organizational structure or the adoption of a zero-base budget or... a hundred other unexpected changes...

In such a situation, you traditionally choose between three options:

(1) You contact the vendor and inquire if they offer the new feature as a companion product, an option, an add-in, an extra component.

Normally it isn't available - but then, when it is, a bunch of problems go with it (price, installation, documentation, maintenance, training, stepped-up complexity, variance between the canned solution and your particular needs, ...)

(2) You have it implemented via programming.

In this case you know that you are heading for trouble of a different kind.

What kind of programming are we talking about? What are the available ways to plug-in the programmed bit into the existing scenario (macros, user hooks, compilation and linkage, DLL, OLE, COM... ?)

Programming is a very slow, costly, error prone process. Alas, we all know the frustration and horror stories that it evokes.

Sometimes there is a third way, which is too often overlooked:

(3) Do it yourself. Learn new ways to use the existing OLAP and simply add the new feature.

This is the TANGRAM way.

This is the moment of truth---you discover that you don't have a fragile hard-coded application but a custom solution built on a general open-ended tool.

You also discover that you can reconfigure all building blocks in your application, and there are no off-limits areas.

This self-confidence is the guarantee that you will be able to respond to the next unanticipated emergency in a time-scale of hours.