In the Field with our Experts

BI and Data Warehousing, and the Role of Business Analyst

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. 

The Metadata ROI Series: Episode 4: Program Management

By Stephen Putman, Senior Consultant

This posting is the fourth in a series discussing various aspects of the financial justification of a metadata management system implementation that are not obvious in many existing analyses. Today, we will discuss the time and effort saved by Information Technology program management staff in system implementation projects.

In Part 3 of this series, the return on investment in a metadata system was shown in relation to end-user reporting groups in your organization. In the fourth and final installment in this series, we will look at how a metadata system can strengthen the program management of the entire system development process.

A great deal of a project manager’s day is spent assembling various lists of functionality to be released into the production environment, and checking the progress of these pieces to ensure that everything is completed in time for the scheduled release. Much of this work is done manually by checking with the various producers, either in person or by status report. It is, frankly, a complicated juggling act that introduces risk into the release process that does not need to be present.

With a robust metadata system, participants in the development and testing of data solutions have a central repository to place updates on the status of various pieces of the product. Unfortunately, status reporting is something that is often neglected, and therefore such a system could easily fall into disrepair. There is a solution that serves all parties, however - the program management group enforces a policy that no piece of software or reporting moves into another state in the standard development-testing-production progression unless the metadata for that piece is complete. This way, the program management staff has an up-to-date view on the status of the entire feature list, and the development staff has incentive to enter data into the system, which benefits all of them during the process and the end-users when the features are released into production. This ultimately saves the organization money in increased efficiency of the entire staff.

A robust and comprehensive metadata system has many benefits to several areas of your organization, and along with effective measurement can provide a large return on your investment in either a purchased or “home-grown” system. It is the basis for effective software development and support in your organization, and should be seriously considered as a best practice for a successful IT function.

photo by perhapstoopink via Flickr

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.

The Metadata ROI Series: Episode 3: Report Users

By Stephen Putman, Senior Consultant

This posting is the third in a series discussing various aspects of the financial justification of a metadata management system implementation that are not obvious in many existing analyses. Today, we will discuss the time and effort saved by reporting users in business organizations.

In Part 2 of this series, we took a look at how the software development process is aided by a robust metadata system. In this installment, we will look at the support that a metadata system can give to the end-user reporting groups throughout your organization.

One of the main things that concern end-users is the definition of business terms and how these definitions are represented in the various computer systems that they use daily. This is a huge risk exposure to the enterprise because confusion on definition of terms could lead to conflicting data reported by different groups in the organization, in extreme cases causing financial restatements at potentially great cost to the organization.

A comprehensive metadata system gives reporting users a consistent base of business definitions, data representations, and linkages between the data to mitigate the risk of misstatement of organizational data. It makes report producers more efficient, and reduces service calls to the IT organization for assistance on the business meaning of data. The returns gained by a metadata system can be measured in the reduction of IT service needs and the mitigation of post-auditing of reporting results that often occurs when definitions are unclear.

Another benefit of a robust metadata system involves the integration of operational metadata to determine the “freshness” of the data in reporting systems. The activity of loading of data into reporting structures can be recorded to the data element level, which is utilized by reporting users in dating their output, ensuring the most current data in the report. This instills further confidence in the results produced by reporting users, and although it is nearly impossible to measure this in monetary terms, it increases the general goodwill of the organization.

In the final installment of this series, we will examine the usage of a metadata system by the software development program management organization.

photo by Engin Erdogan via Flickr

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.

The Metadata ROI Series: Episode 2: Software Development

By Stephen Putman, Senior Consultant

This posting is the second in a series discussing various aspects of the financial justification of a metadata management system implementation that are not obvious in many existing analyses. Today, we will discuss the time and effort saved by software development staff in system implementation projects.

In Part 1 of this series, we examined the value of a metadata management system in regard to the gathering and documenting of business requirements. In this installment, we will take a look at the next phase of a system implementation - software design and development. A metadata management system can help you save money and time in these areas as well.

For new system development, the system designers and developers can use the data stored in the business requirements process as a basis for their designs. Properly documented requirements leave little question as to the intent of the system, and reduce (or even eliminate) the need for follow-up meetings between the engineering staff and the business analysts. Measuring this saved time by the assigned resources is your first source of return for the investment.

Two other major areas of development that benefit greatly from metadata are Extract-Transform-Load (ETL) development and report development. Both functions need to know where data is located on various systems, which is something a metadata system does well. For ETL development, the location and mapping of source data elements is also available. Developers contribute specific information related to their activities to the metadata system to demonstrate fidelity in design to requirements and design considerations introduced to the system.

The major return on investment of a metadata system in the software development area is primarily related to the time saved by staff in information discovery and application. It is important to measure both pre-metadata-system and post-metadata-system metrics on developer and analyst time to accurately determine the money saved by implementing the metadata system.

In Part 3, we will tackle the potential cost saving to end-user reporting groups in your organization.

Photo, "physical metadata," by Nadya Peek (via Flickr)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.