code and a diagramming feature that allows for creating and managing tables and relationships. Figure 1.12 provides a view of a typical star-schema data warehouse from the SSMS perspective.
Figure 1.12 SQL Server Management Studio
Using Dashboard Designer
The starting point for authoring Performance Point dashboards, discussed earlier in the section “Working with Performance Point,” is Dashboard Designer. Dashboard Designer is a click-once application available in SharePoint that is installed on each individual machine that will author Performance Point content. It is not available by default. Once installed, you can launch Dashboard Designer to build and deploy dashboards to a SharePoint site, which is shown in Figure 1.13.
Figure 1.13 Dashboard Designer displaying scorecard
Using Dashboard Designer, you can develop each individual item that appears on the dashboard and then create a dashboard that displays the finished product. Once complete, you can then deploy the dashboard to view it.
Using Report Builder
Similar to Dashboard Designer, Report Builder is also a client tool that you must install on each individual developer's machine. You use Report Builder to develop SQL Server Reporting Services reports. When you compare it to designing reports using SSDT, the features and functionality are almost exactly the same. The difference is mainly in regard to team development and source control. A report designed in SSDT is included within a solution and a project. When designing reports with Report Builder, you can develop only a single report at a time. The concept of team collaboration is not introduced. Report Builder is a light-weight tool for people that need to quickly create and/or modify reports as needed. The application itself is installed on demand, similar to PerformancePoint.
Figure 1.14 displays a sample report being developed with Report Builder.
Figure 1.14 Sample Report Builder report
Summary
This chapter discussed the different Microsoft business intelligence tools that you can use to author, deploy, and maintain a business intelligence solution. In addition, overviews were provided for each tool, and, in some cases, comparisons among the different features and capabilities were provided.
The next chapter provides an overview and some discussions around designing an effective and efficient business intelligence architecture.
Chapter 2
Designing an Effective Business Intelligence Architecture
Whereas the tools that you use to develop the business intelligence solution are one of the top priorities in the project, designing an effective and performant solution may be almost as important, if not more. Once the solution is developed and placed in the hands of the end users, accessibility, availability, and responsiveness now become the top priorities of the solution and of those who manage and maintain it. If either fails, then the repercussions could be detrimental or catastrophic to the entire project. As a result, prior to development and deployment, you should carefully consider identifying who the audience is and what the goals of the project are.
This chapter helps you define your audience and goals, explains the reasoning behind data sources, and gives you the information you need to determine if you need a data warehouse. You also find discussions on data governance, analytical models, and delivery solutions. Happy planning!
Identifying the Audience and Goal of the Business Intelligence Solution
Careful consideration must be taken when identifying the audience and goal of the business intelligence solution. These are key factors in most development projects, not just business intelligence projects. Although the audience often dictates the goals, it is important to realize that in comparison they are both equally important. More specifically you consider:
● What are the data requirements?
● Is there a need for a data warehouse or a semantic model?
● What are the hardware needs?
Without adequate knowledge, these questions could result in the development of a solution that does not meet the needs or goals of an organization. Even worse, they may create a solution that meets the requirements, but cannot physically support an organization because of poorly sized hardware.
Who's the Audience?
Identifying the audience should be the starting point, because if you do not have an intended group of end-users, what is the purpose of the project in the first place? Most successful projects succeed because they have some type of buy-in or sponsorship from a larger group that is not part of the development team. For example, a common business intelligence project involves determining past, current, and future sales for a given company. The request for this may come from the CEO, Finance or Marketing department, or from a branch office. Either way, now that the project is aligned with a specific group or groups, obtaining resources to produce the solution becomes much easier, which is an advantage that any development project can benefit from. These resources, include, but are not limited to software, hardware, and people.
The newfound partnership comes with a list of items that may or may not positively assist the project. One item is goals, discussed in the next section. Another, and probably more important, is deadlines. End users often measure the success of a project based on hands-on interactivity. If end users have nothing to see, touch, and use on a given date, the project can easily lose the trust and support that existed at the inception of the project. You could categorize this as a positive aspect of the partnership in regards to success. Deadlines should ensure the on-time delivery of the solution. However, the developers working on the project may see this as negative because it could inhibit or minimize what can and will be delivered due to time constraints.
Another item that is often a result of this partnership is the amount of partner involvement (or the lack thereof). Because a large part of a business intelligence project is discovery, partners must spend time discovering data sources, data needs, goals, how to visualize, which tools to use to visualize, and so on. This requires the involvement of certain people, who are often already inundated with their existing jobs. Because their time is already at a premium, finding additional time to devote to the new project is difficult. Although developers are often well versed in and have intimate understanding of the data to use, they often lack the knowledge of how to massage the data to meet the project's requirements. Without that knowledge, the business intelligence project is destined to fail before it begins.
What Is the Goal(s)?
Now that you've identified your project's end users, it's time to take their knowledge and convert it into goals and requirements. These goals and requirements typically equate to the scope of the project, which further assists in defining timelines, selecting tools, identifying data needs, and selecting hardware. Within the scope, you outline certain goals, such as what should be developed, how it should look, who or what should have access to it, and what to use as the delivery mechanism. Although not an exhaustive list of outlined goal types, they should assist you in quantifying and identifying a project's goals.
What Are the Data Sources?
With the users and goals identified, the time has now come to perform one of the most difficult steps in the project – identifying the data sources. Believe it or not, a person or group of people from the expected end users are the best source for this task. IT data sources often reference data that resides only in systems that IT manages with no regard to data hosted by a department, branch office, or third party. For a business intelligence project, this is not typical. You must perform an exhaustive search-and-discovery