mis - chapter 14 - building information systems

PA R T V

Implementing and ManagingIT

632

13. Information Technology Economics14. Building Information Systems15. Managing Information Resources and IT Security16. Impacts of IT on Organizations, Individuals,

and Society (online)

�

C H A P T E R

14Building Information Systems

Utility Computing

14.1The Concept of a Systems

Development Life Cycle

14.2Methods for Complex orQuickly Needed Systems

14.3Component-based

Development and WebServices

14.4Systems Developed Outside

the IS Department

14.5Building E-Commerce

Applications, ASPs, andOutsourcing

14.6Some Important Systems

Development Issues

Minicases: (1) “Do or Die” /(2) University of Nebraska

LEARNING OBJECTIVESAfter studying this chapter, you will be able to:

� Explain the concept of a systems developmentlife cycle (SDLC).

� Compare and contrast prototyping, rapidapplication development (RAD), jointapplication design (JAD), object-oriented (OO)development, extreme programming (XP), andtraditional SDLC approaches to systems develop-ment.

� Describe the contributions of component-baseddevelopment and Web services to building infor-mation systems.

� Evaluate alternatives (including the adoption ofutility computing) to in-house systems develop-ment.

� Discuss the major strategies, methods, and toolsfor building e-commerce applications.

� Identify advantages and disadvantages of CASEtools. Describe alternative approaches tosoftware process quality improvement.

0006D_c14_632-678.qxd 10/15/03 17:17 Page 632

633

UTILITY COMPUTING: “THE NEXT BIG THING”

➥ THE PROBLEM

Imagine this scene. It’s noon on Friday and you just found out that your rela-tives are coming to spend the weekend. It’s time to contact the electric companyto let them know that you will need extra electricity for the weekend. You’retold you have to fill out a purchase order and it will be five to seven days be-fore you can get extra electricity. Of course, life is not like this, because basic util-ities have extra capacity built into their delivery systems. But this would be alikely scenario if you were to find out at noon on Friday that you were expect-ing a major spike in usage on your servers. You’d have to call your provider, doa bunch of paperwork, and maybe in a few days you could get the extra capac-ity you need. That’s the kind of problem that utility computing aims to solve.

➥ THE SOLUTION

Utility computing vendors are looking toward a future in which computing ca-pacity is as easy to acquire as electricity. Rather than having a fixed amount ofcomputing resources, you would have access to computing resources on an as-needed basis-just like with electricity. Many IT market leaders are now startingto catch on to the concept of utility computing as a bullet-proof utility servicethat we can virtually take for granted. IBM announced it is spending $10 billionon its on-demand computing initiatives. HP also announced its Utility DataCenter architecture, and Sun has its own N1 data virtualization center plans.Sun, HP, and IBM are duking it out over how best to meet utility computingrequirements and command a leadership position.

➥ THE RESULTS

Already present in a variety of capacity-based pricing models, utility computingis poised to expand throughout the enterprise as various key technologies—suchas Web services, grid computing, and provisioning—intersect. Growth of utilitycomputing in the enterprise will deliver to the industry not only equal access tosupercomputing resources, but also new revenue streams for commercial datacenters, new application pricing models based on metered use, and an open com-puting infrastructure for companies with little or no standing IT maintenancebudget. Utility computing is on track to be the “next big thing” for IT vendorsand services companies that sell to large enterprises.

Sources: Compiled from Zimmerman (2003) and from Neel (2002).

➥ LESSONS LEARNED FROM THIS CASE

Utility computing (also called “on-demand computing”) has become one of thehot topics in the IT analyst community and, increasingly, in larger enterprisesthat are looking for ways to reduce the fixed costs and complexity of IT. Utilitycomputing tools provide total flexibility in information systems development,from in-house and self-managed to fully outsourced, with everything inbetween—including a hybrid deployment model in which in-house capacity canbe supplemented by third-party resources to handle peak needs.

0006D_c14_632-678.qxd 10/15/03 17:17 Page 633

634 CHAPTER 14 BUILDING INFORMATION SYSTEMS

In this chapter we will look at the topic of building information systems.Since organizational environments and general technologies change over time,organizations need new systems, or major revisions to existing systems, to con-tinue to meet their objectives. Therefore, systems development is an ongoingprocess in all organizations that use IT.

In this chapter we discuss various approaches to development that can in-crease the probability of favorable outcomes. We initially present the concept ofa systems development life cycle. We then discuss various system developmentalternatives (prototyping, rapid application development, joint application de-sign, object-oriented development and extreme programming). Then we providea comprehensive discussion of the contributions of component-based develop-ment and Web services to building information system. The subsequent sectioncovers end-user development, acquiring systems from outside sources, utilitycomputing and deciding between development approaches. Next is a sectionon the approaches, methods, and techniques used in developing Web-based in-formation systems. The final section looks at the use of CASE tools, discussesquality improvement, and presents project-planning techniques used to improveoutcomes of the development process.

14.1 THE CONCEPT OF A SYSTEMS DEVELOPMENT LIFE CYCLE

In the early years of data processing, many software developers did not use anykind of formal approach. They would simply ask users a few questions aboutwhat the system was supposed to do and then start programming. Sometimesthis approach resulted in desirable outcomes, but often it failed. The failureswere frequent enough to indicate that a more formal approach was necessary.Systems development refers to the set of activities that create systems forthe effective and efficient processing of information. One approach to systemsdevelopment is the systems development life cycle (SDLC). It provides acomprehensive framework for formal design and development activities.

To understand the idea of a systems development life cycle, consider thisanalogy. A business firm moves from one city to another. The moving projectrequires a very detailed plan. Someone has to acquire property in the new city.Someone has to arrange for telephone and utility services at the new location.People need to pack, ship, unpack, and install furniture and equipment at thenew location. The list goes on and on. The plan should identify every signifi-cant task and assign it to an individual or groups within or outside the organ-ization. Every task needs a start date and a completion date, and some tasks can-not start until after the completion of others. Also, the plan needs to coordinatethe start and completion dates of the individual tasks within the limitation ofthe target completion date for the whole project.

Looking at the plans for several such moving projects, we could find manysimilar tasks. With a little more effort, we could group the tasks into logicallyrelated categories and then arrange the categories in a sequence correspondingto the different phases of a moving project over time. These general categorieswould apply to most moving projects, even though the individual tasks couldvary from project to project.

Substitute the words “information systems development” for the word“moving” in the above paragraphs and you get an idea of what a systemsdevelopment life cycle is like. An SDLC shows the major steps, over time, of an

0006D_c14_632-678.qxd 10/15/03 17:17 Page 634

14.1 THE CONCEPT OF A SYSTEMS DEVELOPMENT LIFE CYCLE 635

information systems development project. Within these general categories areindividual tasks. Some of these tasks are present in most projects, while otherswould apply only to certain types of projects. For example, smaller projects maynot require as many tasks as larger ones.

Note that there is no universal, standardized version of the SDLC. Consult-ing firms, as well as IS groups within organizations, develop individualized ver-sions appropriate to their own operations. They give their versions uniquenames. For example, Accenture calls its version Method/1. The Microsoft certi-fication programs include training in its Solution Development Discipline (SDD)methodology. This chapter’s version of an SDLC is relevant to most other SDLCs.

Figure 14.1 provides a graphic model of an SDLC that has eight stages, or groupsof major tasks. Note also that the stages overlap: One stage may start before theprevious stage ends. This is in contrast to the traditional waterfall method, inwhich the work flows through all the tasks in one stage before going on to thenext stage. Also note that this process can go backward more than one stage,if necessary. These overlapping stages provide flexibility for adapting quickly tothe volatile demands of the current business environment. The method alsoallows for the implementation of ideas or correction of defects that are discov-ered in later stages. The following discussion outlines the individual stages andtheir major tasks.

STAGE 1: PROJECT INITIATION. Projects often start when a manager has a prob-lem or sees an opportunity related to the area where he or she works. Themanager calls IS and requests that a formal planning process be initiated to

An Eight-StageSDLC

(1) Project Initiation

(2) System Analysis andFeasibility Studies

(3) Logical Analysis& Design

(4) Acquisition orDevelopment

(5) Implementation

(6) Operation

(7) Post-Audit

(8) Maintenance

Go Back to a Previous Stage or StopFIGURE 14.1 An eight-stage SDLC.

0006D_c14_632-678.qxd 10/15/03 17:17 Page 635


discover ways that can help the organization meet its objectives. Sometimes theIS group initiates projects that will improve its own operations or deal with com-mon problems among the user areas.

STAGE 2: SYSTEMS ANALYSIS AND FEASIBILITY STUDIES. Stage 2 consists oftwo phases of analysis: systems analysis and feasibility studies.

Systems Analysis. After a project is initiated, the systems analysis phasebegins. Systems analysis is the phase that develops a thorough understandingof the existing organization, its operation, and the situation that is causing aproblem. Systems analysis methods include observation, review of documents,interviews, and performance measurement. Several methods exist for the exe-cution of systems analysis, and some of them are supported by software. Systemsanalysis also examines the proposed system and its anticipated contribution tothe solution of the problem.

Feasibility Studies. Feasibility studies calculate the probability of successof the proposed solution; they may be run several times throughout the sys-tems development life cycle. They determine whether the solution is achiev-able, given the organization’s resources and constraints. The feasibility studyoften includes an impact analysis that examines the effect of the system on otherprocesses and its impact on the surrounding environment. The major areas ofstudy are:

● Technology. Are the performance requirements achievable utilizing currentinformation technologies?

● Economics. Are the expected benefits greater than the costs?

● Organizational factors. Are the skill levels needed to use the new systemconsistent with the employees who will operate it?

● Legal, ethical, and other constraints. Does the system meet all regulatory re-quirements?

If the proposed project is feasible (and the sponsors are still interested), plan-ning can go on to the next stage.

STAGE 3: LOGICAL ANALYSIS AND DESIGN. The emphasis at the third stage ison logical design, the design of system from the (business) user’s point of view.The analyst identifies information requirements and specifies processes and genericIS functions such as input, output, and storage, rather than writing programsor identifying hardware. The analysts often use modeling tools such as dataflow diagrams (DFDs, see Figure 14.2) and entity-relationship diagrams (ERDs, seeFigure 14.3) to represent logical processes and data relationships.

Logical design is followed by a physical design, which translates the abstractlogical model into the specific technical design (the “blueprints”) for the newsystem.

The trend toward purchasing software, instead of developing it, is changingboth the general emphasis and the specific tasks in the logical analysis and designphase. Analysts still need to identify user requirements. However, they nowspend more time comparing requirements to features of available software, andless time on designing systems. They need to prepare detailed specifications onlywhen the functionality that users need is not available in software in the mar-ketplace. They also have to identify configuration requirements for commercial

0006D_c14_632-678.qxd 10/15/03 17:17 Page 636


packages that offer a wide range of customization options. IT At Work 14.1 showshow an information system fails due to poor choice of software.

STAGE 4: DEVELOPMENT OR ACTUAL ACQUISITION. The logical design of thenew system guides the actual development or acquisition, just as blueprintsguide the construction of a new building. IS personnel use the specificationsto purchase the hardware and software required for the system and then toconfigure it as needed. Programmers write code for parts of the system whencommercial sources are not available or appropriate. Technical writers developdocumentation and training materials. IS personnel test the system, and usersdo some testing prior to the actual implementation. The testing identifies bugsand also compares system performance to the specifications in the design.

STAGE 5: IMPLEMENTATION. Implementation is obviously an important stage;the system can fail here even if it has all the specified functionality. The pro-ject team should plan the implementation very carefully, to avoid problems thatcould lead to failure or user resistance. The users need training in the mechan-ics of the system to reduce frustration and to minimize productivity losses inthe transition period. In addition to developing technical skills, the trainingshould also attempt to motivate users, for example, by stressing the benefits thesystem brings to the organization.

Calculateclass

grades

Calculateuniversity

grades

Class/grades file

Students

Final grades

Test scoresCurrentgrade

Finalgrades

Current score

Final score

Final grades

Registrar’soffice

Teacher

Student file

Entity that suppliesor receives data

Process Data stores (files)

Data flows

FIGURE 14.2 Data flowdiagram for studentgrades example.

Student 1 0

Course

Tests

Semester Grade

FIGURE 14.3 Entity-relationship diagram ofstudents, courses, andgrades.

0006D_c14_632-678.qxd 10/15/03 17:17 37

POM


Although MBE executives insist that the technologyworks fine, an internal MBE memo obtained by DarwinMagazine seems to suggest that the company is indeedrethinking its technology strategy, which would mean“deep-sixing” (discarding) a lot of time and money. Alltold, MBE spent in the neighborhood of $25 million on itstechnology program, including equity investments in ahost of dotcoms such as iShip, in which MBE invested $4million. That’s a significant chunk of change for a com-pany with only $81 million in revenues (sales for theglobal MBE network were approximately $1.4 billion infiscal 2000). The system is only part of the problem withAmos’ e-business strategy. Its high-profile agreement to bethe exclusive shipper for online auction giant eBay hasstalled, and iShip is faltering financially. As Darwin went topress in May 2001, MBE announced that it had been ac-quired by shipping giant United Parcel Service of America(UPS).

The MBE story is shaping up as one giant case study forhow not to do a strategic technology initiative. While theUPS deal will likely add an infusion of capital to help mendMBE’s technology woes, it’s still worth asking why such awell-intentioned idea failed so signally. After all, the planto connect the franchises and Internet-enable their opera-tions was not fundamentally flawed. The answer seems tolie in a tangle of poor technology decisions, bad markettiming, and a disconnect between the services MBE offersand what many of the e-tailers want.

Sources: Condensed from Paul (2001) and from mbe.com (2003).

For Further Exploration: What are the problems withMBE’s “jump into new technology”? Discuss the possibleimpacts of poor technology decision on MBE.

Mail Boxes Etc. (MBE) spent $25 million to positionitself as the real-world shipping partner to the vir-

tual e-tail space. It was indisputably a great idea. Only oneproblem: the technology doesn’t appear to work. Manyfranchisees revolted against the system, calling it “a pipedream.” Headquarters insists everything is just fine. Butkey customers are disenchanted. What follows is a caution-ary saga of frustration, stubbornness, poor communication,arrogance, raw power and wasted opportunity.

The iShip system is part of a massive technology over-haul MBE embarked on two years ago. The brainchild ofMBE President and CEO Jim H. Amos Jr., the project wasmeant to position San Diego-based MBE as the premiershipping partner for e-tailers. “Because of our bricks-and-mortar on the ground, I thought we might have an oppor-tunity that no one else had,” said Amos.

By building a satellite network to connect the 3,500 do-mestic franchises with corporate systems, an Internet-enabled point-of-sale (POS) system and the iShip manifestsystem, shipping at MBE would become enticingly simple.The idea was that a returning customer would need to giveonly his phone number to the MBE clerk for service. Upwould pop his entire order history and recipient addressinformation. Customers would no longer need to carrytheir address books into the store. They would feelinstantly at home, as if they were part of a special group. Atleast, that was the plan.

“It’s a great idea, all right. It just doesn’t work,” said Sousa.Besides using the DOS manifest as the default shipping sys-tem, Sousa ditched the satellite network in favor of a localdigital subscriber line (DSL) provider for Internet service. Herelies on paper forms in duplicate to do the bulk of his busi-ness. To Sousa, the new systems have been a big disappoint-ment. “None of it connects. This is all a pipe dream.”

IT At Work 14.1HOW DO TECHNOLOGY INITIATIVES FAIL?

In most cases, implementing a new system requires a conversion from a pre-vious system. Approaches to conversion include:

● Parallel conversion: The old and new systems operate concurrently for atest period, and then the old system is discontinued.

● Direct cutover: The old system is turned off, and the new system is turnedon.

● Pilot conversion: The new system is implemented in a subset of locations(for example, some of the branches in a large banking chain) and is extendedto remaining locations over time.

0006D_c14_632-678.qxd 10/15/03 17:17 Page 638


● Phased conversion: Large systems often are built from distinct modules. Ifthe modules were originally designed to be relatively independent, it may bepossible to replace the modules one at a time.

STAGE 6: OPERATION. After a successful conversion, the system will operatefor an indefinite period of time, until the system is no longer adequate or nec-essary, or cost effective.

STAGE 7: POST-AUDIT EVALUATION. An organization should perform apost-audit to evaluate all its larger systems projects after their completion.Post-audits introduce an additional element of discipline into the developmentprocess. If the implementation was successful, an audit should occur after thesystem’s operations have stabilized. If the project failed, the audit should be doneas soon as possible after the failure.

STAGE 8: MAINTENANCE. Every system needs two regular kinds of mainte-nance: fixing of bugs and regular system updating. Maintenance is expensive,accounting for up to 80 percent of organizational IS budgets. Therefore it isimportant that the design and development stages produce systems that are easyto maintain and are flexible enough to handle future expansion, upgrading andcapacity increases.

There are two major problems with systems development life cycle methodolo-gies. First, many systems projects fail, even though the project managementincorporates a formal SDLC approach. Second, the environment is very differ-ent from what it was 30 years ago. Information technology is much more pow-erful and includes features such as graphical user interfaces and client/serverarchitectures that are very different from earlier forms of programming.

Do these problems mean that project managers should abandon the SDLCconcept? Not really. All the stages in Figure 14.1 are still either absolutely nec-essary or highly desirable for larger projects. The benefits described above arestill important. The increasing complexity of systems development means thatsome form of structure is even more necessary now than 30 years ago. How-ever, the general organization of the SDLC needs to adjust to the realities of thecurrent environment. IS groups considering the implementation of a formalSDLC methodology and associated tools for managing projects should look forthe characteristics listed at Online File W14.1 at the book’s Web site. Yourdon(1989, 2002) proposes a modern structured project life cycle.

The SDLC (both traditional and modern) is a formal and disciplined approachto systems development. The time pressures for e-business development projectsin the twenty-first century have tempted many project teams to simply aban-don whatever degree of disciplined and formal process methodology they mayhave used in the 1980s and 1990s and simply proceed with an anarchicalapproach.

That “winging it” may have succeeded in first-generation e-business projects,but the risk of building a mission-critical system that’s unstable, buggy, non-scalable, and vulnerable to hacker attacks is forcing more and more companies tolook for a methodology that strikes a balance between rigor and speed (Yourdon,

Traditional versusModern SDLCs

A Light SDLCMethodology for

Web-based SystemDevelopment

0006D_c14_632-678.qxd 10/15/03 17:17 Page 639


2000, 2002). Such a so-called light methodology imposes discipline upon themost critical project activities, without wasting precious time on bureaucraticprocesses associated with old mainframe-era projects. It is less structured than thetraditional SDLC and serves more as a framework or reference guide for skilledpeople than as a foolproof recipe for success.

14.2 METHODS FOR COMPLEX OR QUICKLY NEEDED SYSTEMS

The traditional systems development life cycle approach works best on projectsin which users have a clear idea about what they want. The typical automationproject is a good example because, in this type of project, computer systemsreplace manual labor with only minimal changes in processes. Unfortunately,simple automation projects are becoming less common. Nowadays projectstend to require major changes in existing processes, through reengineering orthrough development of processes that are new to the organization. Further-more, the need to build inter-organizational and international systems using Webtechnologies such as extranets, and the need to build or modify systems quickly(see Minicases 1 and 2), created a major shift in the nature of informationsystems.

This shift in emphasis, along with the high failure rate in traditional sys-tems development, indicates a need for alternatives to conventional SDLCmethodologies. Prototyping, rapid application development, joint applicationdesign, object-oriented development, and component-based development arefive possible alternatives.

The prototyping approach to systems development is, in many ways, the veryopposite of an old-style SDLC. Instead of spending a lot of time producing verydetailed specifications, the developers find out only generally what the userswant. The developers do not develop the complete system all at once. Insteadthey quickly create a prototype, which either contains portions of the system ofmost interest to the users, or is a small-scale working model of the entire sys-tem. After reviewing the prototype with the users, the developers refine andextend it. This process continues through several iterations until either the usersapprove the design or it becomes apparent that the proposed system cannotmeet their needs. If the system is viable, the developers create a full-scaleversion that includes additional features.

In this approach, which is also known as evolutionary development, theemphasis is on producing something quickly for the users to review. To speedup the process, programmers may use a fourth-generation language (4GL) andother tools such as screen generators or spreadsheet software for parts of theprototype. Figure 14.4 shows a flowchart of the prototyping process, using arelational database for the initial versions of the system.

Prototyping is particularly useful for situations in which user interaction isespecially important. Examples of such situations would be decision support(DSS), e-commerce “sell-sides,” or executive information systems. Prototypingis also good for IS projects that substantially change business processes. For usersof these types of systems, prototyping allows opportunities to work with themodel, and to identify necessary changes and enhancements, before making a

Prototyping

0006D_c14_632-678.qxd 10/15/03 17:17 Page 640

14.2 METHODS FOR COMPLEX OR QUICKLY NEEDED SYSTEMS 641

major commitment to development. Users should also consider prototyping if itis necessary to start using the system as soon as possible, even before it iscomplete.

Prototyping does have some disadvantages. It largely replaces the formalanalysis and design stage of a conventional SDLC. As a result, the systemsanalysts may not need to produce much formal documentation for the pro-grammers during the project. If managers do not follow up on this, the docu-mentation may be inadequate years later when the system needs maintenance.Another problem is that users, after working with the final prototype, may notunderstand why additional work and associated changes are necessary to bringthe system up to organizational standards.

Joint application design (JAD) is a group-based method for collecting userrequirements and creating system designs. JAD is most often used within thesystems analysis and systems design stages of the SDLC.

In the traditional SDLC, systems analysts interview or directly observepotential users of the new information system individually to understand eachuser’s needs. The analysts will obtain many similar requests from users, but alsomany conflicting requests. The analysts must then consolidate all requests andgo back to the users to resolve the conflicts, a process that usually requires agreat deal of time.

Determine conceptual information model and detail requirements.

Develop initial relational database using data modeling and procedures.

Develop operational prototype, data structure, formal reports, and ad hoc reporting.

Revise prototype as needed by:• adding entities• changing data structures• adding data items• updating data dictionary• adding software tools• enhancing input and output capabilities

Demonstrate prototype to users and have them use it on real problems.

Continue with SDLC.

Isprototype

satisfactory?

No

Yes

FIGURE 14.4 Model ofprototyping process.

Joint ApplicationDesign

0006D_c14_632-678.qxd 10/15/03 17:17 Page 641


In contrast to the SDLC requirements analysis, JAD has a meeting in whichall users meet simultaneously with analysts. During the meeting, all users jointlydefine and agree upon systems requirements. This process saves a tremendousamount of time.

The JAD approach to systems development has several advantages. First,the group process involves more users in the development process while stillsaving time. This involvement leads to greater support for and acceptance ofthe new system and can produce a system of higher quality. This involvementalso may lead to easier implementation of the new system and lower trainingcosts.

The JAD approach also has disadvantages. First, it is very difficult to get allusers to the JAD meeting. For example, large organizations may have users lit-erally all over the world; to have all of them attend a JAD meeting would beprohibitively expensive. Second, the JAD approach has all the problems causedby any group process (e.g., one person can dominate the meeting, some par-ticipants may be shy and not contribute in a group setting, or some participantsmay sit back and let others do the work). To alleviate these problems, JAD ses-sions usually have a facilitator, who is skilled in systems analysis and design aswell in managing group meetings and processes.

JOINT APPLICATION DESIGN AND WEB SITE DESIGN. The emphasis now fore-business Web sites is to improve customer satisfaction and to make the usersexperience at the site simple, intuitive, and efficient. Companies that invest indesigning solutions that make Web site navigation easy for their users are morelikely to achieve customer retention—the key to the success or failure of anybusiness on the Web.

Critical design features are those requirements that a Web site must supportto allow a user to complete a task in an enjoyable and efficient way. For usersto accept and adopt the interface of a Web site, it is useful to have them involvedin its design. An electronic JAD session can be conducted offsite/online withtechnology support. This brings the key representatives of users (customers),managers, systems designers, and other stakeholders together for requirementsdetermination. The initial set of requirements can serve as the basis for thedevelopment of a larger survey to determine user (customer) preferences andpriorities. JAD is thus of particular interest to Web site designers (see Kendalland Kendall, 2002).

Rapid application development (RAD) methodologies and tools make itpossible to develop systems faster, especially systems where the user interfaceis an important component. RAD can also improve the process of rewritinglegacy applications. An example of how quickly experienced developers cancreate applications with RAD tools is provided in IT At Work 14.2.

What are the components or tools and capabilities of a RAD system? Typi-cal packages include the following.

● GUI development environment: the ability to create many aspects of an ap-plication by “drag-and-drop” operations. For example, the user can create areport by clicking on file names, and then clicking and dragging fields fromthese files to the appropriate locations in the report.

Rapid ApplicationDevelopment

0006D_c14_632-678.qxd 10/15/03 17:17 Page 642

MKT


● Reusable components: a library of common, standard “objects” such as but-tons and dialog boxes. The developer drags-and-drops these items into theapplication.

● Code generator. After the developer drags-and-drops the standard objectsinto the design, the package automatically writes computer programs to im-plement the reports, input screens, buttons, dialog boxes, and so forth.

● Programming language: such as BASIC (in Visual Basic), Object Pascal (inDelphi), or C��. This component includes an integrated development envi-ronment (IDE) for creating, testing, and debugging code. It may be possibleto use drag-and-drop operations to create up to 80 percent of the code for asystem.

As Figure 14.5 shows, the same phases followed in the traditional SDLCare also followed in RAD, but the phases in RAD are combined to produce amore streamlined development technique. The emphasis in RAD is generallyless on the sequence and structure of processes in the life cycle and more ondoing different tasks in parallel with each other and on using prototypingextensively.

In addition to the benefits of speed and portability, RAD is used to createapplications that are easier to maintain and to modify. However, RAD packagesalso have some disadvantages. Like prototyping, the iterative developmentprocess can continue indefinitely if there is no unambiguous criterion for end-ing it. RAD packages may have capabilities to document the system, but hav-ing these features does not guarantee that developers will produce appropriatedocumentation.

Riverton HOW), as well as performance monitoring tech-niques and heavy user involvement to ensure the qualityof the system throughout its life cycle. By September 1,1999, the application was available to more than a hun-dred Windows 98-based clients. Since then, the customer-service unit has averaged about 1,800 daily calls and morethan 20,000 transactions a day over the system.

By early 2000, the new customer-service system had al-ready realized an ROI of $500,000, boosts in user productiv-ity, significant strides in system performance, and increaseddata accuracy. The integration, power, and scalability of theBCBSRI solution are truly exemplary.

Sources: Condensed from Bucken (2000) and from paper publishedat adtmag.com (April 2000).

For Further Exploration: To what extent do you thinkthe adoption of the RAD methodology contributed to thesuccess of the BCBSRI project?

AY2K problem without a solution led to the develop-ment of an innovative customer-service application in

less than a year at Blue Cross & Blue Shield of Rhode Island(BCBSRI). The new system is based on an internally devel-oped architecture that the Application Development Trends’2000 Innovator Awards judges lauded as modular and flexi-ble enough to easily allow for system upgrades and theincorporation of new technology.

BCBSRI decided in mid-1998 to build a new customer-service system, a mission-critical application that monitorsand records communications with policyholders. The in-ternal work on the project began in January 1999 after thedevelopment plan and blueprint were validated by outsideconsultants.

The development team adhered to a phased-rollout ap-proach and rapid application development (RAD) method-ology. Developers used several productivity tools (includ-ing the Sybase EAServer, Sybase PowerBuilder, and

IT At Work 14.2BLUE CROSS & BLUE SHIELD DEVELOPS ANAWARD-WINNING APPLICATION USING RAD

0006D_c14_632-678.qxd 10/15/03 17:18 Page 643


RAPID APPLICATION DEVELOPMENT IN THE AGE OF THE INTERNET. RAD hasbeen a key component of client/server systems development. According to Your-don (2000), WWW applications are likely to accelerate the RAD process to thepoint where it becomes “FAD,” or frantic application development. The tech-nology-driven nature of the Internet is forcing developers to deliver applicationsthat use these new technologies, such as streaming video and audio, in shorterand shorter time spans. This is spurred further by the development effortsof vendors, including Netscape and Microsoft, who continually release newversions of their Web browser software. Pressure arising from the constantintroduction of new technology has introduced a FAD approach into organiza-tions that are developing Web-based solutions. It appears that the FAD approachwill become more prevalent as organizations become increasingly aware of thestrategic value of an Internet presence.

Object-oriented development (see Technology Guide 2) is based on a fun-damentally different view of computer systems than that found in traditionalSDLC approaches. Traditional approaches provide specific step-by-step instruc-tions in the form of computer programs, in which programmers must specifyevery procedural detail. They usually result in a system that performs the orig-inal task but may not be suited for handling other tasks, even when the othertasks involve the same real-world entities.

An object-oriented (OO) system begins not with the task to be performed,but with the aspects of the real world that must be modeled to perform thattask. Therefore, if a firm has a good model of its customers and its interactionswith them, this model can be used equally well for billings, mailings, and salesleads. Object technology enables the development of purchasable, sharable, andreusable information assets (objects) existing in a worldwide network of inter-operable inter-organizational information systems.

BENEFITS AND LIMITATIONS OF THE OBJECT-ORIENTED APPROACH. The OOapproach to software development can lead to many benefits. First, it reduces

Object-OrientedDevelopment

Planning Analysis Design

DevelopmentRequirements

IterativeDevelopment

JAD

Design

Develop

TestUser Review

Build

Traditional Development

RAD

Compress

Test Deploy

FIGURE 14.5 A rapidapplication developmentSDLC. (Source:datawarehouse-training.com/Methodologies/rapid-application-development.)

0006D_c14_632-678.qxd 10/15/03 17:18 Page 644


the complexity of systems development and leads to systems that are easier andquicker to build and maintain, because each object is relatively small, self-contained, and manageable. Second, the OO approach improves programmers’productivity and quality. Once an object has been defined, implemented, andtested, it can be reused in other systems. Third, systems developed with the OOapproach are more flexible. These systems can be modified and enhanced eas-ily, by changing some types of objects or by adding new types. A fourth bene-fit is that the OO approach allows the systems analyst to think at the level ofthe real-world system (as users do) and not at the level of the programminglanguage.

On the other hand, there are some disadvantages to the OO approach. OOsystems (especially those written in Java) generally run more slowly than thosedeveloped in other programming languages. By all appearances, object-orientedsystems development (OOSD) is in the throes of a dilemma. Dozens of well-known experts claim the advantages of OOSD make it vastly superior toconventional systems development. But some of them also point to OOSD’s dis-advantages and question whether it will ever be a dominant approach to sys-tems development. Online Files W14.2 and W14.3 show some of the advantagesand disadvantages of OOSD. For a more detailed discussion of the ups anddowns of the object-oriented approach, see Johnson (2000).

UNIFIED MODELING LANGUAGE. The techniques and notations that are incor-porated into a standard object-oriented language are called unified modeling lan-guage (UML). The UML allows a developer to specify, visualize, and constructthe artifacts of software systems, as well as business models. Figure 14.6 providesan example of two UML artifacts, class and object diagrams.

Figure 14.6a shows two object classes: Student and Course, along with theirattributes and operations. Objects belonging to the same class may also partici-pate in similar relationships with other objects. For example, all students register

Student

namedate of birthyearaddressphone

calc-age ()calc-gpa ()register-for (course)

(a)

MaryJones: Student

name=Mary Jonedate of birth=4/15/1980year=junior

(b)

Course

crse-codecrse-titlecredit-hrs

enrolment ()

: Course

crse-code=MIS385crse-title=Database Mgmtcredit-hrs=3

List of Attributes

List of Operations

Class Name

FIGURE 14.6 UML classand object diagrams.(Source: Valacich, et al.,Essentials of SystemsAnalysis and Design,Prentice-Hall, 2001, p. 375.Essentials of SystemsAnalysis and Design byValacich/Hoffer. Reprinted bypermission of PearsonEducation, Inc. Upper SaddleRiver, NJ.)

0006D_c14_632-678.qxd 10/15/03 17:18 Page 645


for courses, and therefore the Student class can participate in a relationshipcalled “register-for” with another class called Course. Figure 14.6b shows twoobject instances (think examples), one for each of the classes that appears inFigure 14.6a. The object instance’s attributes and their values are shown in thesecond compartment. An operation such as “calc-gpa” in the Student class (seeFigure 14.6a) is a function or a service that is provided for all the instances ofa class. It is only through such operations that other objects can access ormanipulate the information stored in an object.

OBJECT TECHNOLOGY AND WEB-BASED SYSTEMS DEVELOPMENT. The object-oriented approach is ideal for developing Web applications. First, the data andcode of object-oriented systems are encapsulated into reusable components,each of which can be developed and enhanced independently. This increasesdevelopment speed and flexibility, as well as reducing system maintenance.Object technology allows companies to share business applications on theInternet.

A second reason why the object-oriented approach is ideal for developingWeb applications is that as the Web evolves from static data to active data, it ismoving toward object-based software systems. Objects become useful in thiscontext because, by definition, they join software code and data. Objects pro-vide a modular way of organizing, configuring, and reusing code instead of“reinventing the wheel” each time a new routine is written. When users clickon a Web page, for example, they are downloading objects into their clientmachines. This combination of data and code can be configured in new ways,manipulated, and operated actively.

Extreme programming (XP) is a discipline of software development based onvalues of simplicity, communication, feedback, and courage. It works by bring-ing the whole team together in the presence of simple practices, with enoughfeedback to enable the team to see where they are and to tune the practices totheir unique situation.

In extreme programming, every contributor to the project is an integralpart of the “whole team.” The team forms around a business representativecalled “the customer,” who sits with the team and works with them daily.Extreme programming teams use a simple form of planning and tracking todecide what should be done next and to predict when the project will bedone. Focused on business value, the team produces the software in a seriesof small, fully integrated releases that pass all the tests the customer hasdefined.

Extreme programmers work together in pairs and as a group, with simpledesign and obsessively tested code, improving the design continually to keep italways just right for the current needs. The extreme programming team keepsthe system integrated and running all the time. The programmers write all pro-duction code in pairs, and all work together all the time. They code in a con-sistent style so that everyone can understand and improve all the code asneeded. The extreme programming team shares a common and simple pictureof what the system looks like. Everyone works at a pace that can be sustainedindefinitely. Figure 14.7 shows the practices and the main “cycles” of extremeprogramming.

ExtremeProgramming

0006D_c14_632-678.qxd 10/15/03 17:18 Page 646

14.3 COMPONENT-BASED DEVELOPMENT AND WEB SERVICES 647

The efficient development of software reuse, as discussed in Section 14.2, hasbecome a critical aspect in the overall IS strategies of many organizations. Anincreasing number of companies have reported reuse successes. While the tra-ditional reuse paradigm allows changes to the code that is to be reused (white-box reuse), component-based software development advocates that componentsare reused as is (black-box reuse). Currently emerging Web services are also aim-ing at improving application development by leveraging existing software; how-ever, they go an entirely different route. Instead of requiring the Web serviceuser to own the component, Web services reside on the provider’s host.Program-to-program communication between the existing application and theweb service is enabled through a set of standardized interfaces, thus taking theblack-box reuse concepts one step further. The importance of these trends isreflected by the growing interest of the IS community in the component-basesoftware development and web services research areas.

Object technology, as discussed in Section 14.2, however, does have its down-side, including a steep learning curve. Business objects, though they representthings in the real world, become unwieldy when they are combined and

Cus

tom

er

Tes

ts

Releases

Small

Planning

Gam

eWhole

Team

Collec

tive

Owne

rship

Intergration

Continuous Pac

e

Metaphor

Sustain

able

CodingStandard

Pai

rP

rogr

amm

ing

DesignSample

Refactoring

Test-Driven

Development

FIGURE 14.7 Extremeprogramming practices.

14.3 COMPONENT-BASED DEVELOPMENT AND WEB SERVICES

Component-BasedDevelopment

0006D_c14_632-678.qxd 10/15/03 17:18 Page 647


recombined in large-scale commercial applications. What is needed are suites ofbusiness objects that provide major chunks of application functionality (e.g., pre-programmed workflow, transaction processing, and user event notification) thatcan be snapped together to create complete business applications.

This approach is embodied in the next step in the evolution beyond objects,component-based development. Components are self-contained packages offunctionality that have clearly defined, open interfaces that offer high-level appli-cation services. Components can be distributed dynamically for reuse across mul-tiple applications and heterogeneous computing platforms. Components take thebest features of objects to a higher level of abstraction, thus enabling mainstreamcommercial software developers to learn and use the technology more easily.

User interface icons (small), word processing (a complete software product),a GUI, online ordering (a business component), and inventory reordering (abusiness component) are a few examples of components. Search engines, fire-walls, Web servers, browsers, page displays, and telecommunication protocolsare examples of intranet-based components.

Code reusability, which makes programming faster and more accurate, is thefirst of several reasons for using components-based development. Others include:support for heterogeneous computing infrastructure and platforms; rapid assem-bly of new business applications; and the ability of an application to scale.

Components used in distributed computing need to possess several key char-acteristics to work correctly, and they can be viewed as an extension of theobject-oriented paradigm. The two main traits borrowed from the world ofobject-oriented technology are encapsulation and data hiding.

Components encapsulate the routines or programs that perform discretefunctions. In a component-based program, one can define components with var-ious published interfaces. One of these interfaces might be, for example, a date-comparison function. If this function is passed to two date objects to compare,it returns the results. All manipulations of dates are required to use the inter-faces defined by the date object, so the complete function is encapsulated in thisobject, which has a distinct interface to other systems. Now, if the function hasto be changed, only the program code that defines the object must be changed,and the behavior of the date comparison routine is updated immediately, afeature known as encapsulation.

Data hiding addresses a different problem. It places data needed by a compo-nent object’s functions within the component, where it can be accessed only byspecially designated functions in the component itself. Data hiding is a critical traitof distributed components. The fact that only designated functions can access cer-tain data items, and outside “requestors” have to query the component, simplifiesmaintenance of component-oriented programs.

A component-based application architecture provides the business benefits ofrapid applications development for quick time to market, enterprise-wide consis-tency of business rules, and quick response to changing business requirements.And because major software vendors are committed to a component architecture,applications can mix and match best-of-breed solutions. Components hide thecomplexity of the underlying systems technology. Plug-and-play business applica-tion components can be assembled or “glued together” rapidly to develop complexdistributed applications needed for e-commerce. The execution of component-based development, however, requires special training and skill. For a methodologyof evaluating component-based systems see Dahanayake et al. (2003).

0006D_c14_632-678.qxd 10/15/03 17:18 Page 648


COMPONENT-BASED DEVELOPMENT OF E-COMMERCE APPLICATIONS. Comp-onent-based EC development is gaining momentum. It is supported by Microsoftand the Object Management Group (OMG), which have put in place many ofthe standards needed to make component-based development a reality. A logi-cal architecture for component-based development of e-commerce applicationscan be described in layers as shown in Figure 14.8.

Component-based development for e-commerce applications is a process ofassembly and refinement. The process begins with cross-application componentsthat provide functionality common to most types of e-commerce applications.Typical of such core components are user-profile management, authentication,authorization, data management, and so on. These cross-application componentscan be customized and extended to form application-specific components. For exam-ple, in a procurement application, a profiling component will contain attributesfor identifying a user’s role and buying power.

When applied to an I-market (Internet market) application, the profilingcomponent will be extended to hold information that can be used to track cus-tomer buying patterns. In addition to the tailored cross-application components,application-specific components will include best-of-breed search engines, shop-ping carts, catalogs, or other elements required for the application. These maybe built in-house or purchased. Cross-application components also can beextended to develop industry-specific components. For example, in a manufacturingindustry a workflow component can be extended to handle work-in-progressand integrate workflows across enterprises to make “just-in-time” a reality.

The final step in the component-based development process is the configu-ration of the components to incorporate the organization’s unique business rulesand user presentation and navigation. It is in this step that a company’scompetitive advantage is built. Components come in many shapes and can bepurchased from special vendors. For ways to combine them into meaningfulapplications, see Arsanjani (2002).

There are several methods that developers can use for integrating compo-nents (e.g., see Linthicum, 2001). These methods can have limitations. Forexample, they can be vendor or platform dependent, expensive, complex tolearn, and inflexible. A potential solution is Web services.

e-Commerce Applications

VendorManagement

Extended Value/Supply Chain

i-Market Customer Care

ApplicationSpecific

Components

CrossApplication

Components

Common Business Objects

Distributed Object InfrastructureLegacy Applications & Assets

IndustrySpecific

Components

FIGURE 14.8E-commerce applicationsand component logicalarchitecture. (Source:Drawn by E. Turban.)

0006D_c14_632-678.qxd 10/15/03 17:18 Page 649


As described in Chapter 2, the major application of Web services is systems inte-gration. System integration is one of the major activities done in system devel-opment. From example, the whole concept of components is based on the ideaof gluing them together. Applications need to be integrated with databases andwith other applications. Users need to interface with the data warehouse to con-duct analysis, and almost any new system needs to be integrated with old ones.Finally, the increase of B2B and e-business activities requires the integration ofapplication and databases of business partners (external integration). Let usexamine the essential of Web services.

BASIC CONCEPTS. There are several definitions of Web services. Here is a typ-ical one: Web services are self-contained, self-describing business and consumermodular applications, delivered over the Internet, that users can select and com-bine through almost any device from personal computers to mobile phones. Byusing a set of shared protocols and standards, these applications permit disparatesystems to “talk” with one another—that is, to share data and services—withoutrequiring human beings to translate the conversations.

The following definition provides a preview of some of the functionalitiesof Web services: “Web service is a URL-addressable software resource that per-forms functions and provides answers. A Web Service is made by taking a setof software functionalities and wrapping it up so that the services it performsare visible and accessible to other software applications. Web services canrequest services from other Web services, and they can expect to receive theresults or responses from those requests. Web Services may interoperate in aloosely-coupled manner; they can request services across the Net and wait fora response. Web services may be combined to create new services. And they maybe recombined, swapped or substituted, or replaced at runtime” (Seybold, 2002).

Specifically, a Web service fits the following three criteria: (1) It is able toexpose and describe itself to other applications, allowing those applications tounderstand what the service does. (2) It can be located by other applicationsvia an online directory, if the service has been registered in a proper directory.(3) It can be invoked by the originating application by using standard protocols.

The Key Protocols: The Building Blocks of the Web Services Platforms. Webservices are based on a family of key protocols (standards). The major protocolsare:

● The XML Language. Extensible Markup Language (XML) is an openstandard, a universal language for defining data schemes. XML makes it eas-ier to exchange data amongst a variety of applications as well as to validateand interpret such data. An XML document describes a Web Service andincludes information detailing exactly how the Web Service can be run.

● SOAP. Simple Object Access Protocol (SOAP) is a set of rules that facilitate XMLexchange between network applications. SOAP defines a common standardthat allows different Web services to interoperate (i.e., it enables communi-cations, such as allowing Visual Basic clients to access JAVA server). It is aplatform-independent specification that defines how messages can be sentbetween two software systems through the use of XML. These messages typ-ically follow a Request/Response pattern (computer-to-computer).

● WSDL. The Web Services Description Language (WSDL) is a protocol is used tocreate the XML document that describes tasks performed by a Web services.It actually defines the programmatic interface of the Web services. Tools such

Web Servicesin System

Development

0006D_c14_632-678.qxd 10/15/03 17:18 Page 650


as VisualStudio.Net automate the process of accessing the WSDL, read it andcode the application to reference the specific Web Service.

● UDDI. Universal Description, Discovery and Integration (UDDL) is a protocol thatallows for the creation of public, or private searchable directories of Webservices. It is the registry of Web services descriptions.

● Security protocols. Several security standards are in development such asSecurity Assertion Markup Language (SAML), which is a standard for authenti-cation and authorization. Other security standards are XML signature, XMLencryption, XKMS, and XACML.

See Cerami (2002) for a list of other protocols that are under development.

THE NOTION OF SERVICES AS COMPONENTS. Traditionally, people view infor-mation system and IT, including the Web as dealing with information (or data)processing. Web services enable the Web to become a platform for applyingbusiness services. By services we mean components in IT applications that are welldefined and perform a useful task. For example, user authentication, currencyconversion, and shipping arrangement are building blocks of broad businessprocesses or applications, such as e-commerce ordering or e-procurementsystems. For discussion see Stal, 2002.

The idea of taking elementary services and gluing them together to createnew applications is not new. As a matter of fact, the approach of using com-ponents for system development has become very popular in recent years dueto savings that can be gained from usability (e.g., see Allen and Frost, 1998).The problem is that earlier approaches were cumbersome and expensive.According to Tabor (2002) existing technologies used for component integrationexhibit problems with data format, data transmission, interoperability, inflexi-bility (they are platform specific), and security. Web services offer a freshapproach to integration. Furthermore, business processes that are comprised ofWeb services are much easier to adapt to changing customer needs and busi-ness climates than are today’s home-grown or purchased applications (Seybold,2002). For further understanding of how this approach works, see the descrip-tion of Web services building process in Online File W14.4.

WHAT WEB SERVICES CAN DO. The major functionalities of Web services areas follows: (1) They provide for faster and cheaper integration. (2) Web Servicescommunicate with other programs automatically without human intervention.(3) They can be deployed for use over the Internet, or on an intranet inside acorporate firewall. (4) They can run in a protected environment set up by busi-ness partners. (5) They can be written using a wide variety of developmenttools. These development tools can perform a wide variety of tasks including:automating business processes, integrating disparate components of an enter-prise-wide system, delivering alerts to individuals about stock prices and theweather, and streamlining online buying and selling.

Key to the promise of Web services is that, in theory, they can be used byanyone, anywhere, any time, using any hardware and any software, as long asthe modular software components of the services are built using the set of stan-dards described earlier (see Fremantle et al., 2002 and Patton, 2002). Thegeneric types of Web services are described in Online File W14.5.

A Web Service Example. As a simple example of how Web services oper-ate, consider an airline Web site that provides consumers with the opportunity

0006D_c14_632-678.qxd 10/15/03 17:18 Page 651


to purchase tickets online. The airline recognizes that customers also might wantto rent a car and reserve a hotel as part of their travel plans. The consumerwould like the convenience of logging onto only one system rather than three,saving time and effort. Also, the same consumer would like to input personalinformation only once.

The airline does not have car rental or hotel reservation system in place.Instead, the airline relies on car rental and hotel partners to provide Web ser-vice access to their systems. The specific services the partners provide are definedby a series of WSDL documents. When a customer makes a reservation for acar or hotel on the airline’s Web site, SOAP messages are sent back and forthin the background between the airline’s and the partners’ servers. In setting uptheir systems, there is no need for the partners to worry about the hardware

TABLE 14.1 Web Services: Advantages and Limitations

Advantages Limitations

Web services are not a silver bullet. The standards underlyingWeb services are still being defined, so interoperability is not auto-matic. Even in those instances where the standards are relativelystable, it still requires programming skill and effort to implementand deploy Web services.

One area where the Web services standards are notwell-defined is security. The good news is that Web services enabledistributed applications to communicate with ease. The bad news isthat Web services also enable applications to bypass security barriers(such as firewalls) with ease. Standards such as XML, SOAP, WSDLand UDDI say nothing about privacy, authentication, integrity, ornon-repudiation. In an effort to bridge the gap between these stan-dards and existing security standards (such Public Key encryption),several vendors and organizations have proposed and are currentlydebating a number of Web service security standards. One of theseis WS-Security proposed by Microsoft, IBM, and Verisign.

While Web services rely on XML as the mechanism for encodingdata, higher-level standards are still required especially in B2Bapplications. For example, if two banks want to communicate, theystill need standards to define the specific content that is being com-municated. This is where standards such as OFX (Open FinancialExchange), which defines the content of transactions betweenfinancial institutions, come into play. The lack of coordinationamong all interested parties for high-level standards is why Webservices will first be adopted within organizations and later acrossorganizations.

Web services rely on universal, open,text-based standards the greatlysimplify the problems posed byinteroperability and lower the ITcosts of collaborating with externalpartners, vendors, or clients.

Web services enable software runningon different platforms to communicate,reducing the cost and headaches ofmultiple platforms running oneverything from mainframes toservers to desktops to PDAs.

Web services promote modularprogramming which enables reuse bymultiple organizations.

Web services are easy and inexpensive to implement because they operate onthe existing Internet infrastructure.They also offer a way to maintain andintegrate legacy IT systems at a lowercost than typical EnterpriseApplication Integration (EAI) efforts.

Web services can be implementedincrementally, rather than all at once.

Sources: Dietel et al. (2003); Shirky (2003).

0006D_c14_632-678.qxd 10/15/03 17:18 Page 652

14.4 SYSTEMS DEVELOPED OUTSIDE THE IS DEPARTMENT 653

or operating systems each is running. Web services overcome the barriersimposed by these differences. An additional advantage for the hotel and carreservation systems is that their Web services can be published in a UDDI sothat other businesses can take advantage of their services.

ADVANTAGES AND LIMITATIONS OF WEB SERVICES. Over the years, there havebeen a number of programming initiatives aimed at solving the problem of inter-operability (i.e., getting software and applications from different vendors run-ning on different hardware and operating systems to communicate with oneanother in a transparent fashion). Web services is the latest of these initiatives.Why is this initiative different from its predecessors? Table 14.1 cites advantages(Dietel et al., 2003; Shirky, 2003) and limitations of Web services.

14.4 SYSTEMS DEVELOPED OUTSIDE THE IS DEPARTMENT

The methodologies presented earlier are usually used by the information sys-tems department (ISD). Their execution requires highly skilled employees, andthe methodologies are fairly complex. The result is a backlog in applicationdevelopment, and a high failure rate. Therefore, many organizations are usingapproaches that shift the construction task from the ISD to others. Of the vari-ous ways of doing this, three are most common: Let users build their own sys-tems; outsource the entire systems development process; or let end users usepackages. These options and model are described next.

In the early days of computing, an organization housed its computer in aclimate-controlled room, with locked doors and restricted access. The onlypeople who interacted with the computer (most organizations had only onecomputer) were specialists: programmers, computer operators, and data entrypersonnel. Over the years, computers became cheaper, smaller, and more widelydispersed throughout the organization. Now almost everybody who works at adesk has a computer.

Along with this proliferation of hardware, many computer-related activitiesshifted out into the work area. Users now handle most of their own data entry.They create many of their own reports and print them locally, instead of waitingfor them to arrive in the interoffice mail after a computer operator has run themat a remote data center. They provide unofficial training and support to otherworkers in their area. Users also design and develop an increasing proportion oftheir own applications, sometimes even relatively large and complex systems.Online Files W14.6 and W14.7 on the Web site provides a detailed discussion of thereasons favoring end-user development and types of end-user computing.

END-USER COMPUTING AND WEB-BASED SYSTEMS DEVELOPMENT. Thedevelopment of client/server applications in the 1980s and 1990s was charac-terized by user-driven systems development. End users have been directly orindirectly making decisions for systems designers and developers on how theprograms should operate. Web-based systems development in the twenty-firstcentury, however, is application driven rather than user driven. The end usercan still determine what the requirements will be and has some input into thedesign of the applications. But because of the nature of the technologies used

End-UserDevelopment

0006D_c14_632-678.qxd 10/15/03 17:18 Page 653

POM


in Web-based application design, the function, not the user, determines whatthe application will look like and how it will perform. An innovative way ofmanaging end-user computing is shown in IT At Work 14.3.

Outsourcing, in its broadest sense, is the purchase of any product or servicefrom another company (see Chapter 13). In general, companies outsource theproducts and services they are unable or unwilling to produce themselves. ISdepartments have outsourced computer hardware, telecommunications services,and systems software (such as operating systems) for some time. They also pur-chase end-user software (e.g., Microsoft Office) because there is no reason toreinvent tools that a software company specializing in these products canprovide more cheaply.

Recently, information technology has hired outside organizations to performfunctions that in the past have been performed internally by IS departments.Common areas for outsourcing have included maintaining computer centers andtelecommunications networks. Some companies, however, outsource most of theIT functions, including systems and applications development, leaving only a verysmall internal information systems department. This department develops ISplans and negotiates with the vendors performing the outsourced functions.

Typically, the outsourcing firm hires the IS employees of the customer andbuys the computer hardware. The outsourcer provides IT services under a

better manage EUC supply and demand; and deliver amore consistent and better quality support service to endusers.

“The study highlighted the fact that Ansett had in effect‘outgrown’ the level of end-user service provided at thattime, and that a quantum leap in service was required toensure a full return on our end-user computing invest-ment,” Pringle said.

“Improving delivery of services to end users and en-hancing end-user productivity are becoming key focus ar-eas for many Australian corporations. I am very pleasedthat we have been chosen to deliver these additional ser-vices to Ansett,” said Mr. Bligh, General Manager of IBMGlobal Services Australia, Travel and Transportation Ser-vices.

Sources: Sachdeva (2000) and ansett.com.au (2003).

For Further Exploration: What strategic advantagescan Ansett Australia gain by ensuring consistent and reli-able supports to its end-user computing? Is it worth it for acompany to invest in end-user computing?

Ansett Australia, one of Australia’s leading airlines, an-nounced on January 4, 1999, that it had appointed

IBM Global Services Australia to manage its end-user com-puting support functions. Ansett (ansett.com.au), based inMelbourne, Australia, operates an extensive range of do-mestic airline services and also flies to Japan, Hong Kong,Taiwan, Bali, and Fiji.

Ansett Australia General Manager for IT Infrastructureand Operations, Hal Pringle, said, “IBM Global ServicesAustralia’s appointment would significantly improve desk-top services to the airline’s end users while at the sametime delivering substantial cost savings.” Such service waspreviously delivered by a mixture of external contractorsand in-house staff.

Mr. Pringle said the decision to hire an external providerof end-user computing (EUC) support arose from a bench-marking study conducted by Ansett earlier this year. Thestudy showed that a move to a single external provider ofthe caliber of IBM Global Services Australia would: achievea more consistent end-to-end delivery of applications; as-sist the implementation of best-practice EUC support at thebest cost; deliver substantial cost savings; allow Ansett to

IT At Work 14.3ANSETT AUSTRALIA AND IBM SIGNEND-USER COMPUTING DEAL

Outsourcing

0006D_c14_632-678.qxd 10/15/03 17:18 Page 654


contract that specifies a baseline level of services, with additional charges forhigher volumes or services not identified in the baseline contract. Many smallerfirms provide limited-scale outsourcing of individual services, but only thelargest outsourcing firms can take over large parts of the IT functions of majororganizations. The benefits and problems of outsourcing are listed in Online FileW14.8 at the Web site of this chapter.

TRENDS TO OUTSOURCE WEB-BASED SYSTEMS DEVELOPMENT. There is agrowing trend to outsource Web-based systems development. This includesplanning, Web site design and development, installation of the hardware andsoftware, and more. A principal reason for outsourcing all or part of a Web proj-ect is that few companies are fully equipped to do everything themselves, andmany demand proof that their online presence will pay off before hiring addi-tional staff. There are many skills needed to develop a Web site and get it up andrunning. You need people who know graphic design, marketing, networking,HTML, programming, copywriting, public relations, database design, accountmanagement, and sales. In addition, issues dealing with the back-end job ofrunning a real business require office managers, accountants, lawyers, and soforth. Outsourcing provides a one-stop shopping alternative to customers whodo not have the expertise or time to develop and maintain a commercial site.Consulting providers are broadening their skill sets and geographic reach to tryto fill their clients’ needs.

Outsourcing Web work means establishing a new, long-term relationshipwith a stranger. Careful questioning can minimize the risk of making a mistake.Look at the vendor’s home page and the home pages it has created for others.Then ask questions:

ABOUT CAPABILITIES

● What portion of the work did you do? What was outsourced to subcontrac-tors?

● What services can you provide?

● Who are your graphic designers, and what are their backgrounds?

● What can you do to publicize my Web site?

ABOUT TECHNICAL MATTERS

● What computer resources do you provide?

● Are your systems backed up?

● Do you have an alternate site in case of hardware failure?

● If you do the programming, how much of the code will be proprietary?

● What provisions do you make for security?

ABOUT PERFORMANCE

● What bandwidth do you provide? How much is dedicated to my home page?

● How much experience do you have managing high-traffic Web sites?

● How high is the volume at your most active site?

ABOUT THE BUSINESS RELATIONSHIP

● What statistical reports do you provide?

● What provisions do you make for handling complaints and problems?

0006D_c14_632-678.qxd 10/15/03 17:18 Page 655


Tapping into compute resources with a simplicity equal to plugging a lamp intoan outlet has been a goal of pervasive computing efforts from the start. Knownas utility computing, the idea is to provide unlimited computing power andstorage capacity that can be used and reallocated for any application—and billedon a pay-per-use basis.

Utility computing consists of a virtualized pool of “self-managing” ITresources that can be dynamically provisioned via policy-based tools that ensurethese resources are easily and continually reallocated in a way that addressesthe organization’s changing business and service needs. These resources can belocated anywhere and managed by anyone (an organization’s IT staff or a third-party service provider), and the usage of these resources can be tracked andbilled down to the level of an individual user or group.

As shown in Figure 14.9, the utility-computing value proposition consistsof three layers of tools and two types of value-added services. Each tool mustbe seamlessly integrated to create a comprehensive solution, but will usually beimplemented separately and tactically—often with little advance planning forthe ultimate solution. These tools are:

● Virtualization tools that allow server, storage and network resources to bedeployed and managed as giant pools, and seamlessly and dynamicallyreprovisioned as needs change;

● Policy-based resource-management tools that automate and standardize alltypes of IT management best practices, from initial configuration to ongoingfault management and asset tracking; and

● Policy-based service-level-management tools that coordinate, monitor andreport on the ways in which multiple infrastructure components cometogether to deliver a business service.

Utility computing still faces daunting obstacles. These include the immatu-rity of the tools; the difficult economy; and the fact that each of the vendorsprefers to tout its own unique variation on the vision with different, often con-fusing, names and terminology—not to mention cloudy value propositions.However, utility computing will, as discussed in the opening case, inevitablyprompt considerable consolidation, as industry giants seek to acquire myriadtechnologies that they cannot develop themselves. It will also accelerate accept-ance of the long-simmering service-provider value proposition, as all providersoffer choices of utility-computing implementation models, and migration pathsamong them.

Utility Computing

Policy-Based Servce-Level-Management tools

Policy-Based Resource-Management tools

Mu

ltis

ou

rcin

g D

eliv

ery

and

Fin

anci

ng

Ser

vice

s Cu

stom

er Access an

dM

anag

emen

t ServicesVisualized Infrastructures

Business and eventually,ROH based management

Fault, performance,operations management, etc.

Visualized server, storage andnetworks, and dynamic provisioning

FIGURE 14.9 The fiveelements of a successfulutility-computing valueproposition.

0006D_c14_632-678.qxd 10/15/03 17:18 Page 656


The choice between developing proprietary software in-house and purchasingexisting software is called the make-or-buy decision. Developing (building) pro-prietary application software gives the organization exactly what it needs andwants, as well as a high level of control in the development process. In addi-tion, the organization has more flexibility in modifying the software during thedevelopment process to meet new requirements. On the other hand, develop-ing proprietary software requires a large amount of resources (time, money, per-sonnel) that the in-house staff may have trouble providing. The large quantityof resources needed for this software increases the risk of the decision to “make”the software in-house.

The initial cost of off-the-shelf software is often lower because a softwaredevelopment firm can spread the cost over a number of customers. There islower risk that the software will fail to meet the firm’s business needs, becausethe software can be examined prior to purchase. The software should be of highquality, because many customers have used and helped debug it. However, buy-ing off-the-shelf software may mean that an organization has to pay for fea-tures and functions that are not needed. Also, the software may lack necessaryfeatures, causing the buyer to have to make expensive modifications tocustomize the package. Finally, the buyer’s particular IT infrastructure may dif-fer from what the software was designed for, and require some additionalmodification to run properly.

SELECTING VENDORS AND COMMERCIAL SOFTWARE PACKAGES. Externallyacquired systems should be evaluated to ensure that they provide the organi-zation with the following advantages. If they do not provide most of theseadvantages, then the organizations may be better off developing proprietary sys-tems. The most prominent considerations are:

● On-time. Completion and implementation of the system on or before thescheduled target date.

● On-budget. The system cost is equal to or less than the budget.

● Full functionality. The system has all the features in the original specifica-tions.

These outcomes are very desirable, especially because fewer than half of allsystems projects achieve all three. However, it is possible to succeed on each ofthese criteria but still have a system that does not increase the effectivenessof the organization. Other important considerations for selecting vendors andcommercial software packages are listed in the Online File W14.9 at the book’sWeb site.

Criteria that may be used to select an application package to purchaseinclude those listed in Table 14.2. Several independent organizations and mag-azines conduct software package comparisons from time to time. For smallerpackages, you can use “trialware” from the Internet before purchase is made.Most vendors will give you the software for a limited testing time. Also, theywill come and demonstrate the software. (Be sure to let them use your data inthe demo.)

ENTERPRISE SOFTWARE. A recent trend in the software business is enterprisesoftware, integrated software that supports enterprise computing. These sys-tems include accounting and finance, human resources, sales and procurement,

External Acquisitionof Software

0006D_c14_632-678.qxd 10/15/03 17:18 Page 657


inventory management, production planning and control, and so on. One ofthe major attractions of enterprise packages is that they incorporate manyof the “best practices” in the various functional areas. Organizations thus havethe opportunity to upgrade their processes at the same time they install the newsoftware. Major suppliers in this category include SAP/AG, Oracle, Baan, andPeopleSoft. Since these companies sell their products to a large number of cus-tomers, they can hire more specialized personnel and spend more on develop-ment than an individual organization would spend to develop its own systems.

The implementation and integration of enterprise software represents thesingle largest information system project ever undertaken by an organization. Itcan cost tens of millions of dollars and require an army of managers, users, ana-lysts, technical specialists, programmers, and consultants. Most enterprise soft-ware vendors provide their methodology and consulting partners to help theircustomers implement such a massive software solution. For discussion on enter-prise resource planning (ERP) systems development, see Ahituv et al. (2002).

E-COMMERCE SOFTWARE. E-commerce software is a powerful yet affordablee-commerce solution that is geared toward Web entrepreneurs of varying skilllevels and can greatly reduce the development time needed to launch an effec-tive site. It can provide a comprehensive fix for the rapid construction anddeployment of database-driven applications. Its back-end integration capabili-ties, combined with wizards and templates, make it both powerful and easy tointegrate. E-commerce software also facilitates sales by sending orders to thewarehouse, adjusting inventory tracking, and even e-mailing stock replenish-ment alerts to the merchant. Real-time credit card verification and processingis also a great advantage and can also be optimized for use with CyberCash fromVerisign.com. The software will also provide comprehensive detailed statistics onsales, users, product categories, and browser types.

With all these options and capabilities provided with just one software pack-age, many companies opt to go with e-commerce software instead of develop-ing their own system. Most e-commerce software is fully customizable for yourparticular company and is easily integrated into your business processes. This

Table 14.2 Criteria for Selecting an Application Package

● Cost and financial terms● Upgrade policy and cost● Vendor’s reputation and availability for help● Vendor’s success stories (visit their Web site, contact clients)● System flexibility● Ease of Internet interface● Availability and quality of documentation● Necessary hardware and networking resources● Required training (check if provided by vendor)● Security● Learning (speed of) for developers and users● Graphical presentation● Data handling● Environment and hardware

0006D_c14_632-678.qxd 10/15/03 17:18 Page 658

POMMKT


trend of using commercially available software will rapidly increase as moremerchants go online. As illustrated in IT At Work 14.4, an organization can setup its online store on the Web instantly and at minimal cost.

Because organizations and their systems requirements vary along many dimen-sions, it is not possible to neatly match all types of systems projects with theacquisition approaches identified in this chapter. Therefore, in many cases itmight be advisable to use a combination of approaches.

In this section we provide general considerations related to the differentapproaches. These considerations should be reviewed in the context of the desir-able outcomes discussed earlier. If coupled with good judgment, these consid-erations may help managers make better decisions regarding new systems’acquisition.

TRADITIONAL SDLC METHODOLOGY. The SDLC approach often works well forlarge projects with well-defined requirements, where there is not a lot of pres-sure to finish the project quickly. Use of this approach requires appropriate andeffective management, possibly including an end user as the leader if the projectis not highly technical.

PROTOTYPING. Prototyping is especially useful in situations where the require-ments (and therefore the costs) are poorly defined or when speed is needed.However, it requires effective management to make sure that the iterations of

the store cost less than $1,000, maintenance less than$500. Now that we are serious, our new site will be about$50,000 and our marketing and maintenance (hard to sep-arate these on the Internet) will be in the six figures permonth. We have still to choose an e-commerce softwaresolution for this second phase.

INTERVIEWER: What are your top tips for anyone consid-ering opening his or her own Web store?

BROADBENT: Start with Icat or Yahoo to test the waters.Plan on growing, and go for it. This is the new frontier ofretailing, and it is going to grow a lot over the next decade.New fortunes are being made right now. Cost of entry isminimal, and the opportunity to support growth throughrevenue created is a dream.

Source: Condensed from Paul, 1999 and tshirtking.com, 2003.

For Further Exploration: What are the advantages anddisadvantages of buying instant e-commerce solutionsfrom software vendors?

Bill Broadbent has been involved in the T-shirt businessfor over twenty years. Less than six months after he

opened his online store, T-Shirt King (www.t-shirtking.com)had already achieved startling results. In this interview Billexplains why he decided to take his bricks-and-mortarstore online and how he went about it.

INTERVIEWER: What made you decide to take your busi-ness online?

BROADBENT: In discussing the advantages of cybersales werealized that we could show thousands of designs to anyonewith Internet access. Also the Internet gave us the world asa market and the ability to bring any design we wanted intoa huge online catalogue. Finally, the cost of overhead in abricks-and-mortar store is sinful. The advantages of sellingonline are truly unfair. Bricks-and-mortar retailers are notprepared for the inevitable growth of online sales.

INTERVIEWER: What server and shopping-cart softwareare you using and why?

BROADBENT: We began T-Shirt King as a Yahoo! Storewhile we were still in the experimental mind. Launching

IT At Work 14.4BILL BROADBENT, THE T-SHIRT KING

ManagementConsiderations

0006D_c14_632-678.qxd 10/15/03 17:18 Page 659


prototyping do not continue indefinitely. It is important to have tools such as4GLs and screen generators when using this approach. If the project is large, itis probably better to establish the information requirements through prototypingand then use a more formal SDLC to complete the system.

RAPID APPLICATION DEVELOPMENT (RAD). This is an obvious candidate whennew systems are needed very quickly. RAD tools can work well for developingclient/server systems or front-ends for mainframe systems. RAD may be lessappropriate than conventional programming languages for larger projects, or fordeveloping systems with a lot of calculations or real-time processing.

JOINT APPLICATION DESIGN (JAD). JAD is easy for senior management tounderstand. The methodology also provides the needed structure to the processof collecting user requirements. However, it is difficult and expensive to get allpeople to the same place at the same time. Another disadvantage of JAD is itspotential to have dysfunctional groups.

OBJECT-ORIENTED DEVELOPMENT. OO development is becoming increasinglypopular, but usage is limited by a shortage of personnel with OO skills. Java isan OO language that is especially suitable for developing network applications.However, OO languages in general, and Java in particular, tend to run slowly.Reusability of code is a potential advantage of OO development, but reuse willnot occur without appropriate cataloging, search engines, and experienced andmotivated employees.

END-USER DEVELOPMENT. Although most appropriate for small projects, end-user development is also a possibility for larger projects whose priorities are nothigh enough to lead to a timely response from the central IS unit. Managersshould beware of end-user development in situations where problems with thesystem can lead to significant risks for the organization, such as system failures,inaccurate results, disclosure of confidential data, inefficiency, incompatibilitywith other systems, and inability to maintain the system if the developer leaves.

PURCHASING OR OUTSOURCING. For large and complex systems with a sig-nificant risk of failure, organizations should always consider using an outsidevendor (e.g., see Lee et al., 2003). The exception to this rule is that in-housedevelopment may be necessary if the system is highly strategic or incorporatescritical proprietary information. If scalability is important to the organization, itmay be advisable to buy systems rather than make them, even for smallersystems. However, managers need to be aware of relatively high additionalimplementation costs when purchasing enterprise software packages.

EXTREME PROGRAMMING. The fundamental idea of extreme programming isto start simply. Build something real that works in its limited way. Then fit itinto a design structure that is built as a convenience for further code buildingrather than as an ultimate and exhaustive structure.

UTILITY COMPUTING. Although not a development methodology, utility com-puting promises a way to cut technology management expenses while consoli-dating resources. However, it is believed that technology has a lot of catching

0006D_c14_632-678.qxd 10/15/03 17:18 Page 660

14.5 BUILDING E-BUSINESS APPLICATIONS 661

up to do before utility computing will become a reality for a company withmany computing needs.

14.5 BUILDING E-BUSINESS APPLICATIONS

The diversity of e-business models and applications, which vary in size from asmall store to a global exchange, requires a variety of development method-ologies and approaches. Small storefronts can be developed with HTML, Java,or other programming languages. They can also be quickly implemented withcommercial packages or leased from application service providers (ASPs) for asmall monthly fee. Some packages are available for a free trial period rangingfrom 30 to 90 days. Larger applications can be outsourced or developed in-house. Building medium to large applications requires extensive integrationwith existing information systems such as corporate databases, intranets, enter-prise resource planning (ERP), and other application programs.

The development process of e-business applications consists of five majorsteps which are discussed in more detail at the Online File W14.10 of the Website of this chapter. The five steps of the development process can be fairly com-plex and therefore they must be managed properly. A project team is usuallycreated to manage the progress of the development and the vendors. Collabo-ration with business partners is critical. Some e-business failures are the resultsof delays and lack of cooperation by business partners. For instance, you caninstall a superb e-procurement system, but if your vendors will not use it, thesystem will collapse.

There are several options for developing e-business (e-biz) applications: buy,lease, or develop in-house.

BUY THE E-BIZ APPLICATIONS. Standard features required by e-business appli-cations can be found in commercial packages. Buying an existing package canbe cost-effective and timesaving in comparison to in-house application devel-opment. The buy option should be carefully considered and planned for, toensure that all critical features for current and future needs are included in theselected package. Otherwise such packages may quickly become obsolete.

In addition, business needs can rarely be fully satisfied by buying a singlepackage. It is sometimes necessary to acquire multiple packages to fulfill differ-ent needs. Integration may then be required amongst these packages as well aswith existing software. Major criteria for consideration in buying e-businessapplications are listed in Online File 14.11. The buy option may not be attractivein cases of high obsolescence rate or high software cost. In such a case, oneshould consider leasing.

LEASE THE E-BIZ APPLICATIONS. As compared to the buy option and to anin-house development, the lease option can result in substantial savings of bothcost and time. Though the packages for lease may not always exactly fit withthe application requirements (the same is true with the buy option), many com-mon features that are needed by most organizations are often included.

Leasing is advantageous over buying in those cases where extensive main-tenance is required, or where the cost of buying is very high. Leasing can be

DevelopmentStrategies for

E-BusinessApplications

0006D_c14_632-678.qxd 10/15/03 17:18 Page 661


especially attractive to SMEs (small to medium enterprises) that cannot affordmajor investments in eBiz. Large companies may also prefer to lease packagesin order to test potential e-commerce solutions before committing to heavy ITinvestments. Also, since there is a shortage of IT personnel with appropriateskills for developing novel e-commerce applications, several companies leaseinstead of develop. Even those companies that have in-house expertise maydecide they cannot afford to wait for strategic applications to be developed in-house. Hence they may buy or lease applications from external resources inorder to establish a quicker presence in the market.

Types of Leasing Vendors. Leasing can be done in two major ways. One isto lease the application from an outsourcer and install it on the company’spremises. The vendor can help with the installation, and frequently will offerto contract for the operation and maintenance of the system. Many conven-tional applications are leased this way. Vendors that lease e-Biz applications aresometimes referred to as commerce system providers (CSPs). However, in e-businessa second leasing option is becoming popular: leasing from an application serviceprovider, who provides both the software and hardware at its site.

DEVELOP E-BIZ APPLICATIONS IN-HOUSE: INSOURCING. The third option todevelop an e-business application is to build it in-house. Although this approachis usually more time-consuming and may be more costly than buying or leasing,it often leads to better satisfaction of the specific organizational requirements.Companies that have the resources to develop their e-business application in-house may follow this approach in order to differentiate themselves from thecompetition, which may be using standard applications that can be bought orleased. The in-house development of e-Biz applications, however, is a challengingtask, as most applications are novel, have users from outside of the organization,and involve multiple organizations.

Development Options. Three major options exist: Program from scratch, usecomponents, or use enterprise application integration.

● Build from scratch. This is a rarely used option that should be consideredonly for specialized applications for which components are not available. Itis expensive and slow. But it can provide the best fit.

● Build from components. Those companies with experienced IT staff can usestandard components (e.g., a secure Web server), some software languages(e.g., C��, Visual Basic, or Perl), and third-party APIs (application programinterfaces) and subroutines to create and maintain an electronic storefrontsolely on their own.

Alternatively, companies can outsource the entire development processusing components. From a software standpoint, this alternative offers thegreatest flexibility and is the least expensive. However, it can also result ina number of false starts and wasted experimentation. For this reason, eventhose companies with experienced staff are probably better off customizingone of the packaged solutions. (For details about using components, seeSection 14.3.)

● Enterprise application integration. The enterprise application integra-tion (EAI) option is similar to the previous one, but instead of components,one uses an entire application. This is an especially attractive option whenapplications from several business partners need to be integrated.

0006D_c14_632-678.qxd 10/15/03 17:18 Page 662

14.5 BUILDING E-BUSINESS APPLICATIONS 663

OTHER DEVELOPMENT STRATEGIES. Besides the three major options for devel-oping e-Biz applications (buy, lease, and develop in-house), several others arein use and are appropriate under certain circumstances. See Online File W14.12on the book’s Web site for a detailed discussion of these options.

In developing e-business systems, outsourcing is a most valuable option sincethese systems need to be built quickly and special expertise is needed. ECsoftware delivery from ASPs is another very popular option.

An application service provider (ASP) is an agent or vendor who assem-bles functionality needed by enterprises, and packages it with outsourced devel-opment, operation, maintenance, and other services. Although several variationsof ASPs exist, in general, monthly fees are paid by the client company. ASP feesfor services include the application software, hardware, service and support,maintenance, and upgrades. The fees can be fixed, or based on utilization.

The essential difference between an ASP and an outsourcer is that an ASPwill manage application servers in a centrally controlled location, rather thanon a customer’s site. Applications are accessed via the Internet or WANs througha standard Web browser interface. In such an arrangement, applications can bescaled, upgrades and maintenance can be centralized, physical security over theapplications and servers can be guaranteed, and the necessary critical mass ofhuman resources can be efficiently utilized.

ASPs are especially active in enterprise computing and e-commerce. Theseareas are often too complex to build and too cumbersome to modify and main-tain on one’s own (e.g., see Ward, 2000). Therefore, the major providers of ERPsoftware, such as SAP and Oracle, are offering ASP options. Microsoft, and Com-puter Associates, Ariba, and other major vendors of e-business also offer suchservices.

BENEFITS OF LEASING FROM ASPs. Leasing from ASPs is a particularlydesirable option for SMEs, for which in-house development and operation ofe-business applications can be time-consuming and expensive. Leasing fromASPs not only saves various expenses (such as labor costs) in the initial devel-opment stage, but also helps to reduce software maintenance and upgradingand user training costs in the long run. A company can always select anothersoftware package from the ASP to meet its changing needs and does not haveto further invest in upgrading the existing one. In this way, overall businesscompetitiveness can be strengthened through reducing the time-to-marketand enhancing the ability to adapt to changing market conditions. This is par-ticularly true of e-commerce applications for which timing and flexibility arecrucial. A detailed list of the benefits and potential risks of leasing from ASPsis provided in Online File W14.13 at the book’s Web site.

Leasing from ASPs is not without disadvantages. Many companies are par-ticularly concerned with the adequacy of protection offered by the ASP againsthackers, theft of confidential information, and virus attacks. Also, leasedsoftware may not provide a perfect fit for the desired application.

It is important to ensure that the speed of Internet connection is compati-ble with that of the application in order to avoid distortions to the performanceof the application. For example, it is not advisable to run heavy-duty applica-tions on a modem link below a T1 line or a high-speed DSL. Some criteria forselecting an ASP vendor are listed in Online File W14.14 at the book’s Web site.

Application ServiceProviders

0006D_c14_632-678.qxd 10/15/03 17:18 Page 663


IT At Work 14.5 shows a successful story of a using an ASP as a contractedpartner to develop an e-biz application. For a study about satisfaction with ASPservices see Susarla et al. (2003).

Internet and intranet Web pages are coded primarily in HTML (hypertextmarkup language), a simple language that is most useful for displaying staticcontent to viewers. HTML has very limited capabilities for interacting with view-ers, or for providing information that is continually being updated. It is not suit-able for collecting information, such as names and addresses, or for providinganimation or changing information such as stock quotes. To do these types ofthings it is necessary to add programs (written in some form of programminglanguage) to the HTML for a Web site.

Java (see Technology Guide 2) is relatively new, but it has already estab-lished itself as the most important programming language for putting extra fea-tures into Web pages. It has many similarities to C and C��, but omits some

on their own Web sites. “One of the first questions we pon-dered before we outsourced was whether we could laterbring that expertise in-house,” Lewis says. “We didn’t wantto do it any other way.” The desire to have expertise in-house was fostered by Snap-On’s desire for control of theirWeb site. “When e-commerce solutions become a mission-critical application, companies can become uncomfortableoutsourcing them. If the outsourcer’s site goes down, thecompany’s business goes down,” says Leah Knight, an an-alyst for the Gartner-Group. Snap-On found a way to bothbuy and build its e-commerce applications.

Snap-On.com is an example of what end users and ana-lysts say is the newest trend in constructing e-commercesites. With this approach, the site would already be in ahost environment, and components are already there, soyou can quickly add to the site. Most companies, feelingthe “Internet-speed” pressure to get their sites up fast, needthe experience and resources of outside vendors. At thesame time, however, these end users are taking charge ofthose sites as soon as possible. Local control enables themto make improvements faster and save money on expen-sive hourly fees each time they need to make a smallchange to the site.

Sources: Compiled from Mullich (2000) and snap-on.com (2003.)

For Further Exploration: As Web sites evolve, e-busi-nesses find that moving programming talent in-house isthe way to go. Do you agree?

Snap-On, a tool and equipment maker in Washingtonstate, wanted to set up an e-commerce site, and do so

quickly. The problem the company faced was whether tobuild the site in-house, or buy the services of an outsidecontractor to set up the site.

Brad Lewis, e-commerce manager for Snap-On, decidedto hire application service provider (ASP) OnLink Technolo-gies to implement a catalog for the company’s e-commercesite. Lewis wanted his industrial customers to navigate eas-ily through the 17,000 products listed in Snap-On’s papercatalog, and he wanted to integrate the site with Snap-On’sERP system. If we developed this application in-house, wewould have spent six to nine months just designing andimplementing it,” he said. By using an ASP, Snap-On wasable to get the entire catalog up and running in fourmonths.

What was unusual is that Lewis integrated his staff withOnLink’s to help transfer those catalog-building skills.Lewis himself spent several days a week during the four-month development period at OnLink’s headquarters,where he had his own office. He concentrated on develop-ing application features and integration with back-end sys-tems. “By spending so much time at OnLink, I became amember of their engineering group, and other members ofmy staff became temporary members of their professionalservices catalog group,” Lewis says.

The result was that Lewis created an in-house ASP con-sulting service for Snap-On, providing guidance to otherdepartments and subsidiaries that want to put up catalogs

IT At Work 14.5SNAP-ON’S APPROACH TO SETTING UPAN E-BUSINESS SITE

Java,a Promising Tool

0006D_c14_632-678.qxd 10/15/03 17:18 Page 664

14.6 SOME IMPORTANT SYSTEMS DEVELOPMENT ISSUES 665

of the more complex and error-prone features of the programming languages.Java was specifically designed to work over networks: Java programs can besent from a Web server over the Internet and then run on the computer thatis viewing the Web page. It has numerous security features to prevent thesedownloaded programs from damaging files or creating other problems on thereceiving computer.

Java is an object-oriented language, so the concepts of object-oriented devel-opment are relevant to its use. However, the Java Web-page programs, calledapplets, need to be relatively small to avoid delays in transmitting them over theInternet. Java programs run more slowly than programs in other languages,which is another reason to keep them small. Therefore it is not necessary thatJava developers use the very formal development methodologies appropriate forlarge system projects. Prototyping is probably the most suitable approach fordeveloping Java applets, because it provides for a high level of interaction betweenthe developers and users in regard to the critical issues of the appearance andease-of-use of the Web page.

Several managerial issues apply specifically to building e-business applications:

● It is the business issues that count. When one thinks of the Web, oneimmediately thinks of the technology. Some of the most successful sites onthe Web rely on basic technologies—freeware Web servers, simple Web-pagedesign, and few bells and whistles. What makes them successful is not thetechnology but their understanding of how to meet the needs of their onlinecustomers.

● Build in-house or outsource. Many large-scale enterprises are capable of run-ning their own publicly accessible Web sites for advertisement purposes.However, Web sites for online selling may involve complex integration, se-curity, and performance issues. For those companies venturing into suchWeb-based selling, a key issue is whether the site should be built in-house,thus providing more direct control, or outsourced to a more experiencedprovider. Outsourcing services, which allow companies to start small andevolve to full-featured functions, are available through many ISPs, telecom-munications companies, Internet malls, and software vendors who offermerchant server and e-biz applications.

● Consider an ASP. The use of ASPs is a must for SMEs and should be con-sidered by any company. However, due to the newness of the concept, caremust be used in selecting a vendor (see Chapter 13).

Managerial Issuesin E-Business

Applications

14.6 SOME IMPORTANT SYSTEMS DEVELOPMENT ISSUES

Building information systems, either by the ISD or by end users, involves manyissues not discussed in the preceding sections. Some additional issues that maybe of interest to managers and end users are discussed here.

For a long time, computer programmers resembled the cobbler in the old story.He was so busy mending his customers’ shoes that he didn’t have time to repairthe holes in his own children’s shoes. Similarly, programmers were so busydeveloping systems to increase the productivity of other functions, such asaccounting and marketing, that they didn’t have time to develop tools to

CASE Tools

0006D_c14_632-678.qxd 10/15/03 17:18 Page 665


enhance their own productivity. However, this situation has changed with theemergence of computer-aided software engineering (CASE) tools. Theseare marketed as individual items or in a set (toolkit) that automates variousaspects of the development process. For example, a systems analyst could usea CASE tool to create data-flow diagrams on a computer, rather than drawingthem manually (see Technology Guide 2).

MANAGERIAL ISSUES REGARDING CASE. Individual system personnel or ISgroups may use a variety of specific CASE tools to automate certain SDLC activ-ities on a piecemeal basis. Or the IS group may acquire an integrated (I-CASE)package, whose components are tightly integrated and which often embodies aspecific systems development methodology. (See Technology Guide 2.) These twoapproaches are quite different in terms of their implications for the organization.

Using tools independently can provide some significant productivity bene-fits. Because the tools are acquired on an individual basis, the organization hasmany options and can select the ones that offer the best performance for thecost and are best suited to the organization’s needs. The tools can be used inde-pendently as needed, so developers have the option of learning, at their ownpace, the tools that are most helpful to them.

On the other hand, the components in integrated packages are specificallydesigned to work together, and therefore they offer the potential for higher pro-ductivity gains. However, the learning pace for these packages is much slowerthan for individual tools. This means that after adoption, productivity maydecline in the short term, which may be unacceptable for an organization witha large backlog of high-priority IS projects. In addition to productivity issues,some components of an I-CASE package may not be as good as correspondingtools that can be purchased separately.

The relatively high turnover rate among systems personnel also createsproblems for use of I-CASE systems. New employees will need time to learn theintegrated package. Existing employees may resist using the package, becausethey feel it will reduce their opportunities to move to other organizations thatuse either traditional development methods, or some other I-CASE package thatis incompatible with the one at the present organization.

In addition to the costs of training and productivity losses, organizationsneed to purchase the actual I-CASE systems. In the past, this often requiredpurchasing workstations in addition to software. Now, with the availability ofmuch more powerful PCs and servers in client/server systems, many organiza-tions may not find it necessary to buy any additional hardware (except possi-bly a plotter for printing large diagrams). Even without additional hardwarecosts, buying an I-CASE system may still cost more than buying a few of themost helpful individual tools.

The success of quality management in manufacturing suggests that quality man-agement could also be helpful in dealing with the problems of IS development.To implement this concept for systems development, the Software EngineeringInstitute at Carnegie Mellon University developed the Capability Maturity Model(CMM). The original purpose of this model was to provide guidelines for the U.S.Department of Defense in selecting contractors for software development. TheCMM identifies five levels of maturity in the software development process, assummarized in Table 14.3.

Software QualityImprovement and

ISO-9000

0006D_c14_632-678.qxd 10/15/03 17:18 Page 666


TABLE 14.3 Levels of the Capability Maturity Model

Level Characteristics

1. Initial Processes are ad hoc, undefined, possibly chaotic. Success depends on individual efforts andheroics.

2. Repeatable Basic project management tracks cost, schedule, and functionality. On similar applications,organization is able to repeat earlier successes.

3. Defined Project management and software engineering activities are documented, standardized, andintegrated into development through an organization-specific process (i.e., an SDLC).

4. Managed Both software process activities and quality are measured in detail and are quantitativelyunderstood and controlled

5. Optimizing Processes are improved continuously based on feedback from quantitative measures, andfrom pilot projects with new ideas and technologies.

Source: Compiled from J. Herbsleb et al., “Software Quality and the Capability Maturity Model,” Communications of the ACM, June1997, p. 32. ©1997 Association for Computing Machinery, Inc. Reprinted by permission.

TABLE 14.4 Improvements from Capability Maturity ModelImplementations

Category Range Median # of Cases

Productivity gain 9–67% 35% 4Faster time to market 15–23% NA 2Reduction in defects 10–94% 39% 5

Source: Compiled from J. Herbsleb et al., “Software Quality and the Capability Maturity Model,”Communications of the ACM, June 1997, pp. 30–40. ©1997 Association for Computing Machinery,Inc. Reprinted by permission.

As an organization moves to higher maturity levels of the CMM, both theproductivity and the quality of its software development efforts will improve.Results of a case study, summarized in Table 14.4, verified substantial gains inboth areas through software process improvement (SPI) programs based on thecapability maturity model. Organizations need to understand, however, that soft-ware process improvement requires significant spending and organizational effort.

ISO 9000 STANDARDS. Another approach to software quality is to implement theISO 9000 software development standards. The International Organization forStandardization (ISO) first published its quality standards in 1987, revised themin 1994, and then republished an updated version in 2000. The new standardsare referred to as the “ISO 9001:2000 Standards.” These international standardsare very extensive: they identify a large number of actions that must be performedto obtain certification. In addition, they define software developer responsibilities,as well as the responsibilities of the purchaser or client, in developing qualitysoftware. The purchaser needs to clearly identify the requirements and have anestablished process for requesting changes in these requirements. However, thespecifications do offer a substantial amount of leeway in many areas. (For anexample of ISO 9000 Standards, see Online File W14.15 at the book’s Web site.)

0006D_c14_632-678.qxd 10/15/03 17:18 Page 667


An ISO 9001:2000 Quality Management System is made up of manyprocesses that are glued together by means of many input-output relationships.This turns a simple list of processes into an integrated system. Under ISO stan-dards, the supplier needs to have documented processes for developing software.The supplier’s senior management is responsible for developing the quality pol-icy document, a short statement that requires employees to use generallyaccepted quality practices in all areas of the organization. This quality policy isimplemented through a quality system, the development and quality-controlprocesses that implement the quality policy. The quality system requires prepa-ration of quality plans for types of products and processes. An internal auditingprocess is required to ensure compliance with the plans. ISO 9000 requiresappropriate funding for quality activities, and appointment of personnel andassignment of responsibilities necessary to implement the program.

Legacy systems are very large software systems that have been developed andare being maintained by many different people. They were developed usingtraditional methods, such as structured analysis and design, or even individualprogramming techniques and styles. Over time, maintenance may have changedthe original program structure and specifications. Often, the specificationsare not maintained, and the current design and program understanding cannotbe determined. Maintenance of these systems becomes so costly that theybecome candidates for reverse engineering.

Reverse engineering aims at discovering design and specifications of exist-ing software programs. The technology reads the program code for an existingdatabase, application program, and user interface, and automatically generatesan equivalent system model. The resulting model can then be edited andimproved by systems analysts and users to provide a blueprint for a new andimproved system. The goal of reverse engineering is to achieve a sufficientunderstanding of the whats, hows and whys of the legacy system as a wholeso that its code can be reengineered to meet new user requirements. Foradditional information see Martin (2003).

Project planning can mitigate the risk of failure and provide a structure for man-aging development risk. Chapter 9 provided a four-stage model for informationsystems planning for IT infrastructure projects. The final stage of this process,project planning, is also used in development of individual applications. Pro-ject planning provides an overall framework in which the systems developmentlife cycle can be planned, scheduled, and controlled. Milestones are one ofthe more effective project management tools used by mangers in the projectplanning process.

MILESTONES. Milestone planning techniques allow projects to evolve as theyare developed. Rather than try to predict all project requirements and problemsin advance, management allows the project to progress at its own pace. Mile-stones, or checkpoints, are established to allow periodic review of progress sothat management can determine whether a project merits further commitmentof resources, requires adjustments, or should be discontinued.

Milestones can be based on time, budget, or deliverables. For example, aproject’s progress might be evaluated weekly, monthly, or quarterly. It mightbe evaluated after a certain amount of resources are used, such as $50,000.

ReverseEngineering for

Legacy Systems

Project Planning

0006D_c14_632-678.qxd 10/15/03 17:18 Page 668


However, milestones are most effective when they identify that specific eventshave occurred, such as the completion of a feasibility study. Figure 14.10illustrates the simplicity of a milestone chart.

PROJECT PROPERTIES AND PRIORITIES. Setting budget and time frames priorto defining the system design constraints is perhaps the greatest mistake madein project planning. For example, management may decide to install a new orderentry system in nine months, for which it is willing to spend $1 million. Thisleaves one important issue undefined: What will the new system do? By settinga budgetary constraint, management has, de facto, limited the functionality ofthe new system.

The proper sequence for managing a project is first to get a good functionaldefinition of what the system is designed to do, and then to have people withexperience and expertise in information systems and in project managementdevelop a budget and schedule. If management cannot accept the schedule orbudget, then the capabilities of the new system can be scaled down to meet theschedule and/or budget constraints.

In developing a budget, schedule, and specifications for a system, managersneed to consider and understand several properties of projects and their man-agement. The following five properties most significantly influence the overallnature of an IT project.

1. Predefined structure. The more predefined the structure of a project is, themore easily it can be planned and controlled.

2. Stability of technology. The greater the experience with a given technologyto be used for a new system, the more predictable the development process.

3. Size. The larger the project, the more difficult it is to estimate the resources(time and costs) required to complete it.

4. User proficiency. The more knowledgeable and experienced users and man-agers are in their functional areas and in developing systems, the more pro-ficient they will be relative to information technology and the easier it willbe to develop systems for them.

5. Developer proficiency. The more knowledge and experience the systems an-alyst assigned to a project has, the easier the project will go, and vice versa.

Projects can possess variations of each of the preceding properties. Forexample, a project can have predefined structure but use unstable technology,or it can be a massive undertaking and have low user and developer proficien-cies (e.g., most initial online airline reservations systems could be described thisway).

WEB-BASED PROJECT MANAGEMENT. Web-based project managementprovides a central Web site, or project portal, where everyone involved in a

Requirementspecifications completed

Development pathformed

Feasibilitystudy acceptedFIGURE 14.10

Milestones.

0006D_c14_632-678.qxd 10/15/03 17:18 Page 669


project can get up-to-date project information, share documents, and participatein planning and problem-solving using such collaboration features as sharednotebooks, threaded discussion groups, and chat forums. By making it easy forteam members and managers to exchange information and ideas, Web-basedproject management promises to reduce mistakes caused by poor communica-tion. It also can minimize or eliminate delays due to the time it takes to movedocuments and people around for approvals and meetings. Examples of Web-based project management packages include: TeamCenter (from Invoie Soft-ware), TeamPlay (from Primavera Systems), and WebProject (from WebProject).

➥ MANAGERIAL ISSUES1. Importance. Some general and functional managers believe that system

development is a technical topic that should be of interest only to techni-cal people. This is certainly not the case. Appropriate construction of sys-tems is necessary for their success. Functional managers must participatein the development process and should understand all the phases. Theymust also participate in the make-or-buy decisions and software selectiondecisions. Inappropriate development methodologies can result in thesystem’s failure.

2. Building interorganizational and international information systems.Building systems that connect two or more organizations, or one organiza-tion that operates in different countries, can be very complicated. (SeeTractinsky and Jarvenpaa, 1995.) As seen in Chapter 9, you need to carefullyplan for such systems, considering different requirements and cultures. Inaddition to planning, the analysis, design, and other phases of systemdevelopment must take into account the information needs of the variousparties. (See Minicase 2.) One of the major problems with internationalsystems is that what is ethical or legal in one country may be unethical orillegal in another.

3. Ethical and legal issues. Developing systems across organizations and coun-tries could result in problems in any phase of system development. Forexample, in developing the Nagano Olympics system in 1998, IBM found atthe last minute that pro-North-Korea groups in Japan took offense at a ref-erence to the Korean War written on the Web site. Although the materialwas taken from the World Book Encyclopedia, it offended some people. IBMhad to delete the reference and provide an apology. IBM commented, “Nexttime we’re going to do a ton of research first versus just do it and find outthe hard way.” A special difficulty exists with Internet-related projects, wherelegislation is still evolving.

4. User involvement. The direct and indirect users of a system are likely to bethe most knowledgeable individuals concerning requirements and which al-ternatives will be the most effective. Users are also the most affected by anew information system. IS analysts and designers, on the other hand, arelikely to be the most knowledgeable individuals concerning technical anddata-management issues as well as the most experienced in arriving at viablesystems solutions. The right mixture of user involvement and informationsystems expertise is crucial.

0006D_c14_632-678.qxd 10/15/03 17:18 Page 670

KEY TERMS 671

5. Traditional approaches vs. prototyping. The traditional development ap-proach stresses detailed, lockstep development with established decisionpoints. Prototyping stresses flexible development based on actual use of par-tially functional systems. Experience has shown that the traditional approachcan be better for low-risk, environmentally stable, and technology-simplesituations; prototyping is often better under the opposite conditions.

6. Tool use by developers. Development tools and techniques can ensure thatdevelopers consider all necessary factors and standardize development,documentation, and testing. Forcing their use, on the other hand, mayunnecessarily constrain innovation, development efficiency, and personnelproductivity.

7. Quality assurance vs. schedules. Quality counts in the short term and thelong term, but it can lengthen development and increase developmentalcosts. Trying to meet tight development schedules can induce poor qualitywith even worse schedule, cost, and morale problems.

8. Behavior problems. People use information systems and often become quiteused to how existing systems work. They may react to new systems inunexpected ways, making even the best technically designed systems useless.Changes brought about by information systems need to be managed effectively.Of special interest is the issue of motivating programmers to increase their pro-ductivity by learning new tools and reusing preprogrammed modules.

9. Perpetual development. Information systems are designed to meet organiza-tional needs. When they don’t accurately meet these needs, or these needschange, information systems need to be redeveloped. Developing a systemcan be a major expense, but perpetually developing a system to maintain itsusefulness is usually a much more expensive.

10. Risk level. Building information systems involves risk. Systems may not becompleted, completed too late, or require more resources then planned. Therisk is large in enterprise systems. For how to manage such risk see Scott andVessey (2002).

ON THE WEB SITE… Additional resources, including quizzes; online files of additional text,tables, figures, and cases; and frequently updated Web links to current articles and infor-mation can be found on the book’s Web site (wiley.com/college/turban).

KEY TERMSApplets (Java) •••

Application service provider(ASP) •••

Component-based development •••

Computer-aided softwareengineering (CASE) •••

Direct cutover •••

E-business application •••

End-user computing •••

Enterprise application integration(EAI) •••

Enterprise software •••

Extreme programming (XP) •••

Feasibility study •••

Information center •••

Java •••

Joint application design (JAD) •••

Legacy systems •••

Light methodology •••

Logical design •••

Milestones •••

Object-oriented development •••

Outsourcing •••

Parallel conversion •••

Phased conversion •••

Physical design •••

Pilot conversion •••

0006D_c14_632-678.qxd 10/15/03 17:18 Page 671


Post-audit •••

Project planning •••

Prototyping •••

Rapid application development(RAD) •••

Reverse engineering •••

Systems analysis •••

Systems development •••

Systems development life cycle(SDLC) •••

Utility Computing •••

Waterfall method •••

Web services •••

CHAPTER HIGHLIGHTS (Numbers Refer to Learning Objectives)

Web service is made by taking a set of software function-ality and wrapping it up so that the services it performsare visible and accessible to other software applications.

� End-user developed systems, on a whole, can be com-pleted more rapidly than those developed through theconventional systems lifecycle.

� Outsourcing custom development or purchasinggeneric systems are alternatives to in-house develop-ment. Utility computing vendors are looking toward afuture in which computing capacity is as easy toacquire as electricity.

� Web-based applications are easy to develop and imple-ment. However, organizations need to establish consis-tent policies and practices to make sure that Web-pagedevelopment activities support organizational goals.

� There are several options for developing e-business ap-plications. The major applications are buy, lease, anddevelop in-house. Application service providers man-age e-business application services for customers froma central location.

� CASE tools can substantially increase programmer pro-ductivity. However, the more integrated packages aredifficult to learn, which initially reduces productivityand can lead to resistance to implementation within ISgroups.

� Software quality can be improved by implementing thecapability maturity model (CMM) or ISO 9001:2000standards.

� A systems development life cycle (SDLC) identifies themajor steps, or stages, in the development or acquisi-tion of an information system. Organizations may usea proprietary SDLC methodology to help manage sys-tems projects. Traditional SDLCs try to complete muchof their analysis and design activities before startingdevelopment and are more appropriate where require-ments are easier to identify.

� Various methods can be used to develop complex orquickly needed systems. The prototyping approach isan iterative process that creates simple versions of asystem to help users identify their requirements. Rapidapplication development (RAD) packages can speeddevelopment. Joint application design (JAD) is a struc-tured process in which users, managers, and analystswork together to specify or review systems require-ments. Object-oriented development makes it easierto develop very complex systems rapidly and withrelatively few errors.

� Extreme programming (XP) is a pragmatic approach toprogram development that emphasizes business resultsfirst and takes an incremental approach to building theproduct.

� Many e-business applications are assembled from a setof components, rather than being constructed fromscratch. Components have evolved from the objects ofobject-oriented methodology. However, they are muchlarger, providing a kind of plug-and-play buildingblocks that help in developing large complex systems,such as ERP or e-commerce.

� Web services are URL-addressable software resourcesthat perform functions and provide answers to users. A

QUESTIONS FOR REVIEW1. Describe the major stages of the SDLC.

2. Explain why it is important to understand the conceptof SDLC.

3. List four different approaches to converting from onesystem to another. Which is most risky? Least risky?

4. Describe the tools that are commonly included in rapidapplication development (RAD) packages. What capa-bilities can they provide?

5. Why do many companies use the prototyping ap-proach to develop their e-business applications? Whatare the limitations of the prototyping approach?

6. Describe object-oriented development and its increas-ing importance.

7. Describe the architecture of component-based devel-opment of e-commerce applications.

8. Define Web services.

0006D_c14_632-678.qxd 10/15/03 17:18 Page 672

EXERCISES 673

9. List the major areas of Web services Applications.

10. List five major advantages and three major disadvan-tages of Web services.

11. List the advantages and disadvantages of purchasinggeneric software versus using in-house staff or out-sourcers to develop customized applications.

12. Identify the major reasons why utility computing toolswill become the next big thing.

13. List the e-business application options.

14. Describe an application service provider (ASP).

15. Describe Java and its role in Internet development.

16. Identify and explain the five levels of the capabilitymaturity model (CMM).

17. List the issues in controlling the quality of systemsdevelopment. What is the role of IS-9000?

QUESTIONS FOR DISCUSSION1. Why is it advisable in some systems development pro-

jects to use prototyping to find information needs?Why can’t the analyst just ask the users what theywant and use the SDLC?

2. What types of incentives could an IS group provide toits programmers to encourage reuse of objects andother software they develop?

3. What type of development approaches would be mostappropriate for developing small systems? For verylarge systems? Why? What other factors need to beconsidered?

4. Is extreme programming (XP) really “extreme”?

5. Discuss the use of Web services for systems develop-ment. What kind of systems are especially amenable toWeb services?

6. End-user systems developers usually work for man-agers whose IT knowledge is limited. Discuss the typesof problems to which this situation could lead, andsuggest possible ways of dealing with these problems.

7. Do you think technology has a lot of catching up to dobefore utility computing will become a reality for com-panies with many computing needs?

8. Although the CASE concept—automated tools to in-crease programmer productivity—seems valid, many

IS organizations do not use integrated (I-CASE) pack-ages. Discuss the barriers to the increasing use of I-CASE.

9. Some programmers feel that implementing the capa-bility maturity model (CMM) will make the develop-ment process too rigid and bureaucratic, thus stiflingtheir creativity. Discuss the pros and cons of this issue.

10. Building Web-based systems such as intranets can be afast and fairly easy process. Based on Chapters 4 and 5can you explain why? What are the long-term impli-cations of this for IS professionals? For end-user sys-tems developers? For outsourcing firms?

11. Discuss the advantages of a lease option over a buyoption in e-business applications development.

12. Compare component-based development to enterpriseapplication integration.

13. A large company with a number of products wants tostart selling on the Web. Should it use a merchantserver or an electronic suite? Assuming the companyelects to establish an electronic storefront, how wouldyou determine whether it should outsource the site orrun it itself?

EXERCISES1. Contact a major information systems consulting firm

and ask for literature on its systems development life cy-cle methodology (or search for it on the Internet). Com-pare and contrast the proprietary methodology to theeight-stage SDLC described in this chapter.

2. Identify and interview some end users who developsystems at their organizations. Ask them whether theirorganization has any standards for documenting andtesting systems developed by end users. If it has suchpolicies, are they enforced? If not, what do the endusers do to ensure the accuracy and maintainability ofthe systems they develop?

3. Contact an administrator at your university or workplace and find out what purchased systems, especiallylarger ones, are in use. Do these systems meet the or-ganization’s needs, or are some important features miss-ing that should be included in these packages?

4. Contact IS managers at some large organizations, andfind out whether their IS developers use any CASEtools. If the IS units use an integrated (I-CASE) tool,what things do they like and dislike about it? If the unitsdo not use I-CASE tools, what are the reasons for notusing them?

0006D_c14_632-678.qxd 10/15/03 17:18 Page 673


GROUP ASSIGNMENTS1. Divide the class into two teams. Have both teams collect

information on SAP’s integrated enterprise manage-ment software, and on Oracle’s comparable softwarepackages. After the teams analyze the data, stage a de-bate with one team arguing that the SAP products arethe more desirable and with the other team supportingOracle (or other vendor).

2. Several vendors offer products for creating online stores.The Web sites of each vendor usually list those onlinestores using their software. Assign one or more vendors toeach team member. Visit the online stores using each ven-dor’s software. Prepare a report comparing the similaritiesand differences among the sites. Do the sites take advan-tage of the functionality provided by the various products?

INTERNET EXERCISES1. Explore the General Electric site at

ge.com, and then compare it to the Ko-dak site at kodak.com. Try to identifythe organizational objectives for thesetwo different types of sites. In the con-text of these objectives, discuss the

advantages and disadvantages of having either: (1) arelatively simple site with limited graphics, or (2) a sitethat contains extensive graphics.

2. Go to the site at geocities.com/�rfinney/case.htm. Followthe links on the page to look at the features of severalCASE tool packages. Prepare a report on the capabilitiesof one or two packages with multiple features.

3. Look at the Netron Corporation site (netron.com). Exam-ine the tools they have for working with legacy systems

(gap analysis) and for rapid application development.Write a report. Prepare a report on Netron’s approach toand tools for renovating and maintaining legacy systems.

4. StoreFront (storefront.net) is the leading vendor of e-Bizsoftware. At their site they provide demonstrations il-lustrating the types of storefronts that they can createfor shoppers. They also provide demonstrations of howtheir software is used to create a store.

a. Run either the StoreFront 5.0 or StoreFront 6.0demonstration to see how this is done.

b. What sorts of features are provided by StoreFront 5.0?c. Does StoreFront 5.0 support larger or smaller stores?d. What other products does StoreFront offer for creat-

ing online stores? What types of stores do theseproducts support?

0006D_c14_632-678.qxd 10/15/03 17:18 Page 674

MINICASE 1 675

A direct cutover from an existing system to a new one isrisky. If the system is critical to the operations of the or-ganization, the risks are magnified to an even higher level.Yet Quantum Corp. (quantum.com), a Milpitas, California,disk-drive manufacturer, did just that—and lived to tellabout it. The vendors and consultants on the project claimthat this was one of the largest-ever direct cutovers of adistributed business system.

Quantum realized that it had to take action. The limita-tions of its existing systems were making it difficult for thecompany to compete in the disk-drive market. Sales repre-sentatives needed to determine how much of a specificitem—in inventory or in production—had not yet beencommitted to other customers. However, because data-bases did not share information, it was very difficult forthem to get this information.

Quantum was especially interested in a piece of infor-mation known as available-to-promise (ATP). This indi-cates how many units of a given item could be delivered,by what date, to specific locations throughout the world.Calculating these values require coordination and real-time processing of sales, inventory, and shipping data. IfQuantum implemented its new system by phasing in themodules one at a time, the conversion would take muchlonger. Furthermore, the system would not be able to pro-vide this key information until the end of the transition.

Quantum felt that the business risks of this kind of de-lay were greater than the technical risks of a direct cutover.The company was also concerned about possible resistancein some departments if the full implementation took a longtime. The departments had enough autonomy to imple-ment other systems if they lost confidence in the new sys-tem and, if they did, Quantum would lose the benefits ofhaving an integrated system.

Although the actual cutover took eight days, the plan-ning and preparation required over three years. The initialanalysis was in October 1992, and Quantum sent out re-quests for proposals in April 1993. In March 1994, thecompany chose Oracle, Hewlett-Packard, and Price Water-house as its business partners on the project.

Quantum created a project team of 100 people, com-posed of key employees from each business unit and the ISdepartment, and moved them into a separate building. Thepurchase of the disk-drive business of Digital EquipmentCorp. in October 1994, which brought in another set oflegacy applications and assorted hardware platforms, setthe project back by about four months.

In February 1995, Quantum started a public relationscampaign with a three-day conference for the users. The

following month, “project evangelists” made presentationsat all organizational locations.

In August 1995, the team conducted a systems valida-tion test. It failed. The team worked intensely to solve theproblems and then tested the system again for four weeksstarting in December 1995. This time, it was successful.

In March 1996, Quantum provided a very extensive andabsolutely mandatory user-training program. In April, itconducted final briefings, tested the system at all locationsthroughout the world, and set up a “mission control” center.

At 5 p.m. on April 26, Quantum shut down the old sys-tem. Hank Delavati, the CIO, said, “Business as we know itstopped . . . we could not place an order, we could not re-ceive material, we could not ship products. We could noteven post cash.” Data records from the old system wereloaded into the new system. At 4 p.m. on May 5, the newsystem started up successfully.

Mark Jackson, an executive vice president at Quantum,noted afterward that the relatively large project budget wasnot the company’s primary concern. He said, “We couldhave figured out how to save 10 percent of the project’scost . . . but that would have raised the risk to an unac-ceptable level. To succeed, you have to spend the moneyand take care of the details.”

Source: Condensed from Radosevich (1997) and quantum.com(2003).

Questions for Minicase 1

1. Estimate Quantum Corporation’s chances of survival ifthis project failed. Provide some reasons to support yourestimate.

2. What did Quantum do to minimize the risks of this di-rect cutover?

3. Evaluate the claim that, because of business and organi-zational issues, this direct cutover was less risky than aphased conversion.

4. Under what, if any, circumstances would you recom-mend this kind of direct cutover for critical operationalsystems?

5. Discuss the impact of this project on the internal powerrelationships between the IS department and the otherdepartments in the organization.

6. It appears that Quantum spent a substantial amount ofmoney on this project and was willing to increase spend-ing when it seemed necessary for the success of the proj-ect. Discuss the risks of a “whatever it takes” approach.

Minicase 1Do or Die

0006D_c14_632-678.qxd 10/15/03 17:18 Page 675

TABLE 14.5 Possible Solutions to Critical Gaps (for Minicase 2)

Option Description Gaps Affected Risk Costs

SAP provides on-sitedevelopers to editthe R/3 system’score program codeand incorporate thechanges in futureR/3 system releases.

IBM creates temporaryworkaroundsolutions that are“bolted on” to thesystem and are notpart of the core SAPR/3 system code

Push project timelinethree months, result-ing in someimplementationactivities being con-ducted simultane-ously to meet theJuly 1 “Go live” date

“Go live” with non-HR modules as out-lined in the projectscope and interfacethe R/3 system withthe University’s cur-rent human resourcemanagement system.

This option wouldresolve all gaps.

This option wouldresolve most gapsas attempts todevelopworkarounds forsome gaps wouldnot be feasible.

SAP validates thatall critical gaps areresolved in thenext R/3 systemrelease.

This option addresses onlythose gaps relatedto the humanresources (HR)applicationmodule.

Moderate risk, assolutions will beincorporated infuture R/3 systemreleases; however,developers mustbegin immediately.

High risk, assolutions are notguaranteed to bein future R/3 sys-tem releases.

High risk, as newversion must bedelivered on timeand resolution ofcritical gaps mustbe supported.

Low risk, as currentpayroll system isfunctional.

Expected low costto the Universityas SAP would beasked to absorbmost of the costs.

High cost to theUniversity forthe consultingresources. Neededto complete theworkarounds.

Moderate cost forsome additionalresources; poten-tial for high costif gaps are notresolved in newversion.

Moderate cost forsome additionalresources and toaddress changemanagementissues; potentialfor high cost ifpayroll systemhas to be up-dated for Y2Kcompliance.

SAP provideson-sitedeveloper(s)

IBM providesdevelopers tocreateworkarounds

Extend projecttimeline untilJuly 1, 1999,to implementthe next ver-sion of SAPR/3

Universitydelays payrolluntil the nextphase ofimplementingfunctionality


On a Monday morning in August 1998, Jim Buckler, pro-ject manager of the University of Nebraska’s Administra-tive System Project (ASP), was preparing for his weeklymeeting with the project’s steering committee, the Finan-cial System Task Force (FSTF). The ASP is an effort chargedwith implementing SAP’s R/3 client/server enterpriseresource planning (ERP) product for the University ofNebraska’s multicampus system.

As a result of mapping the University’s future businessprocesses to the SAP R/3 system, a number of gaps wereidentified between these processes and those offered by theSAP R/3 system. These critical gaps were tracked as one of

the project’s critical success factors. Project managementand the FSTF had to consider all factors that could poten-tially be impacted by the critical gaps. Such factors includethe scope of the project, resources (human and budgetary),the timeline, and previous configuration of the system, toname a few.

Four options have been developed as possible solutionsto resolve the 14 critical gaps. Table 14.5 summarizes theoptions presented to the FSTF by project management.

With a number of constraints and issues in mind, Buck-ler contemplated which one or combination of the four op-tions was the best course of action. Should SAP and IBM be

Minicase 2Implementing SAP R/3 at the University of Nebraska

0006D_c14_632-678.qxd 10/15/03 17:18 Page 676

REFERENCES 677

working concurrently on resolving the gaps (i.e., options 1and 2)? This seemed to be the safest course of action, but itwould be very costly. Should the project timeline be ex-tended until July 1, 1999? What if SAP could not resolveall the gaps by that time? Would that deter the Universityfrom transitioning smoothly into the new millennium?Should the implementation of the HR/Payroll module bedelayed? These options would have to be carefully consid-ered and a recommendation made at Buckler’s meetingwith the FSTF in a few hours’ time.

Sources: Condensed from Sieber et al. (1999) and sap.com (2003).

Questions for Minicase 2

1. Which of the four options or combination of optionswould you recommend to project management and thesteering committee? What are the risks involved in yourrecommendation? How would you manage the risks?

2. Discuss the advantages and disadvantages of a pur-chased system that forces different organizational unitsto change their business processes and policies to con-form to the new system. Identify situations where thisstandardization would be desirable, and other situationswhere it would be undesirable.

3. Can you think of circumstances where a companymight want to install an enterprise management sys-tem, such as SAP R/3, even though it appears that thiswould be significantly more expensive than developinga comparable system in-house? Discuss.

4. Go to the site at sap.com. Follow the links on the page tolook at the features of some cross-industry solutions.Prepare a report on the capabilities of the SAP solutions.

Barbara and Jeremy have done some serious economic jus-tification of the myriad technologies that could benefittheir business, and they have chosen CRM as the top prior-ity. They feel that they have grown to a point where theywill need a full-time project manager to oversee the acqui-sition and implementation of the CRM, and they haveasked you to describe how you would proceed on this proj-ect. At the start of your internship, you were hopeful itmight lead to a full-time job offer after graduation, so yousee this as your opportunity to impress Barbara and Jeremywith your business education and your systems expertise.

1. Propose a system development life cycle for implement-ing a CRM at The Wireless Café (TWC). Consider

methodologies that are well-suited to rapid develop-ment of Web-based applications.

2. Once a CRM system is identified, should its implemen-tation be outsourced? Assuming you do decide to out-source the entire implementation of the selected CRM,how would you manage the outsourcer to make surethe implementation is successful?

3. As TWC expands its utilization of IT, the concept of anapplication service provider becomes increasingly at-tractive. What are some risks and benefits to a smallbusiness of using an ASP for major applications?

Virtual Company AssignmentBuilding Information Systems

REFERENCESAhituv, N., et al., “A System Development for ERP Systems,”Journal of Computer Information Systems, Spring 2002.

Allen, P., and S. Frost, Component-Based Development for EnterpriseSystems, England: Cambridge University Press, 1998.

ansett.com.au (accessed July 2003).

Arsanjani, A., (ed.), “Developing and Integrating EnterpriseComponents and Services,” Communications of the ACM, October,2002.

bcbsri.com (accessed July 2003).

Bucken, M. W., “2000 Innovator Awards: Blue Cross & BlueShield,” Application Development Trends Magazine, April 2000,adtmag.com/article.asp�2692 (accessed July 2003).

Cerami, E., Web Services Essentials, Cambridge, MA: O’Reilly andAssociates, 2002.

Cule, P., et al., “Strategies for Heading Off IS Project Failures,”Information Systems Management, Spring 2000.

0006D_c14_632-678.qxd 10/15/03 17:18 Page 677


Dahanayake, A., et al., “Methodology Evaluation Framework forComponent-Based System Development,” Journal of Database Man-agement, March 2003.

Dietel, E. M., et al., Web Services Technical Introduction, Upper-SaddleRiver, NJ: Prentice Hall, 2003.

Fremantle, P., et al., “Enterprise Services,” Communications of theACM, October, 2002.

Herbsleb, J., et al., “Software Quality and the Capability MaturityModel,” Communications of the ACM, June 1997.

Johnson, R. A., “The Ups and Downs of Object-Oriented SystemsDevelopment,” Communications of the ACM, October 2000.

Kendall, K. E., and J. E. Kendall, Systems Analysis and Design, 5th ed.Upper Saddle River, NJ: Prentice Hall, 2002.

Kern, T., and J. Kreijger, “An Exploration of the ASP OutsourcingOption,” Proceedings, 34th HICSS, Maui, HI, January 3–6, 2001.

Lee, J. N., et al., “IT Outsourcing Evolution: Past, Present, andFuture,” Communications of the ACM, May, 2003.

Liebowitz, J., “Information Systems: Success or Failure?” Journal ofComputer Information Systems, Fall 1999.

Linthicum, D. S., B2B appliation Integration: e-Business-Enable YourEnterprise, Boston: Addison Wesley, 2001.

Martin, C. F., “Legacy Value Engineering: the Foundation of Youthto Maximize the Value of Existing Technology Investments,” TheExecutive’s Journal, Winter 2003.

mbe.com (accessed July 2003).

Montealegre, R., and M. Keil, “De-escalating Information Technol-ogy Projects: Lessons from the Denver International Airport,” MISQuarterly, September 2000.

Mullich, J. “Web Site Development: Back Home,” InternetWeek,January 2000, internetweek.com/indepth/indepth011000.htm (ac-cessed July 2003).

Neel, D. “The Utility Computing Promise,” InfoWorld, April 2002.

Patton, S., “Web Services in the Real World,” CIO, April 2002.

Paul, L., “T-Shirt King,” The Internet Marketing Center, February1999 sellitontheweb.com/ezine.mystore008.shtml (accessed July 2003).

Paul, L. G., “How Do Technology Initiatives Fail?” Darwin Maga-zine, May 2001. darwinmagazine.com/read/050101/po.html (accessedJuly 2003).

quantum.com (accessed July 2003).

Radosevich, L., “Quantum’s Leap,” CIO, February 15, 1997.

Rooney, J. T., Newtrade Technologies, Web Services Before TheirTime, October, 2001. dcb.sun.com/practices/casestudies/newtrade.jsp(accessed July 2003).

Sachdeva, S., “Outsourcing Strategy Helps Ansett AustraliaStreamline Its Business,” IBM Success Story, 2000 ibm.com/services/successess/ansett.html (accessed July 2003).

sap.com (accessed July 2003).

Scott, J. E., and I. Vessey, “Managing Risks in Enterprise SystemsImplementations,” Communications of the ACM, April 2002.

Seybold, P., An Executive Guide to Web Services., Boston, MA: PatriciaSeybold Group (psgroup.com), 2002.

Sieber, T., et al., “Implementing SAP R/3 at the University ofNebraska,” Proceedings of the 20th ICIS Conference, December, 12–15,1999.

Shirky, C., Planning for Web Services, Cambridge, MA: O’Reilly andAssociates, 2002.

Shohoud, Y., Real World XML Web Services, Boston: Addison WesleyProfessionals, 2002.

snap-on.com (accessed July 2003).

Stal, M., “Web Services; Beyond Component-Based Computer,”Communications of the ACM, October 2002.

Standish Group, “Chaos,” Standish Research Paper, standishgroup.com/visitor/chaos.htm, 1995.

Susarla, A., Barua, A., and Whinston, A. B., “Understanding theService Component of Application Service Provision: An EmpiricalAnalysis of Satisfaction with ASP Services,” MIS Quarterly, March2003.

Tabor R., Microsoft.Net XML Web Services, Indianapolis, IN: SAMS,2002.

Tractinsky, M., and S. L. Jarvenpaa, “Information Systems DesignDecisions in a Global vs. Domestic Context.” MIS Quarterly,December 1995.

Valacich, J., et al., Essentials of Systems Analysis and Design, UpperSaddle River, NJ: Prentice Hall, 2001.

Ward, L., “How ASPs Can Accelerate Your E-Business,” e-BusinessAdvisor, March 2000.

Yourdon, E., “What’s So Different About Managing E-Projects?”Computerworld, August 2000.

Yourdon, E., Managing High-Intensity Internet Projects. Upper SaddleRiver, NJ: Prentice Hall, 2002.

Yourdon, E., Modern Structured Analysis. Englewood Cliffs, NJ:Prentice-Hall, 1989.

Zimmerman, J., “Utility Computing is the Next Big Thing,”ZDNetUK: Tech Update, March 2003, techupdate.zdnet.co.uk/story/0,,t481-s2131446,00.html (accessed July 2003).

0006D_c14_632-678.qxd 10/15/03 17:18 Page 678

mis - chapter 14 - building information systems

Documents