Federated Vs. Centeralized Vs. De-centeralized Data warehouse
— 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.
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
More Resources
Premium
Upcoming Events
Your request has been successfully sent