Overtime, I’ve written about keeping your TM1 model design “architecturally pure”. What this means is that you should strive to keep a models “areas of functionality” distinct within your design.
Common Components
I believe that all TM1 applications, for example, are made of only 4 distinct “areas of functionality”. They are absorption (of key information from external data sources), configuration (of assumptions about the absorbed data), calculation (where the specific “magic” happens; i.e. business logic is applied to the source data using the set assumptions) and consumption (of the information processed by the application and is ready to be reported on).
Some Advantages
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
Keeping functional areas distinct has many advantages:
- Reduces complexity and increases sustainability within components
- Reduces the possibility of one component negativity effecting another
- Enables the probability of reuse of the particular (distinct) components
- Promotes a technology independent design; meaning components can be built using the technology that best fits their particular objective
- Allows components to be designed, developed and supported by independent groups
- Diminishes duplication of code, logic, data, etc.
- Etc.
Resist the Urge
There is always a tendency to “jump in” and “do it all” using a single tool or technology or, in the case of Cognos TM1, a few enormous cubes and today, with every release of software, there are new “package connectors” that allow you to directly connect (even external) system components. In addition, you may “understand the mechanics” of how a certain technology works which will allow you to “build” something, but without comprehensive knowledge of architectural concepts, you may end up with something that does not scale, has unacceptable performance or is costly to sustain.
Final Thoughts
Some final thoughts:
- Try white boarding the functional areas before writing any code
- Once you have your “like areas” defined, search for already existing components that may meet your requirements
- If you do decide to “build new”, try to find other potential users for the new functionality. Could you partner and co-produce (and thus share the costs) a component that you both can use?
- Before building a new component, “try out” different technologies. Which best serves the need of these components objectives? (A rule of thumb, if you can find more than 3 other technologies or tools that better fit your requirements than the technology you planned to use, you’re in trouble!).
And finally:
Always remember, just because you “can” doesn’t mean you “should”.
