Conference ulysse::rdb_vms_competition

    If we talk about integration from a marketing standpoint then we
    are light years behind. Because Oracle use SQL*.... and Ingres use
    INGRES/..., then the customer seems them as a related set of products.
    
    We have names that don't even mean anything -- Rally/Raleigh/Rallye
    -- whats that? and TEAMDATA -- isn't that a new uVAX, oh no thats
    TEAMMATE.
    
    How many people have stood up in a VIA presentation to explain
    how integrated DEC stuff is then eat humble pie because Rally
    Forms/Reports cannnot be accessed by, say , COBOL; nothing goes
    onto the CDD from Rally or TEAMDATA, etc.
       
    ALso (going on a bit here..) our sales force are always trying to
    compare ORACLE (or INGRES) against Rdb and forget to include Rally
    &/or Teamdata, so Rdb gets a bad name 'as it doesn't include forms
    like Oracle does'.
    
    I have limited experience with Ingres and find it fairly well
    integrated mainly because you can use ingres/menu to get to the
    various products; after that its separate products with perhaps
    some of the forms being common.
    
    I just hope that all our products will integrate with CDD/Plus &
    VAX Forms for some consistency!

< Note 40.1 by MINDER::PICKERING >

    I just hope that all our products will integrate with CDD/Plus &
    VAX Forms for some consistency!

There are two aspects to this.  First, the engineering work needed to 
'integrate' our products.  Second, the marketing work involved in getting the
message across and setting expectations/perceptions.

Of these, the engineering part would seem to be perhaps a little simpler.
The biggest problem, to my mind, is that these products (Databases, End-User
tools (or whatever we call them now), and forms) come from different engineering
organizations with different axes to grind, and varying levels of communications
with other groups.  Until these groups are measured in a meaningful way on how
well our products are engineered to work together (as opposed to inventing
packages to make them look like they work together), I don't see how things are
going to improve. 

The marketing area is, perhaps, a much bigger problem, although I know database
systems is actively working on doing a lot more now and in the immediate future
to boost our products' visibility and image in the market. 

Comments/opinions ?

ORACLE and INGRES' tools often come from different companies, yet they
still succeed in making them seem like its all one integrated product.

ORACLE's latest is the same ALLY product that we turned into RALLY.
Yet, they get "ooh, ahh, wonderful" and we get "yuch, Rally" (from DEC
employees no less)!

On the engineering side, a lot of our problem comes from no one being
able to agree which is the cart and which is the horse.  ORACLE and
INGRES solved that problem very early:  the database system is #1 and
everything else is just 'there'.  At DEC, no one wants to give up their
own product identity and risk their success on just being 'there' for
some other product.  Hence, ORACLE is a database system with lots of
tools while V.I.A. is a collection of things that sort of work together.
That makes it easy for them to set priorities (ie, a common set of
priorities) while V.I.A. is just, well, 'there'.

Unfortunately, we have gone for so many years with our model that it is
difficult to change it.  The very same customers who scream about lack
of integration contribute to it.  For example, its not a problem that
SQL*FORMS requires ORACLE.  But, could you imagine telling the DEC
customer base that VAX FORMS comes with (or requires) an Rdb/VMS
license, so that the price for VAX FORMS is $n,000 while the price of
FMS or TDMS is .25 * $n,000?  I think you'd have more than a little
trouble keeping the current customer base happy with that situation!

Personally, I'd like to see something become 'the center' around which
everything else is oriented.  That is starting to happen on the
engineering side (slowly and painfully).

Re: 40.3
    
    There is no doubt that the perceived lack of integration with our
    VIA products is an opinion shared out here in the field, and
    unfortunately with our customers.
    
    The VAX Information Architecture concept is an excellent idea, 
    however major gaps with product integration make it appear like
    somewwhat of a "marketing afterthought" than a true architecture.
    Still, the concept is excellent.  I agree with Hal in that ONE product
    must be the CENTRAL product, and for that product I beleive we have
    two choices:
    
    	1) Rdb/VMS - Here, we bite the bullet and say to the world that
    		it's Rdb or nothing.  Forget about DBMS, RMS, and build
    		products like Rdb*DTR, Rdb*FMS, etc..
    
    	2) Active Data Dictionary - This would preserve the VAX Information
    		Architecture concept permitting flexibility in Database
    		products.  However, all databases would have to be
    		generated and maintained based on their Data Dictionary
    		definitions (DBMS would have the most difficult time
    		with this).  All programming languages, 4GLs, Screen
    		Packages, OLTPs would operate through this data dictionary.
    		And, just for fun, give the product the ease of use
    		features that would enable it to be used as a tool during
    		the analysis phase of application development.
    
    In response to the pricing concerns customers may have over paying
    for licenses for these base products, it MAY be worthwhile to look
    at the possibility of bundling it in with VMS and burying the licence
    fees there.  We could afford to charge much less for this add-on
    if shipped with every VMS system. (VAX/VMS services for MS-DOS is
    now included with DECnet licenses).  However, this decision involves
    many factors outside of "database products".
                                                
    Rob Charuk
    SWS Toronto

      This is a double-edged marketing sword. VIA is our best tool for
    competing with Oracle and Ingres in the installed base, beacuse
    most of our customers have an investment in either a DEC forms product
    or CDD. Oracle and Ingres can't use any of VIA including RMS files
    directly (although Ingres now has a read-only RMS Gateway).
      If VMS/VIA is positioned and presented correctly it can be a real
    hedge agaist the encroachment of third party databases. Most of
    the losses I have seen involve an inappropriate $GL tool layered
    on RDB. If we use our CMPs as well as our own products as a base,
    and pick an appropriate product set we usually win. 
      The usual failure reasons are either a poor positioning of VIA
    or an absolute insistance on a DEC-only solution. There are compelling
    reasons to control the database. The 4GL is the real leveraging
    tool in this type of competition. Rdb should not lose as a database
    engine. The development environment should be emphasized in this
    kind of competitive situation. How well can the customer utilize
    his current sw/hw investment if his database is "isolated" from
    the VMS environment?
    ---- Michael Booth

re: -.4
>    	2) Active Data Dictionary - This would preserve the VAX Information
>    		Architecture concept permitting flexibility in Database
>    		products.  However, all databases would have to be
>    		generated and maintained based on their Data Dictionary
>    		definitions (DBMS would have the most difficult time
>    		with this).  All programming languages, 4GLs, Screen
>    		Packages, OLTPs would operate through this data dictionary.
>    		And, just for fun, give the product the ease of use
>    		features that would enable it to be used as a tool during
>    		the analysis phase of application development.
    
I am interested in CASE tools for the whole of application development and
would like in an Active data dictionary at the heart of a Software
Engineering product from DEC. However, I understand that just such a product
is being developed and it will be ISAM based...

So much for integration (if true).

    Have we ever considered the Hewlett-Packard approach to database
    control?  They simply give the database away as part of the operating
    system license and then sell query packages, 4GLs etc. to go with
    it.  As a result, there really isn't any 3rd party database for
    the HP 3000.
    
    Doing this would certainly provide a clear focus for VIA development.
    
    -dave
    

>    Still, the concept is excellent.  I agree with Hal in that ONE product
>    must be the CENTRAL product, and for that product I beleive we have
>    two choices:
    
>    	1) Rdb/VMS - Here, we bite the bullet and say to the world that
.
.
.
>
>    	2) Active Data Dictionary - This would preserve the VAX Information

I would say that, product based is too short sighted.  What I mean my 
this is that an architecture should provide room for growth.  In the 
past the CDD and DBMS/RMS were the storage facilities.  Now this would 
suggest CDD+ and Rdb/VMS replace those two in the charts.  I would 
suggest that changing ideas to RALLY/Rdb, DTR/Rdb,....would snowball 
into a very large problem in the future.  What happens to the VAX 
Information Architecture customers the day "future dictionary" and/or 
"future database" are announced, and they have spent there last 2 
years perfecting an "DTR/Rdb, ACMS/Rdb, TDMS/Rdb and Rdb/VMS" 
application"?  Well, I would say that they would get very nervious 
about even buying another DEC software product, if in the past 
products are 'dropped out of the architecture'....


-Jay

The problem with giving away the database system, and its not an idea
I'm opposed to under the right conditions, is that development funding
tends to dry up since you can't show any direct revenue/profit for the
DB system.  Sure, HP gives away the database software.  IMAGE also went
for nearly 10 years with only trivial improvements.  I haven't heard
rave reviews for their relational product on Spectrum either.  In other
words, this strategy is NOT one of leadership in the database arena.

In fact, HP has signed on to market ORACLE on the Spectrum.

    If we combine the suggestions of Rob Charuk and Michael Booth, we
    might have VIA as the identity vehicle.  i.e.
    
    	VIA/Relational
    
    	VIA/CODASYL			(no, we don't ship the committee)
    
    	etc.
    
    And, at the risk of annoying my immediate colleagues in OLTP and
    bringing back the memories of old wounds, for transaction processing
        
    	VIA/TRAX		(for INTACT+CCD+INTACT-forms+hashed
    				files+RMS journalling, etc.)
    
    	VIA/TRACE		(for ACMS+CCD+TDMS+Rdb+DTR+ etc.)
    
    The names, TRAX and TRACE, are straw suggestions; what is needed
    is a set of names that identifies a *family* of related packages
    where each member of the family is itself a bundled set.  At the
    same time, we can improve on the current acronyms that don't help
    in the marketplace (e.g. ACMS).
    
    The concern of Berenson expressed in 40.3, that a package name implies
    only packaged purchasing, need not be so.  I recently bought a truck.
    I could have bought each piece separately at the parts counter if
    I really wanted, but what the salesman sold and what I bought was a 
    "truck", complete --- even with start-up service (a tutorial on the 
    controls and subsystems by the salesman, an inspection sticker, and 
    half a tank of gas).  The package was called a "truck" --- functionally
    complete and easy to evaluate in a benefits/cost sense.  If I had
    special needs, I could have bought a "cab and chassis" from the
    dealer and a cargo subsystem from the dealer or a third party.
    
    I suggest that we can have the benefits of named packages while
    still giving our customers the ability to mix and match subsystems.

    
    Al, in .10 you suggest:
    
    >    ...a set of names that identifies a *family* of related packages
>    where each member of the family is itself a bundled set...
    
    Are you aware of VAXInfo 1, 2 and 3, which are packages of VIA products
    along the lines you suggest?
    
    A question for those out there selling:
    Has the VAXInfo packaging given customers a warmer feeling about
    the degree of integration between our products?
    
    	Andrew.

    
    I can understand that the name issue is important, but just naming
    it VIA/Relational, Rdb*DTR, etc. can't be the "integration solution",
    can it?  I would like to hear where integration counts, i.e. what
    is it that ORACLE & Others have integrated that we haven't?  End-user
    interface style, common access to different data models, or what?
    
    Further, do our customers typically move from DTR to Teamdata, to
    RALLY, or what's the scenario?
    
                                                  Lars Foldevi, DBS-PMM
    

1) VIA is a registered trademark of another firm.  We can not use it for
ANYTHING we do in writing.

2) VAX VIA/Rdb/VMS is not what I would call a reasonable name.  Further
renaming of products will just confuse the whole issue.

3) Your truck analogy is way off.  Your right, you didn't buy a bunch of
parts you bought an integrated vehicle.  However, with the possible
exception of the radio, every part in your truck is useless without the
whole truck.  The problem making a system out of our parts is that the
parts have intrinsic value on their own, and no one is willing to
sacrifice that standalone value.  Your transmission on the other hand
has no value outside of the truck, so it is optimized for that environment.

    
    Re the earlier note on the different markets for VAXInfo I II and
    III, I don't think these are marketed in such a way as to stress
    the integration we have. I've been along to presentations where
    we've been trying to sell (say) VAXInfo III, and where different
    people have been called upon to present on ALL the constituent
    products. This hardly makes them seem like an integrated product
    set. So it seems as though the whole VAXInfo concept hasn't yet
    been completely understood internally, and in this case it's hardly
    surprising that the customers miss out on how well integrated most
    of the products are.
    
    Chris