The purpose of application planning is to align the application (re)engineering with business goals. Several methodologies have been developed for this planning process initiated with the "classical" information systems planning methodologies such as the following:

Extensions of these methodologies have been reported such as the BSP extensions by Blokdijk and Blokdijk [Blokdijk 1987], and homegrown methodologies [Meyer 1996], [Highsmith 1987], [Hulfnagel 1987], and [Mushet 1985].

Of particular interest are the business process reengineering (BPR) approaches that align IT with business [Boar 1994], [Henderson 1990], [Keen 1993], [Luftman 1996], and [Venkatraman 1984] and the Internet related strategies [Cronin 1996]. Extensive discussion of BPR and planning methodologies is beyond the scope of this book (the aforementioned references should be reviewed for details). However, the following key BPR principle will guide our discussion: You should use information technology to improve the performance of a business and cut costs by redesigning work and business processes from the ground up instead of simply automating existing tasks.

This principle should be the driver as you go through the activities of the planning iteration (i.e., analysis, architectural trade-offs, implementation issues, and deployment/support considerations). Table 3.1 casts these activities into planning steps and Figure 3.3 ties these generic planning steps into a procedure. We will discuss these steps in the following subsections.

Table 3.1 Application Planning Checklist

Based on the results of the planning iteration, and any other relevant information, an initial important decision is made: given a business opportunity, should a new application be developed (application engineering), should existing applications be reengineered, or should a mixture of engineering/reengineering be used? This decision may be revised in later iterations as we develop a better understanding of the problem and the various trade-offs. However, this decision will help us to outline a rough project plan that specifies:

This plan is used to define the next iterations and to decide how much effort will be spent in engineering versus reengineering. Keep in mind that planning does not need to take a long time, it just needs to be done. In my own experience, I have found that preparation of a response to each RFQ (request for quotation) essentially goes through the planning steps.

Figure 3.3 Overall Planning Procedure

Application (re)engineering is an expensive and risky undertaking. The purpose of this step is to understand and analyze the basis and business motivation for this effort before fully launching it. Although different business drivers motivate application (re)engineering the following broad categories represent many business drivers:

In addition to business drivers, you need to develop an understanding of the business requirements that drive the technical requirements (Figure 3.4). In particular, you need to identify the organization and the processes that will be served by the applications and develop an "end-user" profile that shows the characteristics of the user community (e.g., decision support versus operational support users, novices versus "power users"). You also need to identify the main customers and stakeholders who will benefit from the proposed applications. In addition, these requirements should capture:

Keep in mind that these requirements are very high level (also known as "thin" requirements) and are meant to help you assess readiness for (re)engineering. These requirements should be between 20 to 30 statements and must not include screen layouts and other programming details (all that comes later).

After identifying and clearly understanding the business drivers and high-level requirements, you should analyze the opportunity by posing questions such as the following:

As a result of these questions, an overall strategy can be established that defines a short and long range vision for the applications and services under consideration. It is the responsibility of management to develop and present a clearly defined and doable vision. Unfounded visions and too many visions ("vision of the day") cause serious problems. Announcing a vision is not enough; continued and visible support from management is essential for the success of a strategy [Henderson 1990], and [Luftman 1996]. One possible approach to achieve these objectives is to get the information technology experts involved early in the planning process. These experts can help in making the vision realistic and then work as agents and supporters during the implementation stages.

Figure 3.4 Business Requirements Drive the Technical Requirements

Given an understanding of the business drivers and high-level requirements that conform to an overall business strategy, the next challenge is to architect a solution approach that could satisfy these requirements. Specifically, you need to answer questions such as the following:

The answer depends on how new is the business undertaking, what already exists in your organization, what is available as a commercial off-the-shelf package, and how flexible is the existing system. In general, we can analyze these decisions based on the following three factors:

Figure 3.5 shows how these three factors can be used to systematically generate application engineering/reengineering choices. Evaluation of these choices is a time-consuming, yet an essential, aspect of contemporary application engineering/reengineering practice. Broadly speaking, the choices are a mixture of purchasing off-the-shelf packages, developing new application components from scratch, and interfacing of new components with the existing, in many cases, legacy systems.

Purchasing off-the-shelf applications is a viable solution when new databases and new functions are needed. This strategy, if feasible, is by far the most attractive. Consequently, it must be considered as the first choice. For example, if a human resource (HR) application is needed and the requirements seem to be satisfied by an off-the-shelf HR system from a vendor, then this package should be evaluated seriously. The key evaluation criteria are:

In many cases, some or all portions of an application (databases, application code, user interfaces) need to be developed. For example, it is possible that the requirements can be satisfied by engineering (designing, developing, and deploying) a new database that is accessed by off-the shelf packages or end-user tools such as spreadsheets, data browsers, and report writers (e.g., data warehousing applications). If new application code needs to be developed, then we can assume that the new application code will be developed as an object-oriented C/S application. In a few cases, all components of new applications need to be developed. Part II of this book (Chapters 4 through 7) discuss these issues in detail.

Figure 3.5 Application Engineering/Reengineering Approaches

Reengineering (redesign, migration, interfacing) of existing, in many cases legacy, applications is an important aspect of IT practice at present. For example, it may be possible to satisfy the requirements by reengineering (i.e., interfacing and migrating) the existing databases. Access to enterprise data, especially legacy data, from a diverse array of tools and applications residing on a variety of platforms and interconnected through different network technologies is of key importance in most enterprises. In particular, many Web-based tools need to access enterprise data. In several cases, the requirements can only be satisfied by re-architecting and migrating the existing legacy applications that are old, unstructured, and monolithic. Choice of an appropriate approach depends on several factors such as business value of the legacy system and its technical value (see Figure 3.6). We will discuss the legacy application reengineering issues in Part III of this book (Chapters 8 through 11).

Figure 3.6 Legacy Application Analysis (Source: [Sneed 1995])

IT infrastructure (platform) planning is concerned with determining the most appropriate technology needed to develop and deploy the application systems. Examples of such infrastructures are the Intranets that provide Web services in corporate private networks; factory networks that connect many manufacturing devices to cell and area controllers, and "Extranets" that connect many businesses (healthcare industry participants). IT infrastructure planning is a much more challenging and crucial task than network planning. This is because the diverse applications in business, engineering, and manufacturing written in different software/database formats that reside on heterogeneous computing devices need to be interconnected through different communication media by using a variety of communication software packages.

Specifically, the main infrastructure capabilities (middleware, network services, local computing services) needed to support applications that must be carefully examined in the planning iteration. (See Figure 3.7.) The IT infrastructure becomes increasingly important as you iterate through the system life cycle (i.e., planning iteration only concentrates on high level issues that could be "show stoppers" while the first release must go through detailed considerations such as the exact version of middleware needed). The details depend on the type of applications being engineered/reengineered. For example, legacy data access requires a different type of infrastructure than a Web-based distributed object application.

Basically, the entire IT infrastructure should appear as a tightly integrated environment that provides a range of networking, database, transaction management, remote messaging, naming, directory, security, and other services needed by the applications. The key question is: How can we put all these pieces together into a functioning IT infrastructure that can support the variety of services and applications needed by the modern enterprises? The following iterative steps are suggested as a starting point:

Table 3.2 summarizes the main activities in each stage of the methodology introduced in Section 3.2 for the infrastructure services. The rows of this table show the four generic activities (i.e., analysis, architecture, implementation, deployment) and the columns represent the three classes of infrastructure services (i.e., middleware, network, local).

As discussed previously, infrastructure issues are beyond the scope of this book and were briefly introduced in Chapter 2. A detailed procedure for selection and evaluation of OCSI infrastructure can be found in the companion book [Umar 1997, Chapter 9].

Figure 3.7 Conceptual View of Infrastructure Role

Table 3.2 Summary of Infrastructure Considerations

Costs and benefits of emerging technologies such as object-oriented, client/server, Internet (OCSI) environments is tricky. In general, most new technologies are accompanied by euphoric claims of benefits/promises with a deaf ear (typically for two to four years) to costs/pitfalls. To some extent, this "positive wave" is natural because the real costs and pitfalls are revealed only after some hands-on experiences have been accumulated. In recent years, this happened with client/server (C/S) systems. We do not know the real costs and benefits of OCSI at the time of this writing due to its newness. However, we can review the results of C/S computing and extrapolate some results to learn some lessons. Towards this goal, the costs and benefits of C/S computing are reviewed in Sections 3.3.5.2 and 3.3.5.3.

The client/server technology wave hit us all around 1992 as a cure for all the evils of the old mainframe-based systems. Many C/S success stories have been reported in the trade journal since 1992. However, there have been numerous failures, albeit not well documented (see the sidebar in Chapter 1 "Failures–Lessons from the Client/Server Wave"). Here is the main lesson: There will be successes as well as failures in OCSI implementations, but failures will rarely be publicized and will come to surface a few years after the initial wave (usually at the beginning of the next wave).

Cost/benefit analysis of IT, in general, is fuzzy and subjective. The main idea is to be realistic in your expectations about benefits and costs. Since costs (and risks) are facts of life, you need to determine the strategies that maximize business benefits and minimize/manage costs and risks. Survey of a large number of case studies has indicated that successful application engineering/reengineering efforts exploit the promises of new technologies but carefully understand and manage the risks while the others do not (see Figure 3.8). What precisely are the promises and pitfalls of OCSI applications from what we know at this point? See the sidebar in Chapter 1 "Why Object-Oriented Client/Server Internet-based Applications: Promises and Pitfalls." We will visit these issues in more detail in Chapter 4.

A few surveys for the costs/benefits of C/S computing have been published (see the sidebar "Sources of Information for Client/Server Costs/Benefits"). For example, a Gartner Group [Dec 1995] report analyzed costs for C/S computing (see Table 3.3). The main findings of this analysis are:

Dec [1995] also includes a report card on C/S computing. Basically, the report card gives C/S computing failing grades on lowering costs (costs go up), higher availability (C/S systems tend to fail more often), and serviceability (too many components to service). However, the grades for rapid deployment and better scalability are better (B and C, respectively).

Figure 3.8 Recipes for Success and Failure

Table 3.3 How Much Do Client/Server Systems Cost? (Source: [Dec 1995])

Many costs are hidden and are not apparent initially in C/S projects. For example, middleware costs per mainframe is about $200K, and per PC cost is about $500K. Installation of a large scale C/S system involving, for example, 1000 desktops could easily cost 0.5 million dollars. Distributed applications also require many software licenses at many computers, thus potentially increasing the software costs.

The initial axiom of one server machine per application has not resonated very well. According to a study conducted by the University of California at Berkeley’s School of Business, every $1,000 spent on server hardware/software needs to be matched with $9,000 of management and maintenance costs [Jenkins 1995]. Owing to this, many organizations have started using powerful servers that can house many applications (i.e., more centralization).

While estimating costs, intangibles need to be considered. Examples of these intangibles are increases in interdependencies and points of failure, concerns for security and integrity control, and many management/support issues. We will visit these issues in Chapter 4.

Costs of migration to OCSI should be evaluated very carefully (we will visit this issue in Part III of this book). Basically, the potential of big savings for application migration to OCSI is there, but keep in mind that the mainframe costs are dropping. In addition, many hidden costs are hard to control/quantify, because significant costs shift to consulting and training. Full cost savings can only be realized if the mainframes are retired completely and the expected payoffs do not happen right away (many efforts take three to four years with payoffs in the last year). In addition, many people issues arise, because traditional IS staff and users may resist (new skills are usually needed) and responsibilities shift to end users. The bottom line: hardware cost savings alone are not enough for transitions and should not be used as the key business drivers.

In summary, it has been found that C/S increases total costs due to the following reasons:

The introduction of C/S technologies has in general strengthened the position of IT departments because some of the functionality and budget dollars have shifted to the IT departments away from the central MIS departments. (A Gartner Group 1996 report indicates that the annual revenue for decentralized functions will jump from 2.3 percent to 6.8 percent between 1994 to 1999 and will reduce from 2.0 percent to 1.6 percent for the centralized functions in the same time period.) However, the central MIS departments are not extinct–their role has changed to more enterprisewide consultation, integration, and management [Grygo 1996].

In general, C/S benefits are scattered outside the IS department such as: