What makes someone a TM1 "architect?"

[Aussie_Consultant]

I am curious what the forum believes distinguishes a solution architect from an experienced consultant and implementer.

I know this is vague but so is the idea of an "architect."

P.S. Would the IBM TM1 "master" certification be worth the effort?

[Alan Kirk]

I am curious what the forum believes distinguishes a solution architect from an experienced consultant and implementer.

I know this is vague but so is the idea of an "architect."

To me "architect" is nothing more than the GUI .exe that you use when you aren't using Excel or Web.

Seriously, "architect" isn't a term that IBM uses as a title in any of its training courses. It thinks of qualifications in terms of the four roles of Administrator, Explorer, Contributor and Modeller, with the last one being the only one which has an extensive path and one which leads ultimately to the "Master" certification that you mention.

But of course in the more generic sense, a solution architect would be someone who could design a system from the ground up just as an architect designs a building. You'd need to be across an entire range of things starting with hardware, some of the more esoteric features of Windows like IIS if you're deploying Web, the changed security model in WS 2008, possibly Citrix, then moving on to TM1 itself; cubes, dimensions, rules and feeders, TI, locking models in different versions...

Because TM1 is such a flexible tool it's unlikely that two deployments of it will be exactly the same. Consequently for any but the simplest models you really won't be able to implement a solution from a script. And consequent to that I don't believe that you can have an "experienced consultant and implementer" who is not also someone who can and does design the model from the ground up, though I'd imagine that in some consulting firms there may be people who specialise in particular areas and so both the architecture (the original design of the model from hardware to user interface) and the deployment of it (the actual installation and testing) would become more of a collaborative effort. Even then, though, I think that the people doing it would have to have a range of knowledge across the TM1 spectrum, beyond their own speciality.

Of course the other thing to consider too is that it's one thing to design and deploy a system, another to run it. Things that work in theory don't always work in practice, and I think that someone who really knows their TM1 stuff would have to have spent time not just designing and implementing systems, but also driving some for a reasonable period. Because it's in the driving that you occasionally need to pop the bonnet and get into the engine to see what's going on when things don't work as designed, and possibly fix them on the fly.

P.S. Would the IBM TM1 "master" certification be worth the effort?

Depends on how you look at it. One thing to note is that you apparently can't do it in isolation; before you even undertake it you have to also have qualifications in:
- IBM Cognos TM1 Design and Develop Models (9.5) (5 days, $US3500, AUD $4450); and
- IBM Cognos TM1 Analyze Data (9.5) (3 days, $US2100, AUD $2670).

The Master course itself is 5 days, $5 grand US, $AUD4450. (No idea why that one is cheaper down here, but that may reverse itself after our dollar tanked last week as investors did the headless chicken dance.) Though I do note that they're now offering some self-paced courses which give you a 30 day window to complete it, and which cost less; around $AUD 3500 for the 9.5.1 one.

However if you're looking at instructor-led training, you're looking at sinking the better part of AUD $12K and over 2 and a half weeks. A lot of the content, an experienced TM1 designer (architect, if you like) / implementer / administrator should already be across but nobody knows everything (not even me ) and so it would be a rare TM1 specialist who could learn nothing from it. Also it would certainly do you no harm on a resume, and if you're a consultant then potential clients might be more comfortable in hiring people who have formal qualifications as well as experience. (Though in reality most probably only care whether you can deliver what you promise.)

If you have the time and money, you may as well go for it. If you don't have extensive hands on experience with TM1, you should definitely go for it since you have to start learning somewhere. Though I'd have to add that the claim that anyone would come out the other end with "a Black Belt level of training" makes my teeth grind for a couple of different reasons. One I won't go into here and the other is that all the theory and training in the world won't help you when practice collides with theory and things Just Don't Seem To Work Right. That's where experience, intuition and skill come in, none of which a piece of paper can bestow.

[John Hammond]

Thanks, Alan, for that comprehensive answer which is of use to coders of all levels of experience.

One thing that does occur to me is that TM1's application base is a large fraction the Chart of Accounts forecasting model. This is based on limited evidence and others (particularly external consultants) might set me right, but having seen a number of sites and followed this forum, I think it would be a reasonable guess to say that 50% or more of TM1 applications are of this type.

Once you have knowledge of this model it is easy to replicate in another company because of the inherent similarities in all Chart of Account / Forecasting processes. It is almost as if this model was designed to be implemented in TM1! Indeed I would go so far to suggest that this model might have been the inspiration for TM1 since it is natural to want to slice and dice on the various dimensions.

So being able to implement the COAFM while it is a useful skill is not the be all and end all of TM1 design since it tends to be copied from one site to another. I would regard the skills of an "architect" good if he had implemented a system of this sort but inferior to someone who had successfully implemented TM1 in another area (FMCG for instance) since there is a greater degree of design involved.

I would appreciate hearing what others think about the prevalence of the COAFM.

[Steve Rowe]

Hi John,
I think you are probably right that a COAFM is the most common use of TM1 and if that is what you want to build then it makes sense to employ someone who has done that before.

I've done many of these type of implementations and whilst broadly the one liner project description is the same the applications usually vary alot due to the frequency, granularity and approach to forecasting. I've yet to implement anything that approaches a "plug and play" system but I guess this depends on your target market and how much they want to compromise what they think they want versus what they are prepared to pay for....

As far as what makes a good TM1 architect, there are a lot more components to TM1 system than there used to be but you need lots of experience in the development of the core pieces of a TM1 system, i.e. Cubes/Dimensions, Rules/Feeders and TI. All the bells and whistles won't hide a badly designed system forever, though they are pretty good distraction!

I'd also agree with Alan that a good developer should have time at the coal face in an operational role looking after a TM1 system on a day to day basis. This can make a big difference in the quality of the final product. This also helps when it come to translating the business requirements into a TM1 design.

I've no experience of the exams so can't comment.

Cheers,

[jim wood]

On top of some of the points that you have already raised I have found a good working of databases and other potential data sources comes in handy. It's one thing being able to design something to meet requirements, it's another to taylor that and fit it within you have available. (Sometimes it can help when trying to explain to DBA's what you need.)

Jim.