Reassess and reaffirm that the Methodology Path previously chosen remains appropriate for the project.
Purpose of Detailed Business Area Analysis
The purpose of a DBAA project is to provide detailed models as a solid basis for system design. The methodology helps find the right answers to the right questions. Applying the methodology is never an end in itself.
The analysis must ultimately lead to decisions to do certain things, such as to start other projects. For the successful implementation of the decisions, it is important that the decisions be supported by the organization as a whole. A DBAA project provides a framework for communication about things that are relevant to the decisions. During this communication process, conflicts in opinions and interests can be elucidated and resolved, and the overall commitment to the decisions that are made will thus be improved.
Objectives of Detailed Business Area Analysis
During the course of Detailed Business Area Analysis, the scope of the project is constantly refined. Detail is added only where there is a clear requirement for it from users. The level of detail should be enough to evaluate the definition of the design area, covering the scope of a business system. A subsequent design project covers such a design area.
The objectives of the Detailed Business Area Analysis Stage are to:
* Develop a detailed understanding of the design area
* Identify specific information needs and priorities for the business areas as a basis for system design
* Collect and analyze relevant current systems information assuring that the present functionality and problems are resolved in the design area models
* Evaluate the identification and prioritization of the design area
as to its support to the needs of the business area
General Approach to Detailed Business Area Analysis
Overview of Outline Business Area Analysis
An Outline Business Area Analysis (OBAA) project involves a more detailed analysis of entity types(data) and business processes (activities) than an enterprise modeling project. From an OBAA project, users can see precisely what is relevant to them and can agree on plans for developing supporting systems.
The result of the OBAA is a full understanding of the business area, with identified information needs supported by relevant quantitative data as a basis for system design and distribution.
Finally, identification and prioritization of systems to support the needs of the business area, delivers defined design areas, the scope for Detailed Business Area Analysis (DBAA) projects.
Results of Detailed Business Area Analysis
The result of the business modeling is a set of models that describe all that is relevant. The set can then be considered a "statement of requirements" or a "design area description." The major elements of this design area description are:
* A description of the scope of the area
* The detailed business area model, which itself consists of (1) an entity relationship diagram, including relevant business rules, (2) a process decomposition and a process dependency model, (3) the interactions between processes and entity types, and (4) process logic and process action diagrams for elementary processes and business algorithms
* An analysis of the current systems procedures and data stores supporting the design area, including a comparison report stating coverage and differences with the models
* The evaluated definition of the design area
Use in Later Phases of Development
Analysis at the level of a design area creates a base of information about the business on which to build one or more systems designed to serve the requirements of a collection of strongly related business activities. Because the design area is defined within the architecture of the business area, it is ensured that the resulting systems will be capable of being well-integrated.
The DBAA project results in the evaluated definition and prioritization of the design areas. The next stage would be the design of the system.
Planning for the Next Stage
For one design area, experience typically shows that one business system is identified for work in the next stage. Business systems are first identified in enterprise modeling stage and may be refined and re-scoped after completing the detailed business area model in the light of the more detail available at that time.
Role of Detailed Business Area Analysis
EM produces a general information architecture for the enterprise. OBAA leads to a detailing of the architecture for a particular area so that users can see precisely what is relevant to them and can agree on plans for developing systems to support the architecture. Then, DBAA fully describes in a rigorous way the detailed contents of a design area, being the conceptual basis for a business system.
Analysis lets people show just what their part of the enterprise looks like and what should happen within it. It highlights similarities and differences with other parts of the enterprise. It then becomes possible to see where difficulties in communication could arise and what the options are for resolving them.
An important feature is that the principal results from analysis can be represented diagramatically and can be easily read and checked. The diagrams are used as a formal definition of the design area -- i.e., they are the users' description of the way the business should be. The diagrams are valuable because they provide unambiguous instruction to the designers of information systems. The designers can translate the instructions directly into a specification for computer support.
In addition to adhering to the general philosophy of the Application Development Methodology (ADM), DBAA has certain characteristics of its own:
* DBAA takes place within the framework of an EM and an OBAA and is driven by corporate objectives. It aims at producing a clear view, in business-oriented terms, of selected parts of the business, so that they can be given effective information system support.
* DBAA is geared to producing information system support for a whole design area, not to ad hoc solutions to short-term problems.
* DBAA focuses on the user's perception of the enterprise.
* DBAA provides a sound basis for estimating the broad costs and benefits of providing computer support through the implementation of high-quality information systems.
* DBAA requires greater initial effort and investment than traditional development approaches, but it leads to greater productivity and more effective, higher-quality systems.
* DBAA deliverables follow the concepts and definitions of the ADM and are used again in subsequent stages of the development process.
A number of critical factors require special attention during a DBAA project. To a large extent, these factors determine the success or failure of the project.
Though not requiring the same level of involvement by top management as EM, a DBAA project does require top-management commitment to providing the required resources. This can be particularly important for ensuring that knowledgeable and appropriately skilled users are made available to participate in the project.
Furthermore, from the start of the project it should be possible to nominate an "owner" for the design area and its resulting system, giving an opportunity for very specific sponsoring of the project.
It is of prime importance to gain the commitment of senior managers whose world is to be analyzed. During EM and OBAA, these managers' opinions helped define the design area and its priority for system support. If the project is to succeed, senior management must be seen to be backing it. It must be clear right from the start that the DBAA must lead to management decisions for subsequent actions.
It is critical to the success of this approach that the direction and priorities of the effort be established and controlled by users. A real commitment is now required in terms of access, involvement by user staff, participation in user workshops and access to all information relevant to the design area, including details of business objectives, plans, and procedures.
For this reason, resources for a DBAA project must always be drawn in part from the user community directly interested in and knowledgeable about the business requirements of the area in question. The most effective way to involve users is the use of user workshops in which the business is analyzed and requirements are defined. These intensive group sessions are normally much more productive than interviewing. Reaching consensus is part of the workshop.
Attention must be paid to ensuring that the project team members and user workshop participants have the required experience and capabilities. End users should provide business experience and specific knowledge of the design area under study. Analysts should be experts with techniques and should understand information systems. The overall direction should be controlled and coordinated through development coordination.
Projects involving analysis can become subject to "paralysis
by analysis." Such projects are never successfully concluded, being
constantly overtaken by changes in the business requirements. In general,
this happens because analysts become too immersed in details that are irrelevant
to the definition of the design area model. It is, however, important that
the right level of detail be reached, because the next stage of development
should be able to make a direct translation into a system design. The amount
of time allocated to a DBAA project should be realistic, reflecting the
number and complexity of business processes involved. Producing a detail
design area model should generally not exceed two months. Using CASE tools
for support and applying rapid development techniques, like user workshops
and timebox management, will reduce the lead-time.
Please paste the activity description here!
Previous : A3.8.7
Activity Overview : A3.8
Stage Overview : Analysis Stage
Overview : Table of Contents