micro strategy development methodology

8/3/2019 Micro Strategy Development Methodology

1/14

MicroStrategy Development Methodology


2/14

TABLE OF CONTENTS

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


3/14

I. Introduction

It is critical for every BI implementation to use a standardized approach tomanaging the development and release of new reports and objects. As part of asound, structured development life cycle, project administrators must employ objectchange management strategies which include following standardized developmentprocedures and implementing security access controls. Moreover, the inclusion ofmultiple development groups, further necessitates the need for a rational changemanagement strategy to ensure application integrity.

The purpose of this document is to define a standardized applicationdevelopment and release methodology for the MicroStrategy projects. Thisdocument is a collection of policies, processes and procedures used for BI reportdevelopment. This document covers the following aspects:

(i) MicroStrategy Environments(ii) MicroStrategy Connectivity Architecture

(iii) Life Cycle(iv) Explanation of recommended methodology for Requirements

gathering and Design(v) Explanation of recommended development and object

management methodology(vi) Description of object migration process


4/14

II. Environments

Almost all MicroStrategy projects have atleast 3 main environments which areexplained below. Some projects may have Training environment along with thesethree main environments.

(1) All the Development and Unit Testing will be carried out in the Developmentenvironment, which is a replica of QA, and once tested and verified will be movedto QA.

(2) The QA system will be used for unit and system testing. No object developmentis allowed here.

(3) The Production system shall be used for production purposes. No objectmodification 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 MicroStrategyDesktop installed and with no administrator components. The offshore developersshould have access only to the development environment and restricted access tothe QA environment at any time. Only the onsite team will have access to theproduction environment.


5/14

III. Life Cycle

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

IV. Requirements Analysis

Complete Business Requirements for Reporting are captured and mapped tocorresponding MicroStrategy objects to ensure that the requirements are feasiblein MicroStrategy. The following requirements checklist helps in gathering thecomplete requirements


6/14

Sl. Questions Y / N / NA Comments

1. Are the report layouts pre-defined?

2. How many reports are to be developed?

3. Does the data mart already exist in thesystem (applicable for migrationprojects/only MicroStrategy developmentprojects)?

4. Can all the report columns be mapped tothe columns in the datamart ((applicablefor migration projects/only MicroStrategydevelopment projects)

5. Are there any formatting requirements forthe reports?

6. If the answer to the above question is yes,what are the formatting requirements forthe reports (font, border, cell alignment)?

7. If there are any requirements not feasiblein MicroStrategy, will the requirements beslightly modified to suite theMicroStrategy product suite?

8. Are these reports delivered to the externalcustomers?

9. If the answer to the previous question isyes, what is the intended delivery mode?

10. Is ad-hoc reporting in scope of thisproject?

11. Are there any graphing requirements forthe reports?

12. If the question to the answer above is yes,what are the exact graphingrequirements?

13. What is the expected number of datapoints in a graph report?

14. Is data security using security filters a partof this project?

15. Is object level security desired from thisproject?

16. What is the maximum number of rowsthat can be present in a report?

17. Are thresholds to be applied to reportvalues?

18. Are there requirements to combinemultiple reports in a single display?

19. What are the analytical functions involvedin these reports?

20. What is the display format for eachcalculation displayed in the report?

21. Are there any custom display formatsdesired in these reports?

22. What is the frequency of data load in thedata mart?

23. What is the expected performance limit ofeach report and how much is the


7/14

expected performance limit feasible?

24. How are NULL values expected to bedisplayed in the reports?

25. What is the maximum amount of time auser can remain idle being logged to theintelligence server?

26. What are the access privileges to begranted 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-basedscheduling?

30. What is the sorting behavior desired foreach report?

31. Should drilling be enabled for the reports?

32. What is the desired behavior for eachreport?

33. Are there any requirements for displayingindividual attribute form names in thereport in web?

34. Are web users supposed to set thresholdsfor report metric values from web?

35. Are there any prompt displaycustomizations desired? (the client shouldbe educated about the available promptstyles in MicroStrategy before asking thisquestion)

36. Are there reports with nested prompts?

37. Is the functionality of nested prompts

spanning multiple pages in webacceptable to the end user? (this isbecause nested prompts span multiplepages in web)

38. What is the configuration of theMicroStrategy intelligence server machine(development, QA and production)? (forperformance measurements andstandardizations)

39. What is the maximum number of reportsthat a user will execute during a particularlogin?

40. Should pivoting be allowed in the reports

to the end-users?41. Are there requirements for dynamic graph

generation with large number of datapoints from MicroStrategy web?

42. Are graph axes labels to be displayed bydefault for graph reports?

43. Are NULLs to be a part of graph reportdisplay?

44. What is the maximum number of column


8/14

series expected in a graph report?

45. Should grid lines be displayed in graphreports?

46. How are the percentage metrics expectedto be displayed with respect to graph axisdisplay?

47. Is zooming a desired behavior in graphreports?

48. How are sub-totals expected in thereports?

49. Are the combination of sub-totalsexpected for adjacent columns in thereports?

50. Is threshold display desired for sub-totals?

51. Is reporting from multiple data marts in asingle report desired from this project?

52. Is reporting from heterogeneousdatabases desired from this project?

53. Which users should be given more prioritywhen job execution is considered?

V. Design Methodology

a. A logical data model is established for a project by examining thebusiness reporting requirements of user community and the availabilityand the structure of source data

b. Using Microstrategy Architect schema objects are created that representthe 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 primarilynumeric and/or aggregatable, examples - sales and profit.After identifying the facts, the level at which each fact will bereported is also determined.

Identify the attributesEntities in the business model are normally identified asattributes. Attributes define the level of detail of a report.

Determine the relationships between the chosen attributesThree types of relationship can exist between directly relatedattributes

o one to oneo one to manyo many to oneo many to many

Many to many relationships are normally not desired andshould be resolved using relationship tables appropriately.

Define hierarchies based on the chosen attributes


9/14

Hierarchies are created by grouping the attributes that aredirectly related to each other.

d. Report Designers can then use these schema objects to createapplication 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 beconsidered 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 OffshoreDevelopers with security controls in the Development Environment.This is to ensure proper object version control management during

development phase.

Public Objects Folderso Objects related to developed and verified reports will be

moved from Offshore Developers folders to appropriatefolders in Public Objects folder. The default MicroStrategyfolder structure is recommended for the new high-levelstructure.

o Public objects security - The Public Objects folders will havestrict Access Control Lists (ACLs) applied to them such thatonly the Administrator user will be able to makemodifications to the folder structure and contents. The groupEveryone 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, Off-

Shore and Onsite. Any objects that are remaining inthe Developers folders will solely be objects that arecurrently being developed or fixed.

o Development Folder Security


10/14

New Developer user groups will be created andapplication functional privileges will be granted usinga Developer security role. Developers will begranted all Web privileges and all Desktop Designerand above privileges through this security role.Developers will not be able to create or modifyschema objects, however they will be able to use theArchitect editors in order to examine the definitionsof existing schema objects.

Each folder will have developer group level securityapplied to it such that developer group will only beable to see their groups folders. In addition,modification privileges will be granted to specificusers for their personal development folders.

Production Support Foldero Production Support Folder Structure

A new Production Support folder will be created inthe Development project to provide an area forProduction bug resolution. Initially, the On-Shoredevelopment team will be the only development

group who has access to this set of folders. Subfolders will be created in the Production Supportarea for each on-shore developer. A separate folderwill be created inside a developers prod support foreach production support issue that a developer iscurrently working on. It is hoped that these foldernames can be reconciled with actual Prod SupportIssue #s.

o Production Support Folder Security Privileges to these specific developer prod support

folders will be restricted to View only for other On-Shore developers and business analysts, andmodify privileges will only be grated to the individual

whose prod support folder that is.

Development Process

New Report/Object Developmento All Schema Objects (Attributes, Facts, Hierarchies, Partition

Mappings, Transformations) will be created by theAdministrator or the architect who has been granted accessto 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. willbe done by the Administrator.

o Administrative Tasks Scheduling, Cache Management willbe done by the Administrator.

Development Folder Useo 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.


11/14

o Developers should have the ability to create additional SandBox folders within their own personal development folders.

Public Object Re-Useo Reuse of all the application objects defined in public objects

folder whenever possible.

Off-shore Development Processo

The on-site servers can be accessed via Remote TerminalAccess. A Microsoft Access copy of the developmentmetadata will also be sent to the off-shore team to conductfurther research and prototyping.

o Migration Request Document is needed to keep track of allthe objects which needs to be migrated to Public objectsfolder from development folders.

Object Migrationo Object Migration Requests within Development

Objects will be moved from the Developers foldersto Public Objects by the Administrator using theMigration 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 tobe after migration, the investigations are done indevelopment and the object which is changed ismigrated using Object Manager tool. Theadministrator can determine which objects need tobe migrated, as well as conflict resolution options incase objects that are being moved already exist inthe destination object.

o Migration from QA to Production All the objects are migrated to the QA environment

using Project Merge Wizard. The project can beduplicated to production also from QA.

o Bug Fixing

If an object does not pass QA test, the issue is fixedin the Development environment and Unit Testedand migrated to the QA environment as specified.From the QA environment, the report is migrated tothe Production environment using Project Merge.


12/14

A sample Conflict Resolution Grid is shown below:


13/14

VII. Object Management

MicroStrategy Administrator Tool, Object Manager checks for the objectdependencies. As a result, it is not required that base objects, such as theattributes 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 thefollowing 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 ObjectManagement heavily relies upon an objects GUID (Global Unique Identifier). TheObject Manager tool uses the GUID of an object in the source project, to identifythe object in the target system that it relates to and thus the one it will update ifinstructed to do so.

When an existing object is copied and pasted, that copy object will have a newGUID. 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 targetsystem. Instead, the Object Manager simply moves the copy object into the targetsystem. The original object would therefore need to be deleted since it would nolonger be required due to the copy object, being the enhanced object.

Copy, enhance and delete the original is an inappropriate developmentmethodology for the following reasons:

o The Object Manager cannotsynchronize object deletions across systems.

o The enterprise manager project (the Microstrategy usage statistics project)will be unable to analyze the object in question over time since it too reliesupon GUIDs for such tasks.

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

VIII. Scan MD Metadata Sanity

ScanMD is a utility designed to maintain the integrity of the Microstrategy 7metadata. It detects and fixes logical inconsistency issues that may preventMicroStrategy 7 projects from functioning properly.

By default, Scan MD is run in "check only" mode. When run in this mode, Scan MDwill 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 "fixmode". When run in fix mode, Scan MD will detect logical inconsistencies in themetadata and then provide an option to let Scan MD fix the inconsistency. It is


14/14

important to note that not all proposed Scan MD fixes should be accepted. It isrecommended to use Scan MD only to fix metadata inconsistency issues if the tooldetects a problem that is preventing a project from working as desired. If theactions proposed by Scan MD are for objects working as desired, the fix should notbe accepted. It is strongly recommended that a complete backup of themetadata is made prior to running Scan MD in fix mode. With a backup of themetadata in place, proposed fixes should only be accepted if the full impactof the fix is understood.

Scan MD should be run at regular intervals during the development and testing lifecycles. Scan MD should be run when any of the following activities are done

1. Project deletion from the server2. Project Merge3. Project duplication from one environment to another (Scan MD to be

run in the target environment).4. Project cleanup (involves users/groups cleanup also)

micro strategy development methodology

Documents