Manage Framework Manager Model Changes

Managing change is difficult in any aspect of life, whether changing jobs, moving cities or simply adapting to the fact that Panera has done away with your favorite Cuban Chicken Panini (bummer, right?).

Addressing changes in business critical systems can range from mildly annoying to down right time consuming depending upon several factors. How big your environment is, measured by the number of users, developers, servers, and reports, is critical to consider. The larger the deployment in any of these terms increases the environment’s complexity. Layer on top of that the need to roll out changes that don’t interrupt daily operations and suddenly you can hear gears grinding to a halt.

Many software houses have adopted specific software and rigorous processes which manage the chaos of change. These systems, known as version control systems, keep old revisions, have the ability to roll back changes in the event of catastrophic change or deletion and can even branch and merge disparate development efforts. We all try managing our own needs for change management to some degree when we ‘Save As…’ with an important document, but these systems are built for stability and to reduce the risk of introducing a disruptive change to internal or external customers.

For many Cognos deployments, particularly in their early stages, either the environmental complexity, qualified personnel, financial commitment or general process discipline doesn’t exist by which to purchase and implement, let alone make use of such a system. The goal for my post is to outline a simple manual process that, when adhered to with regularity, has shown to reduce risk of changes in the Framework Manager Model development cycle.

As a self-contained output of the Framework Manager model, the package serves as a stable source upon which the reports are built and run. Introducing new requirements, however, can prove to be challenging.

• Can the current production package be regenerated in case of deletion or corruption?
• How can model changes be tested without interruption to production reports?
• How can we roll back to a prior version if errors are not caught before production?
• Can we have user acceptance of the changes before committing to a production version?

The process is analogous to a consistently applied and well managed ‘Save As…’ paradigm and is outlined here:

Purpose

To establish a process by which precautions are taken to ensure no unintended changes are allowed into normal daily operations and to prevent accidental deletion or modification of operational reporting structures.

By investing regular time in following the process below, the risk of rework or report inoperability is greatly reduced. Between this process and an automated server backup the chances of losing work are nearly eliminated.

Ideally this process can be managed by a version control system, however often these systems are unwieldy and overpowered for many implementations.

Requirements

• Compression Software (ex. WinZip, 7Zip)
• It is recommended that a PDF (uneditable) version of this process be stored in the root of the folder structure below
• Regularly Scheduled Backup of the File System
• FM_Models Folder Structure
  • FM_Models\_DEVELOPMENT
  • FM_Models\_PRODUCTION
  • FM_Models\_PRODUCTION\_ARCHIVE

IBM Cognos Framework Manager Package Release Process*
DESIGN CHANGES ARE TO BE MADE ONLY TO DEVELOPMENT MODELS, NOT TO PRODUCTION MODELS

1. OBTAIN approval via the current Change Management Process
2. COPY current FM Development Model Project Folder
3. PASTE copied FM Development Model Project Folder into FM_Models\_PRODUCTION folder.
   1. This is now the latest Production Model.
4. OPEN the latest Production Model (newly copied from prior step).
5. RENAME the desired Production Package from within the project from its Dev name to Prod name by replacing the word ‘PRODUCTION’ with your ‘CompanyName‘. See Example Below.
   1. Example
      1. Dev Name: PRODUCTION Finance
      2. Prod Name: CompanyName Finance
   2. NOTE: The step to rename prevents an accidental publishing of the package within the development folder. When package locations and names match from Framework manager to Cognos Connection, the target package is overwritten.
6. PUBLISH the desired Production Package.
7. SAVE & CLOSE the FM Model.
8. ZIP current FM Production Model Project Folder.
9. RENAME zipped copy with prepended date for straightforward reference and ordering.
   1. Example
      1. 20150326_model.zip
   2. By immediately zipping and archiving the production model, the chance of unintended modification, confusion or package publishing is reduced dramatically.
10. DELETE the FM Production Model Project Folder after its archival.
11. MOVE renamed, zipped copy to _ARCHIVE folder.
12. COMMUNICATE completed change to appropriate stakeholders.

*NOTE: Many of these steps can be scripted via command line or framework manager XML scripts.