1 application architecture & process design introduction the chapter will address the following...

1

Application Architecture & Process Design

Introduction

The chapter will address the following questions: What is an information system’s architecture in terms of DATA,

PROCESSES, INTERFACES, and NETWORKS — the building blocks of all information systems?

What are both centralized and distributed computing alternatives for information system design, including various client/server and Internet/intranet options?

What are the database and data distribution alternatives for information system design?

What are the make versus buy alternatives and variations for information system design?

What are the user and system interface alternatives for information system design?

2


Introduction

The chapter will address the following questions: What are the various networking topologies and their importance

in information system design? What are the methods for general application architecture and

design? What are the differences between logical and physical data flow

diagrams, and explain how physical data flow diagrams are used to model application architecture and guide process design?

How do you draw physical data flow diagrams for a system/application?

3


General System Design

During general systems design the basic technical decisions are made. These decisions include:

Will the system use centralized or distributed? Will the system’s data stores be centralized or distributed? If

distributed, how so? What data storage technology(s) will be used? Will software be purchased, built in-house, or both? For programs

to be written, what technology(s) will be used? How will users interface with the system? How will data be input?

How will outputs be generated? How will the system interface to other, existing systems?

4


General System Design

The decisions made during general systems design constitute the application architecture of the system.

An application architecture defines the technologies to be used by (and to build) one, more, or all information systems in terms of its data, process, interface, and network components. It serves as a framework for general design.

5


INFORMATION SYSTEMS FRAMEWORK

SYSTEM

ANALYSTS

INFORMATION

TECHNOLOGY

ARCHITECTURE

SYSTEMBUILDERS

(components)

SYSTEMDESIGNERS

(specification)

SYSTEMUSERS

(requirements)

SYSTEMOWNERS

(scope)

DatabaseArchitecture

Database Scehma

Data Requirements

Business Subjects

FOCUS ONSYSTEM

DATA

Application Schema

Business Processes

Business Functions

FOCUS ONSYSTEM

PROCESSES

Interface Schema

Interface Requirements

System Context

FOCUS ON SYSTEM

INTERFACES

Processor and Software Architecture

InterfaceArchitecture Networking

Architecture

Network Schema

Communication Reqts.

Operating Locations

FOCUS ONSYSTEM

GEOGRAPHY

Architecture Project

or

Configuration

Implementation

Phase

(deliver the new system into operation)

Design/Constructio

n Phases

(design and develop the system solution)

Definition Phase

(establish and prioritize business

system requirements)

Study Phase

(establish system improvement

objectives)

Survey Phase

(establish scopeand project plan)

System

Development

CUSTOMER customer-no customer-name customer-rating balance-due

PRODUCT product-no product-name unit-of-measure unit-price quantity-available

ORDER order-no order-date products-ordered quantities-ordered

Order Form

Help +

Customer Form

Product Lookup

Logon

New Customer

New Order

Order Accepted

Change of

Address

First Order

Request Order Help

Order Help Complete

Request Product Lookup

Request Product Lookup Help

Product Lookup Help Complete

Customers order zero, one, or more products. Products may be ordered by zero, one, or more customers.

Marketing

Advertising

Orders

Sales

Cancellations Services

Order Management

SystemCustomer

Accounts Receivable Database

Warehouse

Bank

OrderPicking Order

Credit

Credit Voucher

Check credit

Validate customer

Validate products

Release order

Customers

Orders

Products

order

customer number

valid order

order without valid

customer

credit

order with valid products

approved order

quantity in stock

approved order

rejected order

prices

picking ticket

EDI Cust

St. Louis

HQ

LA Office

Indy Ware- house

NY Office

West Customers

East Customers

Maintenance Records

Products Catalog

ordercatalog

changes

ship order

ship order ship order

credit credit

service

CUSTOMER customer_no [Alpha (10)] INDEX customer_name [Alpha(32)] customer_rating [Alpha(1)] INDEX balance_due [Real(5,2)]

PRODUCT product_no [Alpha(10)] INDEX product_name [Alpha(32)] unit_of_measure [Alpha(2)] unit_price [Real(3,2)] quantity_available [Integer(4)]

ORDER order_no [Alpha(12)] INDEX order_date [Date(mmddyyyy) CUSTOMER.customer_no

ORDER_PRODUCT ORDER.order_no PRODUCT.product_no quantity_ordered [Integer(2)

Ord e r Pro c e s s in g

Pro g ra m

Pro c e s s a n Ord e r

In i tia tio n Ro u tin e

Sh u td o wn Ro u tin e

Ge t a n Ord e r

Va lid a te a n Ord e r

F ile a n Ord e r

Ch e c k Cu s to m e r

Cre d it

Ch e c k Pro d u c t

Da ta

Ch e c k Cre d it Da ta

Re le a s e a n

Ord e r

Cu s to m e rs Pro d u c ts Ord e rs

St. Louis Mainframe

Indy AIX Server

NT Server LA

NT Server NY

Communications Controller

PBX

Enternet LAN AIX/Lan Manager

Ethernet LAN/NT

Ethernet LAN/NT

Client PC Client PC

Client PC Client PC

Fi r ecr acker Sal es

Database Decisions

Process Decisions

Interface Decisions

Network Decisions

6


Information Technology Architecture

Network Architectures for Client/Server Computing What is client/server computing?

A client is single-user computer that provides (1) user interface services, appropriate database and processing services; and (2) connectivity services to servers (and possibly other clients).

A server is a multiple-user computer that provides (1) shared database, processing, and interface services; and (2) connectivity to clients and other servers.

In client/server computing an information system’s database, software, and interfaces are distributed across a network of clients and servers which communicate and cooperate to achieve system objectives. Despite the distribution of computing resources, each system user perceives that a single computer (their own client PC) is doing all the work.

7



Network Architectures for Client/Server Computing Client/server computing is an alternative to traditional centralized

computing. In centralized computing, a multi-user computer (usually a

mainframe or minicomputer) hosts all of the information system components including (1) the data storage (files and databases), (2) the business logic (software and programs), (3) the user interfaces (input and output), and (4( any system interfaces (networking to other computers and systems). The user may interact with this host computer via a terminal (or, today, a PC emulating a terminal), but all of work is actually done on the host computer.

8


What is the

client and

operating

system?

Where are

user/syste

m interface

instruction

s

executed?

Where is

the

business

logic

instruction

s

executed?

Where are

database

commands

executed?

The clients are either dumb (non-programmable) terminals, or PCs (any OS) that are emulating dumb terminals using software.

Any system interfaces are either executed on the server or across the network on another server.

The user interface (usually non-graphical) is stored and executed on the server.

All business logic is programmed to execute on the server.

Resulting data files may be transferred to another server across the network.

All data is stored on the server and all file and database access and update commands and instructions are executed on the server computer.

Centralized

Computing

The clients are personal computers or workstations (sometimes called fat clients) running Windows 9x, Windows NT, OS/2, or Macintosh OS.


All business logic is programmed to execute on the server.

Resulting data files may be transferred to another server across the network.


Distributed Presentation

Computing



The user interface (usually graphical) is stored and executed on the client.

All business logic is programmed to execute on the client using a PC-based programming language.


A database server is usually microprocessor-based (e.g., UNIX or Windows/NT Server) but could still be a mainframe or minicomputer.

Distributed Database

Computing




Some business logic may be programmed to execute on the client.

Most business logic is programmed to execute on the server.

Typically. data and business logic (and possibly other services) are on separate servers (same OS's as in previous column).

Distributed Data/Logic

Computing

In addition to fat clients (see previous column), some clients may be network computers (also called NCs or thin clients) that only execute downloaded programs

User interfaces may be stored and executed on the client, or downloaded from the Internet or intranet for execution on the client.

System interfaces are managed from the Internet or intranet.

Appropriate business logic may be downloaded from Inter/intranet server to execute on the client.

Appropriate business logic is programmed to execute on the server.

All data is stored on the server (possibly multiple servers) and all file and database access and update commands and instructions are executed on the server computers.

Utilizes data and/or file servers as in previous two columns, but adds one or more Internet and intranet servers.

Internet/Intranet

Computing

What is the

server and

operating

system?

The server is usually a minicomputer or mainframe, possibly networked to other minicomputers or mainframes.

The server is usually a minicomputer (e.g., OS/400 OS) or mainframe computer (e.g. MVS,

VM, or UNIX OS).

Wide

Area

Network

Wide

Area

Network

Local

Area

Network

Wide

Area

Network

Local

Area

Network


All data is stored on the server (possibly multiple servers) and all file and database access and update commands and instructions are executed on the server computers.

Local

Area

Network

Intranet

or

InternetLocal or

Wide Area

Network

9



Network Architectures for Client/Server Computing Centralized Computing:

Centralized process architectures were once dominant because the cost of placing computers closer to the end-user was prohibitive.

Many (if not most) legacy applications remain centralized on large mainframe computers (such as IBM’s S/370 and 3090 families of computers) or smaller minicomputers (such as IBM’s AS/400).

10



Network Architectures for Client/Server Computing Distributed Presentation:

This alternative builds upon and enhances centralized computing applications.

The old character user interfaces are stripped from the centralized applications and regenerated as graphical user interfaces that will run on the PC.

The user interface (or presentation) is distributed off the server and onto the client.

All other elements of the centralized application remain on the server, but the system users get a friendlier graphical user interface to the system.

11



Network Architectures for Client/Server Computing Distributed Presentation:

Distributed presentation computing advantages:• It can be implemented relatively quickly since most aspects of the

legacy application remain unchanged.

• Users get a friendly and familiar interface to existing systems

• The useful lifetime of legacy applications can be extended until such a time as resources warrant a wholesale redevelopment of the application.

Distributed presentation computing disadvantages: • The application’s functionality cannot be significantly improved,

and the solution does not maximize the potential of the client’s desktop computer by only dealing with the user interface.

12



Network Architectures for Client/Server Computing Distributed Data:

Sometimes called two-tiered client/server. This architecture places the information system’s stored data on a

server, and the business logic and user interfaces on the clients. A local or wide area network usually connects the clients to the

server.• A local area network (or LAN) is a set of client computers (usually

PCs) connected to one or more server computers (usually microprocessor-based, but could also include mainframes or minicomputers) through cable over relatively short distances.

• A wide area network (or WAN) is an interconnected set of LANs, or the connection of PCs over a longer distance.

13




The database server is fundamental to this architecture and it’s technology is different from a file server.

• File servers store the database, but the client computers must execute all database instructions. This means that entire databases and tables may have to be transported to and from the client across the network.

• Database servers also store the database, but the database commands are also executed on those servers. The clients merely send their database commands to the server. The server only returns the result of the database command processing — not entire databases or tables. Thus, database servers generate much less network traffic.

14




The clients in the distributed database solution typically run the business logic of the information system application.

Distributed data computing advantages:• Separates data and business logic to (1) isolate each from changes

to the other, (2) make the data more available to users, and (3) retain the data integrity of centralized computing through centrally managed servers.

Distributed data computing disadvantages:• The application logic must be maintained on all of the clients.

15



Network Architectures for Client/Server Computing Distributed Data and Logic:

Referred to as three-tiered or n-tiered client/server computing. This approach distributes databases and business logic to

separate servers. Uses the same database server(s) as in the two-tiered approach. Uses an application server.

• The application server provides a transaction monitor such as to manage transactions.

• Some or all of the business logic of the application can be moved from the client to the application server.

Only the user interface and some relatively stable or personal business logic need be executed on the clients.

16



Network Architectures for Client/Server Computing Distributed Data and Logic:

Distributed data and logic computing disadvantages:• Very complex to design and development.

• The most difficult aspect of three-tier client/server application design is partitioning.

– Partitioning is the act of determining how to best distribute or duplicate application components (data, process, and interfaces) across the network.

17



Network Architectures for Client/Server Computing The Internet and Intranets:

The Internet is an (but not necessarily ‘the’) information superhighway that permits computers of all types and sizes, all over the world to exchange data and information using standard languages and protocols.

An intranet is a secure network, usually corporate, that uses Internet technology to integrate desktop, workgroup, and enterprise computing into a single cohesive framework.

• The intranet provides management and users with a common interface to applications and information

18



Network Architectures for Client/Server Computing The Internet and Intranets:

Java is a cross-platform programming language designed specifically to exploit the Internet standards.

• Java applets (modular software components) are stored on an Internet or intranet server and downloaded to the client when they access the application.

• Java applets can execute on any client computing platform. A network computer (or NC) is designed to only run Internet-

based applications (such as web browsers and Java applets).• The NC (also called a thin client) is simpler, and much cheaper

than personal computers (increasingly called a fat client).

19



Network Architectures for Client/Server Computing The Role of Network Technologies:

The well designed network provides connectivity and interoperability.

• Connectivity defines how computers are connected to “talk” to one another.

• Interoperability is an ideal state in which connected computers cooperate with one another in a manner that is transparent to their users (the clients).

• Network topology describes how a network provides connectivity between the computers on that network.

20


Data and DB process on server

All business logic on the mainframe server

All data on the mainframe server

Business logic on application server

User Interface on the PC Client

Network

Logic & user interface on PC

Network

Data on DB process on Server

User interface on the PC client

Network Network

Some logic on Intranet Server

Data on database server

Internal user interface on PC

Network

Secure intranet provides access

to data, logic, and interfaces

Distributed Presentation

Distributed Data (2-tier)

Distributed Data & Logic (3-tier)

Internet and Intranet

Some logic on Internet Server

External user PC client

Internet Connection provides access to

interfaces and some logic

Secure Gateway to protect applications

and data

Connection to outside

world

Secure connection to database

server

21




The Bus network topology:• A direct point-to-point link between any two computer systems.

• The simplest network topology.

• The network can contain mainframes, minicomputers (or mid-range computers), personal computers, and dumb and intelligent terminals.

• To completely connect all points between n computers, you would need n times (n-1)/2 direct paths.

• Only one computer can send data through the bus at any given time.

22




The Ring network topology:• Connects multiple computers and some peripherals into a ring-like

structure.• Each computer can transmit messages, instructions, and data (called

packets) to only one other computer (or node on the network). • Every transmission includes an address. • When a computer receives a packet, it checks the address and if the

packet’s address is different than the computer’s address, it passes it on to the next computer or node.

• Ring networks generally transmit packets in one direction; therefore, many computers can transmit at the same time to increase network throughput.

23




The Star network topology:• Links multiple computer systems through a central computer.

• The central computer does not have to be a mainframe or minicomputer.

• Central computer could be an application server that manages the transmission of data and messages between the other clients and servers (as in the n-tier model).

24




The Hierarchical network topology:• Can be thought of as a multiple star network, where the

communications processors are arranged in a hierarchy.

• The top computer system (usually a mainframe) controls the entire network.

All network topologies operate according to established network protocols that permit different types of computers to communicate and interoperate.

25



Data Architectures for Distributed Relational Databases

The underlying technology of client/server computing has made it possible to distribute data without loss of centralized control. This control is being accomplished through distributed

relational databases.• A relational database stores data in a tabular form. Each file is

implemented as a table. Each field is a column in the table. Each records in the file is a row in the table. Related records between two tables are implemented by intentionally duplicating columns in the two tables.

• A distributed relational database distributes or duplicates tables to multiple database servers (and in rare cases, clients).

26




The software required to implement distributed relational databases is called a distributed relational database management system. A distributed relational database management system (or

distributed RDBMS) is a software program that controls access to, and maintenance of the stored data. It also provides for backup, recovery and security. It is sometimes called a client/server database management system.

27




What sets a distributed RDBMS apart from a PC RDBMS is the database engine. The database engine is that part of the DBMS that executes

database commands to create, read, update, and delete records (rows) in the tables.

• In a PC RDBMS, the database engine that processes all database commands must execute on the client PC, even if the data is actually stored on the server.

• In a distributed RDBMS, the database engine that processes all database commands executes on the database server.

28




True data distribution partitions data to one or more database servers. Entire tables can be allocated to different servers, or subsets of

rows in a table can be allocated to different servers. An RDBMS controls access to and manages each server.

Data replication duplicates data on one or more database servers. Entire tables can be duplicated on different servers, or subsets

of rows in a table can be duplicated to different servers. The RDBMS not only controls access to, and management of

each server database — it also ensures that updates on one server are updated on any server where the data is duplicated.

29



Interface Architectures - Inputs, Outputs, & Middleware

Batch Input/Output: In batch processing, transactions are accumulated into batches

for periodic processing. • The batch inputs are processed against master files or databases.

• Transaction files or databases may also be created or updated by the transactions.

• Most outputs tend to be generated to paper or microfiche on a scheduled basis.

30



Interface Architectures - Inputs, Outputs, & Middleware On-line Processing:

The majority of systems have slowly evolved from batch processing to on-line processing.

On-line systems provide for a conversational dialogue between user and computer.

Business transactions and inquiries are often best processed when they occur.

• Errors are identified and corrected more quickly. • Transactions tend to be processed earlier since on-line systems

eliminate the need for batch data file preparation. On-line methods permit greater human interaction in decision

making, even if the data arrives in natural batches.

31




Remote Batch: Remote batch combines the best aspects of batch and on-line

I/O. Distributed on-line computers handle data input and editing. Edited transactions are collected into a batch file for later

transmission to host computers that process the file as a batch. Results are usually transmitted as a batch back to the original

computers.

32




Keyless Data Entry: Keying errors have always been a major source of errors in

computer inputs (and inquiries). In batch systems, keying errors can be eliminated through

optical character reading (OCR) and optical mark reading (OMR) technology.

The real advances in keyless data entry are coming for on-line systems in the form of auto-identification systems.

• Bar coding systems (similar to universal product code systems that are commonplace in the grocery and retail industries) are widely available for many modern applications.

33




Pen Input: Some businesses use this technology for remote data

collection.• For example, UPS.

A promising technology is emerging in the form of handheld PCs (HPCs).

• Similar to personal organizers and personal data assistants, these HPCs offer greater compatibility with desktop and laptop PCs.

• Based on Microsoft’s Windows CE operating system, they can be programmed to become disconnected clients in a client/server application.

34




Graphical User Interfaces: GUI technology has become the user interface of choice for

client/server applications. GUIs do not automatically make an application better. Poorly designed GUIs can negate the alleged advantages of

consistent user interfaces.

35




Graphical User Interfaces: Most users interface with the Internet via a client software tool

called a browser. • The browser paradigm is based on hypertext and hyperlinks.

– Hypertext are keywords that are clearly highlighted as a link to a new page of information.

– Hyperlinks are links from graphics, buttons, and areas that link to a different page of information.

• These links may it easy to navigate from page-to-page and application-to-application.

36




Electronic Messaging and Work Group Technology: Information systems are being designed to directly incorporate

the electronic mail.• For example, Microsoft Outlook and Exchange Server and

IBM/Lotus Notes allow for the construction of intelligent electronic forms that can be integrated into an application.

37




Electronic Data Interchange: Businesses that operate in many locations and businesses that

seek more efficient exchange of transactions with their suppliers and/or customers often utilize electronic data interchange.

• Electronic data interchange (EDI) is the electronic flow of business transactions between customers and suppliers.

With EDI, a business can eliminate its dependence on paper documents and mail, plus dramatically reduce response time..

Various EDI standards exist for the standardized exchange of data between organizations within the same industry.

38




Imaging and Document Interchange: Similar to EDI except that the actual images of forms and data

are transmitted and received. It is particularly useful in applications in which the form

images or graphics are required. (insurance industry)

39




Middleware: Information systems must also interface to other information

systems.• System integration is the process of making heterogeneous

information systems (and computer systems) interoperate. A key technology used to interface and integrate systems is

middleware.• Middleware is utility software that serves to interface systems

built with incompatible technologies. Middleware serves as a consistent bridge between two or more technologies. It may be built into operating systems, but it is also frequently sold as a separate product.

40




Selecting User and System Interface Technologies: The preferred or approved user and system interface

technologies may be specified as part of the Interface architecture.

An organization may leave interface technologies as a decision to be made on a project-by-project basis.

An organization may establish macro guidelines for interfaces and leave the micro decisions to individual projects.

41



Process Architecture - The Software Development Environment and System Management

The PROCESS architecture of an application is defined in terms of the software languages and tools that will be used to develop the business logic and application programs. This is expressed as a menu of choices since different software

development environments (SDEs) are suited to different applications.

• A software development environment is a language and tool kit for constructing information system applications. They are usually built around one or more programming languages such as COBOL, Basic, C or C++, Pascal, Smalltalk, or Java.

42




SDEs for Centralized Computing & Distributed Presentation: The software development environment for centralized

computing consists of:• An editor and compiler, usually COBOL, to write programs.

• A transaction monitor, usually CICS, to manage on-line transactions and terminal screens.

• A file management system, such as VSAM, or a database management system, such as DB2.

43




SDEs for Centralized Computing & Distributed Presentation: The personal computer brought many new COBOL

development tools down to the mainframe. • A PC-based COBOL SDE provided the programmer with more

powerful editors, and testing and debugging tools at the workstation level.

• A programmer could do much of the development work at the PC level, and then upload the code to the central computer for system testing, performance tuning, and production.

• The SDE could be interfaced with a CASE tool and code generator to take advantage of process models developed during systems analysis.

44




SDEs for Centralized Computing & Distributed Presentation: SDEs provide tools to develop distributed presentation

client/server.• The Micro Focus Dialog Manager provided COBOL Workbench

users with tools to build Windows-based user interfaces that could cooperate with the CICS transaction monitors and the mainframe COBOL programs.

45




SDEs for Two-Tier Client/Server: The SDE for two-tiered client/server applications (also called

distributed data) consists of a client-based programming language with built-in SQL connectivity to one or more server database engines.

SDEs provide the following:• Rapid application development (RAD) for quickly building the graphical

user interface that will be replicated and executed on all of the client PCs.

• Automatic generation of the template code for the above GUI and associated system events (such as mouse-clicks, keystrokes, etc.) that use the GUI. The programmer only has to add the code for the business logic.

46




SDEs for Two-Tier Client/Server: SDEs provide the following: (continued)

• A programming language that is compiled for replication and execution on the client PCs.

• Connectivity (in the above language) for various relational database engines, and interoperability with those engines. Interoperability is achieved by including SQL database commands (to, for example, create, read, update, delete, and sort records) that will be sent to the database engine for execution on the server.

• A sophisticated code testing and debugging environment for the client.

47




SDEs for Two-Tier Client/Server: SDEs provide the following: (continued)

• A system testing environment that helps the programmer develop, maintain, and run a reusable test script of user data, actions, and events against the compiled programs to ensure that code changes do not introduce new or unforeseen problems.

• A report writing environment to simply the creation of new end-user reports off a remote database.

• A help authoring system for the client PCs.

48




SDEs for MultiTier Client/Server: Unlike two-tied applications, n-tiered applications must support

more than 100 users with mainframe-like transaction response time and throughput; with 100 gigabyte or larger databases.

The SDEs in this class must provide the all of the capabilities typically associated with two-tiered SDEs plus the following:

• Support for heterogeneous computing platforms, both client and server, including Windows, OS/2, UNIX, Macintosh, and legacy mainframes and minicomputers.

• Code generation and programming for both clients and servers. Most tools in this genre support pure object-oriented languages such as C++ and Smalltalk.

49




SDEs for MultiTier Client/Server: The SDEs in this class must provide the all of the capabilities

typically associated with two-tiered SDEs plus the following: (continued)

• A strong emphasis on reusability using software application frameworks, templates, components, and objects.

• Bundled mini-case tools for analysis and design that interoperate with code generators and editors.

• Tools to help analysts and programmers partition application components between the clients and servers.

• Tools to help developers deploy and manage the finished application to clients and servers. This generally includes security management tools.

50




SDEs for MultiTier Client/Server: The SDEs in this class must provide the all of the capabilities

typically associated with two-tiered SDEs plus the following: (continued)

• Ability to automatically ‘scale’ the application to larger and different platforms, client and server. This issue of scalability was always assumed in the mainframe computing era, but is relatively new to the client/server computing era.

• Sophisticated software version control and application management.

51




SDEs for Internet and Intranet Client/Server: Most of these rapid application development tools are built

around three core standard technologies:• HTML (Hypertext Markup Language) — the language used to

construct world wide web pages and links.• CGI (Computer Graphics Interface) — a language for publishing

graphical world wide web components and links• Java — a general purpose programming language for creating

platform-independent programs and applets that can execute across the world wide web.

These SDEs can create both Internet, intranet, and non-Internet/intranet applications.

52




System Management: Client/server computing applications usually require one or more

of the following common process development and management tools:

• Transaction Processing (TP) Monitors — software that ensures that all of the data associated with a single business transaction is processed as a single transaction amongst all of the parallel business transactions that may be in the system at the same time.

• Version Control and Configuration Managers — software that tracks on-going changes to software that is usually developed by teams of programmers. The software also allows management to rollback to a prior version of an application if the current version encounters unanticipated problems.

53


Application Architecture Strategies & Design Implications

The Enterprise Application Architecture Strategy In this strategy, the organization develops a enterprise wide

information technology architecture to be followed in all subsequent information system development projects.

This IT architecture defines the following: The approved network, data, interface, and processing

technologies and development tools (inclusive of hardware and software; and clients and servers).

A strategy for integrating legacy systems and technologies into the application architecture.

An on-going process for continuously reviewing the application architecture for currency and appropriateness.

54



The Enterprise Application Architecture Strategy This IT architecture defines the following: (continued)

An on-going process for researching emerging technologies and making recommendations for their inclusion in the application architecture.

A process for analyzing requests for variances from the approved application architecture. (You may recall that SoundStage received such a variance to prototype object technology in the member services system project.)

55



The Tactical Application Architecture Strategy In the absence of an enterprise wide application architecture, each

project must define its own architecture for the information system being developed.

The developers usually have somewhat greater latitude in requesting new technologies, but they must be defended and approved as feasible.

IT feasibility usually includes the following aspects: Technical feasibility — This can either be a measure of a

technology’s maturity, or a measure of the technology’s suitability to the application being designed, or a measure of the technology’s ability too work with other technologies.

56



The Tactical Application Architecture Strategy IT feasibility usually includes the following aspects: (continued)

Operational feasibility — This is a measure of how comfortable the business management and users are with the technology, and how comfortable the technology managers and support personnel are with the technology.

Economic feasibility — This a measure of both whether or not the technology can be afforded, and whether it is cost effective, meaning the benefits outweigh the costs.

57



Build versus Buy Implications One of the most fundamental software decisions in any project is

build versus buy — should we design and build the software in-house, or should we purchase the software as a package? The packages are referred to as COTS — commercial of the

shelf. Many organizations have made an enterprise IT decision to always

purchase those applications that do not significantly add competitive advantage to the business. Typically, these include human resources (and payroll),

financial systems, and systems subject to frequent regulatory change (such as college financial aid).

58



Build versus Buy Implications The purchase of application software does not invalidate systems

analysis and design, but it does, however, change the methodology and project in the following ways: Alternative application software packages must be analyzed

against the user requirements, and any unfilled business requirements must be identified.

Options and preferences within the chosen software package must be analyzed and selected. (Most packages allow various one-time and on-going customization.)

Business processes and documents must be analyzed and redesigned to interoperate with the selected software.

59



Build versus Buy Implications The purchase of application software does not invalidate systems

analysis and design, but it does, however, change the methodology and project in the following ways: (continued) Transition processes must be analyzed and designed to import

data from legacy systems into the new software’s files and databases.

The application software’s interfaces to other information systems must be analyzed and designed.

Any unmet business requirements are subject to analysis and design as extensions to the chosen software package

Purchased application software may also be subject to any IT architectural standards adopted by a business.

60


Modeling Application Architecture & Information System Processes

Physical Data Flow Diagrams DFDs can also be used to model the physical (meaning

‘technical’) design of the system. Physical data flow diagrams model the technical and human

design decisions to be implemented as part of an information system. They communicate technical and other design constraints to those who will actually implement the system—in other words, they serve as a technical blueprint for the implementation.

• Physical DFDs use the same shapes and connections as logical DFDs: processes, external agents, data stores, and data flows. Only the naming standards (and a few new rules) are changed to extend the language to document technology and design decisions.

61


Account Register (Quicken File)

Bank

Reconcile account balances (Quicken)

Verify balances and transactions

(You)

Monthly Statement

(Printed Form)

Beginning and Ending Balance (Windows Dialog Box)

Cleared Transactions

(Window Checkboxes)

Reconciliation Report (Window and/or Printed Report)

Transactions and

Balances (Read)

Revised Transactions (Create, Delete, Update)

Cleared Transactions (Update)

CreditorPlan payment of

the bill (You)

Bill (Paper Invoice)

Bill (Electronic Invoice)

Transaction (Create, Delete, or Update)

Pay a bill

Time to pay a billTransaction Due

(Read)

Schedule a payment (Quicken)

Memorized and Scheduled Transactions (Quicken File)

Memorized or Scheduled Transaction (Create, Delete, or Update)

Reusuable Transaction

Details (Read)

Paid Transaction (Update)

Check (Printed)

Check (Hand)

Check (Electronic

Fund Transfer)

Make a deposit or withdrawal at the

bank (You)

Record deposit or withdrawal

Make a withdrawal

(ATM)

ATM Receipt (ATM printout)

Teller Receipt (Printout Form)

Transaction (Create, Update)

You

Deposit Slip (Form)

Withdrawal (verbal)

You

Customer PIN (bank card) and

Withdrawal Info (keypad)

Direct Deposit

Reminder (read)

This diagram is intentionally incomplete and oversimplified

62



Physical Data Flow Diagrams Physical Processes:

Recall that processes are the key shapes on any DFD. • A physical process is either (1) a processor, such as a client PC,

network server, or robot; or (2) specific work or actions to be performed on incoming data flows to produce outgoing data flows. In the latter case, the physical process must clearly designate which person(s) or what technology(s) will be assigned to do the work.

63




There are two elements to physical data flow diagrams:• Logical processes are frequently assigned to specific physical

processors such as clients, servers, or other devices in a computer network. To this end, we might draw a physical DFD called a network topology data flow diagram for the information system.

• Subsequently, logical processes are usually implemented as one or more physical processes.

64




• Some logical processes must be split into multiple physical processes for the following reasons:

– To split the process into that portion performed by a person and that portion performed by the computer.

– To split the process into that portion to implemented with one technology, and that portion to be implemented with a different technology.

– To show multiple, different implementations of the same logical process (such as processing a paper order versus processing a phone order).

– To add processes that are necessary to implement audit and control requirements, or handle exceptions.

65




Process names use the action verb + object clause convention, however, the name is preceded or followed by an implementation method. The format is:

• implementation method : action verb + object clause

• action verb + object clause : implementation method If a logical process is to be implemented partially by people

and partially by software, it must be split into separate physical processes and appropriate data flows must be added between the physical processes.

• The name of a physical process to be performed by people, not software, should indicate who will perform that process.

ID# (opt)

action verb + object clause

implementation method

ID# (opt)

implementation method : action verb + object

clause

ID# (opt)

action verb + object clause

(implementation method)

66




For computerized processes, the implementation method is, in part, chosen from one of the following methods:

• A purchased software package, possibly to be selected.

• A productivity or utility program.

• An existing application program from a program library.

• A program to be written.

67




The number of processes on a physical DFD will usually be greater than the number of processes on its equivalent logical DFD.

• Processes may be added to reflect data flow collection, filtering, forwarding, preparation, business controls—all in response to the implementation target that has been selected.

• Some logical processes may be split into multiple physical processes to reflect portions of a process to be done manually versus by a computer, to be implemented with different technology, or to be distributed to clients, servers, or different host computers.

68



Physical Data Flow Diagrams Physical Data Flows:

Recall that all processes have at least one input and one output data flow.

A physical data flow represents the planned implementation of an input to or output from a physical process. It can also indicate database action such as create, delete, read, or update a record. It can also represent the import of data from, or the export of data to another information system across a network. Finally, it can represent the data flows data between two modules or subroutines within the same program.

69




Physical data flow names use one of the following general formats:

• implementation medium : data flow name

• data flow name : implementation method For data transmitted across a network, the implementation

media should indicate the file transfer protocol to be used. For data transmitted between processes that are to be part of

the same program, you could specify parameters and variables to be passed between the program modules.

implementation method :

data flow name

data flow name :

(implementation method)

70




Physical DFDs must also indicate any data flows to be implemented as business forms.

• Business forms frequently use a multiple (carbon or carbonless) copy implementation.

• At some point in processing, the different copies are split and travel to different manual processes.

– This is shown on an physical DFD as a diverging data flow.

– Each copy should be uniquely named.

71




Most logical data flows are carried forward to the physical DFDs.

• Some may be consolidated into single physical data flows that represent business forms.

• Some may be split into multiple flows as a result of having split logical processes into multiple physical processes.

• Some may be duplicated as multiple flows with different technical implementations.

72



Physical Data Flow Diagrams Physical External Agents:

External agents are carried over from the logical DFD to the physical DFD unchanged.

• Because, by definition, external agents were classified during systems analysis as outside the scope of the systems and, therefore, not subject to change.

• Only a change in requirements can initiate a change in external agents.

73



Physical Data Flow Diagrams Physical Data Stores:

Each data store on the logical DFD now represents a data entity on a normalized entity relationship diagram.

Most physical data stores represent a single file or a single database or table in the database. Additional physical data stores may be added to represent temporary files or batches necessitated by physical processes.

The name of a physical data store uses the following format:• file or database implementation method : file, database, or table

name

• file, database, or table name : file or database implementation method

database name (implementation

method)

implementation method:

database name

74



Physical Data Flow Diagrams Physical Data Stores:

Some designs require that temporary files be created to act as a queue or buffer between processes.

• Such files are documented in the same manner except that their name should include some indication of their temporary status.

A design may also include non-computerized files.• The storage mechanism name replaces the file organization.

75



System Flowcharts Before the popularity of DFDs, systems flowcharts were a

popular tool for modeling design decisions. System flowcharts are diagrams that show the flow of control

through a system while specifying all programs, inputs, outputs, and file/database accesses and retrievals.

The American National Standards Institute (ANSI) has established certain symbols that have been widely used in the computer industry to describe the flow of process control in systems.

System flowcharts are supposed to be the basis for communication between systems analysts, end-users, applications programmers, and computer operators.

76



System Flowcharts System Flowchart Symbols:

System flowchart symbols can be conveniently classified into six subsets:

• There are four symbols for processing:

– the computer program (to be written)

– the library program (that already exists—possibly a utility program)

– the manual operation (indicating who and/or what—the symbol is also used as a start or finish symbol in a flowchart)

– the auxiliary operation (used to indicate operations performed by other office equipment)

77




System flowchart symbols can be conveniently classified into six subsets: (continued)

• There are four symbols for batch input:

– the source document or form (from which data will be keyed into the system)

– the key-to-punched-card (a dated and increasingly rare batch input medium)

– the key-to-disk (KTD) or key-to-tape (KTT)

– the optical character (or mark) document (which could also be used for EDI and imaged documents)

78





• Batch output forms or files are represented by a single printed output symbol.

– The symbol could also be used for microfiche output.

• System flowcharts show only those files and databases stored on computers.

79





• There are only two symbols: the tape file, and the disk file or database.

– Because tape files are always sequential, updates always occur in pairs—an original file is input to a program and a new file is produced by the program.

– Disk files need not be duplicated since reads and writes are processed against the same copy of the file or database.

– Databases serve to integrate many files., therefore they can be depicted as one integrated symbol or as one symbol per file, record type, or table—depending on what level of detail you are trying to depict.

80





• Most designers show only the net inputs and outputs and exclude the on-line dialogue that gets you to those inputs and outputs.

– There are two on-line symbols: the on-line input and the on-line output.

• There are a number of miscellaneous symbols in the ANSI standard.

– The most important of these symbols is the comment.

– It may be connected via a dashed line to any other symbol to add information about such things as timing, security, or instructions.

81



System Flowcharts Reading System Flowcharts:

The symbols are connected by one of three lines: • A single-ended arrow (indicating either the sequence of activities or

processing in the system or a read-only or write-only access to a file or database).

• A double-ended arrow (indicating read-write operations against files and databases).

• A jagged-double-ended arrow (indicating on-line dialogue or data flow).

Unlike DFDs, connections on system flowcharts are not labeled or named.

Symbols and connections are combined in classic input-process-output patterns to document the design of a system.

82



CASE for Physical DFDs and Flowcharts Most CASE products support DFDs, but don’t distinguish between

logical and physical models. Some CASE users simply modify the logical DFDs that they

created during systems analysis. The problem with that approach is that you are overwriting the

logical DFDs—the requirements themselves! A better approach is to copy the logical models and then

transform the copies into physical DFDs.

83


Designing the Application Architecture & the Information

System Processes Drawing Physical DFDs

Physical DFDs document the high-level, general design of the new system. An acceptable design results in: A system that works. A system that fulfills user requirements (specified in the logical

DFDs). A system that provides adequate performance (throughput and

response time). A system that includes sufficient internal controls (to eliminate

human and computer errors, ensure data integrity and security, and satisfy auditing constraints).

A system that is adaptable to ever-changing requirements and enhancements.

84




A single physical DFD, or a set of physical DFDs can be drawn for the target system.

The FAST methodology calls for the following: A physical data flow diagram should be developed for the

network topology. For each processor on the above model, a physical data flow

diagram should be developed to show those event processes that will be assigned to that processor.

85




The FAST methodology calls for the following: (continued) For all but the simplest event processes, they should be

factored into design units and modeled as a single physical data flow diagram.

• A design unit is a self-contained collection of processes, data stores, and data flows that share similar design attributes. A design unit serves as a subset of the total system whose inputs, outputs, files and databases, and programs can be designed, constructed, and unit tested as a single subsystem.

86



System Processes Prerequisites

The prerequisites to creating physical DFDs include: A logical data model. Logical process models. Logical network model. (optional) Repository details for all of the above.

87



System Processes Prerequisites

Given the previous models and details, data and processes can be distributed to create a general design. The general design will normally be constrained by one or

more of the following:• Architectural standards that predetermined the choice of database

management systems, network topology and technology, user interface(s), and/or processing methods.

• Project objectives that were defined at the beginning of systems analysis and refined throughout systems analysis.

• Feasibility of chosen or desired technology and methods.

88



System Processes The Network Topology

The first physical DFD to be drawn is the network topology DFD. A network topology DFD is a physical data flow diagram that

allocates processors (clients and servers) and devices (e.g., machines and robots) to a network and establishes (1) the connectivity between the clients and servers, and (2) where users will interact with the processors (usually, only the clients).

Network topology DFDs they show highways over which data flows may travel in either direction.

89



System Processes The Network Topology

Network topology DFDs indicate the following: Servers and their physical locations. Clients and their physical locations. Processor Specifications. Transport protocols.

The network topology DFD can be used to either design a computer network or to document the design of an existing computer network.

90



System Processes Data Distribution and Technology Assignments

The goal of this step is to distribute data stores to the network processors. The required logical data stores are already known from

systems analysis — as data stores on the logical DFDs or as entities on the logical ERDs.

The following are possible distribution options. Store all data on a single server. Store specific tables on different servers. Store subsets of specific tables on different servers. Replicate (duplicate) specific tables or subsets on different

servers.

91



System Processes Data Distribution and Technology Assignments

The reasons to distribute data storage are as follows: Some data instances are of local interest only. Performance can often be improved by subsetting data to

multiple locations. Some data needs to be localized to assign custodianship of that

data. Data distribution decisions can be very complex—normally the

decisions are guided by data and database professionals

92



System Processes Process Distribution and Technology Assignments

Information system processes can now be assigned to processors as follows: For single-tiered client/server systems, all of the logical event

diagrams are assigned to the server. For two-tiered client/server systems, all of the logical event

diagrams are assigned to the client. For three-tiered client/server systems, you must closely

examine each event’s primitive (detailed data flow diagram.• In general, data capture and editing is assigned to clients, and

other business logic is assigned to servers.

93



System Processes Process Distribution and Technology Assignments

After partitioning, each physical DFD corresponds to a design unit for a given business event. For each of these design units, you must assign an

implementation method, the SDE that will be used to implement that process.

You must also assign implementation methods to the data flows.

94



System Processes The Person/Machine Boundaries

The last step of process design is to factor out any portion of the physical DFDs that represent manual, not computerized processes. This is sometimes called “establishing a person/machine

boundary.” Establishing a person/machine boundary becomes complex when

the person/machine boundary cuts through a logical process—in other words, part of the process is to be manual and part is to be computerized.

95


Summary

Introduction General System Design Information Technology Architecture Application Architecture Strategies &

Design Implications Designing the Application Architecture &

the Information System Processes