Delivery Methodology, SAP Business Objects

Developing BI Applications

This article looks at an approach to developing SAP BusinessObjects solutions where rather than just writing reports and universes we instead build a BI Application. The main benefit of this approach is a more efficient, streamlined and organised delivery process.

A BI Application is viewed as a complete project where the components of the BI application, the reports, universes, security model, user guides etc, all go through a typical systems development lifecycle of analysis and design, development, testing and release.

Initially this may not seem any different to any other approach but the key difference here is that it is a BI Application as a whole that is packaged and released through the different environments of development, testing, system testing and so on to production. By keeping all the related components together we greatly improve the efficiency and quality of delivery and at the same time reduce the risk of delivering a change in one area that adversely affects another existing BI implementation.

SAP BusinessObjects Enterprise is then viewed as a platform on which we can deploy many different BI Applications. The users are granted access on an application by application basis, greatly reducing the complexity of security modelling.

This article begins by looking at a typical BI project requirement and then looks at how a BI application approach helps implement this project.

Business Scenario

To help better understand what we mean by a BI Application and the benefits to the project life cycle let us look at a typical business scenario.

In this scenario we are delivering a project to implement a BI system for a high street clothing and food retailer called Grace Brothers. Grace Brothers have two initial BI initiatives:

  • A system to allow reporting and analysis of product sales and marketing campaigns to look at best selling products and the effectiveness of marketing campaigns
  • A system to allow reporting and analysis of budgeting and forecasting data and to improve accuracy of the budgeting process through analysis of actuals against costs.

These two initiatives are the first of many and if these are successfully delivered they intend to immediately start with other BI initiatives.


The high level architecture is to build a single enterprise data warehouse from which we expose the required data through the following data marts,

  • Budgeting and Forecasting data mart – financial forecast and budget across the company.
  • Costs data mart – actual costs by department across the whole company.
  • Sales data mart – information on all products sold across all stores and online.
  • Marketing data mart – marketing campaign information.

Security and Access Requirements

We are also required to maintain two separate groups of users who will have access to one or other of these two logical areas of financial analysis and sales and marketing analysis. Initially the two groups will contain employees from either the finance department or the marketing department but will expand in future to include employees from other departments. Some employees will have access to both.

The purpose of this is to minimise training and support where an employee will only be trained on the area they have access to.

It is also required that within these two groups the will be three different types of users:

  • standard users who can view operational reports and any shared reports created by power users who belong in the same group.
  • analysts who can create reports on their area but then only save the report to their own folder and,
  • power users who can create and maintain the shared reports.


Deliverables for the financial analysis subject area

  • Budgeting Dashboard – an Xcelsius dashboard displaying costs against targets across the business
  • Financial Operational Reports – departmental reports detailing costs and other reports displaying budget information using Crystal Reports
  • Budgeting and Forecasting universe – for analysis of data in the Budgeting and Forecasting data mart
  • Costs universe – for analysis of data in the Costs data mart
  • Sample Web Intelligence Reports – a set of sample Web Intelligence documents of the above universes
  • User Documentation on the universes – documents that detail the structure of the two universes.

Deliverables for the sales and marketing analysis subject area

  • Sales Operational Reports – for every store a set of reports detailing weekly sales information. Delivered in Crystal Reports
  • Sales universe – allows the business to analyse sales data within the sales data mart
  • Marketing universe – allows the business to analyse data within the Marketing data mart
  • Sample Web Intelligence Reports – a set of sample Web Intelligence documents of the above universes
  • User Documentation on the universes – documents that detail the structure of the two universes.

These are the high level requirements of the project and the next section will look at the development process where we deliver BI Applications. But first let us define what is a BI application.

Definition of a BI Application

Looking at the above requirements it is obvious that we have two distinct subject areas: financial analysis and sales and marketing analysis. We can then think of a BI application being a subject area, that is, a BI application will consist of all the reports and universes that can be used to report and analyse data within a single subject area. This definition is based around the data that the BI application provides access to however for a full definition of a BI application we need to consider additional components.

In addition to controlling data access we must also control which users have access to this data and also what they are then allowed to do with this data. We can now define a BI application based on 3 key areas,

  • the data that the application works with
  • the users that can access the application
  • the functionality that those users will have when working with the data

By keeping these three areas in mind we can fully define our BI application. Let us look at how this then impacts our above delivery requirement.

Controlling User Access

Our above requirement is to have two sets of users, each of which has access to only one of the two subject areas of Financial Analysis and Sales and Marketing Analysis. In BOE we can define two user groups and then membership of these groups will provide the require access to the application.

Create a top level user group for each BI application

Controlling Data Access

SAP BusinessObjects provides many ways to access data including universes, pre built reports, Xcelsius dashboards etc. Each these need to be controlled so that only the authorised users have the appropriate access.

A universes is used by a user to create a new reports to analyse data within the data mart that the universe provides access to. We therefore need to control access to the universes deployed to SAP BusinessObjects Enterprise. We can control access to a specific universe however it is more pragmatic if we apply security to a folder in which we can place the universe. This means that any universe within that folder will have the same access control.

In our above application we are creating four universes, two for the sales and marketing application and two for the finance application. We therefore create two universe folders for each of these pairs of universes. We then grant access to this universe folder to the appropriate user group.

Create universe folders and assign access to the user group

As well as controlling universe access we also need a means to allow users within a group share reports with each. This is done by creating a BI application folder immediately below the top level public folder where only the user group is granted access to this folder. All users of the group have access to this folder but only power users can create new reports and save them to this folder.

In our requirement we create two BI application folders named “Financial Analysis” and “Sales and Marketing Analysis”. We then only allow the Financial Users group access to the Financial Analysis folder and similarly only allow the Sales and Marketing Users group to have access to the Sales and Marketing Analysis folder.

User groups also control access to report folders

Xcelsius dashboards are typically based on Web Intelligence queries and so they should be treated in the same manner as reports and should be placed in the appropriate BI application folders.

Controlling Functional Access

So far we have defined how membership of the BI application group can control access to universes and reports. Our third area that we need to consider is controlling functional access. Our requirement is to define three different type of user, providing different levels of functionality.

In BOE we have two methods in which we can do this. First we can define a custom access level or we can create further groups where membership of those groups defines functional access. The ability to create custom access levels is a new feature introduced in the XI3 release of BOE. These access levels then define the functional access that a user or group has within a particular folder. For example you can create three access levels “standard”, “analyst” and “power user” and then for each of these specify the required access level.

They have the advantage of allowing you to allocate the same group different levels of functional access for different folders which allows quite a fine degree of control. One disadvantage is that because of this fine degree it can be quite difficult to ascertain the actual functional access for a given folder.

The alternative is to create a user group which itself defines functional access. Here we create three user groups called “standard”, “analyst” and “power user” and each group itself defines a different functional access. In this scenario a user must be a member of both a BI application group and a functional access group.

Each user is added to one or more application groups and one functional group

In the above example the functional groups work across BI applications, that means that if a user is a power user for one BI application then they will be a power user for all other BI applications that they are granted access to. This limitation may or may not meet your requirements but if it is a limitation it is then possible to create functional user groups as sub groups of a BI application group.

They key requirement is to separately maintain a users functional access and their application access. This distinction is important for two reasons, firstly you can easily determine a users functional access or BI application access by quickly listing the groups that the user is a member of. Secondly you can easily change a users functional access without affecting their BI application access and vie versa. This is one of the key features of this approach.


So as can be seen each application defines its own user group an only this group has access to the applications report folder and universe folder. This way we can easily control who has access to the required reports and universes via group membership. We also define functional groups and membership of these functional groups define the users functional access. The functional group can be part of a BI application or apply across all BI applications

Each BI application must define,

  • a top level BI application folder that contains all reports and dashboards
  • a universe folder that contains all universes for the application
  • a top level user group that controls what users have access to the application

The Benefits of using the BI Application Approach

At the beginning of this article we stated that the main benefit of the BI application approach is to have a more efficient delivery process. This is discussed below by looking in detail at different benefits.

Deliver Separate Work Streams

In our above scenario we are required to deliver two initiatives – Financial Analysis and Sales and Marketing Analysis. Why don’t we just have one large project that delivers both rather than split the work into two projects?

The main reason for not delivering a single large project is that the amount of work required to implement one of the initiatives is unlikely to be the same as the other. For example if the estimate for implementing the financial initiative is 12 months and the sales and marketing initiative is 6 months then we would want to be able to release the sales and marketing project after 6 months and not have it wait on the delivery of any components in the financial initiative.

By decoupling the project into two smaller projects (or work streams) we can deliver the sales and marketing initiative as soon as it is ready and start earning a return on investment as soon as possible.

Similarly it may not be possible to start both projects at the same time as in our scenario you will need to conduct requirements analysis and workshops for both departments at more or less the same time.

Small subject focused universes

A second benefit of splitting the projects in this way is that we no longer have any shared components between the two projects. For example in the list of deliverables above we are delivering 4 universes – two for each work stream. If we delivered a single large universe that provides access to all data marts we would have to deliver both initiatives at the same time.

There are further advantages of delivering subject specific universes rather than one large all encompassing universe.

  • Minimise impact of change.

If we need to update a universe then any report based on that universe may be impacted by that change. If we limit a universe to a single subject area we minimise the impact on the reports and the amount of regression testing.

  • More user friendly

Separate universes are smaller, less complex and more use friendly – it is easier for users to find the required information.

  • Logically group related information

A subject based universe will only contain objects that logically relate to each other, that is, the user can create a report that consists of any combination of object within the universe and the report will be logically coherent. In our scenario there is very little relation in data from the marketing data mart and the costs data mart and so a universe that allows integration of this data could be confusing to the users.

  • Less costly to test

When testing a universe we need to ensure that any combination of objects in a Web Intelligence query will create a report that makes logical sense and does not corrupt data. We don’t necessarily need to test every conceivable combination of object but certainly we should test combination of at least one object from each different classes. If we have 4 classes then the number of tests for each different combination of classes is 11. If we have 10 classes the total number of conceivable tests jumps to 1023.

BOE User Security Model is Easier to Build and Maintain

As we have seen above when following the BI application approach we then focus on implementing a security model that isolates each application. This then makes the security model much easier to build, test and maintain.

Constructing the security model is easier as we now have a standard that all BI applications can follow. Testing is also more efficient as we only need to test the security model for the BI application we are releasing as we know it won’t impact other BI applications. Maintenance is also quicker as we don’t need to asses the impact of any change to any other BI application, in addition it is easier to troubleshoot as we can easily identify the applications that a user has access to and separately the level of functionality that has been granted to the user.

Streamlined configuration management and release process

In software development configuration management is concerned with identifying the components and their versions that make up the release of a software package. When developing BI applications we should follow the same process.

If we compare a BI application to a software package we can see that the BI application also consists of components: reports, universes, security model, user guides etc. Each of these components requires development after which they should then be unit tested. At this point in the project life cycle we need to promote our code to the system test environment.

In SAP BusinessObjects Enterprise we can use the Life Cycle Management tool to do this. Here we identify the version of all the components we wish to promote and group them into a package. This package is promoted as a whole to the next environment.

A Web Intelligence document is built on a universe and so if we are promoting a Web Intelligence document from development to test environment we must be certain that the version of the universe in test is the correct version for the report.

When we promote our code from one environment to the next if we keep in mind the idea of a BI application then we ensure that we promote all components that make up that application, that is, the reports, universes, security model etc.


This article discussed the idea of developing BI applications and how this approach can improve the efficiency of the development process while minimising the complexity of hosting multiple applications on a single BOE platform.

A BI application is defined by three key components: the data that is accessed by the application, the users that have access to the application and the functionality that the users have.

To implement this we are required to create a top level application folder which will contain all reports, documents and dashboards. We also need to create a universe folder and then finally define a user group which has exclusive access to these folders.

Finally we saw that following the approach of developing BI applications we can help improve several areas of the delivery process including constructing more efficient, subject area based projects, minimising impact between projects, streamlining the configuration management and release process.

Hopefully you will find some of the ideas in the article interesting and that by building BI applications you will have further success in delivering BI projects.

1 thought on “Developing BI Applications”

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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