🚀 go-pugleaf

In article <1992Nov17.111656@is.morgan.com> mpiet@is.morgan.com (Mark Pietrasanta) writes:
>Okay.  I'll ask it.  Is Client-Server going down the tubes in
>favor of peer-to-peer?

Client-server applications are what you run on a network. Whether or not
that network has "servers" and "workstations" or runs "peer-to-peer" does
not change this.

>Are networks like Novell, Banyan, etc. that rely on the logical
>star of client-server a thing of the past now that Unix and
>Microsoft's Windows for Workgroups and Windows NT are on the
>horizon?

You will still likely have your database server process running on the node
with the big disk, fast processor and tape backup. As a result, that node
becomes a "server", even though the OS may be capable of making any node on
the LAN a server. 

>It would seem that business is more suited to a peer-to-peer
>environment, although IS typically isn't.  How do we IS'ers
>maintain our role (or any role) as the business units start to
>welcome the new peer philosophy?  Especially if they embrace
>Microsoft's solutions, which will mean they can support and
>develop with minimal man-hours and without IS?

Someone will still need to do the administration ( backups, installation
of new software, upgrades, etc ).
-- 
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8

mpiet@is.morgan.com (Mark Pietrasanta) writes:
>Okay.  I'll ask it.  Is Client-Server going down the tubes in
>favor of peer-to-peer?

       The main purpose of client-server systems is isolation of the
manipulation of important data from the (probably graphical) user
interface.  Whether both reside on the same machine is not the central issue.
GUI-based applications tend to be mostly user interface in terms
of code volume, and breaking up the program into a user-friendly
client and a server whose users are programs seems to be a good
division of labor.

						John Nagle

In article <1992Nov17.111656@is.morgan.com> 
mpiet@is.morgan.com (Mark Pietrasanta) writes:
>How do we IS'ers
>maintain our role (or any role) as the business units start to
>welcome the new peer philosophy?  Especially if they embrace
>Microsoft's solutions, which will mean they can support and
>develop with minimal man-hours and without IS?

A rose by any other name ...

I always laugh when I see someone claim that client/server, PC's/
peer-peer etc. systems can be supported and developed without IS.

Now I would tend to agree that traditional IS groups may have
trouble with this but certainly the skills required to design,
install, support, etc a complex heterogeneous LAN environment 
are the same skills required to run a large central computer center.
The details change, but the concepts are much the same.

In fact in some ways is harder to administer to the needs of a 
distributed PC based environment.  Just think about making reliable
backups for all those PCs.

What needs to happen is that the IS group must change its structure
and the services it offers so that the smaller groups within your
organization can rely on you to continue to manage their systems.
Why should each of these smaller groups being hiring (or drafting)
PC and network experts?  Usually they take what they can get from
there existing staff instead of hiring a skilled/trained person.
-- 
Gary Wright                                                 ...!uunet!hsi!wright
3M Health Information Systems                                     wright@hsi.com

In article <1992Nov18.050812.20252@netcom.com> nagle@netcom.com 
(John Nagle) writes:

>       The main purpose of client-server systems is isolation of the
>manipulation of important data from the (probably graphical) user
>interface.  

Why do we have to perpetuate the abuse of the "client-server" term?
Client-server is an abstract concept with many concrete implementations.

To claim that the computation/display relationship between two pieces
of software is a special or primary meaning of "client-server" is to
make that term less descriptive.  What do I call two computational
systems that communicate in a request/reply manner if the term
client-server has been redefined to mean Microsoft Windows and SQL Server?

Certainly NFS is based on a client-server concept but there is no
display software at all in that system.
-- 
Gary Wright                                                 ...!uunet!hsi!wright
3M Health Information Systems                                     wright@hsi.com

nagle@netcom.com (John Nagle) writes:

>mpiet@is.morgan.com (Mark Pietrasanta) writes:
>>Okay.  I'll ask it.  Is Client-Server going down the tubes in
>>favor of peer-to-peer?

>       The main purpose of client-server systems is isolation of the
>manipulation of important data from the (probably graphical) user
>interface.  Whether both reside on the same machine is not the central issue.
>GUI-based applications tend to be mostly user interface in terms
>of code volume, and breaking up the program into a user-friendly
>client and a server whose users are programs seems to be a good
>division of labor.


I think that client-server is the wave of the future.  The future that I
see is that the computer will be a network of machines.  Some of the machines
will be clients, some machines will be servers and some machines will be both.
The future I envision has a disk machine, which has a lot of online storage
connected to a fast but otherwise pretty minimal CPU (NFS).  There is a compute
server, a computer which has been optimized to have a fast, powerful computer
and lots and lots of RAM.  There are terminals connected to terminal servers,
terminals which are servers (X-terminals).  Security is maintained by a
security server (Kerberos).  Time is provided by a time server.  Now, the
machines can take on different roles at different microseconds.  For example,
the compute server is a client of the file server, but it is a server to
a general purpose computer.  The file server is obviously a server to lots of
clients, but less obvious is that it is a client of the security server and
the time server (Kerberos requires time synchronization).

I think if you look carefully at the new offerings, you will see that deep
down inside they are still client server based!  

Jeff Silverman, Boeing.

In article <Bxwz4p.4tq@hsi.com>, wright@hsi.com (Gary Wright) writes:
|> In article <1992Nov17.111656@is.morgan.com> 
|> mpiet@is.morgan.com (Mark Pietrasanta) writes:
|> >How do we IS'ers
|> >maintain our role (or any role) as the business units start to
|> >welcome the new peer philosophy?  Especially if they embrace
|> >Microsoft's solutions, which will mean they can support and
|> >develop with minimal man-hours and without IS?
|> 
|> [...]
|> Now I would tend to agree that traditional IS groups may have
|> trouble with this but certainly the skills required to design,
|> install, support, etc a complex heterogeneous LAN environment 
|> are the same skills required to run a large central computer center.
|> The details change, but the concepts are much the same.
|> 

I agree.  But what happens when the LAN goes away, something like
Windows for Workgroups becomes easily accessable, all college grads
learn it, and the users start saying, 'hey, why is it that IS can never
give us EXACTLY what we want, when we want it, and charge us so much?
Screw them, let's higher some kid (one of them) at entry and get 
everything we want.'

They will only have to rely on IS for the cabling, and the maintenance
of the actual backend data (SyBase, mainframe, whatever).  This means
that IS loses their ability to stay in contact with the business, and
therefore become VERY expendible (more so than today).  In addition, they
lose alot of the unique expertise gained from working in different large
businesses (since they will be the first ones to fall?).

The LANs forced IS to restructure and say 'Okay, the PC's are yours,
but the server, well, that's a big, complicated thing that only we
can deal with.' -- a variation on the mainframe.  Once this type of
client-server goes away (which I contend it will), then the users 
basically control everything except the storing of the data -- they
control the retrieval, manipulation, and distribution, typically IS
assisted functions.

What can we do to avoid or work with this?  Restructure again?  Or 
do you think this is something that is extreme and will never happen?

|> In fact in some ways is harder to administer to the needs of a 
|> distributed PC based environment.  Just think about making reliable
|> backups for all those PCs.

Every week I see an easier and easier way to do LAN backups, whether PC,
Unix, or Novell.  If Windows for Workgroups kicks off, I'm sure there will
be some painless way to do the distributed backups.  And the one 'kid'
will still be able to maintain it.
 
|> What needs to happen is that the IS group must change its structure
|> and the services it offers so that the smaller groups within your
|> organization can rely on you to continue to manage their systems.
|> Why should each of these smaller groups being hiring (or drafting)
|> PC and network experts?  Usually they take what they can get from
|> there existing staff instead of hiring a skilled/trained person.

Okay, we did it once with LANs, what do we do now?  The reason they would
use/hire their own person is that is would sure be alot cheaper to have
one real headcount than to pay for endless manhours within IS.  It's
often very difficult to explain to the users where all these man-hours 
come from.

Very interested in any comments.
Mark Pietrasanta - mpiet@is.morgan.com
* * * * * * * * *

"Great spirits have always encountered violent opposition from
mediocre minds." - Albert Einstein

----------------------------------------------------------------
Disclaimer: These responses are my own and in no way reflect the
            views of my employer.
----------------------------------------------------------------

I think that folks are looking at client-server from different viewpoints
here.  The first from a small workgroup viewpoint (office/workgroup
server, local info-bases, small to medium size data & apps), which can
be adapted to "ad-hoc" programming styles and minimal configuration
support.

But that doesn't solve the corporate level viewpoint for a large
Fortune 500 company.  The execs in the corporate strategic planning
office need the data from the entire company, not just one department.
The raw compute power may be there in a 486 server, but it'll never
handle the I/O volume on the input side with any kind of response.
What about processing Citibanks credit card info each month?   Or any
Fortune 500 company-wide payroll or personnel systems?

The big iron will stay around as mega-data servers, the SPACRServes
will be the departmental servers, and the GUIs will be run off the
desktop.  Move the different parts to the right type of machines, with
multi-client-server configurations (as described in another posting).

And you'll still need IS to keep everything in sync (do you trust
every department to install the correct versions of the client
software on every machine ON SCHEDULE?) and talking to each other and
the world.

Michael A. Chance
--
Michael A. Chance          St. Louis, Missouri, USA    "At play in the fields
Work: mc3078@sw1sta.sbc.com                             of St. Vidicon"
Play: bq434@cleveland.freenet.edu
      mchance@nyx.cs.du.edu

mpiet@is.morgan.com (Mark Pietrasanta) asks:

> It would seem that business is more suited to a peer-to-peer
> environment, although IS typically isn't.  How do we IS'ers
> maintain our role (or any role) as the business units start to
> welcome the new peer philosophy?  Especially if they embrace
> Microsoft's solutions, which will mean they can support and
> develop with minimal man-hours and without IS?

Expecting end users to produce answers-oriented analysis applications
to benefit themselves or their immediate work group is a reasonable
thing.  The IS department writing monthly sales role-up reports is
probably a thing of the past, and any IS department that tries to
fight over this type of application is likely being foolish.

Expecting end users, or even department specialists, to write
applications that respect cross department information requirements
and obscure legislated auditing requirements is probably foolish.
These considerations don't help with getting the "job at hand" done,
they only may reduce problems in the future.  And the future could
very well be outside of the current budgetary cycle.  I suspect that
the role of IS will be concentrated here;  coordinating the corporate
information schema, dealing with what the government insists you be
able to produce, and coordinating information exchanges with outside
agencies (either governmental or companies you do business with).  For
example, an insurance company would probably want an IS department
designing and building the applications for remote independent
insurance agents so a single application handled the full spectrum of
claims and new account business handled by the independent agents.
Having the claims department, the auto insurance department, the
medical insurance department etc. all come up with their own
applications is probably expensive for the big company, and more so
for the poor independent agent who then has to deal with 16 different
incompatible applications, probably some running on different
hardware.  (If you have 6 departments involved, at least one will
probably "standardize" on the Mac...)

R Mark Chilenskas
Chilenskas@Office.wang.com