MicroStrategy Development Methodology

TABLE OF CONTENTS

TABLE OF CONTENTS .............................................................................................................. 2 I. Introduction.............................................................................................................................. 3 II. Environments .......................................................................................................................... 4 III. Life Cycle ................................................................................................................................ 5 IV. Requirements Analysis............................................................................................................ 5 V. Design Methodology................................................................................................................ 8 VI. Development Methodology...................................................................................................... 9 VII. Object Management .............................................................................................................. 13 VIII. Scan MD Metadata Sanity.................................................................................................. 13

I. Introduction
It is critical for every BI implementation to use a standardized approach to managing the development and release of new reports and objects. As part of a sound, structured development life cycle, project administrators must employ object change management strategies which include following standardized development procedures and implementing security access controls. Moreover, the inclusion of multiple development groups, further necessitates the need for a rational change management strategy to ensure application integrity. The purpose of this document is to define a standardized application development and release methodology for the MicroStrategy projects. This document is a collection of policies, processes and procedures used for BI report development. This document covers the following aspects: (i) (ii) (iii) (iv) (v) (vi) MicroStrategy Environments MicroStrategy Connectivity Architecture Life Cycle Explanation of recommended methodology for Requirements gathering and Design Explanation of recommended development and object management methodology Description of object migration process

II. Environments
Almost all MicroStrategy projects have atleast 3 main environments which are explained below. Some projects may have Training environment along with these three main environments. (1) All the Development and Unit Testing will be carried out in the Development environment, which is a replica of QA, and once tested and verified will be moved to QA. (2) The QA system will be used for unit and system testing. No object development is allowed here. (3) The Production system shall be used for production purposes. No object modification is allowed here. Each environment is connecting to its own metadata repository and warehouse. The metadata can be on the same database instance as the warehouse.

The onsite servers can be accessed via Terminal Services with the MicroStrategy Desktop installed and with no administrator components. The offshore developers should have access only to the development environment and restricted access to the QA environment at any time. Only the onsite team will have access to the production environment.

III. Life Cycle

The figure below describes the basic project life cycle and where Microstrategy products and services can be utilized

IV. Requirements Analysis

Complete Business Requirements for Reporting are captured and mapped to corresponding MicroStrategy objects to ensure that the requirements are feasible in MicroStrategy. The following requirements checklist helps in gathering the complete requirements

Sl. 1. 2. 3.

Questions Are the report layouts pre-defined? How many reports are to be developed? Does the data mart already exist in the system (applicable for migration projects/only MicroStrategy development projects)? Can all the report columns be mapped to the columns in the datamart ((applicable for migration projects/only MicroStrategy development projects) Are there any formatting requirements for the reports? If the answer to the above question is yes, what are the formatting requirements for the reports (font, border, cell alignment)? If there are any requirements not feasible in MicroStrategy, will the requirements be slightly modified to suite the MicroStrategy product suite? Are these reports delivered to the external customers? If the answer to the previous question is yes, what is the intended delivery mode? Is ad-hoc reporting in scope of this project? Are there any graphing requirements for the reports? If the question to the answer above is yes, what are the exact graphing requirements? What is the expected number of data points in a graph report? Is data security using security filters a part of this project? Is object level security desired from this project? What is the maximum number of rows that can be present in a report? Are thresholds to be applied to report values? Are there requirements to combine multiple reports in a single display? What are the analytical functions involved in these reports? What is the display format for each calculation displayed in the report? Are there any custom display formats desired in these reports? What is the frequency of data load in the data mart? What is the expected performance limit of each report and how much is the

Y / N / NA

Comments

4.

5. 6.

7.

8. 9. 10. 11. 12.

13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

expected performance limit feasible? 24. How are NULL values expected to be displayed in the reports? 25. What is the maximum amount of time a user can remain idle being logged to the intelligence server? 26. What are the access privileges to be granted for each user/group? 27. How often do the report layouts change? 28. Are there any reports to be scheduled? 29. If the answer to the above question is yes, should it be time-based or event-based scheduling? 30. What is the sorting behavior desired for each report? 31. Should drilling be enabled for the reports? 32. What is the desired behavior for each report? 33. Are there any requirements for displaying individual attribute form names in the report in web? 34. Are web users supposed to set thresholds for report metric values from web? 35. Are there any prompt display customizations desired? (the client should be educated about the available prompt styles in MicroStrategy before asking this question) 36. Are there reports with nested prompts? 37. Is the functionality of nested prompts spanning multiple pages in web acceptable to the end user? (this is because nested prompts span multiple pages in web) 38. What is the configuration of the MicroStrategy intelligence server machine (development, QA and production)? (for performance measurements and standardizations) 39. What is the maximum number of reports that a user will execute during a particular login? 40. Should pivoting be allowed in the reports to the end-users? 41. Are there requirements for dynamic graph generation with large number of data points from MicroStrategy web? 42. Are graph axes labels to be displayed by default for graph reports? 43. Are NULLs to be a part of graph report display? 44. What is the maximum number of column

series expected in a graph report? 45. Should grid lines be displayed in graph reports? 46. How are the percentage metrics expected to be displayed with respect to graph axis display? 47. Is zooming a desired behavior in graph reports? 48. How are sub-totals expected in the reports? 49. Are the combination of sub-totals expected for adjacent columns in the reports? 50. Is threshold display desired for subtotals? 51. Is reporting from multiple data marts in a single report desired from this project? 52. Is reporting from heterogeneous databases desired from this project? 53. Which users should be given more priority when job execution is considered?

V. Design Methodology
a. A logical data model is established for a project by examining the business reporting requirements of user community and the availability and the structure of source data b. Using Microstrategy Architect schema objects are created that represent the different pieces of the logical data model c. There are four steps to create schema objects Identify the facts required to satisfy your user reporting requirements. Fact object are defined on columns, which are primarily numeric and/or aggregatable, examples - sales and profit. After identifying the facts, the level at which each fact will be reported is also determined.

Identify the attributes Entities in the business model are normally identified as attributes. Attributes define the level of detail of a report. Determine the relationships between the chosen attributes Three types of relationship can exist between directly related attributes o one to one o one to many o many to one o many to many Many to many relationships are normally not desired and should be resolved using relationship tables appropriately.

Define hierarchies based on the chosen attributes

Hierarchies are created by grouping the attributes that are directly related to each other. d. Report Designers can then use these schema objects to create application objects like metrics, filters, prompts, templates e. Reports are then created using the application objects. f. Microstrategy shall only access the database via logical views. Direct access to physical tables shall be avoided. g. All database schemas shall be designed as per dimensional warehouse modeling standards with either a snowflake or star or hybrid schema. h. Use of aggregate tables and fact table partitions is recommended for performance reasons, but the appropriate analysis requirements must be considered during the design of such mechanism. i. Implementing as much business logic as possible within an ETL process (the physical database design process) rather than in MicroStrategy. j. Use appropriate wizards for the creation of attributes and facts. k. Attribute column names shall be suffixed with ID. l. Fact column names shall not be suffixed with ID. m. All occurrences of an attribute or fact column, in all tables, shall have the same column name. Heterogeneous column names shall be avoided wherever possible. n. Save the objects under respective folders to avoid confusion and to make the search easy.

VI. Development Methodology

Development Folder Structure and Security

Creation of appropriate folder structures for Onsite and Offshore Developers with security controls in the Development Environment. This is to ensure proper object version control management during development phase. Public Objects Folders o Objects related to developed and verified reports will be moved from Offshore Developers folders to appropriate folders in Public Objects folder. The default MicroStrategy folder structure is recommended for the new high-level structure. o Public objects security - The Public Objects folders will have strict Access Control Lists (ACLs) applied to them such that only the Administrator user will be able to make modifications to the folder structure and contents. The group Everyone will be granted only View access to all Public Objects Folders. Developers Folder o Development Folder Structure The developers folder will have two sub-folders, OffShore and Onsite. Any objects that are remaining in the Developers folders will solely be objects that are currently being developed or fixed. o Development Folder Security

New Developer user groups will be created and application functional privileges will be granted using a Developer security role. Developers will be granted all Web privileges and all Desktop Designer and above privileges through this security role. Developers will not be able to create or modify schema objects, however they will be able to use the Architect editors in order to examine the definitions of existing schema objects. Each folder will have developer group level security applied to it such that developer group will only be able to see their groups folders. In addition, modification privileges will be granted to specific users for their personal development folders. Production Support Folder o Production Support Folder Structure A new Production Support folder will be created in the Development project to provide an area for Production bug resolution. Initially, the On-Shore development team will be the only development group who has access to this set of folders. Sub folders will be created in the Production Support area for each on-shore developer. A separate folder will be created inside a developers prod support for each production support issue that a developer is currently working on. It is hoped that these folder names can be reconciled with actual Prod Support Issue #s. o Production Support Folder Security Privileges to these specific developer prod support folders will be restricted to View only for other OnShore developers and business analysts, and modify privileges will only be grated to the individual whose prod support folder that is.

Development Process

New Report/Object Development o All Schema Objects (Attributes, Facts, Hierarchies, Partition Mappings, Transformations) will be created by the Administrator or the architect who has been granted access to create schema objects by the administrator. o All required public objects (Reports, Metrics, Filters, Prompts, etc.) will be created by the Developers in their appropriate folders. o Project Level Settings VLDB Settings, Caching, etc. will be done by the Administrator. o Administrative Tasks Scheduling, Cache Management will be done by the Administrator. Development Folder Use o Developers should organize their objects by type into the appropriate object type folders (i.e. metrics, filter, reports, etc) prior the migration to the Public Objects folder.

Developers should have the ability to create additional Sand Box folders within their own personal development folders. Public Object Re-Use o Reuse of all the application objects defined in public objects folder whenever possible. Off-shore Development Process o The on-site servers can be accessed via Remote Terminal Access. A Microsoft Access copy of the development metadata will also be sent to the off-shore team to conduct further research and prototyping. o Migration Request Document is needed to keep track of all the objects which needs to be migrated to Public objects folder from development folders. Object Migration o Object Migration Requests within Development Objects will be moved from the Developers folders to Public Objects by the Administrator using the Migration Document as a reference. o Migration from Development to QA All the objects are migrated to the QA environment using Project Merge Wizard. If any change needs to be after migration, the investigations are done in development and the object which is changed is migrated using Object Manager tool. The administrator can determine which objects need to be migrated, as well as conflict resolution options in case objects that are being moved already exist in the destination object. o Migration from QA to Production All the objects are migrated to the QA environment using Project Merge Wizard. The project can be duplicated to production also from QA. o Bug Fixing If an object does not pass QA test, the issue is fixed in the Development environment and Unit Tested and migrated to the QA environment as specified. From the QA environment, the report is migrated to the Production environment using Project Merge. o

A sample Conflict Resolution Grid is shown below:

VII. Object Management

MicroStrategy Administrator Tool, Object Manager checks for the object dependencies. As a result, it is not required that base objects, such as the attributes and metrics of a report, have to be duplicated before the report. Furthermore, multiple objects can be moved or copied at the same time. The enhancement or bug fixing of existing objects should be handled in the following way: The change has to be made in the object itself in the development environment, prior to being migrated across the systems. The reason is MicroStrategy Object Management heavily relies upon an objects GUID (Global Unique Identifier). The Object Manager tool uses the GUID of an object in the source project, to identify the object in the target system that it relates to and thus the one it will update if instructed to do so. When an existing object is copied and pasted, that copy object will have a new GUID. Therefore, as can be expected, the Object Manager tool is unable to identify the copied object as been intended to replace the existing object in the target system. Instead, the Object Manager simply moves the copy object into the target system. The original object would therefore need to be deleted since it would no longer be required due to the copy object, being the enhanced object. Copy, enhance and delete the original is an inappropriate development methodology for the following reasons: o o The Object Manager cannot synchronize object deletions across systems. The enterprise manager project (the Microstrategy usage statistics project) will be unable to analyze the object in question over time since it too relies upon GUIDs for such tasks.

However, there are a small number of scenarios where this approach will be required. In such situations, the object to be deleted will NOT be deleted from any of the systems until after a full impact analysis has been performed and the change has been released. If the copy, enhance and delete the original approach is required, then the object in question shall be renamed and prefixed with DELETE and object managed across the systems. Once the update has been released, which includes the rename of the original object then the original object can be deleted from all systems.

VIII. Scan MD Metadata Sanity

ScanMD is a utility designed to maintain the integrity of the Microstrategy 7 metadata. It detects and fixes logical inconsistency issues that may prevent MicroStrategy 7 projects from functioning properly. By default, Scan MD is run in "check only" mode. When run in this mode, Scan MD will detect and log information about logical inconsistencies in the metadata, however no changes will be made to the metadata. Scan MD can also be run in "fix mode". When run in fix mode, Scan MD will detect logical inconsistencies in the metadata and then provide an option to let Scan MD fix the inconsistency. It is

important to note that not all proposed Scan MD fixes should be accepted. It is recommended to use Scan MD only to fix metadata inconsistency issues if the tool detects a problem that is preventing a project from working as desired. If the actions proposed by Scan MD are for objects working as desired, the fix should not be accepted. It is strongly recommended that a complete backup of the metadata is made prior to running Scan MD in fix mode. With a backup of the metadata in place, proposed fixes should only be accepted if the full impact of the fix is understood. Scan MD should be run at regular intervals during the development and testing life cycles. Scan MD should be run when any of the following activities are done 1. Project deletion from the server 2. Project Merge 3. Project duplication from one environment to another (Scan MD to be run in the target environment). 4. Project cleanup (involves users/groups cleanup also)