Building a TM1 COE, Part 1: Application Definition

In an earlier post, I listed the five areas of responsibility typically assigned to a TM1 Center of Excellence. The first of these responsibilities, and the starting point for everything that comes after, is application definition.

"Well begun is half done", as the old adage goes, and one of the bigger challenges I face when working with TM1 customers is helping them decide on the boundaries of their new TM1 projects and applications.

Given TM1's insane level of scalability and flexbility, you can easily forgive architects, developers and their business users and sponsors for getting ahead of themselves when defining the scope of a TM1 application. After all, "To Infinity... and Beyond!" is pretty much the rallying cry of the global TM1 community.

TM1 application definition usually follows an agile, iterative path, but like most things associated with TM1, there is rarely only one way to accomplish something, so the art and science of application definition belongs to the realm of "best practice", a mostly-heuristic body of practical knowledge built up over many years of trial and error. That hard-won knowledge is hopefully retained, amplified and circulated in your company's institutional memory by a TM1 Center of Excellence.

A real challenge in establishing a set of best practices, and codifying them within a COE, is the fact that TM1 does not natively offer a lot of transparency to understand how the parts of an application fit together. For example, I defy anyone reading this article to explain how a TM1 application (even your own...) works just by looking at a list of cubes, dimensions and processes. You might get a general sense of what the application does from the object names (if they are named properly - that topic deserves a blog post all on its own!), but you can never be sure. Among other things, this knowledge and confidence gap is one of the things that Pulse for TM1 fills very nicely. It's not by accident that the tagline for Pulse is "Know everything."

Once you get beyond the Hello, World! stage of TM1 (maybe you tweaked TM1's default "Planning Sample" database a bit and tried to run a budget through it...), your next application definition challenge is understanding what already exists so that you can:

  • decide where the system boundaries and extension points should be
  • determine what objects (e.g. dimensions and hierarchies) you should re-use, and
  • measure how people are actually using the production applications to assess what is adding value and what is not

Again, TM1 does not provide a lot of built-in instrumentation to help you with these tasks, so most of your evidence ends up being anecdotal. For fact-based managers, "going with your gut" is rarely the preferred option for decision-making.

To net all this out, what TM1 COE personnel need is complete visibility into existing TM1 applications so that they can confidently and efficiently build the next one(s).

One of my favorite Pulse features for this TM1 "X-ray vision" requirement is the Model Spotlight, that provides expert and novice users alike with full text search capability on the model (e.g. "Show me all objects that have the string 'Ledger' in them"), and an interactive model visualizer that lets you pan, scan and zoom into the TM1 model and instantly see what object is related to what.

There are many other Pulse features that will help you fulfill the Application Definition charter of a TM1 COE. I invite you to explore all of them on our website, and to contact us if you would like to discuss your unique TM1 challenges and requirements.