Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


2.4. REENGINEERING LIFE CYCLE

The reengineering life cycle is the content and sequence of the methodology. The life cycle describes in detail how the future business system will be defined, developed, and implemented. The methodology spans business activities from strategic planning, through product development and process redesign, to operations. The author's version of the methodology has five phases (Beckman, 1996):

Phase 1: Determine strategy
Phase 2: Assess current state
Phase 3: Develop conceptual design
Phase 4: Build and test detailed design
Phase 5: Implement design


FIGURE 2 Infrastructure elements.

The determine strategy phase focuses on setting and/or validating the strategic direction through analysis of industry, market segments, customer needs, competition, core competencies, and external trends and forces. Mission, vision, improvement initiatives, and plans are melded into a business strategy. Then, strategic initiatives, primarily reengineering projects, are scoped and aligned to ensure commitment of executive leadership. Outcomes from phase 1 are the business strategy, targeted market segments, and approved project charter.

The assess current state phase assesses the current state of each of the components in the business system. Needs, values, and expectations of current customers, targeted market segments, including the interests and issues of key stakeholders, are determined, clustered, and prioritized. Next, constraints such as project funding, political sacred cows, technology feasibility, market dynamics, resources, and workforce expertise are determined. Conflicting needs and unnecessary constraints are negotiated and resolved. The resultant customer needs are then transformed into high-level business requirements and constraints. Further, problems and defects in the current system are identified and also converted into requirements. The outcomes from phase 2 are the case for action that documents the current state, defined value and performance gaps, and a set of high-level business requirements and constraints.

The develop conceptual design phase starts with the high-level business requirements and tries to design an ideal system by decomposing the design into work system components. Design enablers such as customer needs, value gaps, performance gaps, best practices, innovative IT, and creative thinking are used to improve and enhance the design. Next, design functionality/features are prioritized by the stakeholders, clustered into releases, and assessed for costs, benefits, risks, and dependencies. Outcomes are the conceptual design and high-level business case.

The build and test detailed design phase takes the conceptual design and decomposes each component into its detailed attributes. An operational prototype of each component is developed and tested for feasibility and effectiveness. After component testing, an integrated test is conducted of the overall design that is evaluated by the various customers and stakeholders. Design modifications are made and tested until the customers are satisfied. Outcomes are the detailed design, release strategy, and business case.

The implement phase first conducts a release pilot at an operational site to field test the design. Once proven, releases are rolled out across all sites. The final activity, transition to operate, includes measurement, problem-solving, and learning.

At the end of each phase, a decision point with three options -- go, no go, or wait -- is used to determine whether staffing and funding resources for the next phase will be approved and committed. Thus, resources are both managed efficiently, and more promising or urgent initiatives may displace or delay, but not kill, an existing one.

3. DESIGN CONCEPTS

Advice on design is both scarce and often difficult to generalize across domains. Design is a creative, problem-solving process that attempts to produce an artifact with functionality that meets specified needs or goals. Design goals and needs must be translated and articulated into a measureable set of specifications. These specifications are in turn decomposed into requirements and constraints. Requirements describe the desired functionality; constraints place limitations on the design. Design components are then created or selected with features that satisfy various requirements and constraints. Finally, the overall design is assembled, integrated, and optimized.

According to Darr and Dym (1997), designs can be categorized into three classes:

  • Creative: entirely new design artifact created to meet new purpose
  • Variant: creation of new components and improvements to an existing artifact, resulting in significant new functionality
  • Routine: assembly and configuration of existing components to meet expected or customized needs

Creative designs are required to meet ill-structured problems; variant designs are needed to solve semistructured problems; and routine designs can be used to optimize well-structured problems.

One goal of designers is to convert difficult ill-structured design problems into easier routine design problems by accumulating knowledge in the artifact's domain. Knowledge of prior successful designs can often be used as the basis for modified new designs. Case-based reasoning (Kolodner, 1993) can be applied to find the closest matching design solution in the case base, and modify it using rules to fit the current problem situation. Routine design problems can also be termed configuration problems. Configuration design tasks often require that a known set of parts be assembled into an artifact framework that has not been specified in advance (Ruby and Kibler, 1993).


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.