Essbase Analytics: Where to calculate metrics?

One of the most often missed enterprise information improvements with Essbase is the calculation of organizational metrics. All Essbase frontends have the ability to perform calculations on the fly, but often this is overused.

The Problem (in the beginning)
Essbase is often implemented to standardize an organization's financial data. In addition to extending analysts' capacity to review financial data beyond the limits of Excel and traditional reporting tools, having standardized metrics ensures all decision makers are comparing similar values. You've probably heard the cliche 'Single Version of the Truth'... this centralized storage of financial information alongside centralized metrics is the embodiment a single version of the truth.

The Deployment
Great... so once an organization realizes the need to standardize and centralize, step one of any successful implementation is to define their requirements. In the simplest terms, this includes the data to be housed in the application, as well as the definitions for the metrics to be applied to that data. Utilizing this blueprint results in an implementation that solves the key goals: having everyone utilizing the same data and the same definitions.

But...
There is always something that isn't captured. This isn't a problem, this is a reality. Often, a metric isn't included either due to time constraints, foresight constraints, or conflicting priorities.

The front end to the rescue!!!
All modern Essbase front ends have the ability to do calculations. Some are limited to rudimentary calculations, others have robust calculation languages. Regardless, the inevitable suggestion of "Lets just accommodate that in the front end" is brought up. Which is great, but...

Back to square one
Back during the evaluation phase, one of the key decision points to implement an Essbase application was to centralize and standardize all business logic. As soon as the decision is made to move away from centralized business logic, the long term value of the implementation begins to erode.

What to do
I'd be a fool if I heavy-handed recommended that any and all business logic is only ever developed in the backend. This is going squarely against one of the key benefits of Essbase- power to the analysts' to perform their own operations, without being at the mercy of someone else to implement logic. But, that's where the distinction ends. One of the key rules to any successful Essbase, or Performance Management, or BI, implementation is that all logic that will be shared amongst multiple users must be centralized. A key principle that an organization must adopt is a requirement that any business logic that is to be distributed to the masses must be implemented at the point at which it is sourced to the masses. This doesn't necessarily imply that every piece of business logic is sourced solely in Essbase; it may be that the logic is created in a system that feeds Essbase. In addition, the realities of a modern complex organization must be recognized, and, situations where the full audience for a piece of business logic are served by multiple systems, there may be justification for business logic configuration in multiple systems.