The Importance of Governance

I don’t know if this is a new phenomenon, or if I’m just more observant of it, but there seems to be a trend in BI today that is rather troubling: the lack of governance. What is governance, you ask? That’s a good question.

Before anything is published into a BI system, it should be subjected to a process that insures that it meets certain standards. In other words, someone needs to look at it and see if it is formatted correctly, has the right naming convention, includes the right information, or disclaimers, etc. This process is known as governance.

In the world of SAP BusinessObjects, governance can be applied to Connections, Universes, Documents, Dashboards, Workspaces, etc. Let’s take a look at the things that can be applied to the governance process.

  1. Naming Standards
    1. Should define a guideline for everything that can be built in BusinessObjects
    2. The goal is to create a consistent experience for users, and an easily maintainable and supportable system for developers and administrators
    3. Naming conventions can be applied to the following objects:
      1. Database connections
      2. Universe names
      3. Universe class names
      4. Universe object names
      5. InfoView folder names
      6. Document names
        1. SAP BusinessObjects Web Intelligence (Webi)
        2. SAP Crystal Reports
        3. Xcelsius (SAP BusinessObjects Dashboards)
        4. Other
  2. Security – three approaches:
    1. See everything except what is forbidden
    2. See nothing except what is needed
    3. Hybrid (usually the preferred approach)
  3. Reporting Guidelines
    1. Define how a report is made public
      1. How it is done now?
      2. What works well?
      3. What doesn’t work well?
      4. How should it be done?
    2. Establish formatting standards for public documents
      1. Creates a common look and feel to all public reports
      2. Makes it easier for users to find what they need on public reports
  4. Best Practices
    1. Job scheduling
      1. Limit the number of users who can schedule, to one or two per group
      2. Take advantage of Events
      3. Don’t schedule everything for the same time
      4. Apply a global limit to instances
      5. Avoid scheduling the same document multiple times
    2. Universe techniques
      1. Keep universes small and focused (no more than 700 objects)
      2. Never use underscores in anything that a user will see
      3. Give the universe a user friendly name and description
      4. Set the universe connection to “Disconnect after each transaction”
      5. Set the array fetch size to an appropriate level
      6. Set reasonable universe limits
      7. Set parameters appropriate to your database
      8. Every object should have a user friendly description
      9. Never have more than 3 levels of classes/subclasses
      10. Use proper case for object names
      11. Use full words for object names
        1. Use “Date” rather than “Dt”
        2. Use “Number” rather than “No” or “Nbr”
      12. Use Index Awareness to improve performance
      13. Every measure object should have an aggregate function in the select
      14. Format all numeric objects in the universe
      15. LOVs should have meaningful names
      16. No two objects should have the same name
      17. Use only custom hierarchies
      18. Set cardinalities on all joins

Now that we know what’s possible in a governance process, let’s take a deeper look at some of these.

Naming Convention Suggestions:

Connections: The connection name should be devised so that it includes information about the database that it is connecting to. For example:

Syntax: Environment_Platform_Database

Example: DEV_TD_CSR (Development Environment, Teradata, CSR database)

Universes: Universe long names should match the application that the data belongs to, as well as the focus of the universe. For example, if the data is from the CSR application, and the focus of the universe is sales, the universe could be named “CSR Sales”. The idea is to use a name that makes sense to the users.

Universe Class and Object Names: These should be consistent between universes. For example, if the Month object from Universe A, and the Month Name object from Universe B, return the same values, they should both be called the same thing. This creates a consistent user experience, and avoids confusion.

Documents: It can be very helpful to begin the name of a document with a code that identifies the universe or group that it belongs to, as well as sequential number. For example:

Syntax: Universe-SequentialNumber Document Name

Example: CS0001 Quarterly Sales By Title

In this example, CS represents Customer Service, and 0001 is simply a sequential number. This type of naming allows the documents to be sorted easily by universe, and also helps the user to specify which document they are referring to when they need to discuss documents.


As a starting point, we should review the current security, and see what works well, and what doesn’t. If the current security meets the needs of the organization, then we can keep the current security, and tweak as needed. The three common approaches to security are as follows:

See everything except what is forbidden. In this approach, everyone sees everything by default. Then, content is hidden that is not allowed to be seen by specific users. This approach can be very hard to manage.

See nothing except what is needed. In this approach, the default is to see nothing, and only grant access to content that is required. This is easier to maintain, but can create a bureaucracy that will only frustrate users looking for content that they can’t see.

Hybrid. In this approach, most, but not all, content is hidden by default. Some content is deemed appropriate for all users, and, therefore, is granted to all users. Other content is only granted as needed. This is the easiest to maintain, and is also the best for the users. Users don’t want to see everything, as the volume of content can be overwhelming. By limiting them to what they need, as well as what they are allowed to see, their view becomes more manageable.

Reporting Guidelines

There should be a standard format applied to all public documents. This common “look and feel” makes it easier for users, as they always know what they’re looking at, and always know where to find what they need on the report. They also can tell, very easily, when they are looking at a document that has not received official approval. Standards may include, but are not limited to, the following:

  • Cover page that includes standard information about the document:
    • Document name
    • Document author
    • Document description
    • Universe(s) in use in this document
    • Last Refresh Date/Time
    • Query filters, include prompts
    • Disclaimers
    • Company logo
      • Which logo?
      • Size
      • Position
    • Standard report colors
    • Document/Report naming conventions

All documents will need to pass the governance process before being placed into a public folder. This process should be streamlined, so as not to create a bottleneck.

There should be one or two people, in each group, who are trained to apply the governance process to a document, and who have permission to add objects to a public folder. These people will be responsible for making sure that all documents meet enterprise standards before being published.


Everything we do should be designed to make life better for the users. We need to treat them like customers, and we want their business. So make sure that your governance process is designed to do just that. Don’t let it become a hurdle that the users need to jump over. Streamline the process as much as possible.

Setting up a governance process is a difficult process. It needs to involve key users who will give input of what the standards should be. The problem is that everyone will feel strongly that their way is best. So your job is to try to find a solution that meets everyone’s needs as much as possible. Give it a shot, and let me know how it goes.

11 Responses to The Importance of Governance

  1. B Prashant says:

    Thanks Michael for your wonderful article. It helps lot on deciding guideline and best practices.

    I would like to is there any way for universe rebuilding like Deski – Webi Conversion.
    The idea is to combine/separate discrete objects/tables which were added to universes and added universes with duplicates according to functional points which help report developer and even business to create reports to have better presentation of data.

    I have many questions in my mind would like to hear from you.

  2. A lot of the reasons behind governance seem to be common sense, but as you correctly say, it takes an effort to get these processes set up and find the right people. These days when people are so busy and need their BI info now, now, now, I can see how governance runs the risk of getting “rubber-stamped.”

  3. I like the article. I would go further and suggest that a similar effort be applied to the data that fuels these tools. Companies will invest 6 and 7 figures into a BI tool and development staff but spend almost zero effort in governing their data and data collection processes.

  4. Jansi D says:

    Good blog, Michael. I loved reading it.

    Renaming the contexts will be of great help. No custom SQLs please.

    The other thing which I notice is people (from the development & the support team) do not like spending their time in following the best practices and like to spend as little time as possible in achieving the tasks. Someone from each team needs to have a governance over this escaping approach.

  5. Pavani says:

    Following the standards often is something overlooked upon in almost all technologies. The impact of slight deviation from the standards might NOT reflect immediately but as the systems grow bigger and bigger, the difficulties that developers face in managing the systems lacking standards is exponential. And the companies spend lot more money to get things straightened up. Only way to arrest this to put some measures in place. Well….but how and who is responsible to see that the deviations from standards if occurred are for a reason.

  6. Great stuff Mike, A lot of these are hard to enforce, thus they become suggestions or just best practices in the wild. The rule of thumb being enforce what you can automate, suggest everything else. Good developers will run with it. It’s also important to get everyone onboard early in the development lifecycle, it’s much harder to retrofit later.

  7. Karen Adams says:

    Good info. We do pretty well on the reporting guidelines you suggested, and also include the print time, time zones for print and data refresh times, name of the person who printed the report, and bread crumbs for the report’s menu location in Launch Pad/Infoview.

    We also assign a number to each report and track detailed info in a simple Sharepoint list (who requested the report, specs, subsequent revisions, related Help Tickets and so on).

    We also make sure the Report Name and # that print on the report is consistent with its name/# within Infoview. In other words, it shouldn’t print ‘AP Aging Report’ as the report title and show up in Infoview as ‘AP Invoices by Date.’

    On the universe side, now that we’re moving over to 4.x and adding Explorer, we’re having to modify the conventions to incorporate data layers, business layers, views within layers, and Infospaces, yikes.

    As you point out, consistency is key for users and developers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: