Federated vs. Centeralized vs. De-Centeralized Data Warehouse
Federated vs. Centeralized vs. De-Centeralized Data Warehouse
Federated vs. Centeralized vs. De-Centeralized Data Warehouse
De-centeralized Data
warehouse
by Dr. Berg
June 7, 2010
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:
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.
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.
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:
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