Client/Server Architecture Promises Radical Changes


Copyright 1991 CAUSE From _CAUSE/EFFECT_ Volume 14, Number 1, Spring 
1991. Permission to copy or disseminate all or part of this material is 
granted provided that the copies are not made or distributed for 
commercial advantage, the CAUSE copyright and its dateappear, and notice 
is given that copying is by permission of CAUSE, the association for 
managing and using information resources in higher education. To 
disseminate otherwise, or to republish, requires written permission. For 
further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, 
Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu


            CLIENT/SERVER ARCHITECTURE PROMISES RADICAL CHANGES
                      by Grey Freeman and Jerry York

************************************************************************

Grey Freeman is Program Director, Information Technology Management
service, at the Gartner Group. Previously he was Vice President,
Information Services, responsible for management of the company's
computing systems, voice and data communications facilities, and other
data processing activities which support company operations. Before
joining Gartner Group, he was Director of the Yale University Computer
Center, which provided general computing services to the academic
community. While at Yale, he headed the project that developed the
widely used Yale ASCII Terminal Communications System. He is a co-
founder of BITNET.

Jerry York is Vice Provost for Computing and Information Technologies at
the University of Cincinnati where he is responsible for computing for
instruction, research, administration, and hospital and medical
requirements. In addition, he is responsible for all data communications
and has led a number of task forces in Ohio, a state known for its very
successful cooperative initiatives. He currently serves as the Vice
Chair of the CAUSE Board of Directors.

************************************************************************

ABSTRACT: Client/server architecture is the latest paradigm for the 
delivery of computer applications. It has emerged in response to the 
proliferation of microcomputers and local area networks (LANs), and will 
have far-reaching implications. Not only will it radically change the 
way computer applications are developed and used during this decade, it 
will also require restructuring of central information technology (IT)
organizations if they are to remain viable participants in the
deployment of information technology on the campus. This article
discusses the emergence of the client/server paradigm, aspects of the
transition to its widespread adoption, the applicability of the model in
academic institutions, and its implications for campus IT organizations.


Architectures for computing applications have evolved as have the
internal architectures of computers themselves. Propelled by the
opportunities and challenges posed by advances in the underlying
hardware technology and increases in the magnitude and sophistication of
the business problems to be addressed, each step along the path--from
batch to online to database transaction processing and, now, to
client/server--has brought with it not only exciting new capabilities,
but also a higher level of complexity to be understood and managed
effectively. (See Exhibit 1 for attributes of the generations of
computing environments.)

[FIGURE NOT AVAILABLE IN ASCII TEXT VERSION]

What does "client/server" mean?

The client/server model is an architecture for the kind of
multivendor, networked information systems environment that promises to
become broadly accepted in the 1990s. As with any emerging concept, it
has a variety of working definitions, depending on the perspective from
which it is viewed.

For the end user, the client/server model means the use of a
personal computer as an "agent" to gain access, through a consistent
user interface, to a wide variety of resources without knowing about the
path to them, the hardware or software characteristics of the platform
on which they function, or the specific commands needed to interact with
each one. The user simply requests an action and the "client" system
decides whether it is capable of performing the task and, if not, passes
it through the network to an appropriate "server."

For the systems designer, in its basic form the client/server model
breaks each application into two parts, the "client" task and the
"server" task, with each part assigned to the system component best
suited to performing it. The client task, which is usually performed on
the user's desktop system, acts as the agent for the user, i.e., it
handles the interface between the user and the rest of the system,
including managing the network dialogue and everything to do with the
keyboard, mouse, and screen presentation. It can also perform various
functions on behalf of the application that previously required
resources on the host, such as data validation, query formulation, or
scrolling through or printing the results of a query. The server task,
which is where the "work" actually gets done, is performed wherever
there are adequate data and computational resources--on a central
mainframe, departmental minicomputer, multiuser microcomputer, or even
the same desktop system that also handles the client task. Once the
server performs its task, it passes the result back to the requesting
client and thence to the user.

In more advanced versions of the client/server model, the server
task may be broken into subtasks, which are each assigned to the most
suitable servers. Also, a server may in turn act as a client, requesting
other servers to perform tasks for it. Ideally, these tasks and subtasks
are all allocated automatically and dynamically to servers to provide
optimal responsiveness. (Figure 1 graphically depicts the difference
between traditional and client/server architecture systems.)

What is most definitive--and important--about the client/server model
is that the assignment of tasks to servers is transparent to the user
(and, by and large, to the client task as well), i.e., the user simply
indicates what is to be done, and the client/server "system" determines
how and where to do it. In a comparable way, the server, although it may
need to authenticate the identity of the requesting user, does not need
to know the path from, or the characteristics of, the client; it simply
receives requests, processes them, and returns the results.

The personal computer was the harbinger of the client/server model.
It transformed the population of frequent computer users--data entry
operators, who spend an entire workday at a terminal connected to a
single application, have been joined by a multitude of middle- and even
upper-level management knowledge workers who use personal computers to
access a wide variety of applications to do their jobs. The arrival of
the microcomputer also inverted Grosch's Law1 and confronted the systems
designer and asset manager with an opportunity that just couldn't be
passed up--a chance to move part of the processing for applications off
comparatively expensive mainframes onto "cheap" personal computers.

If the personal computer was the harbinger, the local area network
(LAN) was the catalyst--neither adding nor changing information, but
essential to the process. From its humble beginnings as a means of
connecting personal computers to shared printers and disks, the LAN,
together with the wide area network (WAN), is becoming the medium to
ensure that any intelligent device in the enterprise can communicate
with any other. The hierarchical networks of point-to-point links from
terminal to processor and thence to other processors have given way to
logically "flat" networks, and master-slave control has been replaced
with peer-to-peer relationships.

Prior to the emergence of the client/server model, application
systems may have spanned multiple tiers, but they were tightly coupled,
self-contained and centrally defined, acquired (often from a single
hardware vendor) and managed as a single unit. The applications set was
specific to the mainframe or middle-tier processor family. Each
component was custom-built to work with, and often only with, the
specific application. The structure of the application was essentially
static between "reconfigurations," major events that could take a system
out of service for a period of time.

Contrast this with an environment where all users tie into a
network which in turn provides access to a great variety of capabilities
or functions, without regard to the provider platform's architecture or
vendor (a particularly important characteristic in the academic
community where pressures for autonomy and local control remain strong).
The key is access for all users to all capabilities (given appropriate
attention to security). Connections between components of a particular
application are established dynamically, at a minimum for each session
and possibly to satisfy each request. Thus the structure of the "system"
is constantly changing and cannot be predicted. This demands consistent
interfaces between all components.

The client/server concept emerged, not as a full-blown architecture
waiting for technology to make it feasible, but rather out of the need
to bring order to, and capitalize on the capabilities provided by, this
new computing environment. At the moment, the industry is still "out
ahead of its blockers"--the hardware is available to assemble complex
webs of powerful workstations and servers, but it is not yet matched by
the standards and the software technology for using and managing these
resources productively.

What will it take to make the transition?

Applications that cooperatively run on multiple platforms will open
a new chapter in system design, and it is likely that these designs will
become an architectural standard in the 1990s. In fact, by the mid-
1990s, client/server will likely be the mainstream computing environment
for many Fortune 500 companies and will likely have gained ground in
higher education as well.

As much as the arrival and evolution of client/server environments
will depend on the availability of technology, even more important will
be the international community's agreement on standards, a critical mass
of development tools, and vendor consensus around a cluster of de facto
standards. Mainstream desktop productivity applications will most likely
start to appear by 1992, as standards initiatives and enabling
technologies mature.

     Standards

A number of standards are essential to the realization of the
client/server environment. For example, networking standards (such as
Ethernet, TCP/IP, Token Ring) ensure that the workstations and the
servers can send and receive data over the network. A stable, standard
network operating system for LANs is required to attract vendors to this
architecture. Open standards will be required to enable interoperability
across heterogeneous platforms. The underlying communications
infrastructure for cooperative processing will depend on low-level
protocols that are nearing maturity. These include IBM's APPC,
Microsoft's LAN Manager, and DEC's DECnet, all of which promise to be
well established by 1992. However, heterogeneous client/server
integration and interoperability as it applies to network services will
not be fully realized by the 1992 time frame. The lack of industry
standards--such as global naming, integrity, availability, 
authorization, administrative services for storage management, and 
backup--will prevent a truly heterogeneous client and server mix until 
later in the decade.

Remote procedure call (RPC) standards define the structure of the
data that enable the client and server tasks to exchange requests,
results, and status. The RPC is a critical enabler for client/server
architecture, but there is currently no single standard RPC. However,
the Open Software Foundation's landmark decision to provide a vendor-
neutral distributed computing environment (DCE) has accelerated the
standardization process and will catalyze the shift to client/server
computing. The implications of this decision are manifold, and strategic
to the industry as a whole.

SQL (structured query language) provides a standard for database
access. The SQL Access Group, a coalition of vendors formed in 1989 to
develop a working standard for SQL, has made progress toward the
definition of an SQL application programming interface and the protocol
for interoperability of heterogeneous SQL products across a network.
While IBM may remain a holdout from the SQL Access Group standards and
other vendors may develop proprietary extensions to SQL--both of which
could complicate applications deployment--it is nevertheless likely that
interoperable SQL products will be widely available by mid-1993.

Taken together, standards ensure that all the components that
constitute a particular computing environment can interoperate and that
each can be replaced as needed to meet demand and/or take advantage of
new technologies, much as one can upgrade a stereo system's tape deck,
amplifier, or speakers independently of the other components.

     Consistent user interface

As we noted, one of the duties of the client task is managing the
user interface. While it is not, per se, part of the client/server
architecture, the graphical user interface (GUI) currently in vogue has
become inextricably associated with it and therefore bears discussion
here. GUIs (such as OSF/Motif, X Windows, Microsoft Windows, IBM's
Presentation Manager, or Apple's Macintosh) provide structure through a
combination of windows, icons, a mouse, pull-down-menus, and scroll-bars
(WIMPS), and a set of techniques for manipulating the WIMPS interface
that is consistent across all applications.

The command invocation part of the GUI includes basic capabilities
(e.g., cut, paste) as standards, plus specialized features for the
unique aspects of each application. Through the menus, a user can, in
principal, discover every action that can be taken in any particular
context. These actions are usually expressed in the user's terms; the
client system spares the user the discomfort of learning arcane
commands, such as those that infest IBM's job control language, or
remembering different, often conflicting commands for each server system
in the network.

The information display portion of the GUI will be common to all
applications using a given graphical interface standard. However, what
appears in each window will depend upon the conceptual model(s) embodied
in the application software, particularly the server portion. Hence, the
user will have one conceptual model for departmental operating expenses,
another for computer-aided design, and so forth.

Thus, a GUI provides a consistent user interface across various
applications tasks, and as such will enable many users on different
client platforms to share an application, or a single user to have
access to applications across a number of different server platforms. It
is unlikely that any single desktop interface will dominate, but it is
expected that the myriad of GUIs available will converge on enough
features to permit users to navigate with pull-down menus, scroll bars,
icons, buttons, and dialog boxes regardless of the desktop hardware or
operating environment being used. Selecting a standard GUI throughout an
institution not only will improve the productivity and satisfaction of
individual users, it will leverage training and support investments as
well.

     Development methodologies, tools,
     and priorities

Applications development in a client/server environment is much
more complex than in present-day systems. The complexity will, however,
be made more manageable through the cooperation of users, information
systems managers, and vendors (including systems integration companies).
This will be especially important in new applications development, which
continues to be a major bottleneck. To overcome responsiveness problems
inherent when applications development is the exclusive purview of the
information systems (IS) department, end users will be more heavily
involved in the design and implementation of new applications. This will
provide the users with increased "ownership" in what is developed, and
the resultant understanding of the applications software structure
should be invaluable to the end users and to the institution as a whole.

This is not to say that end users will be writing or maintaining
code in some object-oriented language or even in Cobol. They may,
however, use fourth- and fifth-generation languages, expert systems, and
various kinds of "applications generators" to achieve an equivalent end
result; but even then most end users cannot (or should not) undertake
applications development on their own, especially under the multi-
vendor, networked conditions that will characterize client/server
systems. It is too easy, on the one hand, for unsophisticated end users
to fall prey to exaggerated vendor claims in selecting which application
development tools and platforms to use or, on the other hand, to wind up
"re-inventing the wheel" out of ignorance of the off-the-shelf packages
and tools that are commercially available. So the experience and
technical expertise of IS departments will be needed to guide end users
past these rocks and shoals of applications development. Some of this
guidance will come in the form of a priori standards selection by the IS
department, but most of it will be in the form of good old-fashioned
"hand-holding."

Another paradigm shift that will occur with the onset of
client/server architecture will be in the overall priorities that govern
information system selection, implementation, and operation. In the
traditional information systems world, system efficiency and stability
have been paramount, while in the end-user computing revolution, these
priorities have given way to ease of learning and ease of use. In the
client/server environment, the primary concerns will be the ease of
prototyping and building new applications and the ease of changing
existing applications. Actually, these new priorities will not replace
the others, because previous ones will still be essential. Rather, the
earlier priorities will be assumed to be satisfied, while the new ones
will be layered on top of them, in a Maslow-like hierarchy of
information system needs.

     Vendor contributions

The vendors' contribution will be in the form of the standards,
software packages, toolkits, development tools, and hardware from which
IS and the users will select. Of these, the development tools are
perhaps the most important in the context of designing and implementing
new applications. Unfortunately, most of the tools now available are
oriented exclusively to professional programmers. Hence, a major shift
in how these tools are structured (and marketed) will have to occur
before the synergy inherent in the IS/end user partnership can be
realized.

The higher education administrative user community, lacking the
time (patience), money, and skill base for custom coding, is heavily
dependent on independent software vendors for applications. While there
is a dearth of client/server architecture packages on the market now, a
few vendors have delivered applications which exhibit some client/server
characteristics (e.g., Oracle and Sybase with their networked database
management system access and IBM with OfficeVision), but the internal
interfaces are often proprietary.

The ability of independent software vendors to develop new
client/server applications will depend on toolkit availability. Since
early versions of these enablers are already beginning to appear, it is
not unreasonable to anticipate that a number of third-party applications
will appear in 1992.

Applicability to academic institutions

The client/server model of application delivery may be particularly
important to higher education institutions. Autonomy of academic units
within a college or university constitutes both an inherent strength of,
and a challenge for, our institutions. The client/server architecture
enables units to participate more heavily in application selection while
also bringing their biases for a particular vendor's hardware and/or
software to the table. An engineering college may, for example, choose
to implement a Hewlett-Packard-based application because their college
technicians tend to be more familiar with the RISC architecture that HP
engineering academic applications utilize. On the other hand, a business
school that is training professional systems analysts, economists, or
accountants, may look to IBM for their college's application which may
ultimately become a critical university resource on the network.
Client/server architecture provides the flexibility that these units
require. Cooperation and complementary coexistence in our very political
world can be enhanced through this emerging architecture.

For information technology managers, client/server architecture is
a means to leverage systems development, computing, and support
resources. Modules built for one application have a higher probability
of use in other situations than in the past since they use standard
interfaces. Each part of an application can be delivered by the platform
whose technology is most cost-effective for it. By dedicating servers to
specific applications, management can put bounds on their resource
consumption and operate more explicit cost allocation schemes. A common
user interface for widely used applications can have a salutary effect
on support costs. These are important considerations with many colleges
and universities facing budget cuts, and information technology managers
being asked to find better ways to leverage their institution's
investment in information technology.

The standardized interfaces required for access to information
resources and services will provide substantial advantages for the
institution's own systems implementors as well as a clear definition for
how individual members of the academic community may gain access
themselves. Certainly access to a variety of libraries' catalogs and
databases through the Z39.50 protocol is an important example.[2] More
structured databases, such as those underlying administrative
information systems, might be accessed through SQL-based interfaces.

The client/server model provides a sound basis for an inter-
institutional system architecture because it allows the individual user
to transparently access resources beyond institutional boundaries. As
state-supported universities, for example, begin to share more data with
their governing boards and with each other, client/server systems will
enhance their ability to do so.

Client/server architecture is a vehicle for providing faculty,
staff, and students improved (simpler and broader) access to databases,
traditional hosts (through gateways), print/file services, or other
shared resources. Even a relatively modest workstation can participate
in a network that offers broad information retrieval, electronic mail,
and other services coupled with desktop personal services.

On the downside, all users who wish to participate in client/server
systems must have, or have access to, such an intelligent workstation,
configured with the appropriate software and attached to the campus
communications network. This will increase the already high cost burden
borne by students and runs the risk of disenfranchising those unable to
pay the added cost unless the institution provides financial assistance
or a sufficient number of public-access workstations to meet the need.

To help institutions minimize the problem of the "rich getting
richer," we hope that vendors will ease the transition to client/server
architecture by providing multiple interfaces (analogous to IBM's Common
User Access I and II) for important applications so that those users who
have invested in "dumb" terminals could still access the applications,
even if it is with reduced capabilities.

Implications for information technology
organizations

Many colleges and universities will shortly begin a transition to a
new technology platform based on client/server architecture. A
successful transition will require careful execution of a plan over
three to five years. In addition to assimilating a new set of
technologies, institutions will have to develop new applications design
and development methodologies, and likely restructure the information
technology (IT) organization as well.

Clearly, higher education institutions face enormous challenges in
upgrading the skill sets of analysts and programmers. In-house
professionals will require training in cross-platform design, program-
to-program communications, testing and debugging techniques, and new
support programs. Graphical user interfaces, remote procedure calls, and
object-oriented programming mustall become part of the staff's
repertoire. But this may be the easy part--the difficult part will be
changing existing mind-sets and philosophies toward applications design
and development. No courses or seminars are available to do this, and
some information systems professionals may be unable to make the
transition. The best approach appears to be to obtain hands-on exposure
to the new technologies. The more creative people will begin to see the
possibilities. In any case, the process needs to be started immediately.

The key differentiating factor between the current technology
platform and the client/server platform is the concept of networked
computing. The new approach recognizes that the application is not
targeted for a single host platform, but for the network. Parts of the
application will likely be executing in different systems, with the
different pieces of the application communicating with one another via
standard application programming interfaces.

Unfortunately, current design and development methodologies are
primarily focused on applications that reside on a single host system
(the "host" can be a mainframe, a minicomputer, or a workstation) and
communicate with "dumb" terminals. All the processing and data
management is performed on the host, while the terminal is only used to
input and display information. This approach to applications design and
development not only is inculcated in the thinking of systems analysts
and programmers, it is enforced through the development tools at their
disposal, including third- and fourth-generation languages and even the
majority of CASE (computer-aided software engineering) tools. While this
approach has worked well for the past thirty years, it will not work in
the client/server world--at least it will not facilitate the 
exploitation of the new environment. This approach reduces the benefits 
of client/server architecture or, worse, suboptimizes the platform and 
leaves the institution worse off than it was before.

Information technology organizations and users should be
identifying opportunities for client/server systems, both new and as a
logical migration of installed systems. While most users will wait for
more robust toolkits and/or third-party applications, the more
aggressive colleges and universities should be implementing pilot
client/server database management systems (DBMS) applications today
using products such as Sybase front-end development tools for its back-
end DBMS, or Hewlett-Packard's NewWave or DEC's DECwindows toolkits.
Phased implementation is possible, using "frontware" packages (e.g.,
Easel, MacroScope, MitemView) that operate on the user's workstation and
provide a graphical user interface to traditional, character-screen-
oriented applications running on a host system. They offload forms
management, editing, and validating functions of existing applications
from the mainframe onto workstations and provide the user with what
appears to be a client/server application. This last aspect is
particularly important in that it is viewed by users as the IT
organization really doing something for them, and it begins the process
of conditioning users to the client/server environment.

Campus networks must be implemented that interoperate with
departmental ones to provide an institution-wide communications
infrastructure. The care and feeding of networks is both an
organizational and a technical hurdle. If a print server is down today,
it may be a temporary inconvenience, but server and network reliability
becomes critical when applications have a dependency on server
availability to deliver any function at all. The campus network
operations must approach the reliability and availability of the
telephone and electric utilities.

Achieving effective, efficient delivery of computer-based
applications to the institution will require an examination of both the
role and structure of the information technology organization. The
central IT organization will certainly not control the majority of
computing power, and probably not the majority of application creators.
Its role, therefore, necessarily changes from one of ownership and
control to one of standards setting, support, and leadership.

The shape of the IT organization must also change. The tradition of
separate and fully self-sufficient administrative and academic computing
units will no longer be appropriate. Institutions cannot afford to fund
multiple staffs for networking, operations, workstation development, and
so forth. Nor can they wait for ultimate client/server standards and
technology solutions before developing new support infrastructures.
Neither the centralized support paradigm that worked with hierarchical
mainframe computing, nor the decentralized model of the mid-1980s that
emerged to support widely dispersed microcomputers, will be sufficient.
Just as client/server architecture implies that processing is done on a
distributed basis (i.e., where it can be done most efficiently), end-
user, network, and application development support will also have to
work on a distributed model with some functions performed centrally and
others at the local user sites. The viability of the client/server
architecture will ultimately depend on the willingness and ability of
central information technology staff and user groups to reorganize into
cooperative teams to support the new architectures[3]

Summary

Client/server computing is as important to the 1990s as the time-
sharing model was to the 1980s. It will initially cause confusion but
will ultimately lead to systems that are highly functional, easy to use,
and affordable. The technology to implement effective client/server
systems is now emerging, but key standards, tools, and skills needed to
construct them are only nominally available. Hence, the transition to
this new environment will not take place overnight; rather, it will
emerge gradually in the coming decade.

Nevertheless, the perceived benefits of client/server architecture
will spawn a number of near-term initiatives by the information
technology organization--for itself, end users, and institutional
management. IT organizations must therefore begin now to learn about
this new paradigm, to educate their staffs and users, to begin pilot
projects, and to examine carefully their own structure to assure the
continued effective use and management of information technology on the
campus.

========================================================================

Footnotes

1  Herbert Grosch proposed, in the early years of mainframe computing,
that computing power increases as a square of the cost, i.e., if you
double the cost of a computer, you quadruple the speed.


2  For a description of the Z39.50 protocol, see Clifford Lynch, "Access
Technology for Network Information Resources," CAUSE/EFFECT, Summer
1990, pp. 15-20.

3  Cornell and Indiana University are examples of institutions that have
recognized the need to restructure the central information technology
organization and have completed transitions to a more efficient
structure. Both are organized around five areas: information resources,
workstation resources, network resources, computing resources, and
support services.

************************************************************************

Client/Server Architecture Promises Radical Changes