Interesting assessment of TM1 'vs' EP

[David Usherwood]

(NB - this isn't my assessment, though I don't disagree with much of it)
http://ykud.com/blog/cognos/tm1-enterpr ... ment-16414
TM1 + Enterprise Planning, When, Why and How?

This post will be some extracts from a recent PoC, where we made a complex planning system including a rich scenario modeling part. So it was our first big TM1 + EP integration experience.

Some basic definitions:
Cognos Enterprise Planning (aka Adaytum EP) is a very scalable system, all computing is client-side, nice workflow organization, nice GUI (version 8.4 Eclipse one especially) with huge limitations when it comes to the moment of “show me the whole budget in one place” or to serious what-if modeling. But scaling is trivial, each server acts as many clients simultaneously (number of cores\CPUs) and adding more servers scales the system linearly. So to build really scalable systems, we made Contributor only working places, with all analysis done in Cognos 8 BI and Analyst was turned into a modeling tool. In adaytum and cognos 7 times a lot of things(consolidating, what-if) could be done (and to be honest, still can be) in Analyst, but just up the point you reached 40mln cells cube limit in Analyst, then you started dividing cubes and the system became nightmare. Transforming the same consolidation task into series of Contributor applications connected by admin links gave huge performance enhancements, but the "show me the whole budget" limitation was a major problem.
Cognos TM1 (aka Applix TM1) is an in-memory OLAP engine, ultra-speed calculations, server side computing, excel based gui (with web publication), limited workflow capabilities (compared with current EP), scalability limitations (imagine putting servers across whole Russia to ensure response time)

So when it comes to a planning system with large user base – it’s EP, but if some serious modeling and calculations are requied as well – it’s time to fire up TM1 as well.

Overall interaction scheme seems pretty simple:
tm1ep

1) Most of users work in EP inputting budgets, submitting and doing all other workflow related activities
2) After some user actions (saving budget, submitting, accepting it) data is transferred into TM1.
a. Detecting the desired action is easy – we’ve got Event Studio for that (see here and here).
b. Incremental publish is fired and changed elist is republished – that’s pretty fast
c. Then there’s a problem to extract only changed data from publication. That’s the same as with incremental admin links, you just write a simple database procedure that logs last data transfer time and create views showing only recent data (as usual, you want code samples – drop a line)
d. Changed data is bcp’ed\sqlloaded to TM1 server
e. TM1 TurboIntegrator process is fired, loading the extracted data into TM1
3) Analysts work with “live” data in TM1, doing what-if analysis (they dynamically add scenario versions for this purpose), having access to all enterprise budget and actual data.
4) Then a version could be used for top-down propagation and exported into EP (that’s pretty simple, just some writing into EP applications import tables)

The whole system seems pretty healthy, data transfers happens with 1-2 minutes latency (we used Save as trigger action). Doing any kind what-if analysis on a budget version only 2 minutes "stale" with ultra-speed seems very impressive to me. For instance, in that particular PoC the goal was to speed up overall company budget consolidation, including complex allocation and elimination rules. It took over 8 hours in their current system. And only 4 minutes in Tm1 -- imagine all the benefits you can get from that kind of speed.

Since there are more and more rumours about coming TM1+EP bundle, I just hope that step 2 will be more automated. For example, they can track delta xml's sent by contributor client, containing all data updates, instead of publishing and bcping. But I can see no way they can get rid of neccesity of creating 2 models, one in Analyst for Contributor applications and another in TM1. Although dlists\dimensions can be synchronized, calculations are utterly different (you can target specific cube cell in TM1 formula and only the cube slice in EP).

[jim wood]

We have and use both. Our planning mechanism is a large amount of input from various areas. With EP being client based you can have a large number of people accessng at one time. When we tried to do this with TM1 it really did start to drag and did fall over quite a bit.

I would agree with your post, the calc engine in TM1 is much more powerful and does "what if" much more eaisly. I would also add somthing else. EP can't handle big cubes due to local machine limitations. They recommend not to use a cube with more 30 millions possibilities. (I do mean possibilities. It does not do sparcity at all) This means larger more complicated models have to be split across multiple cubes. It also means you rely on libaries for versions rather than having multiple versions in the cubes. The impact of this is that you can't easily review the information you have jut calculated and you can't compare it previous iterations.

[mce]

I would also add somthing else. EP can't handle big cubes due to local machine limitations. They recommend not to use a cube with more 30 millions possibilities. (I do mean possibilities. It does not do sparcity at all) This means larger more complicated models have to be split across multiple cubes. It also means you rely on libaries for versions rather than having multiple versions in the cubes. The impact of this is that you can't easily review the information you have jut calculated and you can't compare it previous iterations.

This was not quite right. Here are my clarifications on Cognos Planning:

• - 30 millions limit (actually 100 millions) is for Analyst Cubes which is the modelling interface and it does not necessarily include the hirarchy (e-list) dimension of your Contributor application. The cubes in Analyst are not the ones that are accessed by Contributor users and therefore this limit is not applicable to Cognos Planning Contributor applications.
  - Congos Planning has different modelling approach than TM1, and it does not require having sparce cubes for planning purposes. Therefore it does not require having big sized cubes for planning requirements. All the limits that we are mentioning for Cognos Planning are the limits for non-sparce data.
  - However, there is a limit on the number of cells in Contributor application per e-list slice (means per element in hierarchy dimension). This is about 10 million per slice, but it is not recommended to exceed 3 million for acceptable performance in a typical web client PC. This does not put any limit on the total size of the application and on the total size of a cube in an application. You can have tens of thousands of elements in your hierarchy dimension even in a small hardware configuration and therefore you can have multiple billions of non-sparce cells per application and per cube in such an application.
  - Moreover there is also a mechanism in Cognos Planning to manage defined sparcity using Access Tables. This allows you to disable any cube slices that are not applicable to any element in hierarcy dimension. This allows us to considerably reduce the effective size of the model that is applicable to size limits.
  - Relying on libraries for multiple versions is the bad design practice in Cognos Planning (It is almost like having a seperate TM1 instance for different versions, but multiple libraries can share objects in Cognos Planning). You can have version dimension in your models in Cognos Planning and you can manage multiple versions. But you should make your design accordingly considering size limitations.

[lotsaram]

Hi mce

I think most if not all would agree that due to limitations in the calculation engine there are a lot of finesseing, design considerations and workarounds to do in order to make a large EP model work, and I mean A LOT. The point is that TM1 just does it, there is no need to worry about dimension size, cube size, number of versions, number of time periods, etc. as TM1 handles model sparsity very well.

[mce]

I think most if not all would agree that due to limitations in the calculation engine there are a lot of finesseing, design considerations and workarounds to do in order to make a large EP model work, and I mean A LOT.

Hi Lotsaram,

Each tool has its own issues and considerations. Those size considerations in EP may not be more than that of Locking issues/considerations in TM1. You may need to do some modeling tricks in Cognos EP to make really big model work properly, while you may have to do much more tricks to make a TM1 model serve hundreds of users.

In my openion, Cognos EP is a better tool for planning than TM1, while TM1 might be preferred in cases when you need a tool serving both planning and OLAP style reporting requirements at the same time without any integration.

Regards,

[jim wood]

MCE,

I have just noticed your post. What I put down is based on our experience here and the version we are using. We do not use contirbuter, only analyst. The 30 million limitation is based on teh average user desk top for Analyst. I would however say that now that TM1 includes contributer basing any comparisum of EP Vs TM1 on conributer could get a little mucky,

Jim.

[mce]

What I put down is based on our experience here and the version we are using. We do not use contirbuter, only analyst.

This was the way Cognos Planning was used prior 2004-2005 when there was no Contributor. Since then, there has been a lot of developments in performance management technology in general and in Cognos Planning specifically. Nowadays, Analyst is not considered/offered as a "user tool" for planning and forecasting anymore. It is rather a modelling tool that Administrators and Developers use to build planning models that are to be published to wider user audiences as web based Contributor applications. This means your company is using Cognos Planning as per its features that were available 5+ years ago. Therefore comparing what Cognos Planning was 5+ years ago with today's other technologies and requirements, I think, is not fair. Cognos Planning has a different offering for deploying planning applications today than the one 5+ years ago, and I think we now should base our evaluations to this offering.

I would however say that now that TM1 includes contributer basing any comparisum of EP Vs TM1 on conributer could get a little mucky,

Although both products are called as Contributor (to be able to sell new TM1 to existing EP clients), and although they have similar look and feel, we know that they are completely differnt in the way they work and in most features that they deliver, and IBoglix still does not recommend 9.5 to be installed in production environments as it is not stable yet although they use 9.5 features in marketing the product.

[jim wood]

Using an unstable version for marketing, nothing new there then. One of my bug bears with TM1 has always been stability. I don't if it is me but I have an uncanny knack for finding either known or unknown issues. (Normally resulting in a crash)

It might just be me being the harbinger of doom!!!