Читать книгу Applied Microsoft Business Intelligence - Sarka Dejan - Страница 21

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 the necessity of determining and defining the data architecture before beginning any development.

The challenges include:

● Slow development and maintenance time: Without a data architecture, developers will have to reinvent the wheel each time they begin a new project, by evaluating the pros and cons of a new solution. Without the full picture of other solutions and existing systems, you increase your risk of defining a suboptimal solution for not only this solution, but for the entire data ecosystem. Additionally, by designing a new “mini” data architecture, a developer introduces a different style to the organization, which other developers must learn. The differing styles of solutions can easily cause any new development or changes to existing systems to take much longer than expected.

● Wasted time due to redevelopment: If you choose the wrong data architecture, you may need to add one band-aid after another to satisfy the data needs. Business intelligence and reporting are all about the end user, but testing with the end users tends to happen at the end of the development cycle. If the end users have a concern with the amount, type, or frequency of the data they are receiving, you will be up a creek without a paddle! Having a solid data architecture up front means that you can prevent finding these issues at the end of a long development cycle.

● Loss of confidence in the solution: A typical symptom of not having a standard data architecture is duplication of information within the system. If a developer does not follow the existing data architecture, he could apply an undesirable band-aid fix. Sometimes this duplication does not result in the same answer, either due to different data in the system or due to user error caused by different access methods. In addition to differing answers, this duplication also causes requests for the information to take longer because end users have to decide which one is the best path. Between different answers and longer query times, the end users soon lose confidence in the system.

● Lack of scalability: Providing the ability to appropriately scale a data architecture is a key component of a desirable end-to-end business intelligence solution. Without this ability, the solution will not keep up with the growing business and return times, and its usefulness will slowly deteriorate.

Benefits