Friday, April 29, 2016

Oracle Hyperion Planning VS IBM Cognos TM1 Series - Part 4 (Density, Sparsity and Data Handling)

In this post, we will try to understand the difference in the way Hyperion Planning (Essbase to be specific) and TM1 structure and deal with data. In Hyperion Planning when you create your Application, and once you have finalized your dimensions (apart from the standard dimensions), next thing you need to do is define density/sparsity of the dimensions.

So TM1 folks can grasp the difference between their definition of density/sparsity and Hyperion's, the number of stored members in dense dimensions will give us our Essbase block size, and the number of stored members in our sparse dimensions will give us the number of potential Essbase blocks (this is the first thing you learn in Essbase, I call it baptism of Hyperion professionals). In my Demo application, I kept the settings created by default. I will show next my Demo application outline, I have added few members to use in this post.

So if we do the calculation explained above, we will get our block size and the potential number of blocks. In this post, I want to highlight a key difference in Hyperion Planning and TM1, the level at which we store data (level zero or upper levels). So in order to get on with this, I need to show the two version members/elements I created in my Version dimension.

As shown above, we have two types of versions we can create in Planning:

  1.  Standard Bottom Up
  2. Standard Target
The key difference is our ability to store data in upper-level blocks (i.e parent members). It is pretty straightforward, in bottom-up versions you cannot but enter data in level zero members, whereas in target versions there are no restrictions.

Ok, now I want to create a simple data form as shown below, see the main difference in the editable cells, the column I'musing the bottom up version with has only one editable cell, whereas the column with target version has 3 editable cells.

Before I enter and save any data, I want to look at my application stats.

Number of existing blocks: 0
Existing level 0 blocks: 0
Existing upper-level blocks:0

Now let us enter some data in the bottom-up version.

And our stats will look like:

Number of existing blocks: 1
Existing level 0 blocks: 1
Existing upper-level blocks:0

Moving on to the target version, I will enter data in the level zero member.

And our stats will look like:

Number of existing blocks: 2
Existing level 0 blocks: 2
Existing upper-level blocks:0

Ok now before I enter data in parent members, I want to clear the data in level zero blocks, and clear missing blocks to reset application stats.

And our stats will look like:

Number of existing blocks: 2
Existing level 0 blocks: 0
Existing upper-level blocks:2

Cognos TM1

I went and fixed my dimensions to replicate almost the same structure we followed in our Hyperion Planning Demo application.

I want to create a cube now.

Since I only need at least two dimensions in my TM1 cube, I selected only Version, Entity, and Account. Unlike Hyperion Planning's Essbase we don't tag the dimensions and specify if they are dense or sparse, what we do is order the dimensions in the cube from smallest sparse to largest sparse, followed by smallest dense to largest dense, that is one way or ordering dimensions, there is no right or wrong since everything depends on your data and everything can simply change.

Now because TM1 is an in-memory OLAP engine, meaning everything is kept in the memory (the whole cube), and there is no concept of retrieving blocks from harddesk to the memory, you specify your sparse and dense dimensions order so that you can optimize your cube size and performance. 

Ok now let us create a view.

We have only 3 editable cells (only the level zero elements), in subsequent posts, I will explain element types and differences between Planning and TM1. But for now, I will enter some data in my view.

And our stats will look like.

TM1 is all about RAM memory, and our stats reflect the same, memory usage per cube and dimension, playing around with your ordering and loading the data again is the equivalent of outline restructuring in Hyperion Planning in order to optimize application performance.

Now I would like to conclude but I prefer to do so in a simple way so that people from the non-IT background can understand what is happening. The key difference between Hyperion Planning's Essbase and TM1 is the way data is stored, in Hyperion Planning's Essbase you have a store room with n number of boxes (sparse dimensions) of the same size(dense dimensions), when you need a specific box(s) you refer to your inventory list (Essbase index and page files) and you go and fetch them out of the store room (from harddesk to memory), bring them to your office, and check them out. 

Whereas in TM1 you have a number big boxes in the same room you are sitting in (memory) , every box has a number of smaller boxes varying in sizes (cubes), and you have your labels on the boxes so you can easily go and fetch whatever you need. and at the end of the day when you want to leave the room, you move your boxes to the store room (from memory to harddesk), and next day when you come back to the room, you bring the boxes with you and keep them in the room the whole day until you are about to leave.

Until we meet again, may the Cosmos be with you.

Sunday, April 24, 2016

Oracle Hyperion Planning VS IBM Cognos TM1 Series - Part 3 (Dimensions)

In this post, we will see how Hyperion Planning and Cognos TM1 deal with dimensions. to start with Hyperion Planning as explained in the previous post, you must have the standard six dimensions (Account, Period, Scenario, Version, Entity and Years) and two more in the case of multi-currency applications (Currency and HSP_Rates).

Let us look at our Demo application's outline.

Under Account dimension, you can see we don't have any members(elements for TM1 folks) created so far; whereas in TM1, you cannot create a dimension without having at least one element. In Hyperion Planning, if you add a dimension, you cannot delete it, unlike TM1. Now let us look at our Essbase Demo application directory.

You can view Oracle's online documentation for more information on Essbase files and extensions, what is of interest for me here is the Finance.otl file (.otl = Outline file) which is the file storing our outline details, dimensions, hierarchies, members etc. By looking at the directory above there is no way you can find out the number of dimensions.

Cognos TM1

When we created our Demo application server in the previous post, there were no dimensions created/associated with the application as shown below.

I'm going to create the same dimensions we have in our Demo Hyperion Planning application, in TM1 architect, right-click on Dimensions and select Create New Dimension. In Cognos TM1 you must have at least one element before creating any dimension. After clicking on Create New Dimension, the dimension editor menu will open, right-click and Insert Element. In later posts I will explain the types of elements in TM1, for the time being, we will create elements with Simple type.

My Account dimension after inserting an element.

Will repeat the same process to create the rest of dimensions.

Now let us look at Years dimension in TM1, I have created an element called FY14

In Hyperion Planning year members are always created with the prefix FY (fiscal year), followed by year number. In TM1 there are no restrictions on year elements names. and unlike Hyperion Planning, in TM1, you can play around with Years dimension as much as you like. I deleted the element FY14 and created a new element called No Year for the time being.

Finally, let us look at our TM1 Demo application directory.

By looking at your application server directory, you can find out how many dimensions are there.

Until we meet again, may the Cosmos be with you.

Saturday, April 23, 2016

Oracle Hyperion Planning VS IBM Cognos TM1 Series - Part 2 (aka applications)

In this post, I'll be showing how applications are created in both Hyperion Planning as well as Cognos TM1, by doing this I will also highlight the key differences.

An application is a collection of dimensions, data forms (views or input sheets in TM1) , reports, task lists (applications in TM1) that are built to serve a specific purpose (Budgeting and Planning, Human Capital Planning, Revenue Planning etc..). here I will show how to create a basic skeleton application, in the subsequent posts, I will go into more details like the design of outline, dimensions, sparsity./density settings and so on.

Product versions used:
Oracle Hyperion Planning
IBM Cognos TM1 10.2.2

Hyperion Planning

So to get your application up and running you first need to have a relational database/schema for your application to store your application metadata and system information, like Oracle or SQL Server...) and the reason I made that statement in bold is because in TM1 you don't need one (surprised?)

I have Microsoft SQL Server 2008 so I'll just create a new database called Demo.

Now let us create a data source in Hyperion Planning and define our relational database and Essbase.

Navigate to Planning Administration

Create new data source called Demo as shown below

Now let us create the application, I'm going to create a classic Planning application (sadly with DRM EPMA applications are no longer fun to hang out with).

In the second tab of the wizard, choose whether how do you want your Period and Year dimension setup. Your first fiscal year setting cannot be changed after creating the application (another key difference in TM1 you don't have this restriction, or at least there are some workarounds to overcome this unlike Hyperion Planning)

In the third tab of the application creation wizard, select whether you want your application to support multiple currencies or not (never seen this used in real life) if this option is selected then Planning will add two more dimensions (Currency and HSP_Rates) I'm not selecting the multi-currency feature for my Demo application.

Now the interesting fourth tab, select how many plan types (aka cubes) you want in your application, whether you want your ASO planning cube, and  pre-built Workforce  and Capital Planning modules.

A classic Hyperion Planning application can have up to three standard plan types/cubes (BSO cubes), one reporting ASO cube and two pre-built modules. the latter can also be added after creating the application. Here is a key difference in Cognos TM1 there are no restrictions when creating your application server, in fact when you create your application you don't have any dimensions.

For TM1 folks reading this, the Workforce Planning and Capital Planning modules are pre-built applications with dimensions, data forms, business rules, task lists, smart lists.... ready to use with some slight modifications. this is also a key difference in TM1 this is nothing equivalent (cannot say I miss having them around, I prefer a clean application and build the whole thing from the scratch old school style).

Now create your application, go to the last tab and review your settings and create button. after successfully creating your application you can go to the back end database and see your system tables  as shown here.

Another difference here is in handling system objects, in Hyperion Planning you need a relational database for storing your application metadata details, but in TM1 you don't need one,the  application server in TM1 will have control cubes instead stored in your data directory.

Now let us open the application and see our dimensions.

In Hyperion Planning, you must have six standard dimensions (Account, Entity, Period, Scenario, Version, and Years) or eight dimensions if multi-currency is enabled (Currency and HSP_Rates dimensions as well as the previous six ) and you cannot delete any of them. This is very different from TM1 for example in your application server you may or may not have a Version dimension,  and your minimum number of dimensions in any TM1 cube is two.

Cognos TM1

Let us create our Demo application in TM1 (aka application server). on your server create a folder named Demo preferably in (C:\Program Files\ibm\cognos\tm1_64) and create two sub-folders Data and Logs.

Now we need to have our Tm1s.cfg file, we can go to samples directory (C:\Program Files\ibm\cognos\tm1_64\samples) copy any Tm1s.cfg from any of the samples and paste it in the Data folder under Demo. Edit the copied Tm1s.cfg file and change the following entries:

DataBaseDirectory=C:\Program Files\ibm\cognos\tm1_64\tm1\samples\Demo\Data
AdminHost=Your server computer name
PortNumber=6009 (pick a port number between 5000 and 49151)

Open IBM Cognos Configuration, right click on TM1 Server, and select TM1 Server instances... from New resource

Name the application server Demo, click on and specify the TM1 Server configuration path which is the where we placed the Tm1s.cfg file and slick Save, once done right click on the newly created Demo application server icon and start the application, you should get something as shown below.

Open TM1 Architect and you should see Demo application server in the list, double-click to open and keep password blank.

Congratulations you have your Cognos TM1 application up and running, as you can see there are no dimensions created at this point, unlike Hyperion Planning. Browse to your Demo\data folder and you can see the generated system files or control cubes.

That's it for now :)

Until we meet again, may the Cosmos be with you.

Thursday, April 21, 2016

Oracle Hyperion Planning VS IBM Cognos TM1 Series - Part 1 (aka Introduction)

This is the first post of my Hyperion Planning VS Cognos TM1 series for EPM enthusiasts, the series will talk about key highlights and differences between technologies, compare both products by showing how things are done, whether we want to create a dimension, cube or simply load data. I'm focusing on the technology bit in these posts because 1+1 = 2 using a calculator or Excel :)

Now whether you are from Hyperion Planning or Cognos TM1 background the following  will help you align terminologies and map product components. I will list down the Hyperion components and map it to the equivalent TM1 component, the beautiful part here is that the relationship can be one to many or one to none.

Essbase server/ Administration Console
  • TM1 Architect
  • TM1 Performance Modeler
  • TM1 Turbo Integrator
Hyperion Planning
  • TM1 Architect
  • TM1 Performance Modeler
  • TM1 Web
  • TM1 Perspectives
  • TM1 Turbo Integrator
Hyperion Workspace
  • TM1 Architect
  • TM1 Performance Modeler
  • TM1 Web

Hyperion Calculation Manager
  • TM1 Architect
  • TM1 Performance Modeler
  • TM1 Turbo Integrator
Hyperion SmartView
  • TM1 Perspectives
  • CAFE (Cognos Analysis For Excel)
Hyperion Financial Reporting
  • TM1 Perspectives
  • CAFE
  • Cognos Insight
Hyperion Shared Services (Users and Groups)
  • TM1 Architect
  • TM1 Performance Modeler
  • ET LDAP (utility to upload LDAP users to TM1, this will ONLY create new users)
Hyperion Shared Services (Lifecycle Management)

No TM1 equivalent, batch files to copy data directories will do the job

EPM System Configuration
  • Cognos Configuration
Hi Hyperion this is TM1,,,, TM1 this is Hyperion :)

Now we are done with the introduction.

So now we have mapped our products and components let us look at the services in our servers and see how they look.

Hyperion Planning

Nothing unusual here, we have a service running on for almost every product/component name.

Cognos TM1

First time I looked at the services in TM1 I was like mmm interesting, its pretty simple really you must have Admin Server and Application server services up and running, the rest are all applications (called application servers in TM1). In case you are wondering why are we having a service for every application? well it has to do with  TM1 architecture and the way TM1 handles data, this will be covered in details in a future post.

Next post I'll discuss  high-level architecture, key differences and take it from there until we end up with our own sample applications in both Hyperion  and  TM1.

Until we meet again, may the Cosmos be with you

VAR Declare intentions

I'm not a big fan of writing, I'm more of a reader myself, the intentions behind having this blog is to share some tips, neat workarounds from previous projects, and highlight the key difference between Oracle Hyperion Planning and IBM Cognos TM1 from technical and architecture point of view.

Why technical only? well simply put both of these technologies will get you any budgeting, forecasting and reporting system.