Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« February 2011 | Main | July 2011 »

May 13, 2011

Consolidation with a federation based approach- Is it really a way out?

In some of my previous blogs I have been trying to bring to fore some of pertinent questions and choices that our clients are facing in the Business Objects-BI space, there also certain similar dilemma that they are facing with certain choices in the Business Objects Enterprise-Information Management (EIM) area. One of the many questions  that we  face on a regular basis from our client is on whether to use the Business Objects-Data Federator(BO-DF) in a given scenario and the specific advantages of  the tool as such.

Before we try and answer the question let us get an understanding of what data federation is all about. Data federation is a technique by which data is integrated across multiple systems without physically moving the data from the various sources into a central repository. In other words it is an alternative to an ETL based data integration. Using a federation tool  in the market you can create a virtual data warehouse or a data mart without having to spend a large investment in consolidating the data in one single physical location. Business Objects offers is Data Federator ( DF) to carry out such functions. We are also seeing many of our clients sending us queries on the use case of the tool and the utility. While there are certain distinct advantages that federation based approach offers especially in terms of lowering investments on infrastructure and development efforts it also comes  with its share of challenges like:

  •   scalability and performance  in view of large data volumes
  • data historization
  •  guaranteeing data availability if any one of the source systems are down

By and large Data Federation would work well in scenarios where a limited integration is required between two disparate database systems and not really in building and Enterprise Data Warehouse.

We have tried to draw a few scenarios where a federation based approach would work well and where it would possibly have limitations. Please note that the  table below is a basic guideline and  the final decision on the choice of DF should be taken after evaluating all technical and commercial aspects



Choice of DF



SAP BW as the primary data source [70-80% of the reporting data ] and needs integration with an external DW


An ideal situation for use of BO-DF where by substantial savings can be achieved by avoiding physical movement of data and also not risking performance



Same  as above but with a higher amount of data residing in other DW


This would not be advisable given a larger data volume that it would be required to handle may have adverse impact on the performance



SAP BW as the primary source [70-80% of the reporting data]  with multiple external DW/DM like Oracle, Sybase, DB2, another SAP BW bringing in small amount of data


DF should be able to handle  the data virtualization without major impact on performance.

Downside: Analysis could be impacted if any of the sources are down



SAP BW as the primary data warehouse updated nightly and need combined report with most current data in transactional system


DF could be used to combine data from BW and pull a small amount of data from transactional system to show the most current status. Performance impact on transactional system will need to be properly evaluated and tested beforehand.



Multiple data warehouse systems along with SAP BW and analysts looking to combine data for quick ad-hoc need


Ad-hoc data integration needs can be met by simply combining data at runtime using DF ensuring quick turnaround time. Since usage is limited, even if performance is not optimum, is mostly acceptable.



SAP BW needs integration with a set of flat  files from external systems


Flat-files are best suited to be loaded and integrated with data warehouse instead of accessing at run-time.


Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter