Conference 7.286::digital

    There might be something in the DEC_HISTORY notesfile on this in more
    detail.
    
    The org chart in 1980 from the field's point of view was a joke:
    They (product lines) pretend to support us and we (the field) pretend
    to take direction from them.  Maxtrix management was already a decade
    old.
    
    Nominally powerful product lines in 1980 served a purpose.  At least
    one know where the buck stopped.  It stopped with the product line
    manager. After several "empowering" re-organizations we've lost that
    accountability.
    
    A consequence of being bigger now than we were then is the lengthy
    decision making process.  I figure that in constant 1990 dollars, a
    commitment of $10K has gone from a week to a month and a commitment of
    $1M from two weeks to three months.
    
    In engineering, in 1980 there was a bias towards action, doing
    something and then trusting the marketplace ie customers to let you
    know if you were doing the right thing.  Around 1983, when everyone
    told us we were doing the wrong thing, we kept on doing what we were
    doing, stubbornly.  Volumes have been written about this arrogance.
    
    Finally, there was less hypocrisy in 1980.  But in 1990 we have NOTES,
    so that makes it infinitely better.
    
    Myself, I prefer the 1970 org chart: 6 software specialists to cover
    the United States east of the Mississippi.

    Comparing the field sales force reporting structure when I joined the
    company versus now:

    		1976			1990
    		----			-----
    		KO			KO
    		\|/			\|/
    		Vice President		Vice President
    		\|/			\|/
    		Regional Sales Mgr	Regional Sales Mgr (VP?)
    		\|/			\|/
    		District Sales Mgr	District Sales Mgr
    		\|/			 |
    		Sales Group Mgr		 |
    		\|/			\|/
    		Sales Unit Mgr		Sales Unit Mgr
    		\|/			\|/
    		Sales Representative	Sales Representative

    When the Group Managers disappeared there was not even as much as (from
    my perspective) a minor hick-up.  Never missed 'em.  No reduction
    in the quality or quantity of work.

    I am now, more than ever, convinced that the Sales Unit Manager or the
    District Manager can disappear with a corresponding non-noticeable
    effect.  We need only to automate some functions and another level of
    management can easily be cut....in particular, the Sales Unit Manager.

    I may be wrong...this is just a gut feeling...

    Jerry

The product lines were established with the intent of focusing our Marketing 
efforts to a particular set of customer needs. The P/Ls vanished ('81) when the 
redundancy (multiple Finance/Mareting/Operations Managers) was felt to be
burdensome. In fact, we did away with a great deal of industry-oriented
expertise and fumbled around for a good many years without a Marketing
orientation. It is now the Digital Competence Center (ala IBM), more or less 
devised along Industry Sector lines, which is intended to replace them. We spent 
many years lost in the desert and generated much heartache amongst the
P/L Marketeers after abolishing the P/Ls. And for what, to arrive very much
where we are today in terms of Industry Marketing strategy. The transition 
could have been quicker, more effective, less de-motivating.

One advantage today is that the Account Manager, depending upon ROI, can
be empowered to make investments in his/her Account development, much as the 
original P/L Manager could for all his/her accounts. Another difference is the 
fact that an  International Account has one point of entry into Digital - the 
single, assigned Account Manager - not one per region. In a globalized business
world, where our revenue tends to concentrate in the larger accounts, 
both changes make very good sense.

    Having been a manager in the 80's....here's my opinion.
    
    The average manage now is less experienced, better educated, much more
    self-centered, and cares much less about their employees' welfare.
    
    We are feeling the full impact of the yuppification of DEC, and an
    extreme over-dependence on MBA's and other generally worthless pieces
    of paper.
    
    Overall, we've lost a lot.

    re .5 >the average mager now is less experienced, better educated
    
    I smell a contradiction. More properly, 'less educated through
    experience, more 'schooled'". Too many people, including and
    especially hiring managers, prefer a shingle to a rank-and-filer.

    re -1....I think we're in violent agreement.  I can remember for many
    years when a hiring manager was not allowed to specify degree
    requirements in a req (except for doctors, lawyers, etc.)  Now the
    reqs are full of such silliness.
    
    This new generation of management, having wasted many years and much
    coin in pursuing paper, cannot conceive of someone without an
    advanced degree being even remotely functional.  Sad.

    As a manager in the '80s, I remember getting resumes of PhDs and
    asking "...but can he/she code ?".
    
    Now many of those go straight to already bloated staffs.
    
    Sad, indeed !
    
    Edwin

    1206.5 brings up one of my favorite boogey-persons, yes it is the
    subversive MBA trying to undermine the foundations of Digital.
    
    I've yet to meet an MBA at Digital who's in a position to do 1/100th
    the damage that folks with engineering degrees are doing.
    
    Where are these evil MBA's?
    
    I'll concede that there's a pseudo-MBA mentality in trying to create
    discounted cash flows, internal rates of return, and so forth when
    there isn't adequate common sense to proceed or kill a project, but
    that's as far as I'll go.
    
    I think it's demeaning to employees who have invested 3 or 4 years of
    their life in academic work to get an MBA and _know_ the limitations of
    financial models, to assign to them the stigma of short-term thinking
    and exclusive focus on short-term financial results.
    
    If anything, MBA's have seen more case studies than anyone else of
    companies that went down the tubes for these reasons. 

I don't see much difference between the quality and deportment of DEC's
management in 1980 from the way it is now.  The biggest difference that I see
is that there are a lot more managers around now than there used to be, but
that's to be expected, since the company is several times larger than it used
to be.  This in turn has led to a major problem with DEC's traditional "decision
by consensus" approach.  There're a lot more people who have to "buy into"
something before it happens now than in 1980.  I think it's time to toss
"decision by consensus" on the scrap heap and replace it with "lead, follow, or
get out of the way."

One thing that we had in 1980 was a well-articulated sense of long-term
corporate direction.  We were working towards bringing together the disparate
machine architectures and operating systems of the past into a single,
company-wide systems offering.  This materialized in the middle of the decade
as "one company, one architecture, one message."  The time for that strategy
is past, but in its day it was responsible for most of our growth.  It has been
discarded, but it has not been replaced by anything else.  Here in 1990, I no
longer have the sense that my work is feeding into realizing any kind of
long-term plan for the company's future.

--PSW

RE -1
>One thing that we had in 1980 was a well-articulated sense of long-term
>corporate direction.  

You spell that Gordon Bell.

/George

I take it, then, that I would be considered a non functional engineer by said
Mgt types.  Hmm, after 24 years doing various things in, with, and around
computers is seems I have been wasting my time }8-)}.


				Bill

    re: .12
    
    I think even the most degree-worshiping manager recognizes the value of
    experience.  Experience, however, is the thing most clearly lacking in
    a person just out of school.
        John Sauter, BS '67
    

    
    Neither education nor experience can take the place of effectively
    using wisdom, common sense and intelligence.
    

    There is a "Reprint of the September 12th Report to Readers of the Wall
    Street Journal" inserted in the September 23 issue of Digital Today.
    The last page has a quote from K.O.:
    
    	"One of the things I loved about Digital when it was truly a small
         company was the way we worked together.  We shared information, energy,
         and ideas with a real sense of entrepeneurial teamwork."
    
    The article goes on to say how our global computer network allows this
    teamwork to happen on an international scale.
    
    	"The greatest problem facing any large compay is how to foster
         teamwork across barriers of size, time, and distance.  The network
         makes it possible for everyone to work together."
    
    I would agree that the network is a tool that makes teamwork possible, 
    but the network does not "foster" teamwork; people (managers *and* workers)
    foster teamwork.  That may be nit-picking but I did a double take when I 
    read the next paragraph (emphasis is mine):
    
    	"Digital's teamwork philosophy and SIMPLE ORGANIZATIONAL STRUCTURE
         underscore its long-standing commitment to bring the power of
         information closer to people who make decisions."
    
     "Simple"??  Are there other organizations more complicated than ours?
    
    -pk                     

    re.15
    EXACTLY,
    
    The network ENABLES teamwork, but doesn't initiate, lead it.
    
    It's like most modern adhesives. They are great glue, but need
    pressure, heat to become effective.
    
    /fred
    

    re: .15
    
    Yes, our structure is much simpler that some other large
    organizations.  Consider the Executive Branch of the U.S. Federal
    government, for example.  At Digital we don't even have divisions.
        John Sauter

    
    Dear Group Manager,
    
    Please try to remember that the people who get the work done are the
    worker bees.
    
    Do not try to insulate yourself too much from them.  They are the
    heart-beat of your organisation.  You will quickly lose touch with the
    reality of your organisation if you choose to have a small army of
    smaller managers filter information for you.
    
    Remember, these smaller managers  will also have their own agenda.
    The good ones will tune it to accurately reflect his/her charges.
    But there is about one that's not-so-good for each good one.
    
    You need to be in touch with your individual contributors.  Give them
    more room to make important project decisions.  Insulate them from 
    unnecessary paper work and endless hours of preparing for 
    presentations after presentations.  Keep them in tune with technology
    and encourage them.  
    
    - An individual contributor
      (Phil)

    The difference between my first interactions with DEC in 1972, thru
    DEc in the early 80's and now is pretty minimal.
    
    Once Digital aquired enough momentum to keep growing it never got
    really bad.  Every 2 years we were the darling of Wall Street, a
    one year so-so bit, and every other cycle DEC was oh so bad.  Nothing
    internally changed, it was just business as usual.
    
    When we were good, we hired, felt invincible, started projects on
    a moments notice, and had a wonderful time.
    
    When we were bad, ALL groups got frozen, REQ's stopped, lots of
    memos got circulated, we stopped delivery of the Wall street journal,
    required VP signitures on international travel, etc.  AND lots of
    GOOD people got fed up and left.
    
    Then it all got magically better, everyone felt vindicated, and
    we started to spend like drunken sailors on leave.  Nothing changed.
    
    I think the problem is that everyone is taking this as just another
    bad cycle.  The internal politicians are building a power base and
    canibilizing little groups for charter that can be exploited when
    the bindge comes.  Lots of good news is being circulated so that
    those in power will look else where for cuts. 
    
    I don't think that very many people at Digital can even concieve
    of this as being the one that ends the good times once and for all.
    
    Then it gets sick.  Anyone working for the turn around will have
    lost significant political power time in the case it does come about.
    If we rebound, the ones who worked in the right direction will suffer.
    If we don't rebound, the ones who want to work hard won't have the
    power base to hold on for a long long slow time.
    
    Problem of the commons.  Anyone looking to the eventual outcome
    treats this as a "personnal opportunity"
    
    The real problem here is that in past times there were fewer managers
    and the number working for turn around had a higher impact.  Now
    we have a lot more managers and organization but the number working
    to get good things done is constant.  
    
    

No, but we do have "product lines' or whatever they are called this time around.

If individual business entities (profit centers) exist, are not these in essence
"divisions" operating indivirually under the global direction from the corporate
center ?

Bill

    re: .20---Divisions are more separated than our product lines.  We have
    a lot more central direction than a typical many-divisioned company.
        John Sauter

re Note 1206.15 by WLDWST::KING (and .17 and .21 by SAUTER::SAUTER):

>     	"Digital's teamwork philosophy and SIMPLE ORGANIZATIONAL STRUCTURE
>          underscore its long-standing commitment to bring the power of
>          information closer to people who make decisions."
>   
>      "Simple"??  Are there other organizations more complicated than ours?

        John Sauter's comments have pointed out that a simple
        organizational structure (i.e., no divisions) might actually
        result in an organization which is more rigidly controlled
        and therefore harder to work in.

        During the 12 years I've been at Digital, I've seen a steady
        progression of centralization in engineering.  Back in '78,
        it seemed that a lot of important engineering took place in
        the "product lines" -- outside of central engineering.  And
        even central engineering was divided among product families
        with sturdy walls between them.

        Also, back in '78, Digital occasionally (often?) suffered
        from parallel and duplicative engineering efforts, as well as
        from incompatible architectures.

        I believe that the move toward centralized engineering was
        motivated primarily to solve the problems of duplications
        and incompatibilities within engineering.

        Did it work out?  I would argue that the company has suffered
        as much as it has benefited from engineering centralization.

        I strongly believe that the company must find a way to create
        and nurture islands of engineering excellence.  Yes, and I
        do mean "islands."  They need considerable isolation from the
        day to day intervention and need to coordinate with
        engineering at large.

        About 10 years ago, it was recognized that Digital, if it
        were to do world-class research, needed to form research labs
        that were isolated from engineering and had a great deal of
        independence.  This appears to have worked out -- the labs,
        even though at arm's length, have contributed to major
        architectural efforts.

        I think it is time to recognize that world-class engineering
        and product development likewise needs, in many cases, a
        degree of independence that is not found in central
        engineering today.

        This may result in a (slightly) more complicated
        organizational structure.  However, it will "bring the power
        of information closer to people who make decisions."

        Bob

re .22 

>        I believe that the move toward centralized engineering was
>        motivated primarily to solve the problems of duplications
>        and incompatibilities within engineering.

>        Did it work out?  I would argue that the company has suffered
>        as much as it has benefited from engineering centralization.

>        I strongly believe that the company must find a way to create
>        and nurture islands of engineering excellence.  Yes, and I
>        do mean "islands."  They need considerable isolation from the
>        day to day intervention and need to coordinate with
>        engineering at large.


        From my perspective, centralization is just as risky as
        decentralization.  Instead of loss due to duplications and
        incompatibilities, we can all go down the tubes together, with a
        very efficient, well controlled, crowd of lemmings.

<flame on>

        I fear that we are following a market that is not there with some
        of our (and our competitors, too, thank goodness) moves in the 
        direction of consistent [ :-) ], pretty [ :-| ], and complex 
        [ :-( ] user interfaces.  We are writing software for hardware
        designed for people who can juggle several processes on their
        workstation and still get work done.  There are very few "users"
        who can do this.  

        How often must we repeat it?

        "People buy computers to get work done, not because they love
        computers!"

        (ok, you and I are exceptions, we work in this business, but most
        of the world doesn't!)

        We are contributing to a rate of change in technology that is
        designed for a niche market, and yet we wonder why it doesn't
        have mass appeal?

        Beldin's rule (excuse me, Jerry Pournelle) is:

                "One user, one window, one visible process."

<flame off>

        to get back to the centralization - decentralization issue 


        Yes, there are some business requirements that make
        centralization useful.  There are market exploration and
        development imperatives for decentralization.  Our problem in
        Digital seems to be that we can't "value differences" between
        organizational styles, we can't have recognize (or find) a
        non-dogmatic approach to organization, management, business
        objectives, or anything else.  We don't even recognize our own
        dogmatism.

<all right, I didn't turn it all the way off.  So sue me!>

        After I wrote Note 1206.22, I realized that my suggestion of
        "islands of engineering excellence" might be misconstrued.  I
        in no way wanted to imply that today's engineering
        organization lacks excellence, or that excellence required
        isolation in all cases.

        Sometimes you need large numbers of highly-coordinated
        developers,  but often you don't.

        I am also not advocating that all of Digital's engineering be
        decentralized, but I do think that some larger number of more
        independent engineering groups would help the company react to
        changes in the market and technology

        Bob.

rep ;.22
    >        Also, back in '78, Digital occasionally (often?) suffered
    >        from parallel and duplicative engineering efforts, as well as
    
    You mean like the 8650,8700,8550,6410 cpus we made over the last couple
    of years, all with the same power, and no resemblence to each other?
    
    /Dean

    Question. How many of our software products originated in the
              skunkworks ?
    Question. How many were deliberately planned by "the hierarchy".
    Question. Which are the most successful ?
    
    Mike Day
    

re Note 1206.26 by JUMBLY::DAY:

>     Question. How many of our software products originated in the
>               skunkworks ?
>     Question. How many were deliberately planned by "the hierarchy".
>     Question. Which are the most successful ?
  
        Well, I recently saw some lifetime profit figures for the
        BOSE "family" of products (this is from memory).

        ALL-IN-1, a "skunkworks" product, was enormously profitable.

        VTX, origin unknown to me, is mildly profitable.

        Everything else, planned by "the hierarchy", is enormously
        unprofitable.

        Bob

    Excuse me, but wasn't VMS a 'hierarchy' product?

    I'm sure Kelly Johnson (late of Lockheed's Skunkworks, the earliest use
    of the term that I know of) would object to the idea that his projects
    were unplanned. But that Skunkworks was setup to hide 'black' projects
    from the outside world, not specifically from Lockheed management.
    
    Also, most skunkworks type products have much of their development
    costs hidden in other projects, making it easy to create spectacular
    ROI figures.
    
    If you accept the implication that the skunkworks approach has
    consistantly resulted in better (or more profitable, and the two may
    not be the same) products, what does that tell you? Both (a)"the
    skunkworks approach is inherently better" and (b)"Digital's planning
    heirarchy is broken" are valid conclusions. And if (b) is true, (a) is
    probably also true. Which leads one to ask "what is the best way to get
    my project done?", accept (a) and go underground or try to tackle (b)
    head on. Which is best for my project? Which is best for Digital?
    
    IMO, the skunkworks approach (or anything that tries to end run "the
    heirarchy") may solve an immediate problem but does Digital a
    disservice by allowing the base problem to continue to grow. Indeed, if
    you are successful with the skunkworks approach, the view from one or
    two levels above may very well be that the heirarchy is working well!
    
    gary

    
    I had heard that All-In-1 was originally developed for a specific sale
    for a specific customer.  If that's true, it wasn't really a skunk-works
    deal.
    
    
                                                

re Note 1206.30 by SX4GTO::BERNARD:

>     I had heard that All-In-1 was originally developed for a specific sale
>     for a specific customer.  If that's true, it wasn't really a skunk-works
>     deal.
  
        Yes, you are right.  (Hint:  they make chemicals.)

        But I was only given the choice between "skunkworks" and "a
        planned project of the Digital hierarchy."  Given the
        alternatives, it was much more like skunkworks.

        (Besides, I believe that the creators of ALL-IN-1 were
        intending for it to become a platform to be used for other
        sales to other customers.)

        Bob

        P.S.  Yes, VMS is a "planned project of the Digital
        hierarchy."  But back then, central engineering was not as
        central.

	... product - RSX-11M V1!   If not "skunkworks", it was an "I'll show you"
type of effort most definitely!

    I was technical designer of VTX, and I can assure you it was clearly a
    "skunkworks" project.

    The problem is, as a previous noter stated, that what works for one
    type of work, doesn't work for another.  Engineering may well work best
    in small, innovative groups, even if some end up attacking the same
    problem from a different angle.  Unfortunately, however, as an engineer
    started this company, this become construed as "The Digital Way", and a
    loose, do it your own way, structure ("ask forgiveness not
    permission"), and organization (matrix - at least) developed.
    
    This type of organization does NOT make sense for the majority of the
    work done inside Digial...  Wouldn't it make more sense if the price of
    something was the same everywhere?  Doesn't it make more sense to have
    ONE price file, ONE parts file, ONE employee file, ONE customer master 
    file, ONE call handling system, WORLDWIDE?   And there are thousands
    of other examples.  I mean, when you get right down to it, we sell
    products and services...  anything else?  then why do we need a
    half-dozen call handling systems, literally HUNDREDS of databases with
    something like a "CUSTOMER" or a "PART" in it, and THOUSANDS of
    systems, feeding THOUSANDS of other systems, delivering MILLIONS of
    pieces of information to users that suffer from information overload?
    
    To me, the only way to be successfull is to have a very solid,
    standard, infrastructure (everybody on All-in-1 is a good start,
    architecturally, regardless of your feelings about the product itself),
    with the built-in flexibility to handle local exceptions, laws,
    requirements, etc...
    
    The problem is, because we HAVE "grown up", instead of a result of a
    "central plan", it is extremely difficult to determine any global
    standard; every organization has attacked similar problems in a
    slightly different way, using slightly different terms, policies, and
    procedures, and to make the task almost impossible, today's management (at
    least what I can see) is NOT committed to a complete structural
    overhaul of everything, and instead is committed to PRESERVING their
    fiefdom! 
    
    I'm afraid the only solution is to wait for things to get so bad (and
    they will) that it is OBVIOUS to EVERYONE that "business as usual"
    simply CANNOT continue!
    
    Its very depressing to think that the talent is here, we know what we
    have to do, and we can't get it done because of the beaurocracy.  I'm
    sorry if I've depressed anyone else...
    
    Dave

re .34 

Yes, we need different styles of work for different tasks, but we also
need to economise on the information processing part of the house.  

But do you know how hard it is to get people to understand centralization
in one aspect of the business and decentralization in another?  The next
thing I expect to hear is that we will introduce a fourth order
processing system to integrate the three that are being designed in U.S.,
GIA, and Europe.  Then someone will design an alternative system because
of performance problems in the compound system.  

I swear, I have come to the conclusion that every level of the
organization over-simplifies everything whenever they communicate up,
down, or sideways.  No manager wants to take the time to understand the
content of his/her business, just the form, the process (and with a
What's In It For Me attitude).

It is extremely hard work to write any document, from a business memo to
a product document so that,

        a) it will be read by those who need to read it

        b) everyone who reads it will get the same basic idea.

A friend and colleague once said, "In Digital, we can only go in one
direction at a time, and at only one speed - full".

Today, I think the opposite is true - "Digital employees want to go in
one direction at a reasonable speed, but there isn't one voice telling
them how fast or which way."

I'd say the largest difference between "then and now" in in the 
accountability of managers, particularly in the home offices. 

"Back then" when there were Product Lines, the PL Mgr had to stand under
the bare bulb and defend his numbers on a monthly basis. A series of
failures usually meant a new PL Mgr. 

In the rush to get away from the "evils" of competing PLs and to 
decentralize financial accountability to the Field, PLs were demolished;
and what was left was Marketing Groups who, as Win Hindle put it, " ... 
would be judged on their obvious enthusiasm...." No longer would the 
management have to worry about profits .. or products .. or inventory
levels .. or advertising .. or firing up their Salespeople .. or any of
those 'details' the old style PL Mgrs carried out for the company. There 
may have been stovepipes, but they were "my business" kinds of 
stovepipes.

As a result, Marketing Management has evolved to better fit today's 
success criteria: the "bottom line" is now a corporate problem; 
accountability is much more difficult to pin down;  significant issues
are long term at best; very few 'techies'; assuming the company
survives, there's very little personal risk; .... 

But DEC needs some of those old evtrepreneurial qualities today and I 
suspect Jack Smith lies awake nights trying to figure out how to 
rekindle them in today's environment.

/George

    The author of 1206.31 made the statement that ALL-IN-1 written for a
    chemical company.  This is a legend and not correct.  The first
    customer for the precursor of ALL-IN-1, which was called DECaid, was a
    tobacco company.  They didn't buy the package.  Neither did the second
    company, a textile manufacturer.  The chemical company from the legend
    was the third customer and the first to actually purchase the product.
    I have the project plans for these in my cube in Charlotte.

    Fortunately, that name was changed under corporate duress to CP/OSS
    (Charlotte Package for Office System Services) to remind sales people
    that the it was not a corporate product and to keep the corporate
    product, OFIS, selling.  The corporate product was architecturally pure
    and was a horrible waste of money.  The sad part was that some
    former customers actually purchased the corporate product rather than
    the one that solved customer needs rather than satisfying some
    architects' egos.

    Sadly, the architects have multiplied over the years.  Virtually none
    of them understand what the customers need or want.  This is counter to
    what a REAL architect does, of course.

    The reason that ALL-IN-1 and VAX VTX are so profitable is that they
    both satisfy real business needs very well.  Neither is appreciated
    internally to a large degree.  Neither gets sufficient funding or
    support in engineering to improve.  Both are treated as cash cows while
    the architects dream up more pure ways to waste our money. This is
    largely due to the fact that they don't work the way we do inside
    Digital.

    Fortunately, there are still real solutions being done by the people
    close to the customers and these solutions continue to pave the way to
    higher profits.  A small but excellent example is the EARS product.
    It is yet another example of people who are close to the customer
    providing excellent return while the scientists become more and more of
    a drain with PROMISES of a return SOMEDAY.

    We must REALLY listen to, empathize with, and provide solutions to our
    customers.  I hope that we will learn that architecture isn't what
    sells our systems.  Solutions, real business solutions and not the
    marketing hype, sell our systems.

    We need to adjust to our customers with or without architects.

    Do what's right and DO IT NOW,
    don

    >We must REALLY listen to, empathize with, and provide solutions to our
    >customers.  I hope that we will learn that architecture isn't what
    >sells our systems.  Solutions, real business solutions and not the
    >marketing hype, sell our systems.
    
    	On the other hand, architecture is (supposed to be) what
    	enables the real business solutions to be built.
    
    	DEC is (was?) a leader in networking.  What made this
    	possible?  Architecture.  The idea that there would be
    	a system-independent standard for how you connect things
    	together - with the result that everything from teeny
    	systems running RT11 up to big VAXen running VMS can
    	interoperate in a fairly straightforward manner.
    
    	Much of DEC's success in the '80s was due to a line
    	of computers called "VAX", the members of which ranged
    	from desktop devices to million-dollar data centre
    	machines.  What is the force which keeps new VAXen
    	compatible with the old?  Architecture. 
    
    	Now, I'm not saying that there are never sins perpetuated
    	in the name of architecture - obviously there are.  But	
    	don't dump on ALL architects and architectures.  Designing
    	clean systems can be a tough job.
    
    	The converse attitude to "architects live in an ivory	
    	tower" is "field people will sell any old junk that 
    	barely runs, regardless of whether it will be supportable,
    	upgradable, or even runnable next week".  I don't suppose
    	either of these to be totally true, although I bet you
    	can find at least one example of each.
    
    	
    	Disclaimer: I am not an architect.

re. -2

I think Don has typified a fault in Engineering development startegies.
Sometimes  preference is given to hardware developement over software
development (cultural?) There is an all too prevelent attitude that if a 
piece of software is good, then it must have been produced externally.

I cant answer authoritatively to the allegation that "purity" overrides 
pragmatism in product development, but it seems (to me) that is the case. 
We are getting better at software development, meaning "layered" software 
development (eg.TP and some CASE tools) but have got a fairly long route to go 
before attaining the industry's performance as an average. 

On the other hand, it was IBM's early tendency to build a cpu for each problem 
that lead them down their path-of-no-return. So, there are some merits to the 
consistency that an architecture provides, very much like an international 
standard. Obviously, being consistent is time consuming.

Dunno, difficult to call this one....

    The only part of a VAX that has remained the same all these years, over
    all those different models, has been the user-mode instruction set. 
    The various models implement this instruction set in different ways,
    and the way the memory maps work, and the I/O busses, etc, are all
    different.
    
    So the long-living "architecture" of the VAX is actually only a small
    part of the total system, and it says little about how parts of the
    system are to interoperate.
    
    The network "architecture" on the other hand talks about little *other*
    than how parts are to interoperate.

If we look back to the entry of the PDP-11 into the commercial market
in the early/mid 1970's, however, we do see the distinction between
customer driven and engineering driven development.

The customers asked for software suitable for their particular needs,
while engineering tried (several times) to retarget a real-time
operating system to commercial tasks.  This resulted in several
more or less unsuccessful products (some were disasterously
unsuccessful).  Perhaps more importantly, this also resulted in
a battle-mentality where the opposing camps (noteably RSTS/E vs.
RSX/IAS/TRAX/POS) could not be made to cooperate.

In the long term, this resulted in a failure of VMS (which was a
successful solution to the real-time + timesharing problem) from
capturing the RSTS/E customer base, many of whom are no longer
Dec customers.

Whether the battles shaping up between Unix/Risc/Workstation vs
VMS/Vax/"Mainframe" will be more of the same remains an open question.

Martin.

RE: .37

>    Fortunately, that name was changed under corporate duress to CP/OSS
>    (Charlotte Package for Office System Services) to remind sales people
>    that the it was not a corporate product and to keep the corporate
>    product, OFIS, selling.

Slight historical correction.  OFIS never even made it as far as field test.
It was cancelled (justifiably so, in my opinion) in favor of ALL-IN-1 while it
was still an engineering development project.  A few pieces of OFIS (most
notably WPS-PLUS) eventually did see the light of day.  The name change to
CP/OSS thus could not have been done to "keep OFIS selling" since OFIS never
was up for sale.  Unless you mean keep it "selling" to upper management
within DEC.

--PSW