Tag: BI Platform

Posted on by — Leave a comment

Reducing Total Cost of Ownership In Business Intelligence

Centralising on a single Business Intelligence platform and data warehouse is well known for helping organizations become both more effective and efficient. But it will reduce the total cost of ownership of the Business Intelligence IT system too.

Several efficiencies can be realised. The single Business Intelligence platform can be used to consolidate your numerous disparate reporting mechanisms, meaning that you no longer need to license and maintain them. However, it’s not just the licensing and maintenance costs that can be saved. It can also be expensive to maintain different software from various vendors because the related skill sets must also be maintained. Centralising on a single business intelligence will introduce a common, core skill set that can be shared amongst teams at lower internal cost.

In terms of data, the tedious, error prone, and time expensive practice of manually hand cranking data load can also be replaced with a single ETL tool such Microsoft’s SSIS or Informatica. Not only does this remove the risk of user error in data quality but it brings increased efficiency by freeing team members up to do other work.

A single Business Intelligence platform can also drive down licensing costs. Though no way guaranteed, licensing economies of scale have historically been realised due to business intelligence vendor licensing discounts increasing as the number of user and product licenses bundled into a single purchase increased. This is more cost effective than procuring several small licenses for business intelligence software from different vendors.

This combination of consolidation, easier maintenance, increased efficiency, common skill set, and economy of scale drives down the total cost of ownership.

Posted on by — Leave a comment

Increased Performance Through Optimised Semantic Layer Design

SAP Business Objects Universe

SAP Business Objects UniverseThe semantic layer sits between the reporting tool e.g. Web Intelligence and the data warehouse. It is a type of graphical abstraction of how the data warehouse tables and relational joins would look if they could be viewed with the naked eye.

The critical function of the semantic layer is aptly describer in its name. All data warehouse platforms are interrogated through some type of code. The universe generates code (hence semantic) so that a query can be issued against the data warehouse. This code will be in the form of Structured Query Language (SQL) for relational platforms and Multi Dimensional eXpressions (MDX) for OLAP based universes.

The powerful feature of the semantic layer is that the business information consumer does not need to understand data warehouses or write code. The business user simply drags and drops objects of interest from a side panel on to their report page, e.g. sales revenue and location objects to generate a table displaying sales revenue by location. The semantic layer generates the code automatically behind the scenes.

However, the optimization of the code generated will be dependent upon the structure of the data warehouse tables and semantic layer configuration for relational tables and the cube and query design for OLAP sources.

Whilst it is possible to generate a semantic layer in a few minutes using an automation wizard, the resultant performance of queries may be disappointing. By performance is meant fast queries that return accurate data sets.

With experience it is possible to gain a tool box of best practice techniques to build a semantic layer designed for performance. As a semantic layer designer a good starting place is to build a query and then to ask:

What does the code generated by my semantic layer look like?

If I were to write it freehand in an optimised way, would it be different?

Do I need to change the semantic layer configuration or data warehouse structure to achieve optimised query code?

Posted on by — Leave a comment

SAP BusinessObjects Sizing, Hardware & Licensing Models (Legacy)

This article concerns the sizing of SAP BusinessObjects software and how it relates to the choice of hardware to support it and licensing models.

In terms of SAP BusinessObjects Enterprise XI 3.1 it is important to make an informed decision on licensing and hardware based on a SAP BusinessObjects sizing exercise. The sizing exercise involves considerations for the specific Business Intelligence software products chosen to be implemented on Business Objects Enterprise and an analysis of the quantity and type of user that will be active on the BI System. A series of calculations are then performed based on the findings.

As an example consider Web Intelligence. One single Web Intelligence Report Server (service) running on Business Objects Enterprise can support between twenty five and forty users making simultaneous requests depending upon the report complexity. The Web Intelligence Report Server requires one CPU to support it. If more than forty users stress the Web Intelligence Report Server simultaneously there will be deterioration in performance. This can be rectified by configuring more Web Intelligence Report Servers and adding CPU or limiting the number of users. This principle holds true for several of the SAP BusinessObjects Servers running on SAP BusinessObjects Enterprise.

Whilst we can scale the system retrospectively in this way it is better to carry out the sizing upfront. The benefits are that it will provide an indication to number of SAP BusinessObjects Servers to configure, the number of CPUs required to support them, and the disk space that your BI System will require.

So sizing can be a useful guide to hardware procurement. However, it is also a guide to the most effective type of licensing to procure i.e. CPU based, Named User, or a combination of both. If sufficient licensing is not procured the BI System performance will suffer, but conversely no one wants to procure more costly software licensing than is necessary.