FREE online courses on Information Technology - Chapter 9 INFORMATION
TECHNOLOGY ARCHITECTURES - MATCHING DESIGN TO AN ARCHITECTURE
In many situations, an application will have to run on a existing architecture
because that is what the organization is willing or able to provide. In this
case, the guidelines below can be used, but they must be modified to fit
organizational constraints. Sometimes, however, the architecture can be modified
to provide the appearance of a new system. It is very expensive to redesign
large transactions processing systems, and some firms have been updating the
design to these systems by hiding the old system behind a new PC interface.
One large electronics manufacturer has a major internal transactions processing
system that literally controls its entire business. The system was developed in
the 1960s and runs on mainframes. Users have complained about the old technology
and want a more flexible system. It would cost millions of dollars- possibly
hundreds of millions-to redesign the system. The firm is thinking of replacing
the present terminals with personal computers and using the PCs to develop a new
interface. The existing transactions processing and database system would be
left intact.
In this section we suggest some guidelines for considering the interaction
between hardware and software architecture and systems design. The type of
architecture will influence design. As systems designers we have radically
different choices depending on whether we plan to implement on a LAN or a
mainframe with terminals. Some basic guidelines are as follows:
1.
Start sizing an architecture at the smallest and least expensive
option. Can a suggested application be completed on a PC with packages? If there
are multiple users accessing a central database, the answer is probably no. The
same is true if there are too many simultaneous users. A PC will probably run
Windows 95 or Windows NT and will make use of a popular “suite” of office
applications that include a spreadsheet, word processor, presentation graphics
program, and database management system.
2.
If a stand-alone PC is not adequate, can a system be developed using a
LAN? The LAN can accommodate multiple users who can share data files. The same
software as above is appropriate but the server will probably run Windows NT. At
some point, there may be too many users for the LAN, or more likely there will
be too high a volume of activity for servers. It is also possible that the
system must handle a large volume of transactions, in which case the LAN is not
currently the best alternative.
3.
The Client-server architecture featuring workstations or midrange
computers as the server is a cost-effective alternative for many applications as
long as the system can handle the processing load. The server here may run NT or
Unix, while the clients run Windows 95. User applications may be developed using
the PC database management package, or a midrange DBMS like Oracle or Sybase.
4.
Midrange computers have the capacity to handle a large number of
transactions and large databases and can control large communications networks.
You may program these systems in the language of a DBMS or in a language like
C++.
5.
Mainframes can handle large volumes of transactions and huge
databases. They, too, excel at controlling large communications networks. If the
mainframe applications exists already, then you will probably have little choice
in the programming language and operating system. However, if the application is
new, and you are using a new, large computer, you may be able to use Unix as the
operating system and c or a 4GL as an applications development language.
6.
If users need local processing power and discretionary use of
computers, a mixed network including mainframes and PCs is likely. This
configuration is also popular when the organization has a large number of legacy
computers and applications; networking them together provides users with
features they need and widespread data access.
7.
For providing links with customers, suppliers and others, consider the
option of using the internet and World Wide Web.
A fundamental aspect of design is where to keep data and
where to update it. In the airline CRS, all data are maintained centrally
because of the need for instantaneous information and the frequency of update.
In the broker workstation system, the users do virtually no updating of the data
distributed from the ticker plant. Because fast response is important for
brokers, it is a good design decision to duplicate the data locally. The price
server in each office has identical information that it accepts from the
satellite dish on the roof.
In other systems the trade-offs will differ. The designer has to balance
response time, updating frequency, the need for up-to-date information, and the
cost of duplicate storage. If there are to be copies of the data, we must also
be concerned with the integrity of all copies. Does each copy have to updated
whenever the master record changes? In the broker workstation, a constant stream
of data updates the local file server. In other applications, it may be adequate
to refresh local databases less frequently.
