Always the most important question, and probably killer in this case is "What do the users of the system want from it?"
For example, suppose you have three functional areas -- Finance, Human Resources and Sales:
Now imagine that your users consistently want information that can only be produced using data from all three areas; then you essentially have to build a centralized data warehouse -- the question is answered. The bad news is that such systems are typically much more challenging to build. Oddly, the problem with building a centralized system hasn't so much to do with technical aspects (data volume, merging the data and so on) -- it often has more to do with human issues, such as getting the users to agree to the definition of data. This is not to imply that the technical problems are trivial, but they pale into insignificance when measured against dealing with the internal politics of a large enterprise. And definitions are often as much a matter of politics as of simple partiality.
Alternatively, imagine that you find that each set of information that the users request only requires data from within one functional area to answer. So, finance people only ask for information in the finance domain, and so on. In that case, it is very tempting to go for the silo (or books of record) approach.
However, even then, you have to be careful. Suppose that both finance and HR contain information about salaries and departments. Both can produce figures for the salary expenditure for each department. As long as this information is only used within the relevant departments then all is well. But image for a minute that the heads of both departments attend a meeting and present their figures as definitive. If we want to avoid a fist fight in the boardroom we may find that it is still essential to unify the meaning of the data across those systems. If we do that, we have done most of the work of centralizing it so that even if the information can be satisfied from silos, we may still eventually see a centralized system as the better long term solution.
To summarize: If the BI project is mainly driven by a business need to consolidate and coordinate the information that will be used by the enterprise as a whole, then centralize. If not, and you are sure there are no long term implications, then silos are fine.
Dig Deeper on Database management system (DBMS) architecture, design and strategy
Related Q&A from Mark Whitehorn
Here's a guide to primary, super, foreign and candidate keys, what they're used for in relational database management systems and the differences ... Continue Reading
The unstructured data types common in big data systems are often better managed by a NoSQL database than relational software, Mark Whitehorn says. Continue Reading
Analytics expert Mark Whitehorn explains the strengths of R and how to determine if the open source programming language fits your analytics purposes. Continue Reading