Often you hear about performing an application design review on a IBM Planning Analytics model where both coding and implementation “styles” are compared against “industry proven” practices. During the process, naming conventions, dimensionalities, rule-vs-process strategies, (just to name a few items) are studied and assessed.
One aspect that is sometimes overlooked in the review is the overall architectural design of the “functional components” of the model. This is an area that can have a profound effect on the performance, sustainability and usability of the model.
Common Components
I believe that all Planning Analytics (formally TM1) applications, are made up of only 4 distinct “areas of functionality” – or components. These are absorption (where key information from external data sources is “absorbed” and sometimes transformed into the models environment), configuration (where assumptions about the absorbed data are set and applied), calculation (where the specific “magic” happens; i.e. business logic is applied to the source data using the set assumptions) and consumption (where the information processed by the application is reviewed and reported on).
Keeping these functional components separate and distinct within a model is known as keeping the design “architecturally pure”.
Advantages to a Functionality Pure Design
Keeping functional areas of a design distinct has numerous advantages. For example:
- It reduces complexity and increases sustainability within components
- It reduces the possibility of one component negativity effecting another
- It enables the probability of reuse of the particular (distinct) components
- It promotes a technology independent design; meaning components can be built using the technology that best fits their particular objective
- It allows components to be designed, developed and supported by independent teams or groups
- It diminishes duplication of code, logic, data, etc.
- Etc.
Resist the Impulse
When performing application design, there is always an inclination to “jump in” and “do it all” using one tool or technology or, in the case of Planning Analytics, create just a few “massive” cubes. In addition, with every software version upgrade, there are new “package connectors” delivered that allow you to directly connect (even external) system components to a model. This often promotes the idea that data staging areas aren’t needed, and that data can be directly queried and loaded to a specific view within a model.
One may “understand the mechanics” of how a certain technology works and this will allow you to “build”, 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.
When creating a design, take the time to not only document detailed requirements, but to also understand how the “functional areas” of the model will work. Believe me, its well worth the time.
Final Thoughts
Some final thoughts:
- Try white boarding the model’s functional areas before writing any code
- Once you have your “like areas” defined, search for already existing components that may meet your requirements – don’t reinvent!
- If you do decide to “build new”, try to find other potential users for the new functionality. Could you partner with another project team or business unit and co-produce (and thus share the costs) of 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? (as 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!).
Happy Designing!
