When migrating from TM1 to Anaplan there are many things to consider before embarking on the journey. Both platforms are in memory 64bit applications. Data availability and aggregation is immediate in both platforms. Both allow for complex rule writing. Both allow the user to bring data in from outside sources. From there however, the platforms diverge pretty quickly.
If you have been using TM1 for a while the first thing you will notice is that Anaplan is truly a cloud platform. There is no client install. Both development and user access is accomplished through a web browser. So there is no hardware consideration necessary. Standard browsers like Internet Explorer, Google Chrome or Safari are the only tool you will need to begin modeling.
Having spent time in TM1 you will probably just want to jump right in and begin building your Anaplan modules. You may assume, ‘How different can this be’? I just build dimensions and then bring them together to form a module. However you should not fall prey to the idea that if I had a large cube in TM1, I will build the same module in Anaplan. Technically this is possible. Practically it can be the biggest mistake you make when modeling in Anaplan.
One of the fundamental differences between TM1 and Anaplan is what uses up memory or in Anaplan terms workspace. In TM1 rule logic is what uses up RAM on the TM1 server. As your rule writing and feeder statements become more complex, the amount of RAM the model consumes goes up. Cubes take up some memory but it is only a small fraction compared to rules and feeders. So if you start with a server that has 16 GB RAM you can monitor the consumption as you write and save rules. In todays virtualized world most IT departments can provision additional memory with a few clicks. Certainly there is a cost associated with this but it is fairly cheap to add RAM to a server.
On the other hand, Anaplan modules are what eat up workspace. Workspace is the amount of memory that has been allocated to you for your Anaplan modeling needs. Typically 10 GB is what you start with (you can go up to practical limit of 130 GB). As you build your modules the amount of workspace is consumed. The platform lets you know where you stand on workspace consumption from the model management dashboard. As your modules become bigger workspace can be consumed pretty quickly. What happens if you run out of workspace? Well, you need to go back to Anaplan and have them provision more workspace for you. There is a cost associated with this that is considerably more than just adding 10 -20 GB of RAM in the TM1 case, so designing more efficient modules (read smaller more compact modules) becomes very important in Anaplan. This is not necessarily a bad thing, but something you must be aware of before just going off and building. (See the blog post from March 27, 2017 called Cognos TM1 to Anaplan for some tips on how to build smaller more efficient modules).
Like TM1, Anaplan is a blank slate. You need to build from the ground up. Dimensions or lists, are built first, then modules (Anaplan term for multidimensional cubes) are created followed by the calculation logic. Like TM1, Anaplan allows the user to create attributes or list properties on the elements of dimensions. These properties can be used in various manners when writing calculation logic. You can aggregate data, perform lookups and perform many more useful functions. In previous blog posts we spoke about the rule logic and how much easier it is to code rules in Anaplan vs TM1. Certainly the rule writing is different in Anaplan as the syntax is much easier to grasp. However you are limited to writing calculations on the Line Items in an Anaplan module. This differs from TM1, where you can address calculations to any intersection in a cube at the most specific of levels or write very general calculations that apply to wider swaths of data intersections.
Turbo Integrator vs Anaplan API
TM1 has its own ETL (Extraction, Transformation and Load) called Turbo Integrator. It is a very powerful tool in the TM1 platform. It can link to many data sources via ODBC connection. It has pre built connections to SAP and other multidimensional sources. Text files can also be used as a data source. It allows you as a model builder to query data sources and transform data that can be used as sources for dimensions or cube data. The tool allows for very sophisticated scripting (if you take the time to learn the commands and have the skillset to code your own scripts). The point is that the tool exists and can be invaluable.
On the other hand Anaplan does not really contain a built in tool for ETL. Anaplan does allow you to import data and perform some simple data mappings in order to get data in the model. You can build lists and populate modules via import routines. However, compared to Turbo Integrator the import routines are rudimentary at best. Anaplan offers an API, import/export capabilities, and pre-built connectors for common platforms like Anaplan HyperConnect, Informatica, Dell Boomi, Mulesoft, and SnapLogic. This means you must own one of these third party vendor tools to leverage the API fully.
The Anaplan API’s do offer a more robust method for mapping and transforming data, but it is not easily learned and requires a very technical skillset (even more technical than the Turbo Integrator Skillset) to fully understand and implement.
So the final take away for data imports and transformation is that both tools offer some form of data import and mapping. Anaplan’s really relies on the generation of text files to act as a source in 90% of the cases unless you own a third party tool and want to use the API.