-- 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.
- 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)
- 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
