Why TM1?

[Plunge pool]

If I needed to make a business case on why I should use TM1 over tools such as Microsoft SASS, could I get a few pros and cons in a few sentences?

Only things I can think of is.
Pros
-writeback capability
-forecasting ?
-easier to learn than SSAS ?
Cons
-Not the best integration with Excel (active forms take over entire rows, existing macros are clobbered)
-Need to use Cognos suite of tools,
-hard to connect to TM1 cubes using other reporting tools like Tableau or Qlickview

[Alan Kirk]

Additional Pros

• In memory speed
• Extremely flexible in designing and building cubes
• Very fast ETL tool in TI
• Powerful and flexible rules calculation engine which enables business rules to be applied consistently on the server side
• Excel integration allows you to use VBA for automation purposes
• And a bunch of others that others may add to

Cons
None that you have listed but I'll come back to that.

• Lack of effort by Iboglix in updating things that are essential to running a system but aren't of value in sales presentations (TI Editor, for instance)
• Underdevelopment of some APIs (.net, I'm looking at you.)
• Under-documentation particularly of the APIs, and an absolutely rubbish structure to the documentation.
• Inability to easily do asynchronous row and column arrangements.

And it's worth noting that of these only half are end user issues, half are admin issues.

Now to the ones that you've raised.

The gods (and the photo of me stuck in the centre of the Iboglix development team's dartboard) know that I'm never reluctant to lay criticism, but I like to think that I keep it to situations where it's warranted.

I'm afraid that your examples aren't it.

It has the best integration with Excel of any product that I can think of. Active forms take over entire rows? Of course they do, there's no other realistic way of making them work within the nature of an Excel worksheet. Active forms are intended to be used where you can have a variable number of data rows from 0 to however many exist / will fit. This necessarily involves both deleting and inserting rows as required. If you want to have a pretty chart or something off to the right of it (say) that's fine, but first of all if it's tied to the data in the active form then I'd hate to see the code needed to get it to display properly when the number of source rows are variable. Second of all I'd like to see the code that can avoid that chart being stretched, distorted and/or obliterated upon insertion or deletion of rows. That's an Excel thing, not a TM1 thing. If the number of source rows aren't variable, then you don't use an active form, you use a fixed block of DBRWs. That way you can have whatever your heart desires on either side of them.

The fact that active forms can have multiple sections and that you can have multiple forms on a worksheet, all dynamically restructuring the sheet on the fly (and doing it at quite remarkable speed) including formatting the newly created rows in almost any way you want based on criteria that you can set yourself, with the only requirement that you give it a free hand on its own rows, makes it a remarkable piece of technology. {Sound of IBM developers fainting at hearing praise from my keyboard.}

Also if your "macros are clobbered" and there are tens of thousands of people out there who have macros which AREN'T "clobbered" (which there are) then it's time to be looking at your macros and/or your environment. Think about it for a minute. If the TM1 add in is loaded, but you haven't connected to TM1... then what exactly is the add-in doing? It's not going to be executing code beyond updating the ribbon tab when it loads, so where, exactly, is the conflict coming from?

The sole exception is if the user is actually ON the TM1 tab, since the tab will update dynamically according to context. I put it on record in one of my videos that I thought that was a bad idea; it's paying too high a price in processing overhead and running the risk of corrupting the icons on the TM1 tab when both could be avoided by having a static ribbon with error messages if a user uses a button out of context. {Sound of IBM developers reviving as normal criticism is restored.} However first of all the solution to that is to stay off that tab when it's not in use, and second of all the only way it could be a conflict is if the code that it's conflicting with is precious enough to assume that the ribbon will be neither modified or updated by any other add-in. In fact with TM1 (or any other add-in for that matter) loaded but inactive, the ONLY kind of code that is going to have conflict issues is badly written code.

"Need to use the Cognos suite of tools..." says who? If you're talking about Cognos BI /Reporting, then no, it's still possible to run TM1 without that. We do. You can use Excel as an interface, TM1 Web, Executive Viewer, third party applications like but not limited to Quebit's OLAP Objects (now known as WebWORQ, apparently), and so on. For administering the thing you have the legacy Excel interface, you have Performance Muddler if you absolutely must, you have third party tools like but not limited to Cubewise's Vizier, or you can write your own in the TM1 API.

Hard to connect using other reporting tools? Maybe, I can't comment on the examples provided. But I'd suggest that that comes down to ineptitude or lack of interest on the part of the developers of the other tools. If what you're after is simply pulling data then TM1 offers not one but three APIs to allow you to do this. The original developers of (say) Executive Viewer seemed to have no problem doing it, and there are plenty of other third party tools that manage it just fine. But it does raise the question of exactly how many reporting tools you want to use at one site, and whether you're getting any real value out of having a smorgasbord of them. (Which of course, can lead to the situation where users have to learn "Oh, we go to Tableau to get this report, but if we want that report we go to Qlickview, but if we want to see the other figures we go to TM1 Web...". In this way everyone knows just enough about each reporting tool so that it takes them x times longer than they need to to get to where they want to go. Call me old fashioned, but this strikes me as being "sub-optimal" compared to having a single reporting tool which everyone can learn well.)

[Harvey]

I think you'll find the majority of active members on this board will be techies and TM1 fan-boys, so the "in a few sentences" part might be tricky, as Alan kindly demonstrated

If you're looking for dot-point benefits, IBM should have enough marketing material to keep you going. If that fails, check out some of the IBM partners who put out white papers and other marketing material, or check out the OLAP Survey for other ideas.

[Alan Kirk]

I think you'll find the majority of active members on this board will be techies and TM1 fan-boys,

As the reaction to Performance Muddler and the new 10.1 Java apps from many and varied members shows clearly.

so the "in a few sentences" part might be tricky, as Alan kindly demonstrated

The bullet points are in the first few lines of the above reply. The remainder of the post was explaining why the "anti" bullet points in the original list were wide of the mark. Although the Twitter generation may contend otherwise, 140 characters do not lend themselves to depth of thought.

If you're looking for dot-point benefits, IBM should have enough marketing material to keep you going.

IBM marketing material of course being widely regarded for its conciseness, and ability to get to the point in not (many) more than than 24 volumes. While 140 characters are frequently meaningless, so is endless drivel that is at best beside the point and at worst aimed at the worst excesses of Pointy Haired Bosses.

For another instance of IBM's ability to write to the point, see also "IBM Cognos TM1 The Official Guide". 12% of the way into the thing I had read all manner of self-evident bumf, page after page after page of "Challenges of Meeting Enterprise Performance Management Requirements" including one sub-section on "Increased forecasting and budget cycles" (no s**t, Sherlock), and "The Promise of In Memory Analytics". 12% of the entire book and not a single word on how to work hands-on with TM1. What it is, what it does for your business. At best, only hints of that are buried in the first two chapters. And this is in "The Official Guide". (But there was plenty on Dr. E.F. Codd's thoughts about treatment of non-normalised data and automatic adjustment of physical level, as if anybody who is looking to see whether the product would be a good fit for their business would give a flying fornication about OLAP computer science theory.)

Had I bought the physical book, it would have impacted against the nearest wall. Thankfully for my paintwork I had it on my Kindle so I just flipped across to Dr. Richard A. Gabriel's bio of Scipio Africanus instead. At least Gabriel knows how to get to and make a point. I have failed to return to the Guide at any time since then.

A search of this forum may also yield some of the pros and cons of TM1, probably more objective sets than you're likely to get from IBM. There are not, in fact, many fanboys here. There are many who appreciate and like the product for what it can do, but few who are not frustrated and annoyed by its shortcomings as well.

[Harvey]

A search of this forum may also yield some of the pros and cons of TM1, probably more objective sets than you're likely to get from IBM. There are not, in fact, many fanboys here. There are many who appreciate and like the product for what it can do, but few who are not frustrated and annoyed by its shortcomings as well.

Sorry if the fan-boy label offends, Alan, I intended use it tongue in cheek and apply the same label to myself with some level of ironic pride.

Your description, of course is entirely more accurate.

[Alan Kirk]

A search of this forum may also yield some of the pros and cons of TM1, probably more objective sets than you're likely to get from IBM. There are not, in fact, many fanboys here. There are many who appreciate and like the product for what it can do, but few who are not frustrated and annoyed by its shortcomings as well.

Sorry if the fan-boy label offends, Alan, I intended use it tongue in cheek and apply the same label to myself with some level of ironic pride.

Your description, of course is entirely more accurate.

Yours is more concise though.

(I just didn't want Plunge Pool to get the idea that he wouldn't get unbiased information here...)