At some point you may have developed and delivered some sort of financial model in TM1/Planning Analytics – perhaps starting with the reporting of financials –  and have now been tasked to “add” planning and budgeting (or other) functionality to it. Before you even begin gathering requirements for the new functionality, it is recommended that time be spent reviewing and evaluating the already delivered model and its assets looking for reuse opportunities.

In software development, reuse is the practice of using “pieces” (or components) of existing software, or software knowledge, to build new functionality and or features, following the “reusability principle” which states that (ideally) whatever it is that you want to reuse should be generally easy to reuse. In other words, you should be able to use instances of an already developed “component” in different systems and/or the development of new functionality to save design, development and unit test time.

Obviously not every part or piece of a model is a candidate for reuse, so how can you identify what might be?

First, be sure to start with a mindset that a reusable component isn’t limited to actual software code (or in the case of TM1/Planning Analytics, TurboIntegrator scripts, rules and feeders, workspace or other objects) but can be requirement specifications, design documents, a user interface template, user-focused documentation, or any other item associated with what has already been built and (hopefully) successfully deployed. Basically, anything used and/or delivered during the project life cycle should be looked at as a (potential) reusable asset.

Some examples that are not necessarily software code but are still valuable as a reusable asset might include:

  1. Requirements documents and project plans – these will be good points of reference when creating versions for new projects and be templates outlining common formats that the team will be familiar with.
  2. Test Scripts and Reconciliation Sheets– prior test scripts highlight areas of the business that are particularly challenging to successfully test as well as the level of effort required to address these areas. Reconciliation sheets may be usable “as is” or after minimal modifications. For example, if you have an Excel worksheet that compares views of data after a process runs, it may be able to be used after a new process or feature has been implemented.
  3. Performance baselines – these will indicate the acceptable levels of performance for various work to be performed within a model and can be the standard for evaluating new feature performance for related or similar work. An example might be elapsed time to load data into a cube or how fast a dynamic report refreshes.
  4. Progress reports – Typically these will be the easily understood documents indicating the status of the project at specific stages and will already be familiar to those supervising the project.
  5. Dimensions – Some dimensions will be common across an organization, for example “company” or “item” or “account” so reusing dimensions (and their supporting maintenance processes) will save development time and not require duplicate maintenance efforts. If there are unique security or reporting requirements by the new functionality, they will most likely be able to be handled with alternative hierarchies and element security.
  6. Subsets and Views – in TM1/Planning Analytics projects it’s common to sort dimensions into commonly used groups or lists. These are the subsets and views that are predefined to save time and improve usability within the model and most likely have been created and validated by the business user community and almost always are reusable in any new functionality.
  7. MDX statements and logic – MDX is an industry-standard query language for multi-dimensional databases like TM1 and part of best practices. Once MDX queries have been implemented they should be considered assets and maintained and leveraged as such.
  8. Element or field mappings – Many times a “mapping” is developed to “translate” elements (for example accounts) or fields between systems, departments, or even cubes. These mappings can take time to develop, validate and maintain. Whenever possible, determine if a mapping already exists and can be used by the new functionality.
  9. Stake holders, Acceptance Testers, and System Administrators – this may or may not be obvious, but if during a previous TM1/Planning Analytics project certain individuals stood out (say as meticulous testers or helpful in other roles) or someone had a positive or negative impact on the project (by contributing their experiences and perspectives), it is very important to identify these individuals to either enlist their continued help or support (or avoid involving them).

To determine if there are leverageable areas of actual software code in an existing model you need to be able to perform what some refer to as “component analysis” which is the process of identifying potential objects or areas of code for how it completes the criteria used in your evaluation.

Apart from knowing the specific requirements of the new functionality, you can consider the following as general guidelines:

  • General Requirements – do your new functionality requirements match the delivered components specifications?
  • Component Mechanics – can the new functionality provide the delivered components minimal input parameters, so it works properly with every use case?
  • Architectural Position – will the new functionality adhere to the architectural principles required to support the delivered component in its current state or significant rework be required?

Most importantly, you’ll need to determine if the functionality specifications are defined as to adhere to or take advance of the specifications of the delivered component.  Does the identified component actually do what you need? To answer this question, you need to examine and understand the inter-workings or “mechanics” of the delivered component. The first step is to examine the delivered components documentation. If there is no documentation, then you shouldn’t be considering leveraging it (it’s not mature enough).

Conclusion

Leveraging what has already been delivered saves time, encourages consistently, supports sustainability, and can eliminate surprises – which typically result in setbacks and cost overages. Making a habit of reviewing your existing assets as part of every new development project can greatly optimize the development process and can help reduce costs, save time, and reduce risk.