How Do I Implement Business Intelligence

As either a business manager, knowledge worker or IT practitioner, you will have almost certainly come across terms such as 'business process' or 'software development life-cycle' (SDLC). In both cases, they provide a road-map or some kind of instruction set that spells out what should be done, and in what sequence.

Marching orders such as these need to be carefully planned and constructed to ensure successful completion of a required process, in a way that is consistent and compliant with company policy and best practices.

The field of Data Warehousing (or On-line Analytical Processing - OLAP) is similar to other automated application systems in that it involves the development of databases and software in order to provide some useful and reliable service to its business users.

This document outlines the Process for BI Development and follows industry standard practices, base on the Kimball methodology.

Conventional systems usually have a specific role to play by providing defined functionality that is tied to business processes and that can be preformed repeatedly with virtually the same outcome using, of course, different data and different selections of tasks and operations to be performed. OLAP based systems tend to fall into a rather different category than the general business application. Although it is known what kind of operation and process an OLAP system can be asked to perform, these are not usually mapped to a specific business process. It is much more about exploring data and discovering previously unknown or unrecognized facets of the business and being able to further investigate the data based on such discoveries.

These fundamental differences in the way Data Warehousing and OLAP are employed within an organization are what make the development process also differ from the approach use in developing conventional applications.

The panel that follows lists the main steps in a process for BI development. Please note that 'Requirements Gathering' and Testing have been omitted from the list but will be discussed below.

The major components of the Process for BI Development

* Characterize the Environment.
* Establish Development Road map.
* Perform Data Profiling
* Perform Data Analysis.
* Perform Dimensional Modeling.
* Design ETL (Extract, Transform and Load).
* Design Analytics and Presentation.
* Configure Data Management.


Choice of Platform

There are different platforms, and toolsets on the market and a process for the development of a DW and BI solution should be relatively neutral in this respect. However, there are points in this document where reference is made to the Microsoft BI platform, specifically to the use of Microsoft SQL Server and Microsoft Excel. These products also represent the platform upon which the measuregroup™ framework is built and to which several measuregroup™ tools are applicable.

Requirements Gathering

A project deliverable with a name along the lines of 'Functional Requirements Specification' or 'Business Requirements Document' is typically created by a Business Analyst, at or near the beginning of most conventional application development projects. In the case of the BI Project, However, there is less need for a specification of functionality.

This because the DW and BI facilities are not normally in place to map against a particular 'Business Process'. They are not typically performing set-piece functions as in the case of conventional applications. The need for specification is at a somewhat higher level of generality and speaks more to the scope and treatment of the data that is to be included in the facility.

For the main part, then, it is probably better to eliminate the document that is defined as something to do with 'function' and concentrate more on scoping the data landscape to be addressed by the DW solution.

Testing

Who could imagine the development of anything that involves data design, programming and implementation on computers without some form of testing being performed on the delivered system.

Data Warehouse and Business Intelligence software is no less likely to suffer from logic errors or even simple typographical errors that would render the system far less useful if they were delivered to the customer. These programs need testing just as much as any other software genre.

What is different, though, is the fact that, as stated previously, we are not programming against a set of business functional requirements. This means that the 'best practice' of designing our test specifications against the requirements may not be possible in the same way. They are never the less, still possible to create and execute.

What we need to do, is test the programs against the job that is specified for them to do, and that job is specified in a slightly different way. Instead of business requirements we are faced with technical specifications telling us that certain data has to be copied from its initial location, possibly reconfigured in some way and then deposited in some new and exotic 'Dimensional Model'

The specification for what has to happen in this process is coming not from the business users but from the Data Warehouse Architect and Dimensional Modeler.

It is a common mistake for teams not experienced in DW/BI development to assume that the development process is just like any other they have encountered involving conventional applications. Herein, lies one of the many pitfalls that await the uninitiated.

Business User Expectations

It may be better to think of the BI development effort as being something that is part of the technical 'back-room' of IT. Something like the business of 'back-up', 'high availability' or 'disaster recovery'.

The direction given us by our business sponsors is more along the lines of requests for the availability of certain data, in forms that make it efficient for use with certain tools, created or purchased externally.

That is really what OLAP technology is about. The presentation (or analytic) tools are designed to provide a wide range of generic operations on your company's data but first you must get the data into the Dimensional Model to facilitate the use of such tools. Quite how you go about that is not for the business user to worry about, just so long as you make it work, efficiently, accurately, in a timely manner and with usability high on the list of priorities.

Source : Ezinearticles