-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
From: Bill Gates [/o=microsoft/ou=northamerica/cn=Recipients/cn=1648] on
behalf of Bill Gates
Sent: Monday, January 15, 2001 5:34 PM
To: Jim Allchin (Exchange); Steve Ballmer
Subject: FW: The Fifth Database Revolution
We need to get someone very technical to pull together our platform story.
Jim could do it but its probably best for him to delegate it to a small group
with a leader.
The leader could be Eric Rudder or Rick Rashid or someone I am not thinking of.
Some good work was done during the NGWS days that needs to be carried through.
Eric tells me that currently there is some progress on this stuff but not a
clear direction from management.
It is as a key advisor to this group that David’s input would become important.
The key stuff is under Paul Flessner and Yuval Neeman but neither of them is
right to drive it directly. It does touch on other pieces like WMI and Office
extensibility.
This is one of the bigger items on my memo and its waiting there. I am not
saying its easy work to do.
Lets pick how this is going to be driven.
I need to discuss that with both of you for a number of items in the memo but
this is perhaps the most urgent.
Here is the latest on this from the memo:
<b>Applications platform</b>
Our applications platform message is quite confused today. Pieces like CLR,
WMI, MSMQ, XML runtime, Biztalk, MTS,IIS, ASP+, Load Balancing, Message
bus, ,SOAP, UDDI and Yukon are not consistent and reinforcing. Basic standards
like eventing, logging, and filtering have to be established. The
disconnection of these products make our message when trying to win back the
developers who like JAVA and J2EE very difficult especially when we have the
limitation of being only on Windows and those technologies are supporled on
many platforms by many companies. Although we have waited a long time for the
shipment of VS with the URT that doesn’t give us anywhere near a complete
consistent platform story.
The most consistent platform in the industry is Oracle. They have used their
database as the center of gravity to drive a very strong story. We need to
integrate more capabilities like email and directory and workflow and file
system where Oracle has done very little. In the basic intrastructure area
though there are some lesssons to learn from them.
We have talked about many of these problems but not pulled things together.
MSMQ is a bit of an orphan. Our transaction strategy isn’t getting any
traction while BEA has established an $800M per year business around that
technology. We did a good job on MSMQ and MTS but they couldn’t thrive on
their own. Our decision to make Yukon the center of gravity and to connecl
Yukon to the URT should give us the clear starting point. We may need to be
able to package Yukon so that it doesn’t feel like a database if all you want
is a Message bus. We may need to create some subset implementations of things
like Queuing for size and speed reasons. However the API set should be
consistent. We may need to be compatible with some of the J2EE apis.
Our application platform for the server and the client need to be the same. The
strength of our approach is that code should be able to run Offline. This
highlights again the importance of a Distributed Application Architecture
where code can determine what it needs to execute on a different server or
down on the client. ASP+ has to be made reasonable as a client side API set
which it is not today.
We have to take a hard look at our tools and consider how to be a better high
end solution. We have to spend a lot of money to make sure the openness of C#
is well understood and that it is accepted at a level that allows our
innovations to have traction.
1
Plaintiff's Exhibit 6917
Comes V. Microsoft
MS-CC-Bu 000000089456
I think that between Paul, Yuval and Eric’s group with leader from Rick Rashid
we should be able to go through another iteration on this (like we did with
NGWS) and come up with some clear answers.
The strength of this platform and the innovation around it is the key element
in preventing commodization by Linux, our installed base and Network Appliance
vendors. We are in the best position to define the distributed application
model that allows work to be moved out into the Network. We don’t have enough
research our product group people pushing this agenda but we have the best
opportunity. This is what it takes to seize leadership in caching, load
balancing and protocols. I think between Management/Setup and a vision of how
our platform is Distributed we give ourselves a chance to lead in all the
Level 7 networking pieces. I almost included this as a separate item but
executing on these two technical pieces will give us what we need except for
packaging, marketing and sales force.
There is a major packaging question once we get architectural coherence. To
what degree should we package or charge for the rich so called middleware
pieces separately from the rest of the platform? Are there advanced forms of
some of these pieces that cost extra? Most of the API set we want supported in
the base server with understandable advanced services costing extra.
We are discussing with IBM a joint effort to agree on most of the Application
server pieces so that companies have a choice of our two implementations.
Although this would be an unexpected partnership I see a lot of advanlages for
both companies. I think they can help with parts of the architecture. The
current view is that we do not share any code
between the companies.
We also need to drive Microsoft to use the new platform to prove it out and
show it off. Our Services need to use these architectures so that our tools
make them easy to extend.
- -----Original Message-----
From: David Vaskevitch
Sent: Sunday, January 14, 2001 6.12 PM
To: Bill Gates
Cc: Jim Allchin; Steve Ballmer
Subject: The Fifth Database Revolution
A while ago I promised Bill that I would write down in some detail what has to
happen next in database land. It's also come up in conversation with Steve.
So, here are two papers. There are also two papers dating back about two years
that supply some of the more intricate underlying technical details. The
second paper is more technical, more pointed, and better written. The first
paper is more motivational, kind of, and, because I switched to the second
paper before finishing the first one, the first one runs out of steam near the
end.
(Attachment names)
The Fifth Database
Revolution....
The Structure of
the Fifth Dat..,
Having now sent these I have to admit I also feel pretty weird sending them.
Weird and conflicted. On the one hand, I feel pretty deeply that if we don’t
do what is described in these papers, and some of the others I’ve been
writing, we will either a) not achieve our long term goals (platform adoption,
business growth, developer wins, etc), or b) get into relatively serious
trouble (never catch up with Oracle, not have the platform the biggest apps
are wdtten on, miss key changes). All of that makes me want to write these
papers, want to see them acted on. Then there’s the "on the other hand" ..
On the other hand I am now totally disconnected from pretty much everything to
do with our platform. These papers are hard to write in a wide variety of
ways: time consuming, energy draining, etc. And, being so disconnected from
the platform, it means that most of what gets written in papers like this is
just not going to happen. True of storage. True for distributed app support.
True for things in general. So, I’m saying out loud, that I’m trying to figure
out whether to even keep writing this stuff. Besides the fact that it might
well not have much effect, chews up time, etc, it must be annoying for the
people actually having to build this stuff, to have people off in other areas
writing this kind of stuff down for them.
The next one I would have written was going to drill into the
whole "distributed" and "application server" mess. But, I’d really appreciate
feedback on whether it is good, bad, or indifferent, and why, to be writing in
this vein...
2
MS-CC-Bu 000000089457
HIGHLY CONFIDENTIAL
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpCVc0ACgkQU4xAY3RXLo4ECACfVseSCIJOIUzJZcgWLtBBRhoS
NPgAnRdcW7UAdWKsY8409+/WXwxBJxoI
=kpD4
-----END PGP SIGNATURE-----
|
|
