Conference 7.286::digital

re Note 2359.0 by SMAUG::GARROD:

>     how can Digital continue to engineer exactly what it was before?
>     There's a lot of mouthing about changing direction, doing things
>     differently etc. But as far as I can see it's business as usual.
  
        A very good question.

        I think that this has a lot more to do with the low morale
        around ZKO than even the TFSO.  Almost nothing has changed. 
        And we know that much must change.

        Bob

	Can you tell me specifically what DECImage products are being
	cancelled or give a pointer to the note in SWE_QUESTIONS which
	has this information?

	I've got an application which is using DECImage.

Attached is a memo I got when I asked the same question
    
                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     27-Jan-1993 08:24am EST
                                        From:     CROCKETT_PAU
                                                  CROCKETT_PAU@DNEAST@MRGATE@NIOMTS@NIO
                                        Dept:      
                                        Tel No:    

TO:  michael eck@cyo
TO:  Richard datzman@aci
TO:  pamela moll@aci


Subject: DECimage ****** Alive and well - go sell!!!!                

From:	A1VAX::MAMONE "26-Jan-1993 1709" 26-JAN-1993 17:18:34.69
To:	@DECIMAGE_INT.DIS
CC:	MRKTNG::PHADKE,RINGLEBEN,MAMONE
Subj:	WE JUST MOVED (we didn't go away)

We (the image group) have recently moved from MKO2 to ZKO2 and joined
TNSG as part of the Workgroup Computing Group under Barry Reynolds and 
Stan Smits. Our phones have been temporarily out of service. We are now back 
"on-line." You can reach Barry Washington, Bruce MacDonald, Daryl Rosen and 
myself on node A1VAX:: 

Our new phone numbers are:

Barry Washington 381-0651
Bruce MacDonald  381-0748
Daryl Rosen	 381-0882
Vince Mamone	 381-0580

Engineering has also moved to ZKO2 and is still managed by Charlie Ringleben. 
Charlie reports directly to Stan Smits and has about 14 engineers in ZK. 
This team is part of a larger development effort based in APD.

The notes files and public directories will be back online as soon as the
systems are installed. Hopefully this will be by the beginning of Feb. If you
need information feel free to call one of us or Paul Crockett at 271-6768 
(DNEAST::CROCKETT_PAU). Paul is in ASO and can provide presales support for 
DECimage EXpress, Perceptics and Image Now.

Image is now part of the Document Management effort headed up by Stan Smits
with marketing and product management under Dilip Phadke. The future should
see the integration of image into a larger document management product set 
which include workflow, text document management and office.

In case anyone comes across a note from Dick Mahoney of TNSG on retiring 
products that list DECimage don't get concerned. This memo is incorrect.
We are expecting a clarifying message from upper management to set the record
straight. There are no plans to retire DECimage Application Services, DECimage
Char. Recognition, DECimage Scan, or DECimage EXpress. We have submitted 
DEX V2.1 to the SSB this week and expect it to ship on Feb 12. We are in the 
process of porting DAS to AXP (OSF/1 and Open VMS). We are starting a new 
project for DEX V3.0 which includes Open VMS/AXP support. 

We are also working with the Megadoc group in APD to develop a cohesive set
of products that have a common client and applications and support the 
strategic server platforms. Expect to hear more on the messages and strategy
for this product space in the near future. 

Please distribute this message to other imaging folks.

Vince Mamone
Product Manager for DECimage


VMSmail To information: MTS$::"cyo::michael eck"
VMSmail CC information: MTS$::"aci::Richard datzman",MTS$::"aci::pamela moll"
Sender's personal name: DEX Customer Support 271-6768

>    By the way I don't for a minute believe the 'political speak' in the
>    latest Keillor memo that says that we can continue to do exactly what
>    we were doing before with less people due us being more efficient
>    and the fact that some shell games have been played by moving projects
>    out of TNSG. If they're still being done they are costing DIGITAL
>    money.

In the past, the software engineering of Digital-developed products has
been outsourced to 3rd parties.  These 3rd parties paid for the ability 
to enhance DEC software.  DEC continues to sell these products.  We (DEC)
get a share of revenue for licenses sold by the 3rd party and the 3rd party
gets a share of the revenues when DEC makes the sale.  The 2 products I know
about were outsourced 2 or 3 years ago - the VAX COBOL GENERATOR was one of
them.

I don't know that this is going on now with the projects which recently lost
funding (notice I didn't use the deprecated "C" word :-).  But if it is (and 
I've heard rumors that 3rd parties have made bids), this is one way that Digital 
could do more with less.  

Unfortunately, this is all just speculation on my part...

    You have not elevated my confidence about this by citing the precedent
    of the insignificant VAX COBOL GENERATOR to make decisions regarding
    the 3 or 4 billion that gets spent that has the potential to bankrupt
    Digital.
    
    I'd like to know if the probblem is more complicated that this:
    
    Large volume (and everything that goes along with it, shrink-wrap
    packaging, human-understandable pricing, efficient selling channels)
    means that you call sell really good software cheap.
    
    You can even pick your role: author, marketer, channel, after-sale
    service provider.
    
    Small volume means grief in planning, implementing, and testing, and
    then you've got packaging, pricing, and channels.
    
    The company has to decide to substanially compete with Borland, Lotus,
    Microsoft, Symatec, etc. on Windows, etc. or continue along the same
    track and compete with the ghosts of Wang, Data General, and Prime.

re Note 2359.5 by SDSVAX::SWEENEY:

>     The company has to decide to substanially compete with Borland, Lotus,
>     Microsoft, Symatec, etc. on Windows, etc. or continue along the same
>     track and compete with the ghosts of Wang, Data General, and Prime.
  
        Agreed -- but the decisions and changes to be made are many
        more than simply, as some seem to think, the right choice of
        platform.  It isn't simply a matter of say doing the same
        thing on Windows what we formerly would have done on VMS.  It
        is a lot more than simply hoping that this time our
        proprietary system really will become a dominant industry
        standard.

        Bob

re: .5

>    The company has to decide to substanially compete with Borland, Lotus,
>    Microsoft, Symatec, etc. on Windows, etc. or continue along the same
>    track and compete with the ghosts of Wang, Data General, and Prime.

Well, it seems clear to me, from certain product transitions to Phase V that
is is very un-PC (double meaning intended) to even consider competiting with
vendors such as these _if_ your intent is to compete with "shrink-wrapped
software."  I get the impression that we, as a company, have conceded that 
market to these vendors and are not going to make an attempt to compete at that
level.  The focus is more on infrastructural underpinnings on which these
mass-produced apps would run.  Of course, were you to ask me if this is a 
going out of business strategy, my answer would be <INTERRUPT>

%SYSTEM-E-UNPCREPLY, This reply is not PC and has been edited by the system.

re Note 2359.7 by SCAACT::RESENDE:

> I get the impression that we, as a company, have conceded that 
> market to these vendors and are not going to make an attempt to compete at that
> level.  The focus is more on infrastructural underpinnings on which these
> mass-produced apps would run.  Of course, were you to ask me if this is a 
> going out of business strategy, my answer would be <INTERRUPT>
  
        Let's see how far I can get towards completing the thought:

        There is no way that a mass-produced app will be built upon a
        DEC-proprietary infrastructure (unless that infrastructure
        became wildly popular FIRST).  The best we could do is to
        implement or emulate an existing industry infrastructure.  
        �0DX0205

��������(
L�+�
h�
        �
�

|        �0DX0205

��������(
L�+�
h�
|        �
�

My thoughts exactly.

Our strategy in software used to be to try to do everything.  Maybe we would 
end up not being best-in-market at anything, but we would provide a complete 
line for those customers who want to buy everything from a single vendor.  
Unfortunatlely, most of the marketplace has evolved beyond this, and the 
"one-stop-shopping" approach isn't viable any more, if it ever was viable.  So 
Bill Strecker's new plan is for engineering only to develop products were we 
can be #1 or #2.  Switching from the old strategy to the new strategy means 
that DEC's engineering departments will have to stop work on the products in 
those areas where we cannot (or choose not to) invest the effort and resources 
to be #1 or #2.  Such products must either find homes with ISVs who are willing 
to invest the effort in them, or they must be retired.  This housecleaning 
process is what you see going on in TNSG right now.  Personally, I think it's 
long overdue.

--PSW