The purpose of this phase is to specify and analyze a data base related problem and/or opportunity, and to propose to management a viable solution. It is the most critical phase of the DBEM methodology. Several events occur during this phase:

• The scope of the DBEM project is defined.

• An analysis of the current data base is performed.

• Information requirements are reviewed and updated as required.

• A data base approach is defined for satisfying the requirements. The approach may include new development, modifications/improvements to existing data base, a packaged solution, or combinations of all three.

• An evaluation of alternatives is prepared, including estimates, costs, and schedules.

• A formal review with management is conducted to verify the phase findings.

This type of analysis reflects a "bill-of-material" philosophy. In other words, if one part is changed, what other parts will feel its effect? An IRM Repository is used to perform this type of analysis. An "Impact Analysis" is invaluable for scoping the size of a project and for developing project estimates and schedules.

Before proceeding with the project, the Project Scope and estimates/schedules are reviewed with the user sponsor(s). It is important that the Project Manager and the users have consensus in terms of the work to be performed, the approach, and anticipated estimated time/costs/schedule. This is true regardless of the type of work effort.  

CURRENT DATA BASE ANALYSIS

The purpose of current data base analysis is to inventory data resources for control purposes. Such control eases maintenance and modification/improvement activity. It is also useful for reasons of back-up/recovery of key files. For development projects where a new system is being developed to replace an aging system, it is necessary to document the existing data base so that a strategy can be devised to transfer data from one file format to another.

Under Phase 1, Activity B of ISEM, Systems Engineering is concerned with documenting system resources. This same type of activity is performed under DBEM to document data resources. As such, both activities can be conducted in parallel and are complementary.

Documenting a data base can be a major undertaking. It is important to remember that the intent here is to ONLY IDENTIFY AND DESCRIBE THE CURRENT DATA BASE, NOT TO CORRECT DEFICIENCIES. Quite often, there is a temptation to try to correct an obvious problem at this stage. As a consequence, current data base analysis takes longer and longer. When errors or problems are spotted, they should be documented as future Modification/Improvements and not corrected as part of this effort.

How much definition is enough? DBEM recommends up to a Phase 5 level of detail (all four data base models):

APPLICATION LOGICAL DATA BASE MODEL (ALDBM) - represents the objects, views, and primary data used in the current system. The primary data used here will most likely be re-used, regardless of physical implementation. The logical views provide invaluable intelligence regarding relationships between objects (one-to-many, many-to-many). Consult Phase 2 for the required structures.

ENTERPRISE LOGICAL DATA BASE MODEL (ELDBM) - represents the global view of objects, views and primary data elements used in the enterprise. Consult Phase 3 for the required structures.

ENTERPRISE PHYSICAL DATA BASE MODEL (EPDBM) - represents all of the physical files used to store data in the enterprise. Consult Phase 4 for the required structures.

APPLICATION PHYSICAL DATA BASE MODEL (APDBM) - represents all of the physical files used to store data within a single information system. Consult Phase 5 for the required structures.

Current data base analysis normally begins from the application view, which is then merged into the enterprise view. The next question becomes which type of view to begin with: Application Logical or Application Physical? There are some trade-offs to consider. To most people, physical files will be the most visible and easiest to document. Although a replacement system with its own application physical files will probably supersede the need for the old files, documenting the existing files is necessary to transfer data from the old format to the new. However, if this in not a consideration, then documenting the APDBM is probably not necessary.

Documenting the ALDBM is somewhat more difficult to perform than its physical counterpart. Whereas tangible evidence exists for the physical (e.g., data description language statements, program source listings, etc.), the logical is defined based on deductive reasoning, normally by inference of inputs and outputs. The benefit of documenting the ALDBM is that the logical files, records, and data elements can be re-used in other applications, both existing and new.

There are essentially two approaches for documenting data resources: Top/Down and Bottom/Up.

Top/Down Approach

This approach implies defining logical structures before the physical. To do so, Data Engineering analyzes data requirements from an application as defined by Systems Engineering. Inputs are analyzed in terms of the primary data elements collected. Outputs are analyzed in terms of both primary and generated data elements. Where a generated data element is encountered, it is traced backwards to the primary data elements needed to produce it. After all of the primary data elements have been defined, they can be organized into objects and views.

When the ALDBM has been defined, it can then be merged into the ELDBM as required. Following this, the physical files of the application are defined based on available documentation (e.g., source code, DDL, etc.). The APDBM is then related to both the EPDBM and the ALDBM. Relationships between the ELDBM and the EPDBM are established last.

Bottom/Up Approach

This approach begins with a definition of the APDBM based on available source code, DDL, etc. Following this, analysis proceeds backwards to the EPDBM, the ELDBM, and the ALDBM. Relationships between the ALDBM and the APDBM are defined at the end.

As to which approach is best, Top/Down or Bottom/Up, is actually irrelevant. In all likelihood, a company will probably use both simultaneously. Since Data Engineers and Systems Engineers primarily deal with logical structures, they will concentrate on the ALDBM and work back to the ELDBM. In contrast, Data Base Administrators and Software Engineers will concentrate on the physical structures, thereby defining the APDBM before backing into the EPDBM. The logical structures are then related to the physical to complete the models.  

INFORMATION = DATA + PROCESSING

Specifying information requirement is one of the most important activities in all of "PRIDE." All designs that follow must ultimately satisfy the requirements. Therefore, they must be defined with a high degree of precision and accuracy. Instead of physical media requirements, "PRIDE" focuses on the types of business actions and decisions that need to be supported. Information and Data are not synonymous. Data is the raw material used to produce information.

During EEM and ISEM, end-users are interviewed in terms of the information they need to support their area of the business. This becomes the basis for a formal definition of the information requirements, including:

• The BUSINESS PURPOSE of the requirement.

• The ACTIONS AND/OR BUSINESS DECISIONS to be made, including WHO must make them and WHEN.

• The BENEFITS of having this information.

Data Engineering represents the function in DBEM responsible for analyzing and refining information requirements. From the requirements, Data Engineering can interpret the types of logical objects and views required to support the various requirements, along with indicative data elements that may need to be defined. To demonstrate how objects are used in relation to information requirements, Data Engineering prepares an Information Requirements/Objects Matrix.  

PHASE 1/ACTIVITY D

Activity D represents the first major review with Data Resource Management. This is where the Information Requirements and Project Scope are reviewed and confirmed prior to seeking a solution. In particular, each requirement is evaluated in terms of the affected objects and required data elements (to assure they are accurately defined and related to the requirements). The net result is to reach consensus in terms of the requirements and project scope.  

ROUGH DESIGN

Following confirmation of the information requirements, the Data Engineer is then charged with the task of devising a data base solution. To do so, the engineer prepares a complete rough design of the data base. This involves a tentative design of the four data base models. In this respect, the design process takes on the appearance of mini-Phases 2, 3, 4, and 5.

Participating in the rough design are representatives from Data Base Administration, Data Communications, Systems Engineering, Software Engineering, and DP Operations; all of which consult with Data Engineering during design. The intent is to arrive at a viable solution for the company to implement. In terms of the physical data base, Data Base Administration considers various file management techniques. Data Communications considers data transmission/conversion requirements.

The data base design is considered "rough" in the sense that it represents a tentative design for evaluation purposes. Regardless, there is considerable attention to detail in terms of identifying the data resources needed to satisfy the information requirements. During this activity, the Data Engineer will consider alternatives. For example, the Data Engineer will identify...

• Reusable resources - data resources that have already been developed and are suitable for inclusion in the application.

• Existing resources requiring modification to accommodate requirements.

• New resources that will have to be designed and developed.

• Resources that can be implemented by commercial software packages.

• Data interface requirements between all of the above.

The point is, rough designs are used to propose practical cost-effective solutions for management to consider. However, there are additional benefits. The rough design will become the basis for formulating a project plan, estimate and schedule. This can then be used for "make versus buy" decisions. It will also improve communications and cooperation between the development staff due to early participation in the planning phase.

One final word of advise on rough designs: Do not attempt to perform the whole project in Phase 1. It must be remembered that the intent of Phase 1 is to propose a viable solution for management to consider. Although the rough design may be rigorous, it must not be considered the final design; this is what the succeeding phases of DBEM are for. In other words, do not try to build the perfect system in Phase 1; simply take it to the level where the project team has confidence in the design and that a realistic project plan/estimate/schedule can be prepared.  

DATA BASE CONCEPT DIAGRAM

To graphically represent the data base solution, the Data Engineer prepares a Data Base Concept Diagram. This is a free-form schematic that illustrates to the user how the envisioned data base will operate upon completion. This is similar in intent to an artist's rendering as used in architecture.

Although there are no formal standards for this type of graphic, the Data Base Concept Diagram normally shows the logical objects involved and how they are to be implemented physically. See the "Examples" section under Phase 1, Activity E for a sample Data Base Concept Diagram.  

EVALUATING A PACKAGED SOLUTION

There are two situations where a packaged solution can be considered:

1. APPLICATION SOFTWARE TO IMPLEMENT PARTS OF AN INFORMATION SYSTEM.

   A commercial software package provides one alternative for implementing an information system. Normally, it is not a complete information system but only tested computer programs that is sometimes accompanied by user procedures for input preparation. Most packages tell the purchaser what input is required to produce a specified output without telling the purchaser who does what, when and how. Because of this, fundamental data structures may have to be documented to convert a package into an information system before installation can be accomplished. In other words, a package should be documented in the IRM like any other resource.

   One of the most common pitfalls in purchasing a commercial package is that little consideration is given to the information requirements they must satisfy. Quite often packages are purchased based on marketing hype rather than factual evidence. In other words, a superficial package evaluation is performed. Little investigation is made as how well the package satisfies requirements, how complete the documentation is, what modifications might be required to suit in-house needs, how it will interface with other systems, how long it may take to implement, etc., etc.

   Despite this, experience often shows that the purchase decision is a viable alternative to 're-inventing the wheel'. This is especially true in those situations where resource and/or time constraints have necessitated the purchase consideration. When handled intelligently and adequately managed, packages can be successfully installed to the mutual satisfaction of both development personnel and users to solve pressing business problems.

   How then is it possible to avoid the common pitfalls and evaluate packages intelligently? Fortunately, the answer is simple: Phase 1. It provides all of the background information necessary to intelligently investigate packages. If performed correctly, the Phase 1 will have produced a complete rough design of the data base. This becomes the focal point for preparing a comparative analysis. The Data Engineer should be able to illustrate:

   • The types of file structures that accompany the package and if the files are accessible for additional customer specific processing requirements.

   • How well the package's physical data characteristics conform to in-house requirements. For example, does the package express dates, times, names, monetary values, etc. in the same manner as is commonly used in the company? In other words, how does the vendor express data length, precision, scale, etc? Severe conflicts may be incompatible for in-house use.

   • How the files will interface with other in-house file structures.

   Whenever possible, package documentation should be incorporated into the IRM for management and control. This means that narrative and specifications should be entered in the IRM regarding Files, Records, and Data Elements. This does not necessarily mean entering the product's documentation in its entirety into the IRM, although this would be ideal. It may be more desirable to simply establish cross-reference's to the package's own documentation. However, because the package will ultimately become a natural part of the company's systems, sufficient intelligence should be put into the IRM so that the customer can merge the package's information resources with their own. This provides invaluable control to the customer, particularly when performing an "impact analysis." It also provides the customer with the ability to evaluate a product release prior to putting it into production.

   The customer may elect to execute ensuing ISEM phases in order to properly document the package. This may be accomplished by either the 'in-house' development staff, by vendor personnel, or both working together.

   The decision to purchase a package to reduce development time and costs can produce satisfying results for both the user and development staff. This does, however, require that the organization first develop the information requirements, evaluate and install the package that best meets the requirements, and finally, perform an audit of the project. The DBEM approach is a means for good communications among the participants and earns their commitment, thereby increasing the chances for a successful implementation.

2. FILE MANAGEMENT SOFTWARE TO ACCOMMODATE A NEW SYSTEM OR COMPUTER CONFIGURATION.

   Although physical files are not finalized until Phase 4, Phase 1 begins to highlight the need for file management techniques. Although it may still be too early to make some conclusions, Data Base Administration can begin to consider performance and security issues. From this, some assumptions can be made regarding a suitable approach. In many cases, commercial file management software may be considered, particularly a Data Base Management System (DBMS). It is essential that packages be considered from a practical point-of-view, not necessarily what is technically fashionable. Remember, AN ELEGANT SOLUTION TO THE WRONG PROBLEM SOLVES NOTHING. To this end, Data Base Administrator considers such things as: transaction volume, processing speed, file volatility and hit ratio, backup/recovery, security, number of users, etc. The data base vendor should be able to provide benchmark tests as required to demonstrate how well their product works. Consult Phase 4 for additional considerations.

HARDWARE CONSIDERATIONS

During the rough design, consideration must be given to the physical implementation of the data base. In many instances, the existing operating environment is assumed. However, the rough design may suggest the need for additional equipment and/or enhancements to the current operating environment. This is one reason why DP Operations and Data Communications participate in the preparation of the rough design; to appraise the impact of the proposed data base on the current operating environment.

In studying the rough design, consideration is given to:

• The areas of the business served.
• Processing requirements: such as, Interactive, Batch, etc. Also, distributed versus central processing.
• Types of media (Inputs/Outputs): Graphical, Textual, Audio, Optical, etc.
• Data transmission/conversion requirements.
• Required processing speed and volume of transactions.
• Storage requirements (files).
• Back-up/file retention requirements.

From this, assumptions can be made regarding:

• Computer equipment and operating systems.
• Input/Output peripherals; e.g., terminals, printers, etc.
• Communication hardware/software, including networking.
• Data Base hardware and software.
• Other equipment and files (non-computer related).

From this evaluation, an estimate of anticipated expenditures can be prepared for inclusion in the overall project estimate. At this point, hardware decisions are only tentative. The final decision on these matters should be reserved for subsequent DBEM Phases as designs are finalized.  

PROJECT PLANNING

Before a project estimate and schedule can be calculated, the path of the project must first be defined. Under DBEM, the project path is based on the four data base models.

There are two situations where the project path may deviate:

1. It is possible, but not likely, that a single DBEM project can be used to implement the data requirements for more than one system. In this event, there will be multiple Phase 2's and Phase 5's (one for each system).

2. For an EEM related project, the project path may consist of nothing more than Phases 1, 3, and 6.

The point is, DBEM provides a good framework for executing a development project. However, Project Management must consider the practical implications for controlling the project and, as such, must make the final decision on project execution.

After the path of the project has been determined an Order-of-Magnitude (OOM) estimate and schedule can be calculated. This is an estimate and schedule of the amount of effort required to perform the remaining phases in the project. The estimate, thereby, is an expression of labor charges.  

HUMAN RESOURCE REQUIREMENTS

Following the rough design and the project plan, consideration must be given to the types of human resources required to implement the project. Based on the type of application being developed, Project Management considers the types of Data Base personnel required to work on the project, including the skills and proficiencies needed to perform the work. Based on this analysis, Project Management has four options:

• Use in-house personnel.
• Recruit additional personnel.
• Use outside personnel (contractors).
• Combinations of the above.

In all instances, the use of human resources is based on their qualifications, their availability, and their cost. Project Management, therefore, must balance these variables when selecting personnel. There may be trade-offs to consider; for example:

• One person may be more expensive than others but can deliver the work faster.

• A senior person could perform the work in fewer hours than a junior person, but is committed to other project assignments. Consequently, the person cannot devote sufficient time to the project. Whereas the junior person may have fewer conflicts and is more available for project work.

The use of known human resources has a direct impact on the Order-of-Magnitude estimate and schedule. However, in the situation where resources are unknown, the Order-of-Magnitude estimate and schedule can still be calculated. Here, the Project Manager must make some assumptions as to the type of skills and proficiencies required and the number of Data Base personnel needed for the project. The estimate thereby becomes the basis for recruiting additional personnel or hiring contractors. It also becomes the basis for determining training requirements, the cost of which should be absorbed by the project.  

COST/BENEFIT ANALYSIS

The purpose of a Cost/Benefit Analysis is to perform an economic impact analysis on the data base and the project. Prior to performing this, Project Management has prepared an Order-of-Magnitude estimate to complete the project, along with any additional planned expenditures (such as for additional hardware/software acquisitions).

"PRIDE" provides a worksheet to assist in the preparation of the Cost/Benefit Analysis. However, in-house standards should be observed when performing the analysis.

During the analysis Project Management must consider how the proposed data base solution will affect the company:

• Will it increase or reduce staffing?
• Will it increase or reduce equipment resources?
• What will be the annual savings and expenses of the data base as it compares to the existing environment?
• What will be the one-time savings and expenses of the project as it applies to the existing environment?
• What will be the intangible benefits of the data base?
• What is the investment evaluation? For example, what will be the Break Even Point of the project? What will be the Return On Investment (ROI)?

The Cost/Benefit Analysis becomes the basis for the preparation of the Cost and Evaluation Summary, a textual justification for the project.  

PHASE 1 REVIEW

The formal deliverable resulting from Phase 1 is the "Data Base Study & Evaluation Report." This represents a packaging of the various elements produced during the phase (e.g., Project Scope, Information Requirements, Data Base Concept Diagram, Data Base Approach, Project Plan, Order-of-Magnitude, Cost and Evaluation Summary, etc.). A formal meeting with management is conducted to review the deliverable. At this time, management may elect to approve the project as proposed in the deliverable, request revisions before proceeding, or cancel the project completely.

There may be many reasons for discontinuing a project at this time, perhaps the project team cannot produce an adequate solution for satisfying the business problem, or maybe the economics of the project are not justifiable (the Return on Investment may be too low for example). There is little reason in expending human and financial resources towards an endeavor that cannot be proven worthwhile.

Assuming cancellation of the project, the company retains specifications regarding:

• The current data base.
• Information Requirements.
• A rough design of a proposed new data base.

Based on this report and subsequent review meeting, management may elect to revise parts of the report, discontinue the project, or approve it for continuation.