Systems Analysis & Design in a Changing World
Book Title: Systems Analysis and Design in a Changing World
Chapter 9: Moving to Design
ISBN: 0619213256 Author: John W. Satzinger, Robert B. Jackson, Stephen D. Burd, Richard Johnson
copyright © 2004 Course Technology
Chapter Title: Moving to Design
Learning Objectives

After reading this you chapter, you should be able to:

* Discuss the issues related to managing and coordinating the design phase of SDLC
* Explain the major components and levels of design
* Describe each design phase activity
* Describe common deployment environments and matching application
* Develop a simple network diagram and estimate communication capacity

Chapter Outline

* Understanding the Elements of Design
* Design Phase Activities
* Project Management: Coordinating the Project
* Deployment Environment
* Application Architecture
* Network Design

Fairchild Pharmaceuticals:

Finalizing Architectural Design for a Production System

James Schultz is a summer intern with Fairchild Pharmaceuticals. He has been assigned to an ongoing development project for a production scheduling and control system. The project was nearing the end of the analysis phase when James joined the team two weeks ago.

James works for Carla Sanchez, the chief analyst and project manager. For the past two weeks, James has been shadowing Carla as she completed final analysis phase tasks. He helped Carla prepare presentations to the project oversight committee and system users. He has absorbed a lot of information about the project in a very short time, but the details and overall project direction haven't yet formed a complete and coherent picture in his mind. Yesterday, the oversight committee signed off on the work to date, so Carla asked James to stop by her office first thing this morning to discuss his assignment for the next project phase.

James knocked on Carla's open door and asked, “Is this a good time or should I come back later?”

“I have time now,” she said. “Come in and have a seat. Let's start by reviewing the results of yesterday's meetings, and I'll answer any questions you have. Then we'll narrow down your tasks for the next few weeks of the project.”

James said, “I have two questions that I think are related. The first is, which implementation details have been decided and which haven't? The discussions with the users and oversight committee left me with the impression that the decision to go with a full-blown Web-based system had already been made. Yet none of the supporting infrastructure for a Web-based system currently exists, or does it?”

Carla replied, “A few elements are in place, but most of it will need to be designed and acquired. But let's hear your other question before we get into that.”

James continued, “Well, you've sort of anticipated my next question, which is what do we need to do next? There seem to be several important tasks that need to be started now, such as choosing system software to support Web services, determining what changes will be needed to the company network, and designing the database. But I suspect that I've left out a few important pieces. Also, the tasks and decisions are so interdependent that I don't know which should be tackled first.”

Carla smiled before she replied, “Well, you really were awake during all of the meetings! You should take some pride in knowing that you're confused about exactly the right things at this point in the project. The transition from analysis to design is an important but uncertain step in all projects, and this one is no exception. It's hard to move from a detailed knowledge of what the user wants and needs to a precise blueprint of a system that will satisfy those wants and needs. As you've correctly observed, there are many important decisions that need to be made very quickly, and they overlap. They're also heavily constrained by available time, budget, and existing systems, skills, and infrastructure.”

Looking a bit relieved, James replied, “So what's up first, and where do I fit in?”

Carla replied, “The generic name for the next step is architectural design. It's where we'll finalize all of the big-picture decisions, such as what hardware will support the new system, what operating systems we'll use, how we'll store and access data, and what languages and tools we'll use. Some of these issues were briefly addressed at the start of the project, and some decisions were implicit in the choice of deployment environment and automation scope approved by the oversight committee yesterday. What we need to do now is to lay all of them on the table, make sure they're compatible with one another and with existing systems and capabilities, and parcel out the detailed tasks associated with each.

Carla continued, “I spent yesterday afternoon dividing the work into major categories, including hardware and operating systems, Web support services, database design, application software design, and user interface design. I summarized the choices made so far and the remaining decisions we need to discuss. Key players will meet as a group for the rest of the week to discuss options in each area and develop the system architecture. For example, we'll decide whether to extend our existing database to support the new system or develop a new database with a new DBMS. By the end of the week, we'll have made all of the critical architectural decisions, ensured that the pieces all fit together, and developed plans to tackle each area with personnel assignments and time lines. From that point forward, work in each area can proceed in parallel. Professor Chen told me that you've done an independent study in Web services support software, right?”

“Yes,” James replied. “I did a comparative study of infrastructure-requirements and communication protocols for Web services using COM+, CORBA, and SOAP. I did an in-depth technology review of each and visited two sites using each technology to see how they worked in practice.”

“Good,” said Carla. “That knowledge will come in handy, since we need to decide whether to base the new system on SOAP and, if so, what supporting infrastructure and development tools to use. I think that you'll learn a lot by working with me for another week or two as we hammer out the architectural design. Once we get the detailed design tasks rolling, we'll choose one for you that suits your interests and abilities. There'll be plenty of interesting tasks from which to choose and more than enough work to keep you busy for the next month or two.”

Chapter 8 described the activities that complete the analysis phase and begin the transition from analysis to design. This chapter completes that transition and discusses issues related to the design of the new system. While analysis focuses on what the system should do—that is, the requirements—design is oriented toward how the system will be built—on defining structural components. Such activities as defining the scope and prioritizing the requirements are clearly analysis tasks. However, defining the application deployment environment and determining levels of automation are tasks begun during analysis but completed in more detail during design. Thus, we began the transition to design in the last chapter, and we move completely into design considerations in this chapter.

This chapter is the first of seven chapters discussing design. In this chapter, we briefly describe all design phase activities and discuss the first activity in more detail. Later chapters explore other design phase activities using both traditional and object-oriented models and techniques.
Understanding the Elements of Design

Systems design is the process of describing, organizing, and structuring the components of a system at both the architectural level and a detailed level with a view toward constructing the proposed system. Systems design is like a set of blueprints used to build a house. The blueprints are organized by the different components of the house and describe the rooms, the stories, the walls, the windows, the doors, the wiring, the plumbing, and all other details. We do the same organizing in systems design, although the components we are describing are the components of the new system. We design and specify various components of the solution.

To understand the various elements of systems design, we must consider two questions:

* What are the components that require systems design?
* What are the inputs to and outputs of the design process?

Major Components and Levels of Design

To do design, analysts first partition the entire system into its major components because an information system is much too complex to design all at once. Figure 9-1 depicts how these various components fit together. The icons on the figure are pieces of hardware, and inside the hardware are the software components. The cloud represents the entire system, and the various icons show the parts of the system that must work together to make the system functional. Information systems professionals must ensure that they develop a total solution for the users—they have not done their job if they haven't provided an integrated, complete solution.

As we will see in an upcoming section, the activities of the design phase of the SDLC support this partitioning of the final system into design components. Basically, each design phase activity is focused around designing one of the identified components shown in Figure 9-1.

A second important idea underlying systems design is that of the different levels of design. During analysis, we first identified the scope of the problem before we tried to understand all of the details. We called this step top-down analysis. Analysis, as it was presented, included both top-down activities (for example, scope first, then details) and bottom-up activities (for example, DFD fragments first, then the middle-level diagram). The same ideas apply during design.

Figure 9-1 System components requiring systems design.

[Click to enlarge]

As you begin working in industry, you will find that various names are given to the design at the highest level, including architectural design, general design, and conceptual design. We will use the term architectural design. During architectural design, you first determine the overall structure and form of the solution before trying to design the details. Designing the details is usually called detail design. It is not so important at this point to distinguish which activities are architectural design and which are detail design. Neither is it important to identify which models or documents belong to architectural design or to detail design. What is important is to recognize that design should proceed in a top-down fashion. Let's review the implications of this approach for each of the design components identified in Figure 9-1
architectural design

broad design of the overall system structure; also called general design or conceptual design
detail design

low-level design that includes the design of specific program details

For the entire system, the analysts first identify the overall application deployment environment. They determine the overall architectural requirements and structure of the network before specifying the details of the routers, firewalls, servers, workstations, and other components. This approach was introduced in Chapter 8 and will be expanded in this chapter.

For the application software, the first steps are to identify the various subsystems and their relationships to the network, the database, and the user-interface components. Part of that early design is the automation system boundary. The system boundary identifies which functions are included within the automated system and which are manual procedures. Notice that we began this process by identifying the level of automation, which was explained in Chapter 8.

For the database component, the first steps are to identify the type of database to be used and the database management system. Some details of the record structures and the data fields may have been identified, but the final design decisions will depend on the architecture.

For the user interface, the first steps are to identify the general form and structure of the user dialog based on the major inputs and outputs. The project team also describes the relationship of the user-interface elements with the application software and the hardware equipment. Afterward, the detailed window and report layouts can be developed.
Moving from Analysis to Design

During the activities of the analysis phase, we built documents and models. For traditional analysis, models such as the event table, data flow diagrams, and entity-relationship diagrams were built. For object-oriented analysis, we also used the event table and developed other models such as class diagrams, use case diagrams, and use case descriptions. Regardless of the approach, the input to the design phase activities is the set of documents and models that were built during earlier phases.

During analysis, analysts also built models to represent the real world and to understand the desired business processes and the information used in those processes. Basically, analysis involves decomposition—breaking a complex problem with complicated information requirements into smaller, more understandable components. Analysts then organize, structure, and document the problem domain knowledge by building requirements models. Analysis and modeling require substantial user involvement to explain the requirements and to verify that the models are accurate.

Design is also a model-building activity. Analysts use the information gathered during-analysis—the requirements models—and convert that information into models that represent the solution system. Design is much more oriented toward technical issues and therefore requires less user involvement and more involvement by other systems professionals. Figure 9-2 illustrates this flow from analysis to design, highlighting the distinct objectives of each phase.

The original definition of design indicates that design involves describing, organizing, and structuring the system solution. The output of the design activities is a set of diagrams and documents that achieves this objective. These diagrams model and document various aspects of the solution system. As with the analysis models, some components are similar for structured and OO approaches, but other components are very different.

Figure 9-2 Analysis objectives to design objectives.

[Click to enlarge]

Figure 9-3 duplicates the information about traditional and OO requirements models originally shown in Figure 5-36 and extends it with the design models for both traditional structured design and object-oriented design. As noted in the figure, the models developed during the analysis phase feed directly into the models built for design—the traditional analysis models feed the traditional design models, and the object-oriented analysis models feed the object-oriented design models. Note also that several design models (shown in green and spanning the two sides of the figure) are common to both approaches.

Figure 9-3 Traditional structured and object-oriented models.

[Click to enlarge]

For database design, the traditional approach usually uses a relational database model. The object-oriented technique can design either a relational database model or a newer object-oriented database model. For user-interface design, both techniques include the design of the human-computer dialog, forms, and reports. Both database and user-interface design share many of the same techniques, whether a structured approach or an object-oriented approach is used.

For application architecture design, however, traditional structured techniques and object-oriented techniques do differ substantially. Structured techniques, including analysis and design models, have been used for many years to describe the structure and organization of systems written using the input-process-output model of software. These models are well suited to describing business applications, most of which rely on databases or files and do not require sophisticated real-time processing. These models were originally developed to support application software design and programming using COBOL and BASIC programming languages. They are equally well suited to programming in other languages, such as C, FORTRAN, Pascal, and other business-oriented programming languages.

Object-oriented techniques are newer techniques that have become widely used since the late 1980s. They are well suited to real-time, interactive, and event-driven software such as operating systems that require multitasking capabilities. Object-oriented development is rapidly becoming the preferred approach for developing business applications, which are usually interactive and event driven.

A frequently asked question is, can structured techniques and object-oriented techniques be mixed? In other words, is it possible to do structured analysis and then object-oriented design of the application or vice versa? In some situations it may be possible to mix and match, such as when designing and implementing the interface using OO after completing traditional structured analysis. But generally, such mixing and matching does not work well for application design, because the basic philosophies of the two approaches are so fundamentally different. The design of the application software using a traditional approach provides an architectural structure based on the top-down procedural functions of the system. A system designed using object-oriented techniques has an architectural structure based on the set of interacting objects for each use case.

Whatever approach has been used, once analysts have addressed the major components of a system, have considered its architectural design, and have in hand the documents and models developed during analysis, they can begin to consider how to design the system. We turn next to the activities of the design phase.
Design Phase Activities

The activities identified in the design phase of the SDLC provide an overview of the design process. As indicated previously, these activities provide the design for each of the components illustrated in Figure 9-1. More details about design processes are explained later in this chapter and in subsequent chapters as we discuss each of the design activities. First, let's get an overview of the SDLC design phase. Figure 9-4 identifies the activities that are associated with the design phase.

The design phase involves specifying in detail how a system will work using a particular technology. Some of the design details will have been developed during systems analysis, when the alternatives were described. But much more detail is required. Sometimes systems design work is done in parallel with the analysis phase, and usually the activities within systems design are done in parallel. For example, the database is typically designed at the same time the user interface is designed. An iterative approach to the SDLC is also commonly used, so when we talk about the design phase activities, sometimes the activities are completed for one iteration and then later for another iteration. As with the activities in the analysis phase, each activity of the design phase can be summarized with a question, as shown in Figure 9-5.

Figure 9-4 SDLC phases with design phase activities.

[Click to enlarge]

Figure 9-5 Design phase activities and key questions.

[Click to enlarge]

Each of the activities develops a specific portion of the final set of design documents. Just as a set of building blueprints has several different documents, a systems design package also consists of several different sets of documents that specify the entire system. In addition, just as the blueprints must all be consistent and integrated to describe the same physical building, the various systems design documents also must be consistent and integrated to provide a comprehensive set of specifications for the complete system.
Design and Integrate the Network

Sometimes a new system is implemented along with a new network. If this is the case, then the network needs to be designed. More often, though, network specialists have established the network based on an overall strategic plan. The systems design alternative chosen was one that fit the existing network plan. So rather than designing a network, the project team typically must integrate the system into an existing network.

Important technical issues arise when making the system operate over a network, such as reliability, security, throughput, and synchronization. Again, specialists are often brought in to help with the technical details. The requirements developed during systems analysis specify what work goes on at what locations, so these locations need to be connected. Technical requirements (as opposed to functional requirements) often have to do with communication via networks.

Later in this chapter, we highlight critical issues in network design and planning. The key question to be answered when completing the “Design and integrate the network” activity is, have we specified in detail how the various parts of the system will communicate with each other throughout the organization?
Design the Application Architecture

Designing the application architecture involves specifying in detail how all system activities will actually be carried out. These activities are described during systems analysis in great detail as logical models, without indicating what specific technology would be used. Once a specific design alternative is chosen, the detailed computer processing—the physical models—can be designed. A key decision is to define the automation boundary, discussed in Chapter 1, which separates the manual work done by people from the automated work done by computer. Models created include physical data flow diagrams, structure charts, interaction diagrams, and other physical models.

The approach to application design and the design models created vary depending on the development and deployment environments. If the programming language is Visual Basic, for example, the type and nature of the models developed will be different than if the language were COBOL. If client-server architecture is used, the models used are different than with a centralized architecture. If object-oriented technology is used, the models definitely are quite different. Additionally, some activities are carried out by people rather than computers, so manual procedures need to be designed.

The key question to be answered when completing the “Design the application architecture” activity is, have we specified in detail how each system activity is actually carried out by the people and computers?
Design the User Interfaces

A critical aspect of the information system is the quality of the user interface. The design of the user interface defines how the user will interact with the system. To most users, the interface is a graphical user interface with windows, dialog boxes, and mouse interaction. Increasingly, it can include sound, video, and voice commands. Users' capabilities and needs differ widely; each user interacts with the system in different ways. Additionally, different approaches to the interface might be needed for different parts of the system. Therefore, there are many user interfaces to consider. And as information systems become increasingly interactive and accessible, the user interface is becoming a larger part of the system.

Analysts should remember that to the user of the system, the user interface is the system. The user interface is more than just the screens—it is everything the user comes into contact with while using the system, conceptually, perceptually, and physically. So, the user interface is not just an add-on to the system. It is something that needs to be considered throughout the development process.

The nature of the user interface begins to emerge very early in the development process, when requirements are being defined. The specification of the tasks the users complete begins to define the user interface. Then when alternatives are being defined, a key aspect of each alternative is its type of user interface. The activity of designing the user interface in detail, however, occurs during systems design.

Sometimes specialists in user-interface design are brought in to help with the project.-These specialists might be called interface designers, usability consultants, or human factors engineers. The visual programming environments now available make it easy for developers to create graphical user interfaces for applications. But it is still very difficult to make a graphical user interface friendly or intuitive.
interface designers

specialists in user-interface design; also called usability consultants or human factors engineer

The processes associated with user-interface design are discussed in Chapter 14. The key question to be answered when completing the “Design the user interfaces” activity is, have we specified in detail how all users will interact with the system?
Design the System Interfaces

No system exists in a vacuum. A new information system will affect many other information systems. Sometimes one system provides information that is later used by another system. Other times systems exchange information continuously as they run. The component that enables systems to share information is the system interface, and each system interface needs to be designed in detail.

From the very beginning of system design, analysts must ensure that all of these systems work together well. Some system interfaces link internal organizational systems, so the analyst may have information available about the other systems. In some cases, the new system needs to interface with a system outside the organization—for example, at a supplier's site or customer's home. In other cases, the new system needs to interface with a package application that the organization has purchased and installed. System interfaces can become quite complex, particularly with so many types of technology available today. Often, an organization needs people with very specialized technical skills to work on these interfaces.

System interface design is discussed in more detail in Chapter 15. The key question to be answered when completing the “Design the system interfaces” activity is, have we specified in detail how the system will work with all other systems inside and outside our organization?
Design and Integrate the Database

Designing the database for the system is another key design activity. The data model (a logical model) created during systems analysis is used to create the physical model of the database. Sometimes the database is a collection of traditional computer files. More often, it is a relational database consisting of dozens or even hundreds of tables. Sometimes files and relational databases are used in the same system. Sometimes object-oriented databases might be used instead of relational databases.

Analysts must consider many important technical issues when designing the database. Many of the technical (as opposed to functional) requirements defined during systems analysis concern database performance needs (such as response times). Much of the design work might involve performance tuning to make sure the system actually works fast enough. Another key aspect of designing the database is making sure that new databases are properly integrated with existing databases.

A detailed discussion of database design is presented in Chapter 13. The key question to be answered when completing the “Design and integrate the database” activity is, have we specified in detail how and where the system will store all of the information needed by the organization?
Prototype for Design Details

During the design phase, it is important to continue creating and evaluating prototypes. Often associated with interface design, prototyping can also be used to confirm design choices about the database, network architecture, controls, or even programming environments being used. Therefore, when analysts consider all of the design activities, they think about how prototypes might be used to help understand a variety of design decisions. It is also important to recognize that rapid application development (RAD) approaches develop prototypes during design that evolve into the finished system. In those cases, the prototype is the system.

The key question to be answered when completing the “Prototype for design details” activity is, have we created prototypes to ensure that all detailed design decisions have been fully understood?
Design and Integrate the System Controls

A final design activity involves ensuring that the system has adequate safeguards to protect organizational assets. These safeguards are referred to as system controls. This activity is not listed last because it is less important than the others. On the contrary, it is a crucial activity. It is listed last because controls have to be considered for all other design activities—user interface, system interface, application architecture, database, and network design.

User-interface controls limit access to the system to authorized users. System interface controls ensure that other systems cause no harm to this system. Application controls ensure that transactions recorded and other work done by the system are done correctly. Database controls ensure that data are protected from unauthorized access and from accidental loss due to software or hardware failure. Finally, and of increasing importance, network controls ensure that communication through networks is protected. All of these controls need to be designed into the system, based on the existing technology. Specialists are often brought in to work on some controls, and all system controls need to be thoroughly tested.

Control issues are addressed in several chapters but more explicitly in Chapter 15. The key question to be answered when completing the “Design and integrate the systems controls” activity is, have we specified in detail how we can be sure that the system operates correctly and the data maintained by the system are safe and secure?
Project Management:

Coordinating the Project

The initiation of design activities is a pivotal point in the development project. The focus changes from discovery to solution development, and the whole tenor of the project changes. Coordinating all of the ongoing activities is challenging for even the best project managers because myriad details and tasks must be handled to keep the project on track. Figure A-4 identifies many project management tasks that are required during the design phase. Most of these tasks involve monitoring progress and coordinating the ongoing work.

Even though analysis for an iteration is essentially complete at this point, some analysis tasks remain. Every new system has a multitude of business rules that must be integrated into it. For example, a set of business rules concerning sales commissions includes when and how commissions are calculated, what happens to commissions on merchandise returns, when commissions are paid, how the commission schedule varies to encourage sales of high-margin items and sale items, and so forth. All of these business rules must be defined to develop the commission programs properly. However, what if management is still making decisions about these business rules? You would not want to hold up the entire project for a few of these decisions. On the other hand, you want to make sure that they do not fall through the cracks.

In addition, as the project team members, including the users, better understand the potential capabilities of the new system, they may ask to modify the business definition to provide higher levels of automation and support. This request is good for the company, which will benefit from a better system. However, the request is bad for the project because it will increase the scope and delay the project. How does the project manager control the scope of the project while being sensitive to these additional requests that may be critical to the company?

Design activities also require substantial coordination. The project begins to fragment as an increasing number of design issues are addressed. Frequently, the system is divided into subsystems, and each subsystem has unique design requirements. The project team may also be divided into smaller teams to focus on the various subsystems and on other design issues. Some technical issues—such as network configuration, database design, distributed processing needs, and communications capability—are common to all subsystems. Other issues—such as response time and specialized input equipment—may be limited to specific subsystems. Coordinating and integrating all technical issues for all subsystems, along with any middleware software, are fundamental to the smooth functioning of the overall system. Ultimately, the success of a development project depends on how well all of the work of the design teams is coordinated.

Two other miniprojects may also be initiated at this point: a data conversion project and a test case development project. We will explain more about the details of these projects in Chapter 16. We mention them here simply to note that they insert additional complexity to the management of the project.

Finally, activities of the implementation phase, such as programming, also begin around this time. In fact, design and programming for an iteration frequently are conducted concurrently. Programming can begin as soon as design decisions are made. So, in addition to the various groups working on design issues, groups of programmers and programmer/analysts will probably be added to the project team.

Control and coordination of these various activities can be complicated further by the fact that people involved in the project may work at different locations. Project communications management, which is essential to successful coordination, becomes many times more complicated as people are added to the team.

Given these complexities, let's discuss several project management tools and techniques to help in the coordination of the project.
Coordinating Project Teams

The fundamental tool to coordinate the various project teams' activities is the project schedule. As the activities of the design phase begin, the project manager must update the schedule by identifying and estimating all tasks associated with design and implementation, as well as any outstanding tasks associated with ongoing requirements definition. The project schedule usually must be reworked substantially to ensure that the project remains organized.

During the analysis phase, the project manager and an assistant often do project management tasks, but when the project expands and several teams are formed, management of the project becomes more complicated. Frequently, a committee composed of the leaders of the key design and implementation teams assumes more responsibility for coordinating and controlling aspects of project management. Weekly, and sometimes daily, status meetings are held. If this group includes people at remote locations, teleconferencing support may be required.
The Project Team at RMO

As the customer support system project moves forward into design at RMO, the project team has been enhanced with the addition of new team members. Consistent with the earlier discussion, RMO initiated two new subprojects at this time, one for data conversion and one for the system and acceptance test plans. To integrate new people into the team, Barbara Halifax reorganized the structure of the project team. Those who had been on the team throughout the analysis phase are now key players in getting the new team members up to speed. The accompanying RMO memo highlights some of the changes going on in the project at this point.
Coordinating Information

As design moves forward, the development teams begin to generate a tremendous amount of detailed information about the system. Modules, classes, data fields, data structures, forms, reports, methods, subroutines, and tables are all being defined in substantial detail. Tremendous coordination is needed to keep track of all of these pieces of information. But two kinds of tools can help in this process.

[Click to enlarge]

The most common and widespread technique to record and track project information is to use a CASE tool. Most CASE tools have a central repository to capture information. In Chapter 2, you learned about CASE tools, and Figure 2-21 illustrated the various component tools that make up a comprehensive CASE system. A major element in a CASE tool system is the central repository of information. The central repository not only records all design information but also is normally configured so that all teams can view project information to facilitate communication among the teams of a project. Figure 9-6 illustrates the various information components that may exist within a CASE data repository.

Figure 9-6 System development information stored in the CASE repository.

[Click to enlarge]

Other electronic tools are also available to help with team communication and information coordination. These tools and techniques, often referred to as computer support for collaborative work, not only record final design information but also assist in team collaboration. Often during the development process, several people need to work together in the development of the design, so they need to discuss and dynamically update the working documents or diagrams. One collaborative tool that is frequently used is Lotus Notes. Other software programs allow figures and diagrams to be updated with tracking and version information so that the evolution of the result can be documented.

One especially difficult part of development projects is tracking open items and unresolved issues. We mention this issue here, not because it requires a new technique, but because the problem is pervasive and all good project managers develop techniques to track these items. One simple method is to have an open items control log. In Chapter 4, we presented the idea of an open-items control list and an example in Figure 4-10. It is a sequential list of all open items with information to track responsibilities and resolution of the open item, as shown by the column headings. Frequently, closed items are shaded for easy identification. This technique is effective not only during analysis but also throughout the entire project.

Now that you have an overview of the design phase and major issues of project management, we turn to the tasks associated with architectural and network design. First, we discuss technical aspects of the deployment environment that directly affect architectural design. Then, we describe common approaches to architectural design and the software and network design issues associated with each approach.
Deployment Environment

In Chapter 8, you learned that defining the deployment environment is an activity that bridges analysis and design. The deployment environment consists of the hardware, system software, and networking environment in which the system will operate. In this section, we describe common deployment environments in detail, and in the next section we'll explore related design patterns and architectures for application software.
Single-Computer and Multitier Architecture

As its name implies, single-computer architecture employs a single computer system and its directly attached peripheral devices, as shown in Figure 9-7. It can be a stand-alone PC application, but in this context we are discussing large mainframe applications where users interact with the system via input/output devices of limited functionality that are directly connected to the computer. Single-computer architecture usually requires all system users to be located near the computer. The primary advantage of single-computer architecture is its simplicity. Information systems deployed on a single-computer system are relatively easy to design, build, operate, and maintain.
single-computer architecture

architecture that employs a single computer system executing all application-related software

Figure 9-7 Single-, clustered, and multicomputer architectures.

[Click to enlarge]

The capacity limits of a single computer may make single-computer architecture impractical or unusable for large information systems. Many systems are so large that even the largest mainframe computer cannot perform all the required processing, data storage, and data retrieval tasks. Such systems require another architectural approach.

Multitier architecture employs multiple computer systems in a cooperative effort to meet information-processing needs. Multitier architecture can be further subdivided into two types:

* Clustered architecture, shown in Figure 9-7, employs a group (or cluster) of computers, usually from the same manufacturer and model family. Programs are allocated to the least utilized computer when they execute so that the processing load can be balanced across all machines. In effect, a cluster acts as a single large computer system. Clustered computer systems are normally located near one another so that they can be connected with short high-capacity communication links.
* Multicomputer architecture, shown in Figure 9-7, also employs multiple computer systems. But hardware and operating systems are not required to be as similar as in a clustered architecture. A suite of application or system programs and data resources is exclusively assigned to each computer system. Each computer system is optimized to the role that it will play in the combined system, such as database or application server.

multitier architecture

architecture that distributes application-related software or processing load across multiple computer systems
clustered architecture

a group of computers of the same type that share processing load and act as a single large computer system
multicomputer architecture

a group of dissimilar computers that share processing load through specialization of function
Centralized and Distributed Architecture

The term centralized architecture describes deployment of all computer systems in a single location. Centralized architecture is generally used for large-scale processing applications, including both batch and real-time applications. Such applications are common in industries such as banking, insurance, and catalog sales. Information systems in such industries often have the following characteristics:

* Some input transactions do not need to be processed in real time (for example, out-of-state checks delivered in large nightly batches from central bank clearinghouses).
* On-line data-entry personnel can be centrally located (for example, a centrally located group of telephone order takers can serve geographically dispersed customers).
* The system produces a large amount of periodic outputs (for example, monthly credit-card statements mailed to customers).
* A high volume of transactions occurs between high-speed computers (for example, business-to-business processing for supply chain management).

centralized architecture

architecture that locates all computing resources in a central location

Any application that has two or three of these characteristics is a viable candidate for implementation on a centralized mainframe. Current trends in conducting e-business have instilled new life into centralized mainframe computing because of the transaction volumes of many business-to-business (B2B) processes.

Centralized computer systems are seldom used as the sole hardware platform for an information system. Most systems have some transaction inputs that must be accepted from geographically dispersed locations and processed in real time—for example, a cash withdrawal from an ATM. Most systems also have some outputs that are requested from and delivered to remote locations in real time—for example, an insurance policy inquiry by a state motor vehicle department. Thus, centralized computer systems are typically used to implement one or more subsystems within a larger information system that includes on-line, batch, and geographically dispersed components.

Components of a modern information system are typically distributed across many computer systems and geographic locations. For example, corporate financial data might be stored on a centralized mainframe computer. Minicomputers in regional offices might be used to generate accounting and other reports periodically based on data stored on the mainframe. Personal computers in many locations might be used to access and view periodic reports as well as to directly update the central database. Such an approach to distributing components across computer systems and locations is generically called distributed architecture. Distributed architecture relies on communication networks to connect geographically dispersed computer hardware components.
distributed architecture

architecture that deploys computing resources in multiple locations connected by a computer network
Computer Networks

A computer network is a set of transmission lines, specialized hardware, and communication protocols that enable communication among different users and computer systems. Computer networks are divided into two classes depending on the distance they span. A local area network (LAN) is typically less than one kilometer long and connects computers within a single building or floor. The term wide area network (WAN) can describe any network over one kilometer, though the term typically implies much greater distances spanning cities, countries, continents, or the entire globe.
computer network

a set of transmission lines, equipment, and communication protocols to permit sharing of information and resources
local area network (LAN)

a computer network in which the distances are local, such as within the same building
wide area network (WAN)

a computer network spread across large distances, such as a city, state, or nation

Figure 9-8 shows a possible computer network for RMO. A single LAN serves each geographic location, and all LANs are connected by a WAN. Users and computers in a single location communicate via their LAN. Communication among geographically dispersed sites uses the LANs at both sites and the WAN. A router connects each LAN to the WAN. A router scans messages on the LAN and copies them to the WAN if they are addressed to a user or computer on another LAN. The router also scans messages on the WAN and copies them to the LAN if they are addressed to a local user or computer.

network equipment that directs information within the network

Figure 9-8 A possible network configuration for RMO.

[Click to enlarge]

Technologies such as Ethernet are typically used to implement LANs. They provide low to moderate amounts of message-carrying capacity at relatively low cost. WAN technologies such as asynchronous transmission mode are more complex and expensive, though they typically provide higher message-carrying capacity and greater reliability.

WANs may be constructed using purchased equipment and leased long-distance transmission lines. WAN setup and operation may also be subcontracted from a long-distance telecommunications vendor such as AT&T or Sprint.

Computer networks provide a generic communication capability among computer systems and users. This generic capability can support many services, including direct communications (such as telephone service and video conferencing), message-based communications (such as e-mail), and resource sharing (such as access to electronic documents, application programs, and databases). A single network can simultaneously support multiple services with appropriate hardware and sufficient transmission capacity.

There are many ways to distribute information system resources across a computer network. Users, application programs, and databases can be placed on the same computer system, on different computer systems on the same LAN, or on different computer systems on different LANs. Application programs and databases can also be subdivided and each distributed separately.
The Internet, Intranets, and Extranets

The Internet is a global collection of networks that are interconnected using a common low-level networking standard—TCP/IP (Transmission Control Protocol/Internet Protocol). The World Wide Web (WWW), also called simply the Web, is a collection of resources (programs, files, and services) that can be accessed over the Internet by a number of standard protocols, including the following:

* Formatted and linked document protocols, such as HyperText Markup Language (HTML), eXtensible Markup Language (XML), and HyperText Transfer Protocol (HTTP)
* Executable program standards, including Java, JavaScript, and Visual Basic Script (VBScript)
* Distributed software and Web-service standards, including Distributed Computing Environment (DCE), Common Object Request Broker Architecture (CORBA), and Simple Object Access Protocol (SOAP)

The Internet is the infrastructure on which the Web is based. In other words, resources of the Web are delivered to users over the Internet.

a global collection of networks that use the same networking protocol—TCP/IP
World Wide Web (WWW), or Web

a collection of resources such as files and programs that can be accessed over the Internet using standard protocols

An intranet is a private network that uses Internet protocols but is accessible only by a limited set of internal users (usually members of the same organization or workgroup). The term also describes a set of privately accessible resources that are organized and delivered via one or more Web protocols over a network that supports TCP/IP. An intranet uses the same protocols as the Internet and Web but restricts resource access to a limited set of users. Access can be restricted in various ways, including unadvertised resource names, firewalls, and user/group account names and passwords.

a private network that is accessible to a limited number of users, but which uses the same TCP/IP protocol as the Internet

An extranet is an intranet that has been extended to include directly related business users outside the organization (such as suppliers, large customers, and strategic partners). An extranet allows separate organizations to exchange information and coordinate their activities, thus forming a virtual organization. One widely used method of implementing an extranet is through a virtual private network (VPN). A private network is a network that is secure and accessible only to members of an organization (or virtual organization). Historically, implementing a private network required an organization to own and operate its own network lines or leased dedicated telephone lines. A VPN sends encrypted messages through public Internet service providers.

an intranet that has been extended outside the organization to facilitate the flow of information
virtual organization

a loosely coupled group of people and resources that work together as though they were an organization
virtual private network (VPN)

a network with security and controlled access for a private group but built on top of a public network such as the Internet
Application Architecture

Simple deployment environments, such as a single centralized computer with video display terminals, can be matched to relatively simple application architectures. More complex distributed and multitier hardware and network architectures require more complex software architectures. This section describes common examples of application architecture for distributed and multitier deployment environments and the design issues and decisions associated with each.
Client-Server Architecture

Client-server architecture divides programs into two types: client and server. A server manages one or more information system resources or provides a well-defined service. A client communicates with a server to request resources or services, and the server responds to those requests.

a process, module, object, or computer that provides services over a network

a process, module, object, or computer that requests services from one or more servers

Client-server architecture is a general model of software organization and behavior that can be implemented in many different ways. A typical example is the interaction between a client application program executing on a workstation and a database management system (DBMS) executing on a larger computer system Figure 9-9. The application program sends database access requests to the database management system via a network. The DBMS accesses data on behalf of the application and returns a response such as the results of a search operation or the success or failure result of an update operation.

Figure 9-9 Client-server architecture with a shared database.

[Click to enlarge]

The architectural issues to be addressed when designing client-server software are:

* Decomposing the application into client and server programs, modules, or objects
* Determining which clients and servers will execute on which computer systems
* Describing the communication protocols and networks that connect clients and servers

The key to decomposing the application into clients and servers is identifying resources or services that can be centrally managed by independent software units. Examples of centrally managed services include security authentication and authorization, credit verification, and scheduling. In each case, a service provides a set of well-defined processes such as retrieval, update, and approval based on a data store that is hidden from the client, as shown in Figure 9-10.

Figure 9-10 Interaction among client, server, and a service-related data store.

[Click to enlarge]

Client and server software can execute on any computer system. But the most typical arrangement is to place server software on separate server computer systems and to distribute client software to computer systems “close” to end-users, such as desktop workstations. Figure 9-11 shows a typical arrangement for an order-processing application. Credit verification, delivery scheduling, and database server processes execute on a centrally located minicomputer or mainframe, and users execute multiple copies of the client software on workstations.

Figure 9-11 Interaction among multiple clients and a single server.

[Click to enlarge]

Client and server communicate via well-defined communication protocols over a physical network. In Figure 9-11, the network is a LAN, and an appropriate low-level network protocol such as TCP/IP provides basic communication services. But the system designer must also specify higher-level protocols, or languages, by which client and server exchange service requests, responses, and data. In some cases, such as communication with a DBMS, standard protocols and software may be employed, such as Structured Query Language (SQL) via an Open Database Connectivity (ODBC) database connection. But in other cases, the designer must define the exact format and content of valid messages and responses. If a service is provided by an external organization (for example, credit verification), then the external organization will have already designed an appropriate protocol, and the application designer must ensure that clients adhere to the protocol.

The primary advantage of client-server architecture is deployment flexibility. Client-server architecture arose as an approach to distributing software across networked computers. It provides the inherent advantages of a networked environment including:

* Location flexibility. The ability to “move” system components without “disturbing” other system components, in response to changing organizational parameters such as size and physical location
* Scalability. The ability to increase system capacity by upgrading or changing the hardware on which key software components execute
* Maintainability. The ability to update the internal implementation of one part of a system without needing to change other parts (for example, the credit verification software can be rewritten or replaced as long as the new software uses the existing client-server protocol)

The primary disadvantages of client-server architecture are the additional complexity introduced by the client-server protocols and the potential performance, security, and reliability issues that arise from communication over networks. A centralized application executing as one large program on a single computer needs no client-server protocols, and all communication within the application occurs within the relatively secure, reliable, and efficient confines of a single machine.

For most organizations, the flexibility advantages of client-server far outweigh the disadvantages. As a result, client-server architecture and its newer variants have become the dominant architecture for the vast majority of modern software.
Three-Layer Client-Server Architecture

A widely applied variant of client-server architecture, called three-layer architecture, divides application software into a set of client and server processes independent of hardware or locations. All layers might reside on one processor, or three or more layers might be distributed across many processors. In other words, the layers might reside on one or more tiers. The most common set of layers includes:

* The data layer, which manages stored data, usually in one or more databases
* The business logic layer, which implements the rules and procedures of business processing
* The view layer, which accepts user input and formats and displays processing results

Figure 9-12 illustrates the interaction of the three layers. The view layer acts as a client of the business logic layer, which, in turn, acts as a client of the data layer.
three-layer architecture

a client-server architecture that divides an application into the view layer, business logic layer, and data layer
data layer

the part of three-layer architecture that interacts with the database
business logic layer

the part of three-layer architecture that contains the programs that implement the business rules of the application
view layer

the part of three-layer architecture that contains the user interface

Figure 9-12 Three-layer architecture.

[Click to enlarge]

Like earlier forms of client-server architecture, three-layer architecture is inherently flexible. Interactions among the layers are always requests or responses, which makes the layers relatively independent of one another. It doesn't matter where other layers are implemented or on what type of computer or operating system they execute. The only interlayer dependencies are a common language for requests and responses and a reliable network with sufficient communication capacity.

Multiple layers can execute on the same computer, or each layer can operate on a separate computer. Complex layers can be split across two or more computers. System capacity can be increased by splitting layer functions across computers or by load sharing across redundant computers. In the event of a malfunction, redundancy improves system reliability if the server load can be shifted from one computer to another. In sum, three-layer architecture provides the flexibility needed by modern organizations to deploy and redeploy information-processing resources in response to rapidly changing conditions.

Three-layer architecture is currently a widely applied architectural design pattern with both the traditional approach and the object-oriented approach. As with other forms of client-server architecture, the key design tasks are decomposing the application into layers, clients, and servers, distributing the “pieces” across hardware platforms, and defining the physical network and protocols.

The business logic layer is the core of the application software and is constructed according to the requirements models developed during analysis, as described in Chapter 5 Chapter 6 Chapter 7. For example, in the traditional approach, all of the business logic defined for system activities within the RMO data flow diagrams would be implemented as functions or procedures in the business logic layer. The window or browser forms making up the view layer would not contain much procedural code. In the object-oriented approach, the classes of objects in the RMO class diagram Figure 5-35 would be implemented within the business logic layer as classes of objects that interact to complete user tasks. In either case, the business logic layer is a server for the view layer and is a client of the data layer. However, the business logic layer may itself be decomposed into multiple clients and services. Three-layer architecture is usually implemented with object-oriented techniques and tools, as described in Chapter 11, though it is also implemented with traditional design techniques and programming languages, as described in Chapter 10. In this respect, three-layer architecture is a prominent architectural design pattern that applies to both traditional and OO approaches.

In this text, Chapter 10 Chapter 11 describe the how view and data layer software is designed with traditional and OO approaches. Chapter 13 describes the details of the database that is accessed by the data access layer. Chapter 14 describes user-interface design techniques and guidelines that are independent of the software that implements the view layer, such as the arrangement of interface elements on a video display and the dialog between user and computer that supports a specific application task.

Client-server and three-layer architecture relies on special programs to enable communication between the various layers. Software that implements this communication interface is usually called middleware. Middleware connects parts of an application and enables requests and data to pass between them. There are various methods to implement the middleware functions. Some common types of middleware include teleprocessing monitors, transaction processing monitors, and object request brokers (ORBs). Each type of middleware has its own set of protocols to facilitate communication between the various components of an information system.

computer software that implements communication protocols on the network and helps different systems communicate

When specifying the protocols to be used for client-server or interlayer communication, the designer usually relies on standard frameworks and protocols incorporated into middleware. For example, interactions with DBMSs usually employ standard protocols such as ODBC and SQL with supporting software obtained from the DBMS vendor or a third party. Third-party service providers such as credit bureaus and electronic purchasing or bidding services usually employ a standard Web protocol such as HTTP or XML. Industry-specific protocols have been developed in many industries such a health care and banking.

Complex OO software distributed across multiple layers and hardware platforms relies on an ORB based on a distributed object interface standard such as CORBA. Distributed non-OO software relies on different middleware products based on standards such as DCE or Microsoft's COM+. Web-based applications rely on Web-oriented protocols such as Microsoft's .NET and Sun's J2EE and specific middleware products that implement and support those protocols. Support protocols and software for distributed objects, components, and Web-based applications are discussed in more detail in Chapter 16.
Internet and Web-based Application Architecture

The Web is a complex example of client-server architecture. Web resources are managed by server processes that can execute on dedicated server computers or on multipurpose computer systems. Clients are programs that send requests to servers using one or more of the standard Web resource request protocols. Web protocols define valid resource formats and a standard means of requesting resources and services. Any program (not just a Web browser) can use Web protocols. Thus, Weblike capabilities can be embedded in ordinary application programs.

Internet and Web technologies present an attractive alternative for implementing information systems. For example, consider the problem of data entry and access by an RMO buyer when purchasing items from its suppliers. Buyers are typically on the road for several months a year, often for weeks at a time. A traveling buyer needs some means of remotely interacting with RMO's supply chain management (SCM) system to record purchasing agreements and query inventory status.

One way of providing these capabilities would be to design custom application software and a private network to connect to that software. The primary portion of the system could be installed on a server at RMO. The client portion of the application—for data entry—would then be installed on the buyers' laptop computers. A buyer would then connect to the system from remote locations to gain access to the application server, make queries to the database, and enter data.

Another alternative for implementing remote access for buyers would be to construct an application that uses a Web browser interface. The application would execute on a Web server, communicate with a Web browser using HTML or XML, and be accessible from any computer with an Internet connection. Buyers could use a Web browser on their laptop computer and connect to the application via an Internet service provider wherever they're currently located. Buyers could also access the application from any other computer with Internet access (for example, a computer in a vendor's office, hotel business suite, or copy center such as Kinko's).

Flexibility is the key to the Internet alternative. Implementing the application via the Internet greatly expands the application's accessibility and also eliminates the need to install custom client software on buyers' laptop computers. With Internet technology, client software can be updated by simply updating the version stored on the Web server. The application is relatively cheap to develop and deploy because existing Web standards and networking resources are employed. Custom software and private access via modems require more complex development and maintenance of a greater number of customized resources.

Implementing an application via the Web, an intranet, or an extranet has a number of advantages over traditional client-server applications, including the following:

* Accessibility. Web browsers and Internet connections are nearly ubiquitous. Internet, intranet, and extranet applications are accessible to a large number of potential users (including customers, suppliers, and off-site employees).
* Low-cost communication. The high-capacity WANs that form the Internet backbone were funded primarily by governments. Traffic on the backbone networks travels free of charge to the user, at least for the present. Connections between private LANs and the Internet can be purchased from a variety of private Internet service providers at relatively low cost. In essence, a company can use the Internet as a low-cost WAN.
* Widely implemented standards. Web standards are well known, and many computing professionals are already trained in their use. Server, client, and application development software is widely available and relatively cheap.

Information resource delivery via an intranet or extranet enjoys all of the advantages of Web delivery since intranets and extranets use Web standards. In many ways, intranets, extranets, and the Web represent the logical evolution of client-server computing into an off-the-shelf technology. Organizations that had shied away from client-server computing because of the costs and required learning curve can now enjoy client-server benefits at substantially reduced complexity and cost.

Of course, there are negative aspects of application delivery via the Internet and Web technologies, including the following:

* Security. Web servers are a well-defined target for security breaches because Web standards are open and widely known. Wide-scale interconnection of networks and the use of Internet and Web standards makes servers accessible to a global pool of hackers.
* Reliability. Internet protocols do not guarantee a minimum level of network throughput or even that a message will ever be received by its intended recipient. Standards have been proposed to address these shortcomings, but they have yet to be widely adopted.
* Throughput. The data transfer capacity of many home users is limited by analog modems to under 56 kilobits per second. Internet service providers and backbone WANs can become overloaded during high-traffic periods, resulting in slow response time for all users and long delays when accessing large resources.
* Volatile standards. Web standards change rapidly. Client software is updated every few months. Developers of widely used applications are faced with a dilemma: use the latest standards to increase functionality or use older standards to ensure greater compatibility with older user software.

The primary disadvantages to RMO of implementing the customer order application via the Internet are security, performance, and reliability. If a buyer can access the system via the Web, then so can anyone else. Access to sensitive parts of the system can be restricted by a number of means, including user accounts and passwords. But the risk of a security breach will always be present. Performance and reliability are limited by the buyer's Internet connection point and the available Internet capacity between that connection and the application server. Unreliable or overloaded local Internet connections can render the application unusable. RMO has no control over these factors.

The key architectural design issues for Web-based applications are similar to those for other client-server architectures: defining client and server processes or objects, distributing them across hardware platforms, and connecting them with appropriate networks, middleware, and protocols. However, for Web-based applications, the choices for middleware and protocols tend to be much more limited than for other forms of client-server architecture.

Now that we've discussed common approaches to application architecture, we'll turn our attention to designing the networking infrastructure that connects parts of a modern information system.
Network Design

Networks are used throughout organizations today. As a result, many new development projects involve network design. Network planning and design are critical issues that must be dealt with early in the design phase for any multitiered system. The key design issues are:

* Integrating network needs of the new system with existing network infrastructure
* Describing the processing activity and network connectivity at each system location
* Describing the communication protocols and middleware that connect layers
* Ensuring that sufficient network capacity is available

Network Integration

Modern organizations rely on networks to support many different applications. Thus, the majority of new systems must be integrated into existing networks without disrupting existing applications. Network design and management are highly technical tasks, and most organizations have permanent in-house staff, contractors, or consultants to handle network administration.

The analyst for a new project begins network design by consulting with the organization's network administrators to determine whether the existing network can accommodate the new system. In some cases, the existing network capacity is sufficient, and only minimal changes are required, such as adding connections for new servers or modifying routing and firewall configuration to enable new application layers to communicate.

Planning for more extensive changes—such as significant capacity expansion, new communication protocols, or modified security protocols—is much more complex. Typically, the network administrator assumes the responsibility of acquiring new capacity and making any configuration changes to support the new system since he or she understands the existing network and the way other network-dependent applications operate. The analyst's role for the new system in these cases is to provide the network administrator with sufficient information and time to enable system development, testing, and deployment.
Network Description

Location-related information gathered during analysis may have been documented using location diagrams Figure 6-37, activity-location matrices Figure 6-38, and activity-data matrices Figure 6-39. During network design, the analyst expands the information content of these documents to include processing locations, communication protocols, middleware, and communication capacity.

There are many different ways to describe the network infrastructure for a specific application. Figure 9-13 shows a network diagram that describes how application layers are distributed across locations and computer systems for the RMO customer support system. The diagram summarizes key architectural decisions from Figure 8-5 and combines them with specific assumptions about where application software will execute, where servers and workstations will be located, and how network resources will be organized.
network diagram

a model that shows how application layers are distributed across locations and computer systems

Figure 9-13 A network diagram for the RMO customer support system.

[Click to enlarge]

The diagram embodies specific assumptions about server locations, which would be decided in consultation with network administrators. The Web/application servers could have been distributed outside the Salt Lake City data center, which might have improved system response time and reduced data communication capacity requirements on the private WAN. However, distributing the servers would also entail duplication of server administration at multiple locations, which would increase operational complexity and cost. Decisions such as server locations, communication routes, and network security options are determined both by application requirements and organization wide policies.
Communication Protocols and Middleware

The network diagram is also a starting point for specifying protocol and middleware requirements. For example, the private WAN connections must support protocols required to process Microsoft Active Directory logins and queries. If the WAN fails, messages are routed through encrypted (VPN) connections over the Internet, so those connections must support the same protocols as the private WAN. All clients must be able to send HTTP requests and receive active content such as HTML forms and embedded scripts. Application servers must be able to communicate with credit verification and shipping services via the Internet. Firewalls and routers must be configured to support all interactions among the workstations, customer PCs, Web/application servers, the Active Directory server, and external credit and shipping services. The Park City data center LAN must support at least one protocol for transmitting database queries and responses among the mainframe and Web/application servers.
Network Capacity

Information from the activity-location and activity-data matrices is the starting point for estimating communication capacity requirements for the various LAN, WAN, and Internet connections. Figure 9-14 reproduces data from the RMO activity-data matrix Figure 6-39 covering two activities (Look up item availability and Create new order) and three data entities (Customer, Inventory Item, and Order). Similar tables would be required for all combinations of activity, data entity, and location. Figure 9-14 includes estimates of data size per access type and the average and peak number of access per minute or hour.

Data size per access type is an educated guess at this point in the system design since none of the software layers, interlayer communication dialogs, or databases have yet been designed. Once those components have been designed in more detail or implemented, analysts can refine their estimates or actually sample and measure real data transmissions. Actual data transmission capacity will include communication protocols in addition to raw data.

Figure 9-14 Partial activity-data matrix for RMO customer support system updated with data access size and volume.

[Click to enlarge]

Systems design is the process of organizing and structuring the components of a system to allow the construction (that is, programming) of the new system. The design phase of a project consists of activities that relate to the design of the various components of the new system. The components that need to be designed include the application architecture, the user interfaces, the system interfaces, the database, the network, and system controls. Prototyping may be required to fully specify any part or all of the design.

The inputs to the design activities are the diagrams, or models, that were built during analysis. The outputs of the design are also a set of diagrams, or models, that describe the architecture of the new system and the detailed logic within the various programming components. The inputs, design activities, and outputs are different depending on whether a structured approach or an object-oriented approach is used.

Project management is critical when design activities are initiated. The tenor of the project changes at this point. During design, technical staff are involved. The project manager has to pay particular attention to the schedule, staff, and design activities. Sometimes programming is begun, which requires the addition of programming staff. Other side projects for data conversion and test-data development are also begun at this time.

Designing the application architecture can be subdivided into architectural and detail design. Architectural design adapts the application to the deployment environment, including hardware, software, and networks. Modern application software is usually deployed in a distributed multicomputer environment and is organized according to client-server architecture or a variant such as three-layer architecture. Architectural design decisions include decomposing the application into clients, servers, or layers, distributing software across hardware platforms, and specifying required protocols, middleware, and networks.

Architectural design decisions can be documented in a network diagram. The network diagram describes the organization of computing and network resources and specifies details such as what the required protocols are and which application software and middleware executes on which computer systems. Required network capacity can be determined by expanding the activity-location and activity-data matrices to include estimates of message size and volume.
Key Terms

* architectural design
* business logic layer
* centralized architecture
* client
* clustered architecture
* computer network
* data layer
* detail design
* distributed architecture
* extranet
* interface designers
* internet
* intranet
* local area network (LAN)
* middleware
* multicomputer architecture
* multitier architecture
* network diagram
* router
* server
* single-computer architecture
* three-layer architecture
* view layer
* virtual organization
* virtual private network (VPN)
* wide area network (WAN)
* World Wide Web (WWW), or Web

Review Questions

1. What is the primary objective of systems design?
2. What is the difference between analysis and design? List the activities in the design phase of the SDLC.
3. Why is project management so critical during the design phase? What tools can a project manager use during the design phase?
4. Explain the difference between centralized architecture and distributed architecture.
5. Explain the difference between clustered architecture and multicomputer architecture in a centralized system.
6. How are the Internet, intranets, and extranets similar? How are they different?
7. Describe client-server architecture and list the key architecture design issues that must be addressed when developing a client-server information system.
8. List and briefly describe the function of each layer in three-layer architecture.
9. What role does middleware play?
10. Describe the process of network design.
11. What roles do systems analysts and network administrators play in network design?
12. What is a network diagram? What information does it convey and where does the analyst gather that information?
13. How does the analyst generate estimates of required communication capacity? What analysis phase models are used as input?

Thinking Critically

1. Discuss the evolution of client-server computing from file server to multilayer applications to Web-based applications. What has been the driving force causing this evolution? Where do you think network computing will be in the next five years? Ten years?
2. Assume that the deployment environment for a high-volume payment processing system consists of the following (these assumptions are from the scenario presented in Chapter 8 first Experiential Exercise):
* DB2 DBMS running under the OS/390 operating system on an IBM S/390 mainframe
* WebSphere application server running under the Z/OS operating system on an IBM zSeries 900 mainframe
* CORBA-compliant component-based application software written in Java that will be executed by other internal and external systems
What are the key architectural design decisions that must be made for the system? When should the decisions be made and who should make them? Outline the subsequent design tasks that should occur after the key architectural design decisions are made. To what extent can the subsequent steps be performed in parallel?
3. Develop a network diagram that supports the architectural design decisions in your answer to number 2.

Experiential Exercises

1. Set up a meeting with the chief analysts of a medium- or large-scale development project and discuss the transition from analysis to design for that project. How and when were key architectural decisions such as automation boundary, network design, and supporting infrastructure made? Who made the decisions? Were the early architectural decisions modified later in the project? If so, how and why?
2. Find an example of an application system that is browser based and uses TCP/IP standards. Explain how it works, showing sample screens and reports. List each middleware component and describe its function. List each protocol employed and identify the standard family or families to which the protocol belongs.
3. Examine the RMO network diagram in Figure 9-13 and note the connections to external service providers for credit verification and shipping services. Identify at least three companies that can provide each service. Investigate their on-line Webbased service capabilities and describe the protocols used by clients to interact with their services.

Case Studies
The Real Estate Multiple Listing Service System

In Chapter 8 you were asked to discuss the implications of the “anytime, anywhere” requirement for the application deployment environment and to describe the type(s) of hardware, network, and software architecture required to fulfill that requirement. Assume that you addressed that question by specifying a three-layer architecture using ordinary PCs running Web browsers to implement the view layer. Draw a network diagram that represents your chosen solution.

Today's computer-based real estate listings typically include graphical data, such as still and moving pictures in addition to text descriptions of properties. What is the impact of such data on data communication requirements within your network design, assuming 10 listing accesses per hour? 100 listing accesses per hour? 1,000 listing accesses per hour?
Rethinking Rocky Mountain Outfitters

In Chapter 8, you were asked to consider an alternative deployment scenario for RMO based on Apache Web servers running under Linux and an Oracle database server. Modify the network diagram in Figure 9-13 to reflect the alternative deployment scenario. What changes, if any, are required for the client workstations and customer PCs? What changes, if any, are required in middleware and communication protocols? Will there be any change in the estimates of required data-communication capacity among client workstations and servers located at the Park City data center? Why or why not?
Focusing on Reliable Pharmaceutical Service

Assume the same facts as presented in the Chapter 8 Reliable Pharmaceutical case. Also assume that you are the project manager for the selected vendor's development team. Your company, RxTechSys, develops and markets software to retail and hospital pharmacies and has decided to take on the Reliable project to expand potential market share. RxTechSys and Reliable will jointly develop the new software. RxTechSys will then market the finished product to other companies and pay a royalty to Reliable for each sale.

RxTechSys has been in the pharmacy software business for 20 years. The latest version of the software is a Web-based application built on the Microsoft .NET platform. Major functions such as inventory control, purchasing, billing, and prescription warning are implemented as separate .NET Web services. As part of the team that prepared the response to Reliable's RFP, you determined that RxTechSys's current system can be adapted to Reliable's needs as follows:

* Existing browser-based prescription entry can be modified to handle data input from multiple customer locations over a VPN. This is a significant modification due to expanded data content and greater security requirements.
* Order fulfillment software will have to be written from scratch.
* Billing software will require significant modification since your current system assumes that all patients have their health care managed by a single institution, with possible third-party reimbursements through Medicaid/Medicare.
* Other parts of your existing system can be used with little or no modification.

Reliable has provided you with a complete set of object-oriented analysis models, the quality of which you approved during contract negotiations. Your task is to move the project forward through design and implementation.

Reliable has assigned an operational manager with some computer experience to your team full-time, and she is authorized to assign other Reliable personnel to your project as needed. You have been assigned a full-time staff of four developers, two of whom have substantial design experience and all of whom participated in developing the most recent version of RxPharmSys software.

Develop a design plan and schedule covering the next 4 to 6 weeks (your expected project duration is 10 months). What design decisions must be made within the next two weeks? Who should make them? How will design and development proceed thereafter—what tasks must be performed and in what order? How will you manage and control the project?
Further Resources

* Robert Orfali, Dan Harkey, and Jeri Edwards, Client/Server Survival Guide, third edition. Wiley, 1999.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License