Three steps can help any organization develop the right architecture for business intelligence, analytics, or a re-design of a data warehouse
The best place to start is at the beginning. Does the effort involve building a solution that includes reporting, analysis, mining, or running rules against enterprise data? Before designing business intelligence or analytics solution, or re-designing a data warehouse or data mart, take some time to understand all the business needs.
Whether building a new solution or retooling a poor performing existing DW / analytics solution, the architecture and approach will likely be the single greatest factor in the effort’s success. Before developing architecture, carefully define the real business needs. To clearly understand those needs, consider the following approach.
These 3 high level steps provide an outline for an approach to identifying all of the information needed to design the appropriate architecture based on business needs.
Step 1: Scope and Sponsor Identification
Although there may a person responsible for planning and staffing the project, that person usually is not the business sponsor. Examining the nature of the business problem should help identify the correct business sponsor, who should become the project’s champion as well. They may not know now they will play this role, but before the analysis is complete, they will assume that function. The initial statement of purpose / charter may be specific, but analysis of the actual business requirements may show that what was requested is not what the business really needs. If the analysis starts to show an enterprise effort, it is essential to identify an executive level sponsor or the effort will be vulnerable to all of the politics and strategy that could suffocate it quickly. Keep in mind, the larger the effort, the more senior that business leader must be.
Next, do not forget to identify the IT sponsor. Make sure to identify the IT leaders that have some understanding or stake in the business issue at hand. They will be the ones that can lend the internal support and backing required to interview users that normally are served by other areas of IT. Typically, this individual will be the IT leader responsible for the relationship with the business sponsor identified. Without this crucial IT leader, project team members may struggle to gain access to other IT resources, could lack funding, not receive training, or other external help to complete the project.
In the process of identifying these leaders, much of the scope of the effort should have been clarified. Take that basis, interview the most knowledgeable resources under the business and IT leaders identified, and document the dominant business issues.
The analysis step may require a week to a month, depending on the scope and other factors. Spending the time to share the business importance of this initiative and identifying sponsors and champions, along with the actual business requirements is a critical component of success and is worth this additional time.
Step 2: Usage Flyovers
Once the project team knows the general business need for the effort, start to dig into the actual analysis requirements that will allow the business to leverage their information for real business impact. “Usage Flyovers” should provide the real context to:
- What general purpose should the solution serve? Is the solution dedicated to operational management, strategic planning, in-depth analysis of operations or services, research, or monitoring of business activities?
- How will the business navigate information? In “Corporate Information Factory,” the 4 types of users are defined as Tourists, Farmers, Miners, and Explorers. All of these usage types require potentially different solutions. Combinations of them require a sound, well-designed architecture.
- To whom will users provide results from their analysis? Since information is generated from the data, rest assured there will be value in sharing that information with other resources. Perhaps it is forwarding upward for leadership, conducting initial analysis and forwarding to researchers for more in-depth analysis, providing statistics for management, or even external reporting for compliance or with partners.
This information is uncovered by interviewing the users, management, and leadership. These interviews are intended to be open-ended questions that get business representatives to talk about what they need from the solution. Finish each interview by asking, “What is it you haven’t told me because you figured that it wasn’t reasonable or possible”? This does not commit the project team to solving that problem, but when the team presents its findings, if that is something that is much easier than they anticipated, it may discover some important backers. Therefore, clearly document the results of each interview, and provide the summaries so the interviewees can validate it. Doing this will help with the request to approve the project timeline, resources, and funding. Tying all the needs to the components will serve as a foundation for approval. If leadership wants to cut parts or components, it will be easier to explain the impact that the elimination will have on the requirements.
Step 3: Data Flyovers
The goal of the “Data Flyover” is to get an overview of the types of data required to satisfy the business need, the amount of history needed, the timeliness required, and any known terminology issues/concerns. By classifying information at a high-level, the project team avoids the analysis paralysis associated with trying to define every metric before the business sponsors and champions have had a glimpse of the solution. If an interviewee explains they need “age” information (in healthcare), the project team knows this refers to demographics about a patient. Then they can ask if the interviewee might need other demographics like gender, marital status, household income, race, etc.…
It also allows you to map the high level data requirements to an enterprise Subject Area Model (should the organization have one). In turn, this gives the ability to perform a feasibility study on the data needed by the business. This data feasibility will answer questions like:
- Is the data captured/available?
- Is it timely?
- What is the general quality of the source systems generating the data?
- How much history do we have on this data?
- How many versions of this data do we have?
The information generated out of steps 2 and 3 can be acquired through one set of interviews, so separate resources are not sent to extract business needs multiple times. The business would be frustrated with providing the same information more than once, even against differently posed questions.
Business Analysis for DW/BI/Analytics
It takes an experienced technical background in data warehousing and a highly professional set of business analyst skills to gather this information quickly and accurately. Anyone can learn to do this; new business analysts should learn from experienced resources and training to develop these skills. Learning these DW/BI/analytics business analysis processes enables the analyst to repeat them for future efforts.
Good business analysts must be able to sell the process and solution to their customer (the business), and to adhere to the approved plan and architecture. At times, the analyst will be asked to cut corners and remove components that generally deviate from a sound plan. Only with significant technical experience can someone share all of the reasons why that corner cutting will ultimately change the nature of the solution.
Conclusion
Too often technical resources that have one answer to all data solutions apply that solution in all cases and just start building. Spending time at the beginning of the effort to outline the “Usage” and “Data” needs of the business users will cement the goals and needs that the solution must meet. It will also give the business sponsors clear documentation they can use to champion the cause, fund the necessary components, and ultimately support the effort. Doing that, makes it possible to outline the architecture that will meet those needs and the costs, time frames, and resources required to deliver. Defining the needs and developing the appropriate architecture to address those needs allows the team to examine tools, technologies, and platforms.
