bunchukokoy wrote:
I am kind of shocked in a way because they're asking for cubes to contain an average of 25 dimensions each. Which I'm not used to. In my past clients, as I recall the most number I developed is below 15 dimensions for just one or two cubes only.
But in this client, they're asking me to contain different dimensions found in their sources.
I know that I have a choice. One is to explain that this is not a typical practice to contain cubes with ave 25 dims each. Another is to propose a creation of cubes with same measures but with with different dimensions, that's if they'll understand what I mean and what I'm trying to avoid.
But currently, it seems that, they want what they want. Where in fact TM1 is not of mainstream reporting tool.
It's just that, maybe, I should have a more powerful voice on explaining the normal practice up to what is least accepted.
Who exactly is saying that cubes should have 25 dimensions and
where and
why? Is this listed in a technical specification document for the project? If so why was the design specified? What are the
actual user requirements? As in forget about technical specifications and cubes and concentrate on user requirements:
- what should the reports look like?
- how should the reports be able to be filtered and aggregated?
- what kind of ad hoc analysis needs or might conceivably need to to be done?
This is what should inform the technical design. The best design might be to have a lot less dimensions and more attributes, it might be to have a tiered cube design with "optimized" cubes with less dimensions for most summarized level reporting and "exploration" cubes to drill in to with more dimensions and/or more data granularity for analysis where sub-second query performance is not so important. The best design might be to have one size fits all cubes with 25+ dimensions but it is probably unlikely.
The key is to go back to user requirements and build a quick PoC cube and test this with end users, or if you have to with the Project Manager if direct access to business users is not available. If the users are used to Qlickview then their perception of what they "need" will be shaped by the tool that they know. Qlickview uses columnar processing and doesn't have a concept of multi-dimensionality or hierarchies like TM1 does. What in a TM1 cube might be an alternate hierarchy, attribute or additional measure will all be handled in Qlickview as additional columns.
That said if a large amount of "slice and dice" ad hoc analysis is needed then lots of "attribute based" dimensions may be the only way to go (especially if Cognos BI is the report delivery UI) as TM1 can't do ad hoc calculations with attributes anywhere near as easily as can be done with SQL in an RDBMS. But even still I would push to see whether this is really needed
all the time versus a streamlined cube for 95% of all reporting plus a more detailed cube to dive into for analysis purposes.
Maybe it is just a case of
interpreting or translating the requirements into "TM1 speak" and what is specified as a dimension is really a hierarchy for example once the requirement is properly understood. One thing is for sure and that is to get to the bottom of what the end user requires. If a poor understanding of the tool leads to a poor design and then poor usability and poor performance then it is the tool that ultimately gets a large proportion of the blame and that is always a shame and the reason for many project failures. So yes it is your job to speak up and have an opinion not to just implement whatever is asked without some intelligent questioning. If the customer doesn't understand the tool they have been sold then someone has to educate them and the time to do it is BEFORE a poorly thought-out design is in place not afterwards.
