Music Workstation Desk

Methodologies Agile BI projects

theoretical Continuing the series begun in the previous post ( Data Warehouse, step by step ), now continuous Juanjo Projects BI and we will present different methods to address the development of a BI project, which we use in Stratebi .

See the full entry

Assuming that the work required to develop a BI project can be represented as follows:

Where:

• A first time an analysis is necessary.


• After the analysis is to implement the Data Warehouse ETL and data necessary to feed.


• Once this is done we can tailor our Datamarts (if we have them) and OLAP cubes.


• These OLAP cubes and all information contained in the Data Warehouse are just building the basis for all reports identified that will provide the information identified in the analysis as desired.


• Finally, once we have made our reports, we will implement dashboards.
  
  

The triangle represents the distribution of time to achieve the identified milestones. So there is a large amount of work to identify, extract and consolidate data as it is a necessary work prior to the work of creating reports and dashboards that is what you really want the recipient of this project. So, if we face a BI project following this approach will have great chances of FAILURE

If we return to the pyramid above and add some more information see the reason for this:

All our work can be divided into two groups clearly distinguished by the line of sight:

• invisible job: To make reports, dashboards, OLAP views, etc.. Data need. The data are the raw material of our work and we need cooking before they can be displayed at eye of our management / client.
Working

• Visible: Once all the invisible work of the work comes Visible. The visible work is the work that we show and validate the end user, so far we do not have any validation / confirmation that we are doing our job. Until now we have no assurance that what we are doing is what you really want our customer / end user.
  

This coupled with, usually, lack of skills and capabilities that provide analytical tools to do that, until the user has not seen what we have been asked do not know what you really want and often do not match both.

Usually our work is invisible until you build the first OLAP views and early reports. Until then we did a great underground work is necessary but no one sees. No one sees all the work that involves:

• analyze and discern which sources are reliable
  
  
• Clean the data that we will show:
  
  
  • Inconsistencies
  Duplicates Incomplete Data
  • etc.


• Consolidate data in a Data Warehouse.
  
  
• Create relevant data marts.
  
  
• Automate ETL processes and create appropriate control mechanisms


• Validate ETL processes. Validate the removal.
  
  

Agile Development for BI project

A good way to tackle a BI project is piecemeal. Referencing the Data-Driven Metodology cited by Inmon builiding in the Data Warehouse and current agile development methodologies, such as Srum .

What

proposed Data-Driven Metodology (like SCRUM) is aphrons developments "split" . Divide the triangle that is upright and developing from the bottom up on vertical drawing a spiral on the triangle.

Following the analysis of the project, select an area to implement and deploy all of it from start to finish.

• ETL are conducted but only that area, not all.


• OLAP cubes are created on the area.


• reports are created on the area.
  
  
• are created dashboards covering that area.
  
  

And once made that first area .... IS VALID WITH THE END USER

This gives us:

• A quick interaction with the end user.
  
  
  • You remember the specifications provided to us.
  
  
  • You discover that what we asked for is not what you really want at an early stage project so we can correct, amend, change everything you want faster with a lower cost than if we did it exclusively to final.
    
    
  • validate specifications and will provide data to validate the user in a fast and constant. The data validation is done in phases and is not as arduous and boring task.
    
    
  • Member "is that we are working" thing also important.
    
    


• We can apply the corrections to the developed area and implement new areas with new specifications.
  
  
• get results in the short term, everyone is involved and no one forgets that we are doing a project and the subject matter.


• validations start from the beginning and get progressively. No errors found when we built the whole system.
  

So, once we have the first area developed from the beginning to the end and we can apply the corrections identified and agreed to the following address and also updated the analysis that affects you.