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!

« BI In Cloud -Part 1 | Main | Deciding on SAP Supplier Collaboration solution dilemma - SAP SNC or SUS? »

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.



Very useful information here. Would look forward for more information on how it fares when complex business logic needed to be incorporated in realtime reporting.

Thanks Somnath for this Good insight about Data Federation and in Particular SAP BO Data Federator.

I would like to extend some thoughts here in addition to what you explained.

As far as BW vs Federation is concerned each one have its own pros and cons. Typically Enterprise deployment are complex and huge amount of data needs to be processed for Enterprise Reporting. Sometimes reports needs Historical data and/or Real time Data depending upon the requirement. In these cases having hybrid approach where data federator works as an interface between BW and other transactional system should do most to the job . Data Federator facilitate to feed the data to Reporting tools from historical as well as real time source.

I have had discussion with some experts in this Area and they said that some Organization has been able to fulfill all their BI Needs using this approach. See transcript of one Case Study for Iron Mountain Europe “Iron Mountain uses Data Integrator to consolidate summarized invoice information from their 11 billing systems into their data warehouse, and Data Federator to supplement the historical information with real-time access to production databases.

In general routing queries through Data Federator is advantageous as it has a component called Query Engine/Server running behind the scene. It actually push all computation to Database and exploit best out of it. Except simple aggregation no query processing will be done on DF side. Hence it make it as fast as Physical Warehouse theoretically. Technically only data from specific fields used in report will be pulled in Metadata Layer designed in Data Federation Designer. Though there is some limitation here Data Federator does not support all database functions. There are some complex functions and queries which DF query engine does not honor.

Some organization are leveraging their reporting environment using federation but it cannot be replace Business Warehouse in general.

Now SAP has integrated BO Data Federation technology into their new release (SAP BI 4.0) in their universe design tool (Information Design Tool in BI 4.0 ).
We( BO COE in ESAP) are currently exploring value proposition here. Will share more details soon

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter