By Steven Bebout, Senior Consultant
When I tell people what I do for a living, their eyes typically glaze over. I am a business analyst with an area of expertise in the DW/BI warehouse space. When asked to elaborate, my story changes depending upon the industry, current state of the client, politics, budget, priorities within an organization, the client’s history with past data warehousing efforts, etc…
Fundamental responsibilities include: liaison between the business and technology team. I gather data analytic specific business requirements; making sure that the data is there to support the requirements, ensure that the preliminary conceptual data models validate business scenarios, and work closely with testing teams to make sure that the requirements are met. Gathering thorough business and data requirements leaves the DW more robust and flexible as users further define their needs (especially reporting needs).
I’d like to provide the analogy of building a foundation for a house; a house needs a foundation to shoulder its considerable weight, provide a flat and level base for construction and separate wood-based materials from contact with the ground, which would otherwise cause rot and allow termite infestation. This analogy aligns itself well to a data warehousing project.
The business analyst provides the foundation for the data warehousing project. They shoulder the weight of understanding and identifying data and process deficiencies as you are doing the DW/BI analysis; serving as a business-oriented project resource. In some instances, they may have a systems orientation but this is not an expectation of the business analyst’s knowledge set.
The business needs of the organization are identified by interviewing the key stakeholders. You interview IT to determine technical feasibility, not business needs. IT doesn’t define business needs; they only tell you if it can be done and what it will cost. You take that information back to the business and let them decide if they want to pay for it. Identifying these business needs helps to develop the design needs of the data warehouse; missing or misinterpreting the needs creates ‘infestations’ as described in the housing analogy.
It has been my experience that the business analyst is the right hand and often assists the project manager throughout the project. Knowing the foundation of the project and utilizing their client facing skills provides the project manager confidence that in their absence, the business analyst can attend meetings and speak knowledgably on their behalf.
The most successful DW/BI projects I have been involved in are ones where the business analyst is gleaning the user's wants and needs for the business requirements and the data architect/modeler is analyzing the data sources, underlying processes and data quality aspects. Together they work to construct a business-driven and data-driven conceptual and logical model (and also a dimensional and star-schema model if appropriate). A broader combination of efforts includes working with the development team to discern the functional and non-functional requirements for the reporting or analytic deliverables and the physical model (normalized or multi-dimensional as appropriate).
I realize that some people are capable of fulfilling both roles (business analyst and data modeler), and certainly on smaller project might be called upon to perform both roles. However, due to the business complexity, the need for quick success, the economic pressures, etc., I don't personally subscribe to the ‘jack of all trades’ model.
Certainly being knowledgeable in both areas makes sense, but realistically I think it is more prudent to focus on the task at hand and collaborate together. What is your opinion of a business analyst fulfilling both roles? Do you see fulfilling both roles as a value-add or as a potential pitfall in resourcing?
photo by Martin Pettitt (via Flickr)
Steve Bebout is a consultant with over 15 years of experience in information technology in the areas of application development, business requirements, data analysis, and project management. He has experience in the Communications Media and Entertainment, Financial Services, Life Sciences, and Insurance vertical markets; spending the majority of his efforts on customer data integration initiatives.

Good article Steven,
I agree with you that the role of Business Analyst and Data Architect / Modeller should ideally be separated.
At a minimum, business requirements should be captured independently of whether the data is present to support them.
When a Data Architect / Modeller is involved in capturing Business requirements, there is a risk that s/he will seek to influence the requirements based on the current data architecture.
This introduces restrictions too early in the process.
Rgds Ken
Posted by: Ken O'Connor | August 27, 2009 at 10:52 AM