Remarks by Bill Gates
.NET Briefing Day
Redmond, Washington
July 24, 2002

ANNOUNCER: Ladies and gentlemen, please welcome the Chairman and Chief Software Architect for the Microsoft Corporation, Bill Gates.

BILL GATES: Well, good morning and thanks for coming to this strategy update. We're going to be looking back a little bit today at some of the announcements we made two years ago at Forum 2000 and talk about the progress we've made in the new architecture that we've sent Microsoft on starting at that point.

It was a very bold thing that we did, something that affected all of Microsoft's products, and in a sense it was a bet-the-company strategy. Just like our bet on graphics interface or our strategies around the Internet, we needed to make sure that all of our energy was behind a single approach.

What you'll see is that in some respects we're further ahead today than we expected and in some respects we haven't made as much progress as we expected, but you will hear a very clear message that the direction we announced two years ago is 100 percent the direction that we're driving towards with all of our increased R&D in the years ahead.

So Forum 2000, it's hard to think back on how different the industry was just those two years ago. The NASDAQ was around 4,000. Dot-coms were still considered the center of activity and innovation. People sort of thought that tough problems like e-commerce that clearly require invention, that somehow the foundation pieces would just come together. It's only in retrospect that it's clear that there were a lot of things unrealistic about that phase of our industry. IT investment by companies was still very high at a level that probably won't be repeated for a long, long time to come.

So it was in that atmosphere that we announced .NET. And let's go ahead and look back at some of the things we talked about during the so-called Forum 2000, the kick-off of our .NET strategy.

(Begin video segment.)

BILL GATES: Well, Microsoft is announcing today that our efforts as a company are going to be focused around this next generation platform. We call it .NET.

STEVE BALLMER: There are many islands in this world, and that's why this federation concept gets increasingly important. We're betting that user interface matters, that it's not going to be just a world of browsers.

BILL GATES: When we think about knowledge workers, they're not paid simply to click through screens and read what's there; their value added is taking that information and synthesizing it.

STEVE BALLMER: We're betting that the whole world does not move to a mainframe model of centralized computing.

BILL GATES: It's going to have to really put the user back in control. Perhaps most importantly, it's going to have to help them feel that their privacy is preserved.

STEVE BALLMER: For some of you, though, I'm going to suspect that you still are asking yourselves a few questions. One question might be, and I'll be as direct as I can be about this, what is .NET? Unlike Windows, where you could say it's a product, it sits one place, it's got a nice little box, who's the competition. In some senses it's a very good question. There's no competitor who's announced their .NET

I feel very confident that the XML revolution will happen. We're committed to third-party success.

BILL GATES: So what it comes down to is that after 25 years Microsoft is still focused on the thing that it loves and knows well, and that is building software platforms. This is an era where what's required of that software platform is far more ambitious than anything we've done in the past.

What we're going to be talking about today is something that is very concrete for us, even though it rolls out over a many-year period.

STEVE BALLMER: We know we need to have the same kind of long-term approach and patience that we had with Windows itself.

This is a long-term roadmap. This stuff is not going to happen in the next day or two days or three days.

I'm enthused. I'm charged up. It may take a few years but I'm going to be here.

(End video segment.)

BILL GATES: Well, Steve will be here later today and we are charged up about the decisions we made back then. The ones that felt very, very risky today feel like the right thing. There's a lot of execution still to do but the direction is sound.

Now, the reactions at that time were really all over the map. Some people viewed it as similar to the strategy of a hardware company. Some viewed it as still pat of our embrace of the Internet. I'd say it was fairly rare for people to see it as stepping back and doing the long-term work to build both the standard foundation and the platform foundation for the kind of applications people were talking about back then, taking e-commerce as a very prime example.

Now, within a month of having Forum 2000 we had a developer event where we gave out the early tools, the early work that showed why we believed in that direction, and so people got a sense that it wasn't something that we'd come up with in the month or two before Forum 2000, and it had been the work that we had been doing previous to that and clearly a lot of the R&D energy behind the company very strong.

There were some competitors who dismissed this approach, the centricity of XML, the importance of Web services, and I'd say today those same competitors are no longer saying those same things. In fact, in many ways we see for the first time in a long time an industry coming together to say, okay, the winner will be the one who executes on this in the best possible way.

And to be clear, this is 100 percent a software challenge. Whether it's the elements of security, the breakthrough development tools, the automatic data exchange, the designing of the schemas, the end user tools that are involved here, this is a software problem, one of the toughest software problems ever tackled, easily greater than tough engineering problems like getting to the moon or designing the 747, but it's one that we and our partners have enough energy behind and there's enough importance for solving this, we have no doubt that the pieces will come together.

So let's look at the milestones between June 2000 and where we are today.

September of that year 2000 we shipped our enterprise products. Perhaps labeling those .NET products was premature. Some of the key elements were there, the XML support, and we've rolled out additions to those server products and now we have total support for XML and SOAP based capabilities.

In some ways you can say the first generation of .NET products were putting a layer on top of the existing functionality and making sure the exchange with the new standards was there whether it was SQL or Exchange or Office, and now we're moving into the phase where it's far more profound, where the entire design of the product has XML to the core. We already have several products like BizTalk, Visual Studio that are designed in that way.

March 2001 we took some of the things we'd talked about at Forum 2000, about users being able to get at their information across any device, being able to be alerted or authenticated across any device and any service, and announced that in what we later called .NET My Services.

There were elements of this that in some ways were premature, the whole way we were doing the data model, the way we allowed other people to do the storage and things like that, but again it's a central element of this vision is that people can get at information, that information is not related to the device, say your PC at work or your PDA, that information is your information and software will automatically bring it to you no matter what you're working on.

And so the idea of your favorites or your voice recognition or your files or you address book, you know, today think of your address book information that's in your buddy list, it's on different machines, it doesn't get up to date, somebody can change something, it doesn't automatically get to you, so the information management is not people centric, and .NET My Services, the direction there is to solve that.

Windows XP that shipped last October, that's a big milestone for us and in some ways you can say it's the completion of a previous era, that is getting the NT code base with its security and its richness to be the standard code base for every copy of Windows that goes out, so it's the completion of that and it's the start of the new. It's the first operating system that's got a SOAP stack built into it and it has some of those early XML capabilities.

But if there's a milestone in this progression that's probably the most important milestone it's the launch of Visual Studio .NET. Now, to be fair we had literally millions and millions of people using Visual Studio .NET and the framework, the .NET framework that's a part of that, the rich common language runtime that's a part of that; people were using it as much as nine months before that official launch, but the official launch was a very important demarcation point for us. We had many customers who chose to deploy .NET applications actually before the Visual Studio launch, but after the launch the increase in that was very dramatic.

And I think it's fair to say today that the pioneering customers on our industry across many, many, many verticals with some verticals like financial as usual being somewhat more aggressive than others, the pioneering customers today are building and deploying Web services type applications. They've not only embraced this direction; they already have applications that are using this and getting the benefits from that.

If there's a theme here, it's about breaking down barriers, barriers between different applications that hold information, barriers between systems, barriers between the systems and the people who use them where you have some information that's very ad hoc, say an e-mail, some information that's up in structured systems and, of course, the barriers between organizations where the Internet provided the connectivity but that didn't solve the problem of the information having meaning and being able to control it and share it with the people you're interested in and not share it with others.

And so there are many, many tough problems that connectivity alone didn't solve.

It's important to think of the breakthroughs that were required once we got that connectivity really in two parts. One is how you represent the information and the other is how do you exchange that information. The first is about information formats and schemas and the second is about a rich set of protocols.

Now, the first of those was the format actually got going back in 1997. That's when a committee, which had been largely focused on rich document standards, so called SGML, came up with a radical idea that this idea of hierarchical description, tagged information could be used to break the tyranny of the fact that data storage was largely tabular, the relational model, which works very well for things like sets of order, sets of customers does not work very well when it's dealing with the richness of the real world, trying to describe all the parts that make up a particular product, trying to describe an organization, trying to describe a heterogeneous set of things that have elements in common that you wan tot query across.

And so the XML standards got off, I would say, actually to a fairly slow start. There weren't editors. There were many pieces that had to come into place: How do you query this stuff? Well, a tough problem. It took a long time for SQL to mature as the way that we query tabular data and querying hierarchical data, heterogeneous data is actually far more complicated. And so you saw things like XQL, Xlink, XSLT, various standards to get the maturation of XML.

XML itself is in a very rich form today, where I'd say there's literally not a major product in this industry that doesn't have very strong support for it.

So the format is the foundation and this foundational piece was part of the company bet that we made. This has an impact across all types of software. I mean, literally the internal representation inside a word processor, a spreadsheet, as you're doing development of source code, the source code itself will be an XML document, and things like having rich views where you see the performance or the debugging information, those are XML transformations of the source code with the dynamic data brought in, in that rich viewing.

So it's wonderful that this piece there has been industry wide adoption. There's no competition at this level. This is a standard and the competition will be on implementation.

Now, once you have that way of representing the data you need to move that data around, and that's where the next phase came in, tackling tougher problems. How do you do discovery? Well, that was UDDI. How do you have programs call each other to pass this data? That was SOAP and WSDL. And the key building blocks are really coming into place there.

It's very exciting to see the cross-company collaboration for all of those key protocols, enough protocols at the standards level that although people will compete on these stacks and how they're implemented, say the Web Sphere stack from IBM, the .NET stack from Microsoft, the actual capability of doing rich e-commerce between those different stacks will be clear. Even inside a company, as long as there's adherence to certain XML based approaches following those standard schemas, it's OK for different applications to be written in different languages and use different stacks. The key business value comes from this interoperability, the fact that the software exposes its capabilities rather than keeping it hidden inside, and XML is where that all got started.

So you've got this standard around XML and now you have these emerging protocols and you see very great progress there.

We still get people saying to us, what is .NET. It's one of those great questions that people can say, yes, it's come into focus at the infrastructure level but a little bit where we go beyond that has been unclear to people.

Today, if you leave with one thing, I want you to leave with a clear sense of what we mean when we say .NET. A lot of people like flexibility in choices, so what are the choices here in terms of what .NET means? Well, we want the choices all to be exactly the same: Software to connect information, people, systems and devices. And so a product with .NET is a product that embraces not only the XML formats but the rich protocols that go around it and therefore all the information inside that product can easily be found, updated, secured in a way that was not possible before that product took this .NET approach, so you'll see us using .NET for exactly that: Software to connect information, people, systems and devices.

And so this is something that rightly can be described as transforming all the work we're doing. .NET, we would have had to invent .NET for many different reasons. Take management infrastructure. The fact is that as systems move from having a few mainframes or having tens of servers to people having hundreds or even thousands of servers, some deep architecture had to be created that let people see all the events on those systems, filter those events, be able to reach out and touch systems individually, apply policy to those groups of systems. There needed to be a real revolution in management software. But that revolution could not take place until there was a rich set of protocols that things like system state that does not fit the relational model could be exchanged and could be found.

And so every thing around XML and the protocols that go with it we would have had to invent simply to take care of what the IT department wants, to take care of systems that are always up to date, systems that you can see the status of those systems very, very easily. In fact, in this whole world of management software we'll see revolutionary change because the products that are in the market today are not products that were architected with this basic approach in mind.

We would have had to invent .NET just for information workers, the idea of take a purchasing agent in a wide variety of things that person is asked to do in prioritizing those things, tracking those things. There is a lot of rich information there and yet it's not tabular information. It's not even information that fits naturally into a 2-D grid on the spreadsheet. It's information where you want to find the common elements, you want to sort by different properties, you want to view it in rich graphical ways, again there we would have needed XML and the XML protocols to make that possible.

So whatever dimension you look at this was a necessary advance.

And it's not a simple advance. In a sense you could say it's the Holy Grail that computing has talked about for a long time, having applications written by people who don't have to meet each other, because the number of connections are too great for that, they don't have to trust each other, their system can run even if the other guy's system is unreliable or even if it's malicious you can make sure that the wrong things don't happen to that application. These applications can be debugged. They can have reasonable performance and they can be developed in a reasonable amount of time.

None of that was possible before the billions and billions of investments that we and others have made around .NET. And in this area of the infrastructure we are really in great shape.

The number of customers using this is quite broad. I think you have a handout that goes through a number of the case studies of people, how they're thinking about .NET, why it's been a benefit to them.

I think in today's economic climate the importance of the cost savings is a very, very key point to make. The days when you said, okay, these two systems have to connect, bring in 200 consultants at $200 or $300 an hour, those days are really over. People expect these systems to connect with a modest amount of work where the company designs their own schemas, they describe those and then the information flows between the different systems.

There are a couple great examples that fit this theme of more agility at lower cost. Verizon is an example where systems that were based on the mainframe were not flexible enough and they were able to rebuild those for less than the ongoing cost of maintaining the old systems.

Jet Blue is an example of a competitor in the airline industry who's decided they're going to keep their IT costs below 2 percent and that's against a fairly typical industry average there of about 5 percent. And yet they are able to achieve by using the right architectural approach around .NET, they were able to get done the things that their competitors get done and so it's not a competitive disadvantage. In fact, in many ways because of the way their systems have been designed, it makes them even more flexible.

Let's go ahead and hear from a couple other customers what they're thinking about this advance.

(Video segment.)

BILL GATES: So it is the transition from previous systems into .NET. One thing we want to be clear about is this is not about saying that you have to go in and replace those systems. In fact, the same progression that's taking place with the system software elements will take place in customers' applications, that is at the start they can build an XML layer around the existing applications and they can take things and create common screen views and common reporting, common information sharing without having to go into the heart of the application itself.

A great example of this is when a government wants to do a Web portal. Now, that Web portal has to reach across their tax service, their health service, their education service, all of which have their own IT groups and they've chosen completely different architectures over time. We've gone in now to several dozen countries and taken tools like BizTalk to build a very simple layer on top and in many cases an order of magnitude less cost than they expected in building the government portal, to take all the information and pull it in one place. It's not just read only information; if somebody goes in and says I want to change my address, the XML commands are sent into the applications and then translated into how that application would have expected that change to be made in the past. And so by building that layer you get the rich data interoperability. You can bring those things together.

Now, as people choose to build new applications they can go much more into the core of the application and even have what would have been components in the past exist as Web services.

A good example of this is if you have, say, a company Web site, and the way you want it to look to different customers incorporates common elements that have a somewhat different look, say across divisions, customer types and geography. If you build those elements up as Web services, then the ability to mix and match, combine, change very quickly is dramatically better than how that would have been done in the past.

If there's any surprise to me about how people are using Web services, the amount of the activity, the amount of the benefit that relates to exchanging data inside a company versus across company boundaries, has been much greater than I expected. It's great for going across company boundaries. That's, in fact, what drove some of the tougher elements of the design, some of the security elements, federation that I'll talk about at length, but, in fact, many of the early paybacks have been from these disparate systems and pulling them together, often between different applications and often crossing the boundary between the information workers' unstructured systems and the structured back-end systems.

So this is something where we can go in and say what are the information needs you have, take those demands, that backlog and, say, to create a project that's funded more in terms of hundreds of thousands of dollars than millions of dollars and show people that connecting together, getting rid of their backlog can be done for that kind of a budget.

Now, so we're talking about doing more with less. Let's go ahead and get to the report card. This is something that we've been talking a lot about over the last couple of months to make sure that we're really taking where things have fallen short, the mea culpas and being very clear about that in what we've learned from the customer feedback and what's been challenging as we've been putting this together.

We knew when we did it that it was a five- or six-year effort. I heard that from all the speakers who you look back on from Forum 2000. We knew that Microsoft was in a very privileged position, that because of our leadership role, because of our financial conservatism, that we would commit to a five- or six-year program requiring substantial increases in R&D and be able to see it through. It wasn't something where we needed an escape path or we might go halfway.

So where do we give ourselves good grades? The first area is rallying the industry, getting XML and the Web services protocols around it to be front and center, to get people not to think that they're going to go out and rewrite all their applications in one language and just stick with that without that moving forward, but rather that they can take the existing applications and use these approaches.

We feel really great about the tools' capability and the runtime infrastructure that we've put out there. This is all around Visual Studio .NET. The reaction to that, of course, has us doing even more work to make that better, but we got more done there than we expected.

Okay, where are some of the less rosy parts of this? Building block services, the idea of being able to call out to get the storage capabilities, just having a common schedule, for example, that everybody has the different Web sites and applications can get to and update.

Software as a service, the idea that virtually all your software you would think about paying for on a yearly basis and it being automatically updated and improved across all your different devices; very modest progress in terms of that.

Federation, the idea that all these different systems can be connected together without their being any unique root, that is if two companies want to trust each other they can just federate. If a group of companies want to do that they can federate without having to be connected to a Microsoft namespace or anything else in particular. That need, although we talked about it, that need became more obvious to us as some of our authentication things were rolling out without full accommodation of those requirements.

And finally, the change in the user experiences. If you browse your information, say, to do something like make a forecast are you just looking at Web pages that you kind of scribble down the numbers off that Web page and you go type that into your application or are you really getting rich XML coming down to your system, XML that helps you in your workflows, your prioritization, your visualization. That's still not there but that is coming.

I'm going to drill down a little bit into a couple of these where I feel like there's been some things that didn't go as well as we expected.

Software as a service: There are two aspects to this. There's a technical aspect and a business aspect. The technical aspect is the idea that the software is often connecting back to its creator, it's connecting back for help, it's connecting back for templates, it's connecting back for community type involvement, support and for software improvements themselves, whether they're the more urgent types that relate to security issues or any problems or new features that would come on a less urgent basis. This again is something that we believe in. We think this is how software should work.

There are some good examples of software that works this way, things like online consumer clients whether from MSN or AOL, Media Player-type clients. Those things are constantly going up, looking for new versions and offering value because of that.

Inside Windows itself, the idea of Windows Update is now something that we have million and millions of users using. In fact, we're making the user interface so that it's easy to have just silent updates if you want to configure your system to work that way.

And that really changes the environment because that constant improvement means that as soon as we spot something, a third party driver that's not right or two applications that aren't working together, then we immediately get the fixes out before people run into that problem.

Our analysis tools, where if somebody has a problem with the Windows system, just got really kicked off with Windows XP. Some of you might have seen the screen when an application stops running sends that report back to Microsoft. That's a very rich piece of data that's getting us to prioritize how we work with third parties, how we put different things into the system. It's been an amazing thing to have not just anecdotally but the hardcore data there and then use Windows Update to take whatever improvements come out of that and get those out to users.

So the technical approach, even there is not quite as far as we'd expect, but I'd say much more progress there and a clear destiny that that's how software will work, both from the point of view of wanting to stay in touch with your users, give them better things, respond to new requirements and create the community element that all popular software really benefits from.

As a business approach, certainly if you move down from the large customers where we use Enterprise Agreements that really have always been almost subscriptions, as you move down to the medium or smaller business, the change has not been as dramatic as we would have expected. You see it in things like Hotmail with some subscriptions that we're growing up there, but a lot is still to be done there.

Authentication: This is a tough area. Authentication in the non-digital world is done essentially by governments or employee badges and, of course, it's a system where you have many different identities and anybody who wants to issue identities can come in and build those things.

This is a key building block of the vision of the Internet fulfilling its full potential. You don't want when you go to some small newsletter or some small merchant to have the barrier of proving who you are and retyping in lots of information mean that you're going to stay away from the small companies on the Internet and just go to the ones where you're constantly doing transaction after transaction. That's got to be something where the user, once he's entered the information, it's available to them to use on any site very, very easily.

There are some simple tenets here. The user is in control of their information. They explicitly say when any part of that information is sent to a different Web site. The whole thing about this trust hierarchy is there are many of these forms inside companies, by governments and they're all very independent and the federation is up to the entity to decide how they want to do those things. For example, when Microsoft is securing a document, we'll probably trust the administrator at Intel to take whether or not the Intel user really is who they say they are, and so they'll be in our trust hierarchy and we'll take Intel authenticated names to say OK, for documents that we share and have in common is that person logged in, in such a way, that they should have access to that thing.

The interoperability here is very fundamental. If you had to take and say for e-commerce across the different software stacks, you'd say, OK, security, reliable messaging, transactions, discovery of information, you'd say these are pretty basic building blocks. And so the WS security work that we've done with many, many people is we believe the key standard that pushes that forward.

What are we doing in our product strategy here? Passport is our consumer authentication service. We'll have many different levels that you can get identities at and it will be clear to someone what that authentication is, all the way down to an identity that you can just create ad hoc and may not be connected to any real world thing all the way up to something where you've worked with a partner and actually presented real world credentials and be given a certificate that's connected to those things.

Now, inside corporations people have always had this authentication issue and the most popular product for keeping directories and letting people log in is our Active Directory product. There has been a long phased rollout of Active Directory. Today we have about a third of our enterprise customers fully deployed on that with virtually all of them in process at some stage, using this as a key component for their internal systems.

What we announced recently is what we call "TrustBridge," where you can take that internal Active Directory and say OK, if I want to share these identities outside the company, how can I use this WS security protocol to, say, take the Intel Active Directory implementation and the Microsoft one and exchange that information? That's the corporate-to-corporate case, where you can have a corporate-to-Passport case or any other system as well. And so we're building that, we're testing it with our partners in WS Security to make sure that the interoperability works very well there and so that for the first time goes from the inside authentication to what parts of that you want to expose to the outside, building on this standard protocol.

So there's a lot of direction here. The identity things, it's an enabling element. It's not something that is going to be that much of a source of competitive advantage because the overall protocols and the ability to create namespaces, that's going to be out there for everyone. But we felt the need to invest in this because you've got to start with this before you can have the idea of secure transactions.

So the end user themes are simplify the interface, keep them in control, make it worth it to them to add more information in so that they're not ever entering in things redundantly as they go and visit different locations.

Let's look at .NET My Services. Now, this goes beyond pure authentication to storing of information, a standard way, say, of looking at a schedule and having any application, if you authorize it, be able to look at your schedule, help you to add things onto your schedule. And so as part of that effort we've talked with partners about what should this schedule schema look like, what should the APIs for that look like.

The vision we feel very good about, but we made a couple of missteps on this. Our initial strategy was there was a single tool of the information and we had APIs that people could get at that, but the actual place that it was stored was all in one place. People said, no, they wanted federation of this like authentication from the very beginning. They also said they wanted more extensibility; that is, they wanted to be able to take our base schemas and go out and do different things.

And as we worked out through, we realized we needed a very strong connection between our database strategy and how we're extending the database with XML capabilities to the core, which is codenamed "Yukon," which is an ambitious effort underway, we needed to tie those kind of store extensions and the other standards around XML query into how we did the .NET My Services.

And so in terms of the technical design, we did a bit of a reset, went back out to people, told them what we were prioritizing. We do have some key services that we're getting out in advance of the general .NET My Services, some things around alerts and some other things, but it will be the next developer release for this comes out in the first half of next year.

I keep talking about federation, and it's based on this tenet of our strategy that everything we do should be common between how it works on a rich client that works offline, how it works on a server where a corporation can come in and license the software and run that themselves, and how it works on a service where somebody who doesn't want to run that server can connect into Microsoft and one of our partners, and, under some sort of economic structure, most likely a subscription type structure, have access to the capabilities of that service running out in the Internet.

And so everything we do needs to have the service and the server and then, of course, the work on our client software that matches into that. And so here you can see how those pieces fit together. For authentication it's this TrustBridge capability on Active Directory and the cloud services is how Passport evolves. Passport has evolved a lot in the last year but some of the key milestones in terms of the rich protocols are also later this year and early next year.

Notification is the idea that instead of going and finding information there are certain things you care enough about that you want to be notified. Now, that has to be filtered. You don't just want to be bombarded with instant messages or even e-mail. And so the idea that the user is in control there, they pick these subscriptions, they decide in which context those notifications are interesting to them, again we have a server-based implementation or notification server that we've had out in beta for some time and goes final next month and then we have the .NET alert service.

Real time: Jim Allchin later will talk about our strategy and how that's evolving. In the cloud it's the MSN Messenger and the program element is the .NET Messenger, and the corporate server is still a codenamed product that we've been hard at work on, coming out next year.

Software update: Again, that's one you might think, well, shouldn't that just be in the cloud. Well, no. Corporations want to take whatever improvements we make and then filter those according to their policies: When do they want to put those things out, which class of users do they want to put them out to, and they want to bring in lots of third-party applications or their own internally developed applications. And so they want a common way to say, OK, we get these nice new bits from you, Microsoft, but we stage those in a federated way, and our Software Update Server is the corporate implementation of that.

So now I've looked back and talked about what's happened in these last couple years. Now let me look forward and talk about how some of this breaking down barriers will proceed. And to be clear, it's one architecture, the .NET architecture being used to tackle tough problems, problems that may seem somewhat disparate but, in fact, lend themselves to this rich data description approach and these rich protocols, and all the tools and security things that are being built around that.

And so you've got trust, you've got finding information, you've got managing systems and making sure those are running well. You've got the idea of people wanting to find their information across devices and then you've got just plain simplicity of things being easy, not having to answer as many questions.

The app that continues to drive a lot of the requirements of this is the classic company-to-company doing-business-type application. Here there was a vision a few years ago that some people had that you could shortcircuit the creation of the rich platform by using so-called marketplaces, and you would just point browsers at these marketplaces and somehow they would unjumble the information.

That proved to have problems both in a technical sense and in a business sense, because the kind of information they had available and their incentives in terms of marking up transactions or being the place that understood the real price in the market, that didn't lead to the success that many had predicted.

So what comes of that? Well, what comes of it is that a platform provider or all platform providers go to corporations and say, OK, for literally thousands of dollars you can have the software that makes you both a hub and a spoke. In the case where you're in charge doing business, people find you're a hub. The software lets you do that. No one else sees the information. There's no markup to transactions. There's no unusual incentive created by having somebody in the middle there. If you're a spoke, great, we've got these standards that have come along and so you can use that software and connect up to, say, a major buyer, and the standards work will make sure that it's not different software that you use in the case when you're working with other customers or in the case where people are supplying to you.

Now, the interesting computer science problems that this alone imposes have kept us and many partners very busy doing work, and the whole process we've been going though of having our developer conferences, putting out proposed protocol specs, getting feedback on those, drawing in other partners, refining those things, that has been a fast-moving and I think very fruitful process.

One of the elements that's come together on this is the key industry companies creating a group called Web Services Interoperability. And there are over 120 companies in that today. I could say in a sense it's a given that this is where all that alphabet soup, that at least at a business decision level, people shouldn't have to know all those different elements, all of this will come together into the clear profiles that will drive these systems.

And so somebody can say, OK, if this stack and the way I'm using that supports these standards, then I get the benefit and so then I can look at this stack more in terms of what kind of hardware does it run on, what kind of software development tools does it have available, and I can make these stack providers, including Microsoft with .NET, I can force them to do what I want them to do, because I've picked my common element as something that's out in the standards arena. And so the progress there is a really great thing.

Where are we today? BizTalk, WS-I, those WS standards, the rest of this year you'll see a few more neat things coming out there, but we really are getting to the point where the key ones are in place. I'm not saying there won't be 1.1 type version refinements here but the 1.0 stuff, because it's in use today, because it's working for people, it's got a level of capability that really a lot of that can stay very, very stable looking forward.

Now, the key capabilities are intrinsic to the design, the interoperability, the idea that you can manage these systems, that you can log all the different things that happen, create audit trails, and those audit trails you can store in an XML database and so you can filter those in a very rich way. It's not necessary to transform the information into some other complete architectural domain in order to have the deep manageability that systems have not had to date and yet it's necessary to have that because of the number of systems and the amount that's being done on a digital basis.

Trust: Trust is a very broad thing. It's not just authentication. Trust is a lot of initiatives in our industry. For example, how quickly will the industry move away from passwords as a method of authentication, both inside a company and in terms of doing transactions on the Internet? We don't think in the long run passwords will be used for things where you want a lot of security.

For example, how quickly will we get it so that mail can't be spoofed, so somebody can't just send out mail that appears to come from the IT department and create lots of confusion about which e-mail tells me to do which thing is actually the right thing. That's a significant vulnerability that needs to be eliminated.

We need to have the Internet working for us in terms of propagating software improvements even faster than people who had tried to use the Internet to propagate exploits against those software that's out there. We need methodologies about how these software elements are built.

This is a key focus for us. In fact, the memo that I sent internally in the company really had an even more profound impact than I expected. The interest from a bottom's-up basis inside the company, of taking rich technologies and new processes to build code that was designed to not have these problems, that was a stronger reaction than we ever expected. It was a huge investment but it's an investment in something that's very much top of mind and simply has to be done in a great way to achieve this potential.

There are a lot of different pieces that go into this. The very design of the common language runtime lends itself to securing things in a better way. The way we deploy things and help people set them up, we help them audit them, we help them keep them up to date. We are putting a massive amount of effort into that and we're getting great feedback on what problem does the Software Update Server solve and what new things do we need to do there.

This is an area that Jim Allchin is going to talk about in his presentation and give you a sense of what's gone very well, what came out of that huge focus on the security thing, and what you can expect moving forward.

Now, barriers in communications, this is another domain and here again what we've got is not optimal. You have phone numbers. You've got multiple e-mail addresses. You get interrupted. Do you ever get junk mail? Yes. Do you ever get mail that you'd like to get that you get it at a time where it's not appropriate, where it's kind of an interruption?

We don't have the user centricity. Until we understand context, which is way beyond presence -- presence is the most trivial notion of context, just am I on this device or not; it doesn't say am I meeting with something, am I focused on writing something. Context is where you have enough information to work on behalf of the user and understand what kind of connection can be made.

A big part of this we believe is bringing the voice world and the screen world together and you're seeing this in a number of real time things. We, I would say, kicked that off with our Net Meeting product but we believe that Net Meeting has just really scratched the surface. It was almost a cult-like product because a few people got it, saw that it was a very neat thing, and we need to go well beyond that.

Now, we saw some of that was a support feature we built into Windows where you can connect up to another machine and help someone out. Doing it that way where you have screen share and screen control is so much better than having a voice call where you're trying to describe what's going on. But it's not just support; it should be running a type of application or any call that relates to sales or marketing or planning, why not have those screens working together? Why not have the software deciding when that connection should be made and helping the user to do that? Likewise for meetings, why can't you digitally record and share those things both for remote real time users and for people who asynchronously connect up later? There's a lot that can be done that has become feasible not only because of the connectivity but the low-cost storage, and what remains is simply the software that makes it very straightforward.

For us we have some key assets. Outlook will evolve from being an e-mail client to being far more than an e-mail client. The real time stuff we have in our consumer side in the information sharing in SharePoint is important.

SharePoint, you're going to see, is really a key part of Office. A lot of the neat things that relate to Office require that users be able to share information and SharePoint goes way beyond a file server in making that kind of thing possible.

We talked about the information agent as something that will live both in Outlook and on the server that works on your behalf in terms of the priority things that I talked about.

Finding information: Here we get to something that those of you who have followed my architectural dreams will know this has been a Holy Grail for a long, long time at Microsoft; that is, making it so there's a single search command across all the different kinds of information, and if you want to have a tabular view of information, whether it's a set of printers or users or files that it's one straightforward user interface to use that works for everything.

Well, the only way to do that and to really break down these barriers to knowledge is to have what's called the unified store. Today we've got SQL, we've got Outlook formats, we've got Web site formats, community formats, we've got different things on the devices and none of those really is a superset of the other because we haven't had this XML capability.

Well, that core architecture again shows up and says look, because you can query these heterogeneous things, the idea of all those things in the mailbox and that you have in file folders or different system entities, yes, put that into a single interface and the user will be far more adept and have a lot less to learn. Now, defining those schemas, defining those views, that's the work that we're doing now.

You could say that the beauty of this store is not just that it's unified, but that it replicates onto the different devices and that the search capabilities will be far more intuitive than the things we have today. This is pretty radical, because we want applications, of course, to take full advantage of this.

In terms of everyday use, we all know that the user interfaces we have today are not as simple as they need to be, whether it's simply exposing the user to too much of the insides of the computer or whether it's the lack of natural interaction techniques like ink or speech that would make you far more likely to keep everything in digital form and be able to connect those things together.

One way we look at this is saying, OK, during the course of the day is your digital information always there, is software helping you as much as it can. In most meetings, it's not. Most of the time in terms of when you're reading long documents and taking notes on them, it's not. And so there's so much more that should be possible that again draws on this approach of a rich store, a rich common architecture.

What you're going to see, of course, is that the hardware innovations, despite the challenges in the economy and these IT budgets, the hardware innovation is not slowing down. You know, that might be surprising in a way but the fundamental ability to store more bits, to send more bits down fiber, to have chips have more transistors and higher process rates, those things aren't really slowed down in any dramatic way by the challenge, the business challenges that the industry faces.

And so what you have to do is take those things and drive new scenarios, drive excitement level, drive value into these different things.

So you're going to see with the PC a lot more changes in these next three or four years than in the last three or four. The tablet is kicking that off. What we call the Windows Smart Display is kicking that off. The Windows Media Center for the large screen display type capability, what was codenamed "Freestyle," is also kicking that off. The fact that we get to smaller size, we get smaller disks, better and better control really means that the reach of the PC goes up and we have to combine that with the software that brings in this natural user interface.

So where do we do this? We do it with Windows, Windows Media, Office interface and the way that services connect into this.

Software-as-a-service is fundamental to this. You're going to not want to have to think of you're doing the software installs and when you do that software install you're on your own if something goes wrong, there's nobody who's able to monitor over that and help you out with any of the challenges that are taking place.

So this is a summary slide. It's one of my favorite slides because it shows that here's the one architecture and here's the different domains that it's valuable. And somebody can argue is the benefit greatest in this business process domain, is it greatest in the information worker domain or the IT domain where the problems were really threatening to hold back all of these rollouts, the management, updating those capabilities or is it driving the breakthroughs in the consumer market because of the usability. I'd say that probably the greatest value is in the boundaries of these domains, making sure that things aren't stuck just inside one of those bubbles and that's where the common architecture comes in.

This will roll out in terms of our implementation in a couple different ways. We've got a wave of products over the next 12 months or so. That includes a major update to Office. It includes a lot of updates to things running on top of Windows that I mentioned, an update to our SharePoint capability, so a fairly rich set of activities for the next 12 months.

Then we have a wave where we take the store and we actually get it done in a database release and some things including tools around that, and then finally further our is the version of Windows that we build that store into, and that's where you get the major advances and you get versions of all Microsoft software that comes together and takes advantage of that rich platform.

Now, that's another big bet we've made is we've said that we're going to align ourselves on building the new technologies and then once we get those integrated into a Windows release all our different efforts -- MSN, Office, our PDA efforts are going to connect up to the way that information is presented there. And so that's why I've got a very full-time challenge and exciting job as the Chief Software Architect that sees how that goes together.

So .NET is about breaking down barriers. It's about getting connected. Phase one is essentially behind us with all of its lessons and things that went well and not so well. This is concrete. That's one thing to have an important understanding of. To developers in particular, to people connecting applications today, they are seamless going on and we're getting the feedback that's bringing us down the learning curve.

This is a long-term approach. If we ever make a video for Forum 2004 they can excerpt me saying here in 2002 it's a long-term approach. All these things don't happen overnight. We're committed to the R&D that's necessary for this. But the next two years you'll really see a lot of these key things and then after that is when "Longhorn" comes along.

The user experience pieces, there's very little of that that people have seen today and yet in some ways when it comes together in that, that's when it gets most exciting.

So we're very committed to this and I enjoyed the opportunity to have a dialogue with you about .NET.

Thank you.

(Applause.)