Engineering Stages and the Development Steps
| BI projects are organized according to the same six stages common to every engineering project. Within each engineering stage, certain steps are carried out to see the engineering project through to its completion. Business Intelligence Roadmap describes 16 development steps within these stages, as outlined below. The Justification StageStep 1: Business Case Assessment The business problem or business opportunity is defined and a BI solution is proposed. Each BI application release should be cost-justified and should clearly define the benefits of either solving a business problem or taking advantage of a business opportunity. The Planning StageStep 2: Enterprise Infrastructure Evaluation Since BI applications are cross-organizational initiatives, an enterprise infrastructure must be created to support them. Some infrastructure components may already be in place before the first BI project is launched. Other infrastructure components may have to be developed over time as part of the BI projects. An enterprise infrastructure has two components :
Step 3: Project Planning BI decision-support projects are extremely dynamic. Changes to scope, staff, budget, technology, business representatives, and sponsors can severely impact the success of a project. Therefore, project planning must be detailed, and actual progress must be closely watched and reported . The Business Analysis StageStep 4: Project Requirements Definition Managing project scope is one of the most difficult tasks on BI decision-support projects. The desire to have everything instantly is difficult to curtail, but curtailing that desire is one of the most important aspects of negotiating the requirements for each deliverable . Project teams should expect these requirements to change throughout the development cycle as the business people learn more about the possibilities and the limitations of BI technology during the project. Step 5: Data Analysis The biggest challenge to all BI decision-support projects is the quality of the source data. Bad habits developed over decades are difficult to break, and the damages resulting from bad habits are very expensive, time consuming, and tedious to find and correct. In addition, data analysis in the past was confined to the view of one line of business and was never consolidated or reconciled with other views in the organization. This step takes a significant percentage of the time allotted to the entire project schedule. Step 6: Application Prototyping Analysis of the functional deliverables, which used to be called system analysis, is best done through prototyping so it can be combined with application design. New tools and programming languages enable developers to relatively quickly prove or disprove a concept or an idea. Prototyping also allows business people to see the potential and the limits of the technology, which gives them an opportunity to adjust their project requirements and their expectations. Step 7: Meta Data Repository Analysis Having more tools means having more technical meta data in addition to the business meta data, which is usually captured in a computer-aided software engineering (CASE) modeling tool. The technical meta data needs to be mapped to the business meta data, and all meta data must be stored in a meta data repository. Meta data repositories can be licensed (bought) or built. In either case, the requirements for what type of meta data to capture and store should be documented in a logical meta model. When licensing a meta data repository product, the requirements documented on this logical meta model should be compared to the vendor's meta model, if one is provided. In addition, the requirements for delivering meta data to the business community have to be analyzed (e.g., online help function). The Design StageStep 8: Database Design One or more BI target databases will store the business data in detailed or aggregated form, depending on the reporting requirements of the business community. Not all reporting requirements are strategic, and not all of them are multidimensional. The database design schemas must match the information access requirements of the business community. Step 9: Extract/Transform/Load Design The ETL process is the most complicated process of the entire BI decision-support project. It is also the least glamorous one. ETL processing windows (batch windows ) are typically small, yet the poor quality of the source data usually requires a lot of time to run the transformation and cleansing programs. Finishing the ETL process within the available batch window is a challenge for most organizations. Step 10: Meta Data Repository Design If a meta data repository is licensed, it will most likely have to be enhanced with features that were documented on the logical meta model but are not provided by the product. If a meta data repository is being built, the decision must be made whether the meta data repository database design will be entity-relationship based or object oriented. In either case, the design has to meet the requirements of the logical meta model. The Construction StageStep 11: Extract/Transform/Load Development Many tools are available for the ETL process, some sophisticated and some simple. Depending on the requirements for data cleansing and data transformation developed during Step 5, Data Analysis, and Step 9, ETL Design, an ETL tool may or may not be the best solution. In either case, preprocessing the data and writing extensions to supplement the capabilities of the ETL tool is frequently required. Step 12: Application Development Once the prototyping effort has firmed up the functional requirements, true development of the access and analysis application can begin. Developing the application can be a simple matter of finalizing an operational prototype, or it can be a more involved development effort using different, more robust access and analysis tools. In either case, the front-end application development activities are usually performed in parallel with the activities of back-end ETL development and meta data repository development. Step 13: Data Mining Many organizations do not use their BI decision-support environment to the fullest extent. BI applications are often limited to prewritten reports, some of which are not even new types of reports but replacements of old reports . The real payback comes from the information hidden in the organization's data, which can be discovered only with data mining tools. Step 14: Meta Data Repository Development If the decision is made to build a meta data repository rather than to license one, a separate team is usually charged with the development process. This becomes a sizable subproject in the overall BI project. The Deployment StageStep 15: Implementation Once the team has thoroughly tested all components of the BI application, the team rolls out the databases and applications. Training is scheduled for the business staff and other stakeholders who will be using the BI application and the meta data repository. The support functions begin, which includes operating the help desk, maintaining the BI target databases, scheduling and running ETL batch jobs, monitoring performance, and tuning databases. Step 16: Release Evaluation With an application release concept, it is very important to benefit from lessons learned from the previous projects. Any missed deadlines, cost overruns, disputes, and dispute resolutions should be examined, and process adjustments should be made before the next release begins. Any tools, techniques, guidelines, and processes that were not helpful should be reevaluated and adjusted, possibly even discarded. You do not need to perform the development steps in sequence; most project teams will likely perform them in parallel. However, because there is a natural order of progression from one engineering stage to another, certain dependencies exist between some of the development steps, as illustrated in Figure 0.6. Steps stacked on top of each other in the diagram can be performed simultaneously , while steps that appear to the right or left of each other are performed relatively linearly (with less overlap) because of their dependencies. Figure 0.6. Development Step Dependencies While some development steps are clearly project-specific, most development steps must be performed from a cross-organizational perspective. Thus the focus of those project activities takes on a cross-functional dimension, and the reviewers of those activities should include business representatives from other lines of business. The main task for the business representatives from the other lines of business is to validate and ratify the strategies, policies, business rules, and standards either being used or being developed during the BI project. Table 0.1 indicates which steps are project-specific and which ones are cross-organizational. Table 0.1. Project-Specific versus Cross-Organizational Steps
 |
EAN: 2147483647
Pages: 202