Federated vs. Centeralized vs. De-Centeralized Data Warehouse

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 5

Federated Vs. Centeralized Vs.

De-centeralized Data
warehouse
by Dr. Berg

June 7, 2010

 -- by Dr. Berg

Last fall I was speaking at an SAP conference in Australia and was asked what the realistic options
were for developing EDWs.

After 20 years in this field, I strongly believe that there are only three real options: Federated,
Centralized or De-centeralized architectures. 

And in this blog, I will outline the major differences, issues and benefits of each:

The Federated Data Warehouse (FDW)

Federated Data Warehouses are best in very large organization where development is separated by
geography, organizational boundaries, or where multiple data warehouses exists due to mergers &
acquisitions.
To make FDWs successful, there needs to be a rapid convergence to
standardized technologies. This include:

 Same type of databases and support pack levels (costs and compatibility)
 Same technical platforms Hardware, Backups and Archiving (costs)
 Shared Portal and user interface strategy (reduced training and support)
 Shared security design and centralized administration (risk management)

If the data is federated you gain faster response time to business needs, can execute multiple projects
in parallel, and work 24/7 across the globe. But without any standardization, it can also be very costly.

SAP Customer IT Hub: Maximizing Your Value from SAP Solutions


Get quick and easy access to the wealth of knowledge, resources, tools,
support and services that are available to all SAP customers.

Centeralized Data Warehouse (CDW)

Centralized Data Warehouses are great for small and mid-size data warehouses
(less than 15-40Tb). There are great benefits in terms of the ease to mange
upgrades, support packs, enforcing development standards, transport control,
master data management and the overall total cost of ownership To make CDWs
successful, there needs to be:
 Adequate funding of hardware, application servers, database servers
 Serious consideration should be made to move BI and reporting to BWA
 Focus on using the database capacity on storage and data loads-- not queries
 No direct reporting from DSOs (takes too much system resources)
 Broadcasting , caching and performance tuning is a dedicated support effort
 A plan for data partitioning and archiving needs to be in-place as soon as the system exceeds 5-8
TB.

If the data is centralized it is faster to develop new solutions for the business and merging from different
data sources are easier.

  

De-centeralized Data Warehouse (DDW)

A Decentralized Data Warehouses makes sense if there are logical division between business units,
geographies and little shared reporting I.e. in a conglomerate organization with diverse business units.
The benefits of DDWs include the flexibility of the FDW with the technology standardization and lower
cost of ownership of the CDW. To make DDWs successful, there needs to be:

  A formal Masterdata Management (MDM) strategy with clearly defined standards


 A rule based data cleaning and data integration plan for centralized reporting
 A shared hardware location to keep costs lower
 Tight integration with upgrades, support packs and interface standards 
With DDWs there is a risk of creating st ove-pipe data marts that cannot be integrated at the corporate
level without very high costs.

Recommendations CDW, FDW and DDW Architectures

In general, the benefits and risks can be summarized as:

 
I know someone will use the FDW as an excuse to keep messy legacy data
warehouses. But FDW's are meant to be used for functional different areas
(SCM, HR, Finance), or organizational units (Asia, US, Europe).
 
To quickly get to a new architecture you sometimes simply have to turn off the old
reporting systems (yes, I know that the users will yell and scream).
I want to leave you with an old Norwegian saying:
 
                   "A naked woman quickly learns how to sew"
  
What better motivation to move to your new architecture can the users get, when
the old stuff is gone? :-) 
Sometimes you just have to stop carrying "hay to a dead horse"  and the same
goes for legacy reporting solutions.
 
More ponderings to come...
Dr. Berg

You might also like