In my mind, and with my 15 years experience in this, the term "Business Intelligence" refers to the entire infrastructure used to provide management information and analytics. So ETL is part of BI, as is the data warehouse, as are the reporting layer and consumption layer. All part of the overall Business Intelligence Infrastructure.
BUT, I still run into a lot of people who thing if BI as JUST the reporting front end. Reports, dashboard, customer facing result presentation stuff is BI, everything else is Data Warehouse or something else. It makes it difficult in marketing. If I'm a BI Architect, am I the person who designs it all, or just a Business Objects or Microstrategy expert? Alternatively, if I'm a Data Warehouse Architect, am I just focused on the database, or am I now the overall architect?
So how do you use the term "Business Intelligence"? And if it's for something other than the whole enchilada, what do you call this whole process area? Saving Changes...
Steve -- You raise a good point... specifically, from whose "perspective" is the architecture (in this case, of BI) being defined?
I've run into this same difference of perspective across many different audiences (or "stakeholder-groups," if you prefer that term.)
Business Intelligence is definitely NOT just the ETL, Data Warehousing, Reporting or Report-Consumption activities themselves, but is, instead, the entire spectrum of how (and, more broadly, how effectively) an enterprise makes use of its knowledge resources.
Note the terms "enterprise" and "knowledge," as opposed to "data." I think these are meaningful distinctions in the context of this discussion, since most BI really does take place at something close to the enterprise level, which means it will likely impact users from MULTIPLE business roles, whether they're in the same organizational unit or not.
Similarly, the term "knowledge" rather than "data" suggests that there's something more to consider than just the raw data... How about the data-integrity/quality? How about the governance of the data, the management of meta-data that puts some context around the data as information usable for specific user-roles, and how about the business rules under which that information is supposed to be managed?
I'd contend that ALL of these perspectives, collectively, contribute to the overall sense of how well an enterprise can put its information to use. Clearly, there's much more to BI than just the technological pieces, as important as they are! As an Enterprise Business Intelligence Architect, I'd certainly expect to be able to describe how all these pieces interact, and to be able to illustrate which types of BI are of interest in building a particular solution.
For example, breaking down an analysis into workable subcontexts is often a good start.
Ask questions about:
1) Fundamental-level DATA MANAGEMENT topics (data discovery, data storage, data quality, metadata managment, data access/backup/availability, etc.) and then look at
2) DESCRIPTIVE ANALYTICS (query development and reporting, data trend analysis, data mining, data visualization, business-process analysis, policy-impact analysis, business-rules management and other rearview-mirror-looking techniques to describe where you are and how you got there.) Let this lead you to
3) PREDICTIVE ANALYTICS (forecasting, projection of trends, "what-if" scenario analysis and modeling, and similar future-facing analytical techniques to help you see where you might be going) Ultimately, once you've established these foundational layers of BI, you should look toward a fourth layer of BI, which is
4) DECISION MANAGEMENT (tracking of past decisions and the context-describing information that surrounded those decisions, optimization techniques for using BI to make "better" decisions across your enterprise, and methods to measure you're actually improving your decision-making capabilities.
Ultimately, Business Intelligence as a professional practice is dependent upon an organization having effective requirements-management practices (preferably following the IIBA's BABOK methodology) linked together with an effective project-management and program-management methodology (such as the PMI PMBOK, PRINCE2, ITIL and COBIT bodies of knowledge.)
To answer your questions about the difference between a Data Warehouse Architect and a BI Architect, you'll need to reach some level of agreement with your stakeholders as to how they want YOU to perform in their specific organizational context, and they'll need to understand how you need THEM to behave, as well.
It's a great opportunity to set expectations, mutually-identify critical success factors (CSFs,) and to collaboratively build some meaningful metrics, both as KPIs (key performance indicators) and in a more advanced sense, as KPPs (key performance predictors.)
In summary: business intelligence cannot be just about the techno-tools, or how those tools are used. The discussion needs to take into account how people actually (or should) interact on many levels, and which roles need to be involved in defining a set of solutions, with or without a specific tool being part of the discussion.
As an Enterprise BI Architect, your job is to listen first, educate stakeholders on whichever BI topics are needed, and then guide the stakeholders to engage in meaningful activities that make progress toward their stated objectives.
Note that the BI Architect is rarely also the Project Manager -- each role is distinct, and uses separate skillsets, just as the Project Manager and the Business Analysts use separate perspectives and perform different tasks. All of these people work in support of the actual "customers" and subject-matter experts (SMEs) who use their respective services. Saving Changes...
It is refreshing to see a point of view where BI, BA is describe as more general then just IT.
In my opinion the BI/BA should be consider outside the tools, IT for me is a tools. Business Analyst and/or intelligence is the brain, and IT is the means to execute business. Saving Changes...
