Conference azur::mcc

    I passed .0 on to a friend of mine that knows a little bit about Sun
    workstations.  Here's some info that might be helpful.

From:	UWORKS::elkins "Adam Elkins" 12-JUL-1991 16:14:58.08
Subj:	Re:  SUNnet Manager 

I'm not familiar enough with the product to answer, but I did see
it at INTEROP, and it was superior to our product in several ways.

1.   it was PRETTY PRETTY PRETTY.  Lots of cute pictures, the ability
to put a map in the background of your network.   The little workstations
look like workstations while our icons look like PDP10s.

2.  it was FAST!   Ran on top of flat files instead of our Ingres database
so there wasn't all the database overhead at startup time necessary.
Also, due to an engineering error, each module of MSU had to start
its own session of Ingres, a VERY expensive operation.   I believe
this may have been fixed but I'm not sure.

    A recent SNMP manager survery in network world indicated that of the 50
    SNMP managers in the survey, about half were on SUN machines, the other
    half were on PC's.  DEC was on DEC hardware, NCR was on NCR hardware,
    and there was one on an APPLE.  I think part of the big deal is that in
    the UNIX/IP market, SUN is the de-facto workstation - and so customers
    are looking for software that runs on their SUN.  Also, there are
    utilities in the SUN-OS, which sort of integrate with the NETmanager
    that help manage the 'open network computing' environment that SUN
    workstations use... 
    
    It's also an issue of what the market really wants for integration.  Even 
    with MSU, you can see the difference to MCC.  When using the MSU terminal 
    server support, you are literally 'logged into' the terminal server and 
    must use it's syntax... Polling and map status are not there in the first
    release - cause there is little integration.  However, if you want to
    manage a DEC terminal server from a ULTRIX platform, MSU is the only
    game in town, so the level of integration is whatever you can get. 
    
    MCC's concept of integration is not being copied by ANY vendor.  If
    ease of use, and ease of extensibility problems ever get solved, it
    won't only be the 'wize planners' that are interested in MCC, but it
    will trickle down to the actual managers that have to get a job done.
    MCC IS solving the hard problem - but doesn't have the 'incremental'
    approach that helps the money come in while the real solution matures.
    This is where MSU can help - but the internal fighting and lack of
    synergy between the MSU and MCC groups has limited it's success.
    
    Right now, those with under 10K to spend are looking for software to
    run on what they already have plenty of (SUN workstations) and are
    looking for something that is slick looking, and can manage what they
    want.  Since there are dozens of vendors that support their hardware on
    the SUN NETmanager - it's a nobrainer - 
    
    bill

	re -.1:

	Bill,

	I think most net managers would disagree with your 2 basic premises:

>    MCC's concept of integration is not being copied by ANY vendor.
	
	But there IS very real integration *of SNMP-manageable devices* 
	available now by the competetion.  And that's basically what is needed
	now.

	When CMIP is what is needed, then these products (and their many third-
	party developers) will make CMIP available.  It's probably already 
	there.

>    MCC IS solving the hard problem - but doesn't have the 'incremental'
>    approach that helps the money come in while the real solution matures.

	Which hard problem is that?  Autodiscovery?  Autoconfiguration?
	Trouble ticketing/tracking?  Event handling?  Distributed polling?

    The hard problem I'm refering to is integration.  The rest of the
    market is integrating using SNMP - and indeed that is making the
    selling of DECmcc a bit harder - however there are other protocols that
    must be managed today.  Digital is responsible for several of these
    protocols - having been in the networking business before SNMP came
    about (yes, there was management before SNMP :-)  Since people are not
    going to throw away their DECnet, DEC terminal servers, and DEC
    bridges, they need to manage them.  There is also SNA stuff around,
    signal 7, various T1/T3 management protocols, appletalk, and the like.
    
    The method of integration that most SNMP managers use, is thru the
    database.  Ie, all devices can be registered and shown on the map, but
    when you go to query or set them, you must understand the syntax of
    that device.  MCC uses the same SHOW/SET application, no matter what
    the protocol.  The same NCL language is used for automated routines
    that need a command line - and protocols are 'normalized' to MCC's
    registered verbs and attributes (at least that is the theory).
    
    The challange that MCC has to rize to is the pseudo-integration via
    SNMP, that is solving most of the 'internet' manager's problem. 
    Applications working across multiple technologies (all using SNMP) are
    going to be coming out like blackflys in May, at this fall's Interop
    show.  However, the telecom manager, who still deals in bandwidth
    services from the RBOC's, PBX's, and the like - still has a problem.
    The field has changed a lot since MCC's concept of integration was
    thought up - but there is still the need for that kind of integration.
    It's no longer the bulk of the market however.
    
    bill

    We keep looking for a technical answer to a non-technical question.
    The SUN and HP marketing folks are doing a bang up job. They point
    to the lack of a clear message from DEC and I am not pointing a finger
    at our marketeers. I am pointing out that we only officially talk
    about soon to be delivered product while the competition can talk
    futures too infinity. DECmcc and MSU as they were at the last release
    point is being compared to a future SUN/HP solution that we may never
    see. 
    
    When it comes to the U* word on Workstations, DEC needs to learn how
    to market and build marketplace perception. We are getting beat by
    their marketing. Period!
    
    wally

    I have a beef with DEC's pricing policies - we don't go for volume, we
    go for 500% profit margin and then we're soo disappointed when we don't
    sell a lot!  Furthermore we've gotten used to designing products that
    won't sell in volume. 
    
    However, even Wally would admit that engineering has made a few
    colossal mistakes in the Unix workstation market, starting with
    Ken Olsen's "snake oil" speech!  and that MCC has not been immune
    to this. 
    
    Furthermore, we made it more difficult for marketing by coming out with
    such a complex, difficult-to-install, difficult-to-use product set.   I
    think we in DEC have a lot to learn about how to produce marketable
    products, this ought to be a design goal instead of an afterthought;
    we need not have such a condescending attitude towards the "wiz"
    implementers.  For example, our iconic PM was not available when the
    product first shipped, but from a marketing point of view, this kind
    of functionality is vital to marketplace perception of the product.
    
    Perhaps our attitude is like a man walking through a city street
    with $20 bills hanging out of his pockets, who is then indignant that
    he got robbed!