Microsoft business intelligence in an enterprise-wide manner, you should consider using SharePoint as the preferred method for delivery due to its collaborative nature and centralized delivery methodology. Its ability to consume data from an array of heterogeneous sources, coupled with the plethora of visualization capabilities, makes it a complete solution that addresses a variety of needs. On the other hand, architecting a solution that performs in a manner that exceeds expectations often requires a subject matter expert. Moreover, ensuring that the deliverables (dashboards, reports, spreadsheets, and so on) are always available and secure can potentially introduce other challenges and requirements.
Considering Performance
As mentioned earlier, performance is often a driving factor behind a large percentage of business intelligence projects. Most of the time this performance is related to accessing data and producing reports. While some may argue, including myself, that a business intelligence project should solve a problem, ultimately the end goal must be granting end users access to data in an effective but also efficient way. Satisfying this goal is accomplished by architecting a server topology that can scale and grow. This is where the Microsoft business intelligence stack lends itself perfectly. Figure 2.4 illustrates a sample SharePoint deployment.
Figure 2.4 Sample Microsoft business intelligence server topology
This configuration is scaled out to support a high number of end users and a growing number of requests. You could reduce the number of servers in this configuration by consolidating the web server and application server, but this could adversely affect performance depending on the number of requests sent to the web server. Therefore, as a best practice, always separate the two in anticipation of some type of growth. In addition, as the end-user base grows, SharePoint provides the flexibility of adding more web and application servers to accommodate the increasing population. With multiple servers in place, not only has scale been introduced, but now SharePoint can use its internal load-balancing features to provide optimal performance for end users.
Considering Availability
The topology presented in Figure 2.3 does offer options to improve scale and support a high level of performance. However, it lacks a key factor that should not go overlooked when implementing the solution: availability. In most cases no one considers availability until a disaster occurs. For example, what happens if the SQL Server that hosts the SharePoint databases shuts down? How much downtime will accumulate prior to the system coming back online? As a result, in addition to installing and configuring more web and application servers for scale and high availability, additional servers should be added to ensure that a high level of availability is maintained for all parts of the configuration.
In Figure 2.4, the Domain Controller, SQL Server and Analysis Servers are single machine. This typically introduces a problem of availability. To ensure that the servers are protected in the event of a failure or disaster means implementing some type of High Availability (HA) or Disaster Recovery (DR) solution. You could use clustering for the domain controller and a mix of clustering an AlwaysOn for the SQL Server Analysis Server and the SQL Server Database Engine. Both clustering and AlwaysOn are technologies that provide HA and DR at server and database levels. Implementing this topology almost doubles the number of servers. Figure 2.5 represents a sample of an HA solution.
Figure 2.5 Sample Microsoft business intelligence HA server topology
The SQL Servers and domain controllers are doubled to ensure that the environment remains online in the event of a server failure. What is not represented in the figure is an additional environment that protects against the loss of the primary data center. This addition would even further extend server requirements and increase capital investments. Although costly, this added environment could provide more protection and availability in the event of a major disaster.
Summary
The chapter discussed various techniques and methods that you can use when architecting a BI environment. It also provided various approaches that can assist with identifying users, goals, and requirements. Finally, this chapter identified plans to help you define how to implement certain aspects.
Chapter 3 discusses various architecture implementation strategies. It then moves onto topics that help you identify your organizational needs and how to select the correct architecture.
Chapter 3
Selecting the Data Architecture that Fits Your Organization
As Tim Berners-Lee famously quoted, “Data is a precious thing and will last longer than the systems themselves.” The task of choosing the correct data architecture to safeguard that data falls on data architects, developers, and database administrators. But how do you determine that ideal data architecture? You must take many factors into account to reach the final decision. Be sure to pick the right data architecture from the beginning; otherwise, you will have to reengineer your solution, wasting time and, often, your business users' confidence in the solution.
This chapter helps you select a data architecture that fits your organization. First, you will learn the challenges of not having a data architecture, the importance of having a data architecture, and common data architectures found in organizations just like yours. Then, you will follow a process to determine the best data architecture for your organization. The process includes interviewing key stakeholders, documenting the key factors associated with your organization, and using a flow chart to find out what data architecture works best for you. Finally, you will work with your stakeholders to ensure you have picked the ideal data architecture that will provide a lasting solution for your organization.
Why Is Data Architecture Selection Important?
For organizations just getting started with their business intelligence and reporting implementations, data architecture can often be an afterthought. This is especially true when organizations are participating in a “proof of concept” or a “prototype” reporting solution that somehow ends up being promoted to the production environment for business users' free reign. Unfortunately, postponing or ignoring the data architecture decision can be detrimental to the solution, the business, and sometimes even your role in the organization.
Data architecture could mean different things to different people, although a company's enterprise architecture typically contains the data architecture. Although the enterprise architecture can include the specific servers and hardware needed, the data architecture is more specific. For the selection process discussed in this chapter, the data architecture includes how the data is stored, accessed, and integrated. Understanding these initial criteria ensures that you don't run into problems down the road.
DATA ARCHITECTURE
In the context of this chapter, the term data architecture encompasses how the data is stored, accessed, and integrated. Data storage includes the location and scalability of the data repositories. Data access contains the models and standards to retrieve that information. Finally, data integration includes how the information moves to and from systems.
Challenges
If your organization does not have a defined data architecture, you will probably face challenges down the road. Although the challenges may not appear immediately, certain phases in the business intelligence implementation will highlight the lack of vision. Hopefully, understanding the challenges will help you recognize
