Conference 7.286::digital

        Re:                       <<< Note 1787.0 by MCIS1::RIZZO >>>

Is there a hidden assumption in your question, one that says 
"all good things are planned by somebody"?

If so, I would like to suggest the alternative.  "Many good things
are the result of happy accidents".  In particular, I would put Visicalc, 
MSDOS, LOTUS 123, and such into this category.  I am sure there were people
who "wanted" those products to have the success they did.  I am not sure that
anyone had the foresight to "plan it".  I think it more likely that they
had a good idea and the stubbornness to stick with it until it paid off.

fwiw,

Dick

re:.1
Is there a hidden assumption in your question, one that says 
"all good things are planned by somebody"?

The 1st assumption I have made is that someone or organization is responsible 
for porting applications to Alpha, therefore someone must decide the priority of 
this conversion as it won't be cheap; therefore someone must or should be 
looking at what applications will still have market appeal in 2 years. In order 
to do that someone must or should have an idea what will be required in the 
future that may not be available today.

For example, does the New Ventures group investigate new application 
opportunities?  

Who is responsible for DEC's application strategy?

As for happy coincidences, I for one know that Mitch Kapor did some market 
analysis and believed there was a better way to work with arrays than the SAS 
or SPSS approaches. I don't think Apple ignored Mitch, in fact they funded 
some of the development. Apple realized early on that applications were the 
key to their success and bought/established Claris. Even Bill Gates got funding
from his friends at IBM. Applications are like the fuel of a car. Without it, 
we're going no where.

So I ask again, 
 "Who (and where) in Dec is responsible for projecting the next application 
waves?"
 "Is there a group resonsible for the Application 
Strategy? "
 "Are any of the IBU's looking at the next generation of applications that will 
be considered revolutionary?"
 "Who is responsible for determining the application portfolio 
for porting to Alpha? How are the priorities assigned?"

_Carol

You might try the Strategic Industry Analysis group.  Paul Kampas is the 
program manager.  He is in MLO, MSR1::KAMPAS, DTN 223-6377.

Another suggestion: David Stone has chartered his planning staff to do
this work. He uses this information to guide the budgeting process.
Perhaps someone knows exactly who or where you might find out what the
strategy is. I expect that you would need a reasonable business reason
to request any information which might not be generally available
within Digital.

    
    	Porting effort to Alpha is well under way; however, discussion of
    	priorities is not a topic for this conference.
    
    	John

    Contact ISVG (Independent Software Vendor Group) .... of which I am
    currently a member.  This is a 60+ member group (primarily marketing)
    which leverages sales of DEC systems (including O/S) by working with
    Software Vendors (e.g. Lotus) to port their applications to DEC's
    systems.
    
    We have a plan for DEC OSF/1 (both Alpha and MIPS) and are funded by
    Demmer to provide Alpha VMS application porting "work" with 3rd
    parties.
    
    You may contact me for more details, and/or the ISVG MT (Management
    Team), i.e. Steve Tocman, Mike Wells, Mike Mancuso, Bob Dunham, etc.
    
    Thanks,
    
    Tim O'Neal 297-3387

    Digital has had an abysmal track record in developing and marketing
    applications. I suspect the real problem has been somewhere between
    Engineering and Marketing, but be that as it may, it now appears that
    anyone with responsibility or authority tends to deliberately avoid
    going in the direction of actually committing to an application area,
    preferring insted to depend on third parties.
    
    The net result, as someone stated in this forum a few days ago, is that
    we have plenty of tools and infrastructure, but few applications. It is
    almost frightening to realise that the nearest things we have to actual
    applications are All-in-1 and Notes. All right, I'll stretch to
    DEATHwrite, too.
    
    Part of the reason for this is that, despite David Stone's words to the
    contrary, our engineering management continue to insist on developing
    for VMS and UNIX (generic), forgetting that the bulk of the application
    market is in fact Mac and PC. For those who haven't got the message
    yet, there are (approximately) 80 million PCs, 20 million Macs, and
    less than 1 million "other". 
    
    Any independent application developer looks at the market and develops
    a product strategy based on  that kind of information.
    
    But most people I know in positions of responsibility are happy to
    remain in ignorance.
    
    There are exceptions, and I'll answer one of the questions posed in .0,
    namely "who is recommending new applications"?
    
    For the upcoming and exciting multimedia arena, try John Manzo (MRO1).
    I think you'll find him an open person, ready to listed to new ideas.
    
    Ray
    
    
    
    

RE: .7

I think that a large part of the problem with Digital's lack of sucess
in the applications area is that the organizations that

In theory there are two paths that applications get created.  The
process method would be for marketing to determine a business need. Then
they would create product requirements and ship them off to engineering.
Engineering would the produce the product according to the
specifications.

The other method would be for individuals to come up with an idea,
develop it.  They show their ideas and they catch on, finally we have a
product.  Digital sucesses like All In ONe and DECmessageQ queue came
about in that manner.

I think the problem in Digital is that as things have become more and
more bureaucratic developing a product by following method two has
become less and less likely.

As for method 1, unfortunately Marketing has little power.  What winds
up happening is that as soon as Marketing ships off the requirements to
Engineering, engineering says "No, we know better".  As engineering has
become increasingly isolated from the trenchs their way is often wrong.

What I see from the trenches is that we have now have an engineering
management driven system for new products that takes the worst of the
two previous methods (You engineers can tell me if I'm full of
it...that's what my mother always says).  What appears to happens is
that requirments for applications are comming out of the engineering
bureaucracy without any marketing basis and without the inspiration of a
midnight hack.

Last week I got a Phase 0 announcement for a product (That will remain
nameless) that I would tell they'd be lucky to sell ten copies.  I'm
sure that the phase 0 documents say that we will sell in the thousands
but those in the trenches know there is little need for such a product.

Fortunately, the number of such Phase 0 announcements has dramaticaly
dropped in the past few years.

The problem is that in order to develop applications we have to have
developers who know industries.  Sales reps need to be able to walk to
an engineer's cubicle and say "Hey, Jim!  How'd you like to go with me
to Federal Insurance to here about their 'mumble' problem that you might
be able to to get some ideas."

Digital is in no position to do that.  How many Industry Marketing
Groups are located in facilities with sales reps that call on a major
account for their industry?  For that matter how many Industry Marketing
Groups are located within the same state as on of their major customers?

It's even worse when it comes to engineering's isolation.  Hearing what
the customers' techies have to say twice a year at DECUS just won't
solve the problem.  I bet if Digital had Engineering groups located in
sales offices it would generate many ideas for new products.  In fact, I
know that in many sales offices there are one or two technical people
who have product ideas in prototypes that might be developed.
Unfortunately it's tough to make much progress with one person in your
spare time.

Unfortunately in these times of cost cutting Digital has been retreating
away from the customer due to the low cost of office space in the GMA.

    re: -.1
    
    As they say, "truer words were never spoken".  Good note, IMHO.
    
    Steve

	re .7:

>
>    Digital has had an abysmal track record in developing and marketing
>    applications. I suspect the real problem has been somewhere between
>    Engineering and Marketing, but be that as it may, it now appears that
>    anyone with responsibility or authority tends to deliberately avoid
>    going in the direction of actually committing to an application area,
>    preferring insted to depend on third parties.

	Interesting perception. The way I would put it is that nobody
	has defined exactly what Engineering and marketing do, and the
	result is that it has settled down something like this:

	Engineering	* Devise product strategies (e.g. VMS, UNIX, Alpha,
			  DECwindows, etc.)
			* Propose, authorise, and develop products
			* Maintain and enhance products
			* Do some PR
			* Do a good deal of market research (e.g. CABs, EICs)

	Marketing	* "Rollout" (i.e. PR, roadshows, etc.)
			* Push products that aren't selling (e.g. by begging
			  account managers to sell them, free sales support)
			* Make announcements of things Engineering produced
			* Bring to Engineering's attention things that
			  customers are medium-hot about (white-hot customers
			  rate an Engineering VP right away, Marketing might
			  not even know he's in the country)
			* Be responsible for country sales of products, even
			  though they don't control any of the relevant
			  resources    

	It gets a lot more complicated, partly because there are a zillion
	groups called "Marketing", many of which report in to Engineering.

	As someone who works for Marketing (I think, this week) the salient
	fact is that all the power rests with Engineering. All the really
	big decisions are made by Engineering, and Engineering is never
	obliged to listen to Marketing.

	This sets up a vicious circle. Because Marketing is essentially
	powerless, it doesn't get the funding or the attention it should
	get. Thus, engineers complain that Marketing isn't doing a good
	job, that it is unable to submit proper sets of requirements, etc.
	This is largely because nobody has given Marketing exclusive
	responsibility for doing marketing. It's a management truism that
	if you delegate a job to somebody, and then actually do it over
	his head, that person will wilt and fade.

	/Tom

Ahhh Gi'day...�

    Marketing doesn't  get  the funding or power it "deserves" for one very
    good reason.

			      Non-performance.

    It's been seen as a cushy retirement job in Digital for some time.

    
    so perhaps we need the "death" of central engineering, and move the
    function into the sales office.  Seems drastic, but then we've
    engineered some rather drastic disasters, as far as customer needs
    are concerned.  
    
    I used to argue for more centralized inferstructure - reduce
    redundancy, manage resources more carefully.  However, it clearly
    does not work too well.  Being in central engineering for the last
    9 years, I've witnessed first hand, several times, how effortlessly
    we can ignore what the customer is saying - or worse, pervert the
    message in one that is more self-surving.   The outcome is readily
    obvious - we're losing money and laying off people.
    
    The villan is just people behavior - KO is right on the mark when he
    says good times are more dangerous than bad times.  It is one thing
    to recognize when things go wrong, but it truely amazes me how even
    with such obvious numbers as the PC/Other platform numbers that Ray
    conservatively stated, there is still a determined mind-set to not
    hear them, see them, and most deadly, understand how and why they are
    as they are.
    
    bob
    
    

What's the old saying? Management gets what it inspects not what it expects.
As long as management expects marketing and engineering to do the right thing
not much will change. The same is true for SI, sales management 
still inspects certs-per-second and expects sales people to sell SI when not
taking orders.

    Isn't it amazing that we are back at a full circle again: We need to do
    more QFD product development. Why? Because that approach will solve
    some of this corporation's biggest problems, one of which is this very
    issue of "powerless marketing and deaf engineering". Why?
    
    Because the QFD approach demands that key people from the entire
    product's lifecycle are brought into the same room and are asked to
    develop the product, as a team, together with information and indeed
    participation from customers, where possible.
    
    The loudest voices (usually engineering managers and "architects") are
    muted, because the structured brainstorming and development processes
    demand equality of ideas.
    
    There will be engineering people, who contribute the technical
    information into the system. There will be marketing people, who
    contribute market sizing and research, together with competitive data
    and the voice of the customer. There will be sales people, who should
    "walk in the customer's moccasins", and represent the customer.
    Manufacturing and distribution people. And even actual customers.
    
    Ken Olsen's recent memo about improving our product development could
    not be answered better. He asked that we set product goals, and plan to
    meet them, and be better, cheaper and quicker. It has been shown that
    QFD can improve the productivity ration by not just one, but two orders
    of magnitude (for more information, read the QFD notesfile on
    METOO::QFD). I've never seen a better way of setting product goals,
    too.
    
    This is not going to be achieved by a bunch of engineering managers and
    architects, fighting political battles with marketing, in David Stone's
    current "Domain" meetings, sorry David. When I see the kind of people
    contributing to those meetings, and hear the stories about what's
    happening, it merely confirms my opinion that it's just "business as
    usual". A bunch of senior people who have completely lost touch not only
    with the market, but even with the technologies, making far-reaching
    decisions. A bunch of "architects", who love to develop infrastructure,
    but no products.
    
    We hear that we are supposed to "do QFD", and David Stone recently sent
    a memo around telling all product teams to use it, but what does that mean?
    It's incredibly difficult to bring the right people together in this
    company. To do it properly, it takes a minimum of a 10-day working
    session, in my experience, to do the early Planning and Analysis QFD.
    If you invite sales, marketing, engineering people, etc., what happens?
    
    You can't get them all into a room, and anyway, they are all too busy
    developing code (in a vacuum), writing Market Requirements Documents
    (that others seldom read), or touring around the engineering
    departments looking for a solution for their customer (reasonable, but
    there should be SOMEONE in sales who could contribute to product
    development?). And for ten days? Hah!
    
    Yet, if you reason with people in the cold light of day, ten days are
    nothing compared with the usual two years producing the first version,
    which everyone knows you're not going to ship anyway, right?
    
    In Ken's memo, he said that people will be "rewarded and admired for
    leadership". 
    
    Ken, this is an open letter to you, because I would like to know how
    you plan on implementing that. Because maybe I'm completely up a wall,
    but I like to think that I've displayed leadership in quite a few areas
    over the past couple of years, and frankly, don't see where my rewards
    are coming from.
    
    Sincerely,
    
    Ray

re Note 1787.7 by CALS::THACKERAY:

>     The net result, as someone stated in this forum a few days ago, is that
>     we have plenty of tools and infrastructure, but few applications. It is
>     almost frightening to realise that the nearest things we have to actual
>     applications are All-in-1 and Notes. All right, I'll stretch to
>     DEATHwrite, too.
  
        But Ray, we in TNSG *pride* ourselves on not developing
        applications, but, rather, "middleware" (tools and
        infrastructure).  The strategy is successful!

        Bob

    RE:15
    
    How do you measure success?  Does our "middleware" make DIGITAL
    products the favored choice for developing new applications?  Are
    we racking up large and increasing unit and dollar volumes on sales
    of our "middleware"?  Which products are doing well?  Who is buying
    them?  Do we have any idea why?  Are we finding new needs in
    "middleware" and delivering products that meet those needs?
    
    A claim of success ought to be backed up with some facts.

    IMHO the "application strategy" is to work with third parties to
    provide the applications on our platforms, infrastructure and 
    middleware.
    
    That is similar to Apple's strategy - although admittedly Apple
    does have an application development/distribution subsidiary
    called CLARIS.
    

    Good examples for development environment "middleware" are:
    
    	SuperCard
    	HyperCard
    	Asymmetrix Toolbook
    	Serious Software
    	Omnis7
    
    Bad examples are:
    
    	VUIT
    	U/I Widgets of various kinds
    
    Why? Because the good examples are selling hundreds of thousands
    (HyperCard is in the millions) of copies, and they are EXCELLENT.
    Non-programmers can develop, after a couple of weeks, very
    sophisticated applications. Because they run on Macs and PCs, which are
    plentiful and cheap. Because their performance is generally excellent.
    Because applications can easily be tailored. Because the development
    environments are cheap (the most expensive, Omnis7, is about $1200).
    Because run-time licences are either free or cheap (never more than
    $250).
    
    Contrast the above with Digital's application development environments,
    and the quality of our "middleware" is abysmal.
    
    Ray
    copies

If you want to look at a great piece of middleware, look at Borland's
ObjectVision...or TurboVision which comes with C++ V3.0 (when's our 1.0 C++
due?  What 4GL can we use to generate code?)  Try putting applicatiosn together
with VAXSet (or whatever its called now) as quickly as you can with
ObjectVision...We provide pieces and parts, sometimes packaged together. 
Borland provides the package and people don't have to care about the parts.

    The benefits of QFD are just what this company needs.  The problem is
    that to get them a certain process must be followed, and all the talk
    about TQM is only exhortation: not any different from the "persuasion"
    one hears in church.  
    
    It's inefficient and completely ineffective to exhort exmployees of
    this or any other company to act in the best interests of the company.
    A commercially successfull company is not a democracy where majority 
    rules.  The board of directors should set the goals and processes so 
    that the comany is profitable and successfull.  Without this clear 
    and enforced direction, the employees are left to their own devices, 
    which is exactly the situation in Digital today.
    
    Anarchy is not a model of company behavior that leads to commercial
    success.
    
    
    David

    
re.20
    
>    A commercially successfull company is not a democracy where majority 
>    rules.  The board of directors should set the goals and processes so 
                                                   ^^^^^^^^^^^^^^^^^^
>    that the comany is profitable and successfull.  Without this clear 
>    and enforced direction, the employees are left to their own devices, 
>    which is exactly the situation in Digital today.
>    
>    Anarchy is not a model of company behavior that leads to commercial
>    success.
    
In a company that is supposed to sell "brainware" rather than robot-
    produced goods, I'd insist on the importance of MOTIVATION as a
    primary human brain fuel.
    I'd also choose for longer term sucess, positive motivation
    (as opposed to short term perhaps efficient fear  of getting
    TFSO'ed..... negative motivation)
    Hence, I'd translate "setting goals" as showing where the FUN IS
           and
           "setting the processes" as showing how the FUN shall be
           shared and where the FUN and "anarchy" eventually stops.
        
    Else I am afraid that a human brain (in particular the creative corner)
    won't react so well to "funless" stimuli.
    /fred
         
    
    

	re .0:

>	Who (and where) in Dec is responsible for projecting the next
>	application waves?

	Nobody, as far as I know, and God knows I've looked.

	In theory, Bill Johnson as VP for Marketing. If Bill is in charge
	of Marketing, then he must be in charge of this, as it is one of
	Marketing's major functions. Only question is, "Does Digital really
	want to have a proper Marketing function in 1992?"

	re .11:

>    Marketing doesn't  get  the funding or power it "deserves" for one very
>    good reason.
>
>			      Non-performance.
>
>    It's been seen as a cushy retirement job in Digital for some time.

	(1) This is not true of all marketing people in Digital. Many of
	    them are highly motivated and hardworking.

	(2) It may have been "seen as a cushy retirement job in Digital", but
	    that doesn't mean it's true. I will concede that being in a
	    Digital marketing job for any length of time threatens to rot
	    your skills, market awareness, etc. - but that is not entirely
	    the fault of the individuals in that position.

	(3) It may be true that Marketing doesn't get funding or power
	    because of non-performance; it may also be true that Marketing
	    fails to perform because it doesn't have the funding, power,
	    and the appropriate mission. In fact both may be true: this
	    is known as a "vicious circle".

	re .12:

>    so perhaps we need the "death" of central engineering, and move the
>    function into the sales office.

	This seems to me to reflect a limited outlook. Which sales office
	will be responsible for VMS, which for OSF/1, and which for Alpha
	hardware products?

	If you mean that SOME functions should be moved from Engineering
	into the sales office, I agree. TNSG is already moving in this
	direction.

	re .13:

>	Management gets what it inspects not what it expects.

	Right on the mark! One reason why Dr Deming tells us to "Stop
	haranguing the workers".

	Who inspects the quality of marketing in Digital? The only people
	I can think of are the press, and they're not unduly impressed
	either with our directions as we communicate them, or with the
	resulting products.

	re .14:

>    Isn't it amazing that we are back at a full circle again: We need to do
>    more QFD product development. Why? Because that approach will solve
>    some of this corporation's biggest problems, one of which is this very
>    issue of "powerless marketing and deaf engineering".

	Agree, Ray. We need to find better ways to get the right people
	together at the right time. At the moment the field is moving full
	steam ahead in the opposite direction: all the really good people
	are filling up their diaries for 1993 with customer commitments
	(good) and if any internal function wants some of their time, it
	has to show its money and get in line.

>    A bunch of senior people who have completely lost touch not only
>    with the market, but even with the technologies, making far-reaching
>    decisions. A bunch of "architects", who love to develop infrastructure,
>    but no products.

	This sounds true to me - although I haven't actually been in such
	meetings either. In the parallel world of warfare, it's an old story:
	seasoned, motivated professionals commanded by people without the
	requisite experience. Digital's recent history reminds me of some
	of the early battles in the American Civil War, in which the Union
	generals made every mistake in the book, but their soldiers still
	managed to fight the Confederates to a standstill (I may be thinking
	of Shiloh, but the exact battle doesn't really matter). In another
	situation, an observer summed it up as "lions led by donkeys".

	The historian Fletcher Pratt made the point that since the Union
	soldiers cooperated better than the Confederates, once the Union
	generals became as competent as their Confederate opposite numbers,
	the Union army as a whole would become superior - and this happened
	after Gettysburg.

	The application to Digital is this: if we can hold our own among
	the top 3 or 4 in the world computer industry, disorganised as we
	are, think we could do if we got control of our business. We have
	superb individual contributors, who cooperate together perhaps as
	well as any organisation in the world today. 

	re .15:

>        But Ray, we in TNSG *pride* ourselves on not developing
>        applications, but, rather, "middleware" (tools and
>        infrastructure).  The strategy is successful!

	I don't know whether this strategy is successful or not. What I'd
	like to ask is

		"How would you find out how successful it is?"

	The numbers may or may not exist, but if they do the people who
	own them are not telling. 

	The strategy looks reasonable to me, but a priori theoretical
	projections are not enough - something as important as this needs
	to be measured.

	re .20:

>    It's inefficient and completely ineffective to exhort exmployees of
>    this or any other company to act in the best interests of the company.
>    A commercially successfull company is not a democracy where majority 
>    rules.  The board of directors should set the goals and processes so 
>    that the comany is profitable and successfull.  Without this clear 
>    and enforced direction, the employees are left to their own devices, 
>    which is exactly the situation in Digital today.

	Absolutely agree, David.

	From Dr Demig's 14 Points:

	10. Stop haranguing workers

	/Tom

    
    We don't need new slogans... er, tools (eg QFD) to get the right people
    cooperating to make rational products -- we need to use the tools we've
    already been sold (eg, formal inspections), and we need a heaping
    mesaure of common sense.
    
    In another note, I railed against the fallacy of formal inspection at
    DEC. Getting *REAL* product requirements is precisely an area in which
    this tool could help immensely, if anyone at the top cared to use it
    properly to fix our phase review process. I've sat in many inspections
    of functional specifications (phase 1) where the overpowering message
    is that the requirements were not specific enough (phase 0). I've read
    many project post-mortem reports stating that a lack of rigorous
    product requirements hampered the development cycle. If anyone who
    has control over the phase review proces were actually *LISTENING* to
    all this feedback, we would have implemented QFD-like behavior a long
    time ago, without introducing yet another acronymic crutch.
    

    Re .23:
    
    If that's what you believe, then I'm afraid you haven't seen QFD really
    work yet. QFD is quite definitely *not* just another acronym, but
    rather a new product development process. I thoroughly recommend you
    read some of the case studies in the METOO::QFD notesfile. 
    
    Unfortunately, to get QFD started in this company, the people who
    introduced it did so as a "requirements analysis" approach. That's very
    good, in itself, but that is only the first quarter of what QFD is
    intended for. Some people have implemented it in a project throughout
    the product development process, and productivity gains of 10 or even
    100 times previous are being realized. There is documented proof.
    
    However, I think I understand one of your points, which is that no
    matter what approach we use, if the right people are not cooperating,
    we still fail.
    
    Both Phase Review (a sequential approach) and QFD (a concurrent
    process) require that marketing and engineering sit together (amongst
    others) as peers, and work out the product. Until the commitment exists
    to take it that far, we still fail.
    
    Ray

One of the great difficulties I have is the inertia of the organisation in
recognising and responding to change. From my experience, most of the
reasons for this lie in engineering, not marketing. You too can watch while
market trends get ignored in an environment of inter-group politics,
personal opinions of a few key managers and detachment in relying on the
views of customer VPs at the top of strategic accounts. These people often 
articulate perceived needs - while the profile of business flying in under 
their radar is 180 degrees away!

At the moment, most of the software products being planned are aimed at 
markets and channels that will lock us to very small growth in the
future. While we are trying to do something about it at European level,
we're not seeing a strategy for future (sw) health from the corporation.

The question in .0 is a very good one. We've worked something for our business
along the lines of: "Imagine we are a user of computers in the year 2000.
What do we use products for and what channels of distribution would fulfil
our needs".

Follow that one through and you'll see that market volumes go very binary
between "individual user relationship" channels and "SI/FM". The middle
ground - where a majority of our distribution channels are today, and which is
the environment that our products are designed for - will migrate to one of 
these two models or die.

Personally, I feel we'll get murdered unless we have software products that
build on our "enterprise-wide" strengths and which we can sell to "individual"
users at low cost and high volume. It'll be interesting to see what the
Microsoft and Borland equivalents of Lotus Notes get to look like...

								- Ian W.

Well, I see that the debate over an application strategy or the lack thereof 
has turned to a discussion over marketing versus engineering's responsibility 
for development of applications.

IMHO, the company does not understand what an application is. Middleware is the
catch phrase for what used to be called platforms, Uppercase tools, Lower case 
tools and every software component that is involved in an application. To a 
user, Lotus is an application because they are familiar with calculators and
conventional hardcopy spreadsheets (ie; financial analysts like I once was, used 
to do these by hand with a calculator.). Nevertheless, Middleware is to Digital, 
what the ONE-Step Camera is to Polaroid's Film business. Unfortunately, we have
the metaphor backwards and we are not the sole owner of the technology.

An application is aimed at solving a particular business or scientific problem.
It may involve multiple "middleware" components, but the only thing the end user 
is aware of is the "package" that solves the problem. 

A General Ledger application embeds forms management, a database management 
system, may have been developed with some Upper and Lower Case tools, may use 
a TP monitor to control transaction flows, and assorted other software. The 
business user and even most of the user's IS group will first look at the 
applications functionality. If it meets or exceeds the business requirement, 
the next prudent step is to examine its design and environmental requirements. 
A customer IS organization is usually predisposed to the hardware platform that 
has a specific set of middleware to support existing applications.  If an
application that runs on DEC provides 80% of the functionality is compared 
with a product that runs on the incumbent platform and provides 60% of the 
functionality, the incumbent wins. Unfortunately, in most market niches, the 
functionality delta is even less.

So, how do we turn this situation around?

In my opinion, one way is to look forward in each of the industry areas to 
determine where there are unfulfilled or poorly fulfilled business needs. 

Another avenue is to determine what the next generation application must have to 
replace the incumbent products. For example, most incumbent applications are NOT 
windows oriented. Yet there are millions of PC's that operate in the end user 
environment. 

Finally there is a need to drive new, innovative software developers to develop 
software on our platforms and embed our middleware. Anyone who has worked for a 
software vendor will tell you that their driving force is time to market. If we 
develop system development tools that drastically reduce the development cycle 
while attaining high quality, we will have an environment that the software 
developers will flock to and that our competitors will envy. 

This can and should be our competitive advantage. If you don't believe just 
take a look at HP Wave. I watched one of our third party vendors build a whole
new function for his analytic application complete with graphic output in less 
than 30 minutes! That is frightening. Now he told me that there were plenty of 
improvements that HP needed to make, but they are listening. We, on the other 
hand, ....?

So... the question is still "Who is responsible for the application strategy?"

-Carol

    
    re .25:
    
> One of the great difficulties I have is the inertia of the organisation in
> recognising and responding to change. From my experience, most of the
> reasons for this lie in engineering, not marketing. You too can watch while
    
    Engineering perspective:
    
    Engineering does not respond to change -- because it doesn't get any
    stimulus. "Marketing requirements" have been a joke for as long as I've
    been an engineer. How many of you have sat through phase 0 proceedings
    while an engineering-generated list of goals is accepted as "marketing
    requirements"? Engineers don't do a good job creating marketing
    requirements, but then again that's not a talent for which we were
    selected. Self-creation of requirements is a natural response to living
    in a vaccuum. When we get comprehensive, reality-based marketing
    requirements, we will produce world-class marketable products
    (applications, middleware or Silly Putty) like you've never seen. Our
    mistake lies in not demanding this a long time ago.
    

Here, it seems to fit in Industry Marketing/DCCs alone. They pick their key
application areas, identify target vendors and then activate the CSO channel
appropriately. The CSO organisation then "manage" the fulfilment of our target 
customers perceived business needs on our platforms in unison with the DCCs.

For most software products, we look for any innovative way of selling more of
what engineering throw over the wall (pre-Olsen's last speech) ;-)

What I see very little of is perceiving what individuals will be using
information technology for in the future, and designing up from there. Today,
my biggest problem/opportunity relates to the timely receipt, filtering, 
processing and onward distribution of pretty basic information.

If Lotus Notes was as simple to set up and use as a spreadsheet, they
priced it meaningfully and allowed information to flow between individuals
anywhere worldwide, that would be an absolutely lethal application generator.
Then who'd need middleware, case tools, ...
								- Ian W.

>    Engineering perspective:
>
>    Engineering does not respond to change -- because it doesn't get any
>    stimulus. 

FWIW, most of the Phase 0 calls I get are of the form "We're going to implement
product X. We welcome your inputs". Not "Where are your customers headed. What
problems do they have. What type of products do you need from us".

It's not clear to me how this loop can get closed.
								- Ian W.

RE:>              <<< Note 1787.29 by IW::WARING "Simplicity sells" >>>
>
>FWIW, most of the Phase 0 calls I get are of the form "We're going to implement
>product X. We welcome your inputs". Not "Where are your customers headed. What
>problems do they have. What type of products do you need from us".
>
>It's not clear to me how this loop can get closed.
    
    This sums it up pretty well.
    
    I was listening to a female Irish actress talking about performing
    James Joyce 'Two Women'. She said that the difference between Joyce
    and others that portrayed women was that "Joyce did not assume that
    he knew how women felt or behaved".
    
    Apparently Joyce always asked his wife about her behaviour, opinions
    and attitudes. He would also ask other women and filled up copius
    books with these responses and he used them. He did not assume that
    because he had a relationship with women he knew all about them.
    
    Call it QFD, call it what you will. It comes down to two things,
    respect and common sense. In all of this I'd like to say "Digital did
    not assume it knew how its customers felt or behaved".

    John

    
    One of the very unfortunate aspects of setting up large develpment
    teams is the tendency to grab particular requirments, regardless
    where they came from, and generate little "cells" of product
    prevention, i mean turf, from which to political battles can be won.
    
    People need to realize that all thru the development process, you have
    continually test your assumptions about functionality and the market
    place.  This does put a large burden on developers in that they must
    design well and anticipate that things may change, but that's the
    price of being successful these days.
    
    It's very clear that we cannot force function on customers - there is
    far too many alternatives availible in the marketplace these days.
    
    	bob
    

    	Interestingly enough, I've actually been hearing *good* things
    recently which address a lot of these concerns. I heard at a group
    meeting that people at the top want Marketing to begin specifying
    market requirements for the products they want engineering to build
    (Hey, what a concept!). Since our Marketing and Engineering groups
    haven't worked this way before, it's not clear we'll succeed at this,
    but it's a step in the right direction...assuming Marketing has a
    better idea than engineering about what should be built.
    	Also, Stone's group is gearing up to address more than just
    middleware...and on multiple platforms and operating systems (and not
    all DEC ones either). He believes this is necessary for us to be
    perceived as a software company (which we currently are not). There is
    also an advanced development group in TNSG which is looking ahead to
    see what software we should be building in the future. One area being
    explored is CASE tools.
    	So I've been hearing the right noises for a change. Hopefully,
    there will be enough support to gain momentum in this direction.

    Re: .31
    
    Yes! The best way I can think of doing that is by Rapid Prototyping,
    together with marketing and sales and the customers, the functions of
    products that have been conceived, before any real development effort.
    
    "A customer can tell you what they want, but they can't tell you what
    they DON'T want....until they see it."
    
    Or, conversely, Mr Engineering Manager says:
    
    "OK guys, you start coding....I'll go out and get the requirements".
    
    Tally-ho,
    
    Ray

re: .32

Wouldn't the most significant change be for Stone or whoever is running
software to say "all new products MUST run on DOS or Mac FIRST"?  Isn't
that where the market is in terms of numbers of "seats" out there?  It
seems like hardly a day goes by when i don't get a Phase 0 announcement
on some product or other (some of them fairly incredible sounding, in
terms of "what's the perceived need for this?" or "don't we already have
three products that sorta do this?")--and hidden in the fine print is
usually a statement that the first implementation will be on VMS and that
multiple platforms will be supported at some mumblemumble date.

Maybe this is too simplistic an approach though...
								paul

re .34

I like that!  I might alter it to "the first release must be on the platform most
people use to solve the targeted problem."  That way some applications would be
first offered on Suns, most on PCs and Macs, and a few on Mainframe IBMs.  After 
all, we are a software company, right?

Matt

    
    i think one big area for applications for mini or midrange computers
    is plant automations software ( AGV's (automatic guided vehicles) ,
    control systems software, Databases for plant vehicle build data,
    vehicles ordering processing systems, monitoring software,
    time-keeping, applications automatic fail-over and detections fetc. etc.. ) 
    many of these types of applications cant IMHO be dont on PC's . 
    
    PC's are good for playing games on and running simple minded
    applications like spreadsheets and single users applications, but for 
    heavy duty applications that is used to run a plant, you need a heavy duty 
    reslient machines and software, like VAX/VMS and clusters. i dont want my 
    nuclear plant control and monitoring software to run on a DOS PC or
    even on a PC running NT for that matter. 
    
    but if our industy base keeps disintegrating as it is, then may be we can
    do just with DOS and PC's to run our lifes.
    
    just my 2 silver cents worth..
    
    buy,
    /nasser

re: .35

> I might alter it to "the first release must be on the platform most
>people use to solve the targeted problem."

I can live with that as long as we don't pervert it to mean we only look
at problems that our hidden-agenda-platform has a history of solving.

re: .36

Not sure i get this completely.  Is the reasoning that we f***ed up on
UNIX but haven't gone bankrupt yet, so we can do the same with DOS?;-)
But--seriously--i didn't mean "abandon VMS".  Just do the VMS version
after (or maybe concurrent with) the PC version or UNIX version or
whichever fits the description above as being the best primary market
platform.  If i was David Stone (aren't you glad i'm not;-)) i would at
least give it some serious thought.
								paul

...it is harder to figure out and implement a better way...

What is the ideal product development strategy? Here are a couple
of the usual choices:

1. Marketing does research to determine that the market place needs
   a product that can do "X" and that such a product will sell well.

Result:

Engineer is told, do this and if it doesn't work out, it must be
your implementation that made it fail, not our research. If it falls
flat on its face, you fix it, we can't because we didn't implement it.
If it does well, we'll take the credit for having thought of this in
the first place and we'll give you a pat on the back.

Advantages:

Marketing is close to the market and really can tell if a product is
needed and what its functionality should be.

Disadvantages:

Actual product functionality is a function of communication and 
implementor interpretation.

It is less easy to motivate the implementer in this environment.


2. Engineering in doing its own development work hits on ideas that
   can improve their own work and figures this might be useful to
   anyone else doing simular such work. After bouncing the ideas off
   other people for feedback, the general feeling is that it might
   turn into a good product.

Result:

The engineer is more motivated because (s)he thought of the idea in
the first place and was not simply told "do this". They are the
implementers and have a clear idea of the "how tos" being dealt with.
The feedback process should indicate whether or not they even get
financing to do it at all and marketing should be able to say if it
will sell or not. If everyone agrees, a product will be made.

Advantages:

Market independant creativity can lead to brand new markets!

Disadvantages:

The product may still not end up being exactly what the market place
needs because everyone's situation is different. Buyers will have
different variations of simular problems trying to be solved by the
product.


My personal feeling is that development should be a mixture of both
of the above ways. Who ever originates an idea should use a rapid
development/simulation product/technique to give everyone involved a
first look at the new idea and take it from there.

Example: Marketing or Engineering has an idea for a new Motif
windows based product. They use a tool like VUIT to quickly build
what it would look like and simulate its action. This is demoed
to all parties to get input for functionality and user details.
Marketing goes further to research if it will sell, engineering
examines the details for making it work. A plan of action is decided.
The basis of a decision is now from something that can be seen and
played with, not a description on paper. Communication should be
enhanced and the product should be more in tune with common goals.
In this instance, marketing could in fact be the initial product
developer, creating code that can run and demoed!

Comments?
Craig.

    There _is_ an answer to Digital's perpetual applications conundrum.
    It is called ANDF. ANDF is a technology that allows development 
    software applications on one machine for multiple targets
    and implement new system software and systems without worrying about
    porting. Porting strategies are doomed to failure. ISV's simply
    can't deal with the volume of ports. Witness Oracle with 120+
    port of their software. Witness the excruciating lack of volumne
    on a long list of applications Digital has paid large sums to
    have ported.

    ANDF is real, it works, and it has no inherent performance losses.

    If you wish to know more about ANDF or wish to sponsor a presentation
    about it, please contact me.

    Marshall

    A little more info may help.

	re .39:

>...it is harder to figure out and implement a better way...
>
>What is the ideal product development strategy? Here are a couple
>of the usual choices:
> * * * *
>My personal feeling is that development should be a mixture of both
>of the above ways. Who ever originates an idea should use a rapid
>development/simulation product/technique to give everyone involved a
>first look at the new idea and take it from there.
>
>Example: Marketing or Engineering has an idea for a new Motif
>windows based product. They use a tool like VUIT to quickly build
>what it would look like and simulate its action. This is demoed
>to all parties to get input for functionality and user details.
>Marketing goes further to research if it will sell, engineering
>examines the details for making it work. A plan of action is decided.
>The basis of a decision is now from something that can be seen and
>played with, not a description on paper. Communication should be
>enhanced and the product should be more in tune with common goals.
>In this instance, marketing could in fact be the initial product
>developer, creating code that can run and demoed!


	Great! This seems to me clearly the right way to go! Moreover, it
	sounds a like like the way TNSG is going, with Concurrent Engineering
	and QFD.

	The essentials seem to be an overriding determination to provide
	a superb product at an early date, and everything springs from
	that:

		- Involve everyone WHO HAS SOMETHING TO CONTRIBUTE
		  (Customers, Marketeers, Engineers, Managers)

		- Provide means for "outsiders" to review, criticize and
		  suggest (as we do today through Notes)

		- Do not allow those who do not have anything to contribute
		  to clog up the process

		- Keep iterating (rapidly) until you converge on what is
		  wanted.

	Some prerequisites for this to work are

		- A lot less rigid bureaucracy than today ("you can't have
		  Mary to work on this project, she's MINE")

		- An ability to focus on the END ("a superb product which
		  delights the customer, in 15 months from now"), and if
		  necessary to cut through red tape which doesn't serve
		  that end.

	/Tom

    I echo comments by .42:
    
    Re: .39, congratulations, you just described a blend of Contextual
    Inquiry, QFD and Rapid Prototyping. If people do what you described, it
    will save the company!
    
    Ray

    Guess this is as relevant a string in here as any I can think of at
    short notice...
    
    Recently, VP Stone enunciated a new policy, the crux of which that our
    new SW design center was not to be "workstations" but "personal
    computers."  I probably saw it somewhere in here...  Could anyone with
    the notes of this speech, or its actual text, either post a pointer,
    post it in an appropriate note in ::DIGITAL or send it to me offline? 
    I need a bit of rhetorical ammo for a project of mine...
    
    Thanks!
    

    Yesterday morning, seeing no one in NotesLand had the info requested in
    -.1, I "went to the source" and sent mail to Stone.  Less than an hour
    later I heard back from his Admin Assistant who put me in contact with
    the ZK library, and today I have the video and slides from his "State
    of Software" presentation.  (Presumably I will find the requisite info
    therein.)
    
    Now THAT's a responsive organization!  (Thanks to all who made it 
    happen -- I'm not posting your names so you don't get deluged unless
    you want to.)  Kudos to all.
    

    Wow, just imagine what we could all get done if we had our own Admin
    Assistants like that.
    
    (Well actually we can, but that's another story.)
    
    q
    

    ...  "What is the market telling us that we can do as a company?" 
    
    [puts up chart showing clear sales trends in mainframes, minis, pc's,
    and LANs] ... 
    
    "The PC's make more money in total than the minicomputers.  That didn't
    used to be true but it's true now.  Up until about a year or 15 months
    ago, most of the stuff we designed did not take into account the
    concept that the person using it might be looking at a PC."
    
    "So the basic point about this chart is not really the little details,
    but that there's more PC business out there than there is anything
    else."
    
    "Therefore! -- what you want to do is, you want to recognize that by
    and large every client that you're talking to in your program is going
    to be on a PC."
    
    "So -- that's the design center."
    
    "And by the way, maybe you ought to sell some PC's too.  So now we have
    a PC operation that actually sells  about a million-and-a-half dollars
    a DAY from the catalog, and rising.  So you just have to sort of take
    that into account -- which we haven't done before."