Enterprise Standards


Organizations must establish architectural standards for their BI decision-support environments in the same way they set up standards for their Web sites. An organization would never consider building its Web site with a different look and feel for each Web page. In the same vein, no organization should build a BI decision-support environment in which each BI application had a different look and feel. Therefore, all BI applications must adhere to the same enterprise standards within an organization. Figure 2.10 lists the categories of standards to develop, which are briefly described below.

Figure 2.10. Enterprise Standards

graphics/02fig10.gif

Development Approach

Business Intelligence Roadmap provides a complete list of all the major activities and tasks that are appropriate for BI projects. However, since scope and deliverables of BI projects can vary widely, not every BI project team has to perform every single activity in every step. Some BI projects may justifiably skip activities within a step, combine activities from different steps into one, or skip entire steps. However, no BI project should be developed ad hoc. Organizations should have some guidelines that list the minimum number of activities required (minimum work breakdown structure), the mandatory deliverables, sign-off requirements, and workflow dependencies in order to control the project risks.

Data Naming and Abbreviations

Data naming and abbreviation standards for BI applications provide consistency and a common look and feel useful for both developers and business people. Proven standards can be applied (such as the convention of name compositions using prime, qualifier or modifier, and class words), or new organization-specific standards can be created. The data administration group usually has been trained in the various industry-standard naming conventions.

Abbreviations are part of naming standards, but they apply only to physical names (e.g., column names, table names, program names), not to business names . The organization should publish a standard enterprise-wide abbreviations list that includes industry-specific and organization-specific acronyms. Every BI project team should use these abbreviations and acronyms.

Meta Data Capture

Meta data is a world unto itself. Large amounts of descriptive information can be collected about business functions, business processes, business data objects, business data elements, business rules, data quality, and other architectural components . The organization needs standards or guidelines that govern who captures which meta data components and how, when, and where to capture them. The meta data repository should be set up in such a way that it supports the standards for meta data capture and usage.

Logical Data Modeling

Logical data modeling is a business analysis technique (not to be confused with logical database design). Every business activity or business function uses or manipulates business data in some fashion. A logical data model documents those logical data relationships irrespective of how the functions or the data are implemented in the physical databases and applications.

Project-specific logical data models should be merged into one cohesive, integrated enterprise logical data model. This activity usually is ”and should be ”included in the job description for the data administration department, which may be part of the enterprise architecture group. The enterprise logical data model is the baseline business information architecture into which physical systems (operational or decision-support, including BI applications) are mapped. The organization should establish standards for creating the project-specific logical data models for BI projects and for merging the models into the enterprise logical data model.

Data Quality

Information can be only as good as the raw data on which it is based. Most organizations have a lot of dirty data ”too much to cleanse it all. Each organization must establish guidelines about triaging (categorizing and prioritizing) dirty data for cleansing. In addition, the organization must create standards that define acceptable quality thresholds and specify how to measure data quality during database loads. Instructions for error handling and suspending dirty data records should also be part of the standards.

Testing

Testing standards specify what types of tests should be performed and who should participate in the various types of testing. The organization should provide guidelines that describe the types of test cases required at a minimum, how much regression testing to perform, and under what circumstances to regression test. A brief description of a test plan, perhaps even a template, as well as instructions for how to organize and manage the various testing activities should be included.

Reconciliation

The BI decision-support environment will have multiple target databases and multiple BI applications. Since BI applications are not stand-alone systems, their development must be coordinated and reconciled to guarantee consistency across the BI decision-support environment. That includes having one (logical) central staging area with reconciliation programming for every input-process-output module regardless of whether the module is written in native code or produced by an ETL tool.

Security

BI data is derived from operational data. Therefore, security guidelines that apply to the operational data also apply to the BI data. However, if data is summarized and the ability to drill down to the details is not enabled, some of the security features can be relaxed . But rather than allowing the members of each project team to make up the rules as they please , the data owners should establish security standards to guide the project teams on what types of security measures are mandatory for what types of data exposure. These standards should include guidelines for categorizing security risks. Security risks should be considered for data sensitivity, application security, network security, and security against intrusions, hacks, viruses, and other nuisances on the Web.

Service-Level Agreements

Organizations function according to explicit or implicit business principles. Business principles are explicit if stated in mission or vision statements, implicit if they are just " understood " by the staff. For example, if an organization rewards project managers for meeting deadlines even though their applications are full of errors while it punishes project managers for missing deadlines even though their applications are flawless, the implicit business principle is "speed before quality." Service-level agreements (SLAs) ordinarily support the explicit as well as the implicit business principles. Therefore, SLA standards should state the business principles and outline the minimum acceptable SLA measures to support those principles. For example, "All projects must meet a 98 percent data quality threshold for financial data." SLA measures can also apply to query response time, timeliness, availability, and level of ongoing support.

Policies and Procedures

Standards and guidelines should also cover the policies and procedures of an organization, such as operating procedures, project change-control procedures, issues management procedures, and dispute resolution procedures. Additional topics (e.g., communication processes, estimating guidelines, roles and responsibilities, standard document format) should also be part of the policies and procedures. The purpose of having policies and procedures, along with standards and guidelines, is to help streamline and standardize the BI decision-support environment. In other words, policies, procedures, standards, and guidelines must add value for the organization as a whole ”or they should not exist.



Business Intelligence Roadmap
Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications
ISBN: 0201784203
EAN: 2147483647
Year: 2003
Pages: 202

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net