-- 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.
Federated Vs. Centeralized Vs. De-centeralized Data warehouse
Reading time: 2 mins
— 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…
Access exclusive SAP insights, expert marketing strategies, and high-value services including research reports, webinars, and buyers' guides, all designed to boost your campaign ROI by up to 50% within the SAP ecosystem.
Always have access to the latest insights with articles, Q&As, whitepapers, webinars, and podcasts. Gain
the
inside edge. The SAPinsider Weekly helps you stay SAP savvy. Access exclusive bonus materials, discounts,
and
more.
This website uses cookies. If you continue to use the site you consent to our use of cookies in accordance with our Cookie Policy.ACCEPTRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
