Methodology Overview: Planning and Modeling

NEWS BLOGS FORUMS NEWSLETTERS RESEARCH EVENTS DIGITAL LIBRARY CAREERS

IMMERSE YOURSELF:

Storage & Servers

Methodology Overview: Planning and Modeling
February 8, 1999

Introduction to Application (Re)Engineering Methodolog

3.1 Introduction

This chapter presents a methodology "pattern" that can be customized to engineer new applications and reengineer existing (mostly legacy) applications in the object-oriented client/server Internet environments. There is no "one size fits all" approach but there are certain generic activities that take place whether you are developing a data warehouse, an electronic commerce application, a Web-based work flow system, a Web-based object wrapper for legacy applications, or a gateway for migrating legacy applications. In particular, you should not have to rethink the entire process for the aforementioned situations. Our goal is to present a set of generic activities and answer the following questions:

l What are the key customizable activities of a generalized application engineering/reengineering methodology (see Section 3.2)?

l How does planning fit into this methodology (see Section 3.3)?

l Can an object-oriented framework be used to model the wide range of applications being engineered and/or the legacy applications being reengineered (see Section 3.4)?

Key Points

l An application engineering/reengineering methodology pattern consists of successive iterations, refinements, and expansions of four broad activities: analysis, solution architectures, implementations, and deployment/support activities.

l Overall planning should always be the first iteration of the process and should concentrate on business opportunity analysis and risk analysis to determine the best strategy.

l The object model can be used as a foundation for almost all application engineering/reengineering issues.

3.2 Application (Re)Engineering Methodology

A methodology is needed to direct the application engineering/reengineering activities. Before proceeding with details, we should acknowledge that formal methodologies have had mixed results [Inmon 1993], and [Mowbray 1995]. The appeal of a methodology is that it directs the developers down a reasonable path with pointers for what to do, in what order to do it, what to produce, and what to expect as inputs. However, many methodologies fail because of their linear flow of activities, rigidity in a prescribed set of activities, and emphasis on diagramming tools. For example, more than two dozen methodologies based on object-orientation have been documented [Hutt 1994]. To ameliorate some of the concerns, work in standardizing software life-cycle activities has been initiated [Singh 1995].

Figure 3.1 shows a "methodology pattern" for application engineering/reengineering. This pattern represents a template that can be customized for specific cases. The key points of this methodology pattern are:

l Application engineering/reengineering is an intensely iterative process.

l All iterations are based on the refinement and expansion of the following core activities:

— Analysis,

— Solution architectures,

— Implementations, and

— Deployment/support

l Planning, prototyping/experimentation, first release, and subsequent releases are in fact iterations (not separate phases) in which each one of these activities is performed at different levels of detail.

l Some activities are more extensive than others in each iteration (represented by the width of activity triangle traversed in each iteration in Figure 3.1). For example, the first iteration requires extensive analysis and architecture but minimal implementation and deployment/support activities. This is because the first iteration emphasizes business opportunity analysis and assessment of technical feasibility through architectural evaluations. However, later iterations successively reduce the time spent in analysis and architecture activities but increase the implementation and deployment/support activities. Naturally, later releases of a system are heavily implementation and deployment/support centric.

l For a major release or enhancement of an application, you may restart the entire process with the first iteration.

Let us briefly review these iterations before getting into details (Figure 3.2 maps this methodology to the organization of this book).

Planning. The first iteration, discussed in Section 3.3, essentially concentrates on overall planning. It identifies the business drivers; key stakeholders/funding sources; high-level requirements; and costs/benefits based on a quick review of proposed solution architectures, implementation considerations, and deployment/support issues raised. The main purpose of this iteration, in our case, is to answer the following application (re)engineering question: Given the high level requirements and business drivers, should new application(s) be built (i.e., engineered) from scratch, should existing application(s) be reengineered, or should a mixture of engineering/reengineering approaches (e.g., build a small portion and interface it with existing) be used?

Figure 3.1 A General Methodology Pattern

Modeling and Prototyping. In the second iteration, discussed in Section 3.4, we typically build prototypes and experiment with the architectures, implementations, and deployment/support aspects of an application to gain insights into feasibility and effort sizing. In particular, the application (re)engineering decision made in planning is revised, if needed. Although the specific steps and tools in this iteration depend on the type of applications, we suggest that an object-oriented approach is quite useful as an overall framework. In particular, we show that development of an object model by using an object-oriented analysis approach can be a good starting point for almost all application engineering/reengineering activities (see Section 3.4).

Production Iterations. In the next iterations, the first and future releases of the application are built and deployed. The specific steps and tools in these iterations depend on the type of applications and on the type of application engineering/reengineering approaches. Part II and Part III of this book will explore these iterations in more detail.

Figure 3.2 Application (Re)Engineering Methodology–Another View

This general methodology pattern is based on my own experience in three different areas: (a) more than ten years of real life detailed participation in a wide range of application engineering/reengineering projects, (b) development and teaching of numerous information system analysis and design courses, and (c) extensive examination of the extant literature in methodologies such as the following:

l IS planning methodologies [Blokdijk 1987], [Zachman 1982], [IBM 1978], [Rockart 1982], [Keen 1991], and [Luftman 1993].

l Object-oriented analysis and design methodologies [Booch 1994], [Rumbaugh 1994], [Jacobson 1992], and [Nerson 1995].

l Special design methodologies for application areas such as data warehouses [Inmon 1994] and [Inmon 1993], real-time systems [Fuhrt 1995], and [Gemmel 1995], hypermedia applications [Isakowitz 1995], and rapid prototyping [Gordon 1995].

l Methodologies for reengineering of legacy systems [Brodie 1995], [Sneed 1995], and [Desfrey 1996].

l Rapid prototyping approaches, such as the ones reported by Gordon [1995] that are based on review of almost 40 case studies.

How to Succeed by Trying

1. Be clear about what you are trying to accomplish and what are the business drivers.

2. Involve business and IT groups early (planning stage) in the process.

3. Take every opportunity to improve the business processes and keep technology innovation as a lower level objective.

4. Keep projects short so that you can measure success/failure.

5. Base transition strategies on investments that are already necessary.

6. Get sponsorship/buy-in from senior management.

7. Do not forget/underestimate the people issues.

8. Overinvest in end-user support.

9. Use information technologies as enablers and not as drivers of change.

10. Pay special attention to reuse of existing resources including legacy.

Sources:

Adhikari, R., "Taking Care of Business," Software Magazine, June 1996, pp. 57—62.

Candler, J., et al., "The ORION Project: Staged Business Process Reengineering at FedEx," Communications of the ACM, February 1996, pp. 99—107.

Davenport, T., and Short, J., "The New Industrial Engineering: Information Technology and Business Process Redesign," Sloan Management Review, Summer 1990, pp. 11—27.

Schulman, J., "Transition to the New Computing Environment," Gartner Briefing, February 1995.