Childrens Corner

Prototyping can be an effective method for validating the project requirements and finding missing pieces and discrepancies in the requirements. Business people seldom think of all the details when they state their requirements. They often forget to include dependent processes or related data. A prototype can also help them focus on their access path requirements because they will see the capabilities of the BI technology and the access and analysis portion of their BI application.

If time and budget permit, building a prototype for the original requirements allows the business community to test, extend, or change those requirements at an early stage when the impact on the project schedule is not yet high. The costs of experimenting with different database designs, different visualization methods, different development tools, or different application programming techniques are much less during prototyping than during development because they do not affect a full-scale application.

Another purpose for prototyping is to verify that the design as well as the selected tools, database management system (DBMS), and other technology components will be appropriate for the BI decision-support environment. If the functions of all technology components perform as expected during the prototype development, then the chances of having a successful BI implementation are increased. Therefore, testing the technology features is a valuable benefit of prototyping, regardless of whether you are using existing technology components or buying new ones.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

1. Assess the effectiveness of existing nontechnical infrastructure components.

   The policies, procedures, guidelines, and standards, which are all part of the nontechnical infrastructure, exist to assist in the coordination and management of the BI decision-support environment. They should not hinder the project teams or slow them down unnecessarily. Therefore, review the appropriateness and effectiveness of all nontechnical infrastructure components at the beginning of each BI project. Expand, reduce, or revise any inadequate components as necessary.

   • Eliminate unnecessary activities or tasks from the development methodology or add missing activities or tasks.

   • Ensure that naming standards and abbreviations make sense and are comfortable to the business community.

   • Review the logical data modeling and meta data strategies, and ensure that the data administration and meta data administration groups are adequately staffed.

   • Refine the organization’s data quality initiative.

   • Examine the testing standards, and ensure that a sufficient amount of reconciliation is being performed.

   • Review the guidelines for SLAs and security.

   Tasks within this activity can be performed concurrently.

2. Write the nontechnical infrastructure assessment report.

   Once you have assessed all the components of the existing nontechnical infrastructure, prepare a report that outlines your findings and gives recommendations for improvement. If there are missing nontechnical infrastructure components, prioritize which ones to include in the next BI project and which ones to defer.

3. Improve the nontechnical infrastructure.

   In the project plan, give time estimates for modifying or improving nontechnical infrastructure components as well as for establishing new components. If the improvements must be completed prior to starting the BI project, create a separate infrastructure project with a separate team and a separate project plan.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

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.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

An enterprise architecture is comprised of a set of pictorial representations (models) of the organization in terms of business functions, business processes, and business data. Each enterprise architecture model is supplemented with supporting meta data, such as standard definitions, business rules, and policies. The purpose of these models is to document the set of business actions performed on any real-world object in the course of conducting business. In other words, enterprise architecture models describe the actual business in which the organization engages.

Every active organization has an enterprise architecture by default, even if it is not documented. With undocumented architecture, the organization’s business actions and business objects are most likely not consistently understood by everyone in the organization. The goal of documenting the architecture is to avoid abusing, misusing, or redundantly recreating unique processes or data about business objects, which can lead to losing sight of the cross-organizational picture.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

An organization needs to create a nontechnical infrastructure to prevent the BI decision-support environment from becoming as fragmented as the operational and traditional decision-support environments, from which cross-organizational questions cannot be answered. Creating this infrastructure involves cross-organizational activities such as those listed below.

• Conduct an extensive business analysis involving business people from many lines of business. During this activity, define or redefine the lost complex interrelationships among business functions and business data.

• Adopt a system of peer reviews to support cross-organizational attendance and evaluation of business analysis activities.

• Resolve age-old disputes about data definitions and domains (valid data contents).

• Standardize data names and data values to reflect true business rules and business policies.

• Get agreement from the business people on the business rules and business policies in the first place.

• Create a regular forum for business people to maintain and review the standards, business rules, and business policies on an ongoing basis.

• Over time, create one consolidated, nonredundant data architecture for the entire enterprise to reflect the complex reality of the business; that is, create an enterprise logical data model. This model documents the data inventory of an organization. It is also the primary vehicle for mapping the inventory of operational data to the inventory of BI data.

• Create a meta data repository and populate it with nonredundant meta data.

• Create an inventory of source data and map it to the applicable BI target databases. Also create an inventory of other system components, such as programs, reports, screens, and so on, thereby identifying the reusability of data and process components.

• Create and manage one expanding central staging area (per load periodicity) for the ETL processes. Do not allow independent ETL processes for each data mart solution.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

In the past, the mental model for providing an automated information technology (IT) solution to a business problem has been to “divide and conquer.”

1. Divide a large problem into smaller “digestible” pieces, that is, prioritize and separate the deliverables.

2. Conquer the problem by working on each piece individually, that is, build each deliverable separately.

This approach works very well for reducing risk by breaking a complex problem into small, manageable chunks. However, this approach also has a severe drawback when applied without a nontechnical infrastructure. Namely, it produces stovepipe systems (automation silos). The effects of stovepipe systems are lost business knowledge and lost cross-organizational business view, which severely impact business analytics and data mining activities.

Most businesses are very complex, and as organizations mature, their business complexity increases. As business complexity is broken apart into smaller and less complex components, the interrelationships among those individual components are lost. Much of the business intelligence is contained in these lost interrelationships, and that is a problem for BI applications. Most BI applications, and especially data mining applications, expect to find “golden nuggets” of business wisdom embedded in these complex interrelationships.

Although business managers can answer most questions about the business functions of their own departments, when asked a question spanning two or three lines of business (where complex interrelationships have been lost), those managers must scramble for weeks to piece together the answer.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

1. Technical infrastructure assessment report

   This report should itemize the scalability and limitations of the hardware, middleware, DBMS, and tool platform and should cover the following items:

   - Servers

   - Client workstations

   - Operating systems

   - Middleware (especially DBMS gateways)

   - Custom interfaces

   - Network components and bandwidth

   - DBMS functionality and utilities (backup and recovery, performance monitoring)

   - Development tools such as computer aided software engineering (CASE) and ETL tools

   - Access and analysis tools such as OLAP tools and report writers

   - Meta data repository

   Include a gap analysis section and provide recommendations for upgrading the platform. Incorporate the product evaluation and selection results, listing the weighted requirements and the product features you evaluated.

2. Installation of selected products

   If you identified new products to purchase, write a request for proposal (RFP) or a request for information (RFI) and send it to the vendors on the short list. After selecting a product, order, install, and test it.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

1. Assess the existing platform.

   Review the existing platform in terms of hardware, middleware, DBMS, and tools. It is important to evaluate the interdependence of the tools for their various purposes, such as the interdependence between a multidimensional reporting tool and an ad hoc querying tool. In addition, review the existing network architecture. One of the biggest bottlenecks today, especially in organizations with decentralized applications, is the lack of bandwidth coupled with a limited capacity for network growth.

2. Evaluate and select new products.

   After assessing the existing platforms, identify which types of new hardware, software, or networking components you must acquire. If the existing hardware platform appears to be sufficient, be sure to determine that it will be able to provide the productivity and performance the organization expects from it. Engage business representatives and stakeholders in the decision-making process by including them in peer reviews during the selection process.

3. Write the technical infrastructure assessment report.

   Compile all findings about the existing platform into a report. Explain the strengths and weaknesses of the current hardware, middleware, DBMS, and tools, and provide a list of missing technical infrastructure components necessary to meet the project requirements.

4. Expand the current platform.

   Once you have determined which new products need to be acquired, you can begin the process of evaluating, selecting, ordering, installing, and testing them.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

The following functions are important and necessary attributes of a DBMS for handling the workload of a large BI target database or very large database (VLDB):

• Degree of parallelism in handling queries and data loads

• Intelligence in handling dimensional data models and optimizers

• Database scalability

• Internet integration

• Availability of advanced index schemes

• Replication on heterogeneous platforms

• Unattended operations

A DBMS is a sophisticated piece of software and consists of a number of features that need to be evaluated. Features to look for in a DBMS for BI applications are listed below.

• Network support provided by the DBMS should be compatible with the organization’s data communications standards.

• Dimensional capability in the form of seamless support for fast and easy loading and maintenance of precompiled summaries is important.

• Adequate state-of-the-art triggers and stored procedures can be used as “event alerters,” which trigger an action in response to a given set of circumstances.

• Administrative support features should provide for:

  - Maintenance of consistent historical data

  - Support for archiving (e.g., dropping the oldest week’s data when adding the data for a new week)

  - Controls for implementing resource limits to display a warning when a query that consumes excessive resources is about to be terminated

  - Workload tracking and tuning mechanisms

  - Careful monitoring of activity and resource utilization

• Location transparency across the network must allow the access and analysis tools to retrieve data from multiple BI target databases from a single workstation.

• Future usage explosion must be supported by:

  - Effective caching and sharing of data to minimize input/output (I/O) bottlenecks

  - Effective management of task switching while running many queries concurrently

  - Compatibility with multiple processors

• Scalability requires that the DBMS has the capability to support:

  - Advanced functions for sorting and indexing

  - Fault tolerance for uninterrupted processing

  - Uninterrupted maintenance operations, such as unload, backup, and restore

  - Checkpoints, recovery, and rapid restart of interrupted operations

• Query performance optimization should address aspects of query processing (such as JOINs, sorting, and grouping) that require intensive use of the central processing unit (CPU).

• Load process and performance must address:

  - Data obtained directly from a variety of feeds, including disk files, network feeds, mainframe channel connections, and magnetic tapes

  - Complete data loading and preparation, including format conversion, integrity enforcement, and indexing

• The security system must support unique passwords, password protection, and the authorization constraints necessary for specific persons and for specific tables of the database. The system administrator should provide restricted access to the views and virtual tables.

• The data dictionary should feed into a meta data repository, and the database objects should be linked to all data objects described in the enterprise logical data model.

Selecting and reevaluating the appropriate hardware, middleware, and DBMS components of the technical infrastructure are some of the most important activities on BI projects because they ensure the continued scalability and high performance of the BI applications.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

DMBS gateways, a form of middleware, are generally required to connect the different network architectures of desktop computers, remote clients, or small enterprise servers to industrial-strength enterprise servers.

Gateways fall into four major categories.

1. Point-to-point gateways provide access to only one type of DBMS. Vendors market each point-to-point gateway as a different product. A point-to-point gateway is easy to implement because it handles only one DBMS at a time. It is also a less expensive solution compared with the other three gateway solutions. However, when the organization requires access to multiple DBMSs, it needs multiple gateways. In that case, point-to-point gateways may not be a less expensive solution than using a universal gateway.

2. Gateways that can be used universally provide access to different types of databases on various platforms. Universal gateways require extensive effort to implement and maintain. As a result, these gateways become expensive.

3. Gateways using Structured Query Language (SQL) can access only “real” relational databases, not simulated ones. The SQL gateway translates the client request into the native SQL syntax used by the server’s relational DBMS.

4. Gateways based on application programming interfaces (APIs) are driven by vendor specifications. One of the major gateways of this type is open database connectivity (ODBC). A number of ODBC vendors provide drivers for accessing databases residing on various servers.

Organizational data is distributed across multiple DBMS platforms, cooperating across a network with different instruction sets from multiple vendors.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications