本文发表在 rolia.net 枫下论坛When people found I work for Microsoft, there used to be two questions that invariably came up.
First was, "Do you know Bill?" (Not really, though I've met and presented to him.)
The second was, "How do I do such-and-such on Word/Windows/whatever?" (Sometimes I even know the answer. I turned the tables last week, though; my nephew, a doctor, came to dinner, and before we could stop ourselves, my wife and I asked him a question about our down-with-a-cold toddler.)
These days, there are two more common so-you-work-for-Microsoft questions. The first involves lawyers. (No comment. Really.) The second is, "So what the heck is .NET?"
Let me try to answer the .NET question here. It's complex. Einstein once said, "Everything should be made as simple as possible, but not simpler." In that spirit, I hope the work below makes a useful starting point.
What is Microsoft .NET? To oversimplify, .NET for IT includes services, development tools and systems, and servers. Clients are part of it too where there is direct user interaction.
The remainder of this note describes .NET and how it might touch IT. Part 2, coming shortly, is an overview of the various components from an IT perspective, with links to technical/IT information. In Part 3, which likely will follow Part 2, I'll offer some concrete examples based on experience with real-world businesses.
Descriptions — Microsoft's and Mine
The definition of .NET you might hear from us at Microsoft goes something like this: .NET is Microsoft's platform for XML web services. XML web services allow applications to communicate and share data over the Internet or an intranet, regardless of operating system or programming language.
That's technically accurate. However, I think .NET is about more than XML.
Six years ago, people thought of a browser as a tool that rendered pages and followed links in HTML. Today it's described in part as "a feature-rich platform for building [w]eb-based applications and developing informative content for users." You and I know browsers do HTML, but few of us think about that aspect nowadays; it's a given, the background for the real information.
Likewise, .NET does XML. But that's background, I think. Here's how I'd define it (and note that this is my personal definition, not a Microsoft "official statement" of some sort): .NET is a feature-filled services platform for building web-based applications and developing rich interactive experiences for users and their systems. The small-w "web" includes both the Internet and intranets.
Let's look at three key words and phrases: interactive, experiences, and their systems.
.NET and "Interactive"
Interactive means more than clicking links on pages or filling in HTML forms. Why can't I schedule a dentist appointment on line? Get a version of The New York Times on line that focuses on what I want to read today (which is different from yesterday)? Get my IT systems sharing data?
The technology exists without .NET to allow all of these, but programming is very hard for the vendor, and those that require client logic — say, having Outlook coordinate scheduling with the dentist — are harder yet.
.NET is designed to make this level of interaction easy, even among disparate systems. For IT, consider both internal and B2B line-of-business apps and systems; if they're all .NET enabled, you can mate up systems and give users access to the data-based information they need with tools rather than laborious programming, as in the simplified examples that follow. (I picked the dentist example to show some possibilities. The real IT examples will be in Part 3.)
In other words, .NET is the difference between pointing a browser at a single web site and reading or entering information and working in an environment where information from systems across the Internet can be gathered into a rich view supporting user involvement, creativity, annotation, and true interaction with the applications.
.NET supplements but does not supplant today's HTML approach. HTML works very well for the class of problems wherein one web site presents information or collects simple data from the user. However, if you want to program the web, if you want to treat each device — in server-server or server-client interactions — as having intelligence and being able to exchange data in a flexible, heterogeneous form that includes enough self-description to allow the applications to adapt to that data, then .NET, built on XML/SOAP, is the key.
.NET and "Experiences"
When I set up an appointment with my dentist's receptionist, she offers a time; I can accept, ask her to suggest some other time, or make a counteroffer of days that would work for me. We go back and forth looking at our respective electronic calendars, and eventually settle on a date and time. This negotiation constitutes an experience, a sequence of related small interactions in real time that collectively define a process.
In the IT space, think about, say, the supply chain. Today it's often a series of phone calls, a fax/letter/e-form, more calls to track progress, and then — perhaps — electronic submission of an invoice. .NET posits a world in which I can describe the supplies I need, their schedule, and perhaps the price I'm willing to pay; cast a wide net over the Web for potential suppliers; come to agreement on price, delivery, invoicing, and payment; and then follow progress until the physical goods arrive at my loading dock — with automated tools doing each of the steps I just described. The supply-chain manager can actually manage and supervise rather than perform repetitive manual processes.
.NET and "Systems"
At the dentist's office, the receptionist and I compare our calendars manually, even though those calendars are computer-based. In the .NET world, the calendars themselves could negotiate a series of times and offer them to me, or even in the case of a toothache simply take the first time available to both of us. Just as in the supply-chain example, the systems themselves take on much of the underlying work.
Already our computers "know" things required by systems on the other end, such as my schedule or a needed manufacturing supply. However, because we take for granted that our systems can't interrogate each other and exchange the right information, we don't much consider the time we spend telling one computer what another already "knows."
But this retelling is time wasted. We can't fix it today; not quite. .NET offers hope over the next few years.
Twenty years ago, secretaries routinely retyped letters from scratch, even though they had typed the first version on a machine (remember typewriters?). Until standalone and PC word processors became commonplace, no one thought this was odd. When was the last time you retyped an entire letter to add a line?
Someday, you'll have to think about the last time you reentered information already in your system. My bet is that this day will come sooner than we think. Of course, that's Microsoft's bet too. I can envision losing the bet because some other company does it better, though I believe we'll execute best. I cannot, however, envision losing the bet because that day never comes.
Why .NET Matters to IT
.NET matters for two reasons, one "selfish," one tied to the profit motive.
It matters, in some ways, for the same reason that word processing mattered 20 years ago. In 1982, it was done on standalone machines by trained specialists, themselves called "word processors." Meanwhile, managers were hiding IBM PCs and Apple IIs in their offices to crunch numbers with early spreadsheets. These same managers quickly discovered that they could get word processing programs for their machines, and suddenly their productivity, flexibility, and turnaround time improved. It took IT a decade to catch up to their users.
XML is here. .NET technologies are available. Users and departments will figure this out if IT doesn't. This time, let's keep up with our users.
There's a bigger reason. The corporate environment is changing. Companies are focusing on productivity and efficiency, some because they believe in it, others simply because their competitors are getting ahead of them. Look at general-merchandise retailing in the past decade, for example. One big chain (you know whom I'm talking about) relentlessly reduced both supplier and internal friction in their processes, slicing both their cost of goods and cost of sales; other retailers have had to follow suit. Or think about how the older brokerage houses have been responding to the innovations of their less traditional competitors. It's happened in dozens of sectors.
Do you think this march is going to stop?
I think most of our businesses are going to be engaged in these productivity processes, whether they lead or lag. And if a business is involved, IT is involved. IT needs to be committed to helping businesses not just survive but prosper.
.NET can help you help your company prosper in the coming years. It's not a panacea; it's not a solution in and of itself; it probably won't make much bottom-line difference in the next six or nine months. But looking out 12 to 36 months, the technological ideas behind .NET will be one of IT's biggest factors in driving efficiency.
Suggesting Some Very Unofficial Timelines
I write these without having studied Microsoft's marketing timelines. I'm basing them on actual product schedules, and my experience with IT.
Were I an enterprise IT manager today, I'd be spending time this winter and spring understanding .NET, probably doing a pilot project by the summer to climb the learning curve. Then, armed with that understanding and knowledge, I'd be on the lookout for a corporate initiative where IT could play a key role in winning for the business by using .NET. On this timeframe, I wouldn't be leading the curve, but I'd likely be on the rising side rather than in the middle.
Of course, that's my personality; were I more risk-averse than average (and I believe risk-aversion is generally a good thing in IT), I'd still jump quickly on the knowledge-gathering phase, get a small pilot up sometime this year, and then be ready to respond with larger efforts when you feel the time is right. In other words, whatever my comfort zone on the adoption bell curve, I'd be ready to step up when the business needs it.
Were I in non-enterprise IT, I'd still want to get knowledgeable about .NET before summer. In some businesses, customers may adopt .NET technologies and then expect their suppliers to be ready to join them. In other areas, you may find that a part of .NET affords you the opportunity to deliver a solution or service that belies your smaller size relative to your competitors.
I see .NET having impact in two critical areas of IT in the next 18 months. One area is the perennial IT thorn, integration of disparate systems; some companies are already making real progress here. The other is in providing new capabilities to our businesses.
The sidebar link in the previous paragraph briefly describes two actual IT examples. In Part 3 of this series, I'll dig further into a handful of real businesses and offer examples of where and how I might implement .NET as a productivity enhancer. (I used to be a Principal Consultant for Microsoft Consulting Services; this is what I used to do for businesses around the world.)
For starters, TechNet has an article about .NET and IT.
.NET and Day-to-Day IT
I don't think .NET is much of a risk, but I know most of you do. I know taking risks is especially tough in hard economic times. I also know that it's such times that afford scrappy, efficient companies an opportunity to get in front for the better times that will follow.
I know day-to-day problems are still IT's focus, and many of you are one or two or three versions back on various products. We at TechNet are not going to stop giving you straightforward technical information on these products and issues; we just released 50 new How-To articles on Office, for example.
But I've been reading reports on what companies are doing to cope with a stalled economy, and the TechNet team has been out talking to users. Some folks are ready to start taking advantage of what .NET offers, and with the release of Visual Studio.NET to complement the released .NET Servers there will be solutions flowing.
Which gets us back to the second so-you-work-for-Microsoft question: Can I solve your computer problem? The IT version of this question doesn't have just the help desk as the answer; the bigger computer problems are also business problems. .NET is about solving business problems. I'm trying to help.
Oh, my nephew-the-doctor who came to dinner? Sure enough, over coffee he asked us a question about his PC. And we helped him… I think.
I can't answer questions about your PC on line. However, if you have questions or comments about TechNet itself, here's the address. I can't promise to answer each one individually, but I do read them.更多精彩文章及讨论，请光临枫下论坛 rolia.net
First was, "Do you know Bill?" (Not really, though I've met and presented to him.)
The second was, "How do I do such-and-such on Word/Windows/whatever?" (Sometimes I even know the answer. I turned the tables last week, though; my nephew, a doctor, came to dinner, and before we could stop ourselves, my wife and I asked him a question about our down-with-a-cold toddler.)
These days, there are two more common so-you-work-for-Microsoft questions. The first involves lawyers. (No comment. Really.) The second is, "So what the heck is .NET?"
Let me try to answer the .NET question here. It's complex. Einstein once said, "Everything should be made as simple as possible, but not simpler." In that spirit, I hope the work below makes a useful starting point.
What is Microsoft .NET? To oversimplify, .NET for IT includes services, development tools and systems, and servers. Clients are part of it too where there is direct user interaction.
The remainder of this note describes .NET and how it might touch IT. Part 2, coming shortly, is an overview of the various components from an IT perspective, with links to technical/IT information. In Part 3, which likely will follow Part 2, I'll offer some concrete examples based on experience with real-world businesses.
Descriptions — Microsoft's and Mine
The definition of .NET you might hear from us at Microsoft goes something like this: .NET is Microsoft's platform for XML web services. XML web services allow applications to communicate and share data over the Internet or an intranet, regardless of operating system or programming language.
That's technically accurate. However, I think .NET is about more than XML.
Six years ago, people thought of a browser as a tool that rendered pages and followed links in HTML. Today it's described in part as "a feature-rich platform for building [w]eb-based applications and developing informative content for users." You and I know browsers do HTML, but few of us think about that aspect nowadays; it's a given, the background for the real information.
Likewise, .NET does XML. But that's background, I think. Here's how I'd define it (and note that this is my personal definition, not a Microsoft "official statement" of some sort): .NET is a feature-filled services platform for building web-based applications and developing rich interactive experiences for users and their systems. The small-w "web" includes both the Internet and intranets.
Let's look at three key words and phrases: interactive, experiences, and their systems.
.NET and "Interactive"
Interactive means more than clicking links on pages or filling in HTML forms. Why can't I schedule a dentist appointment on line? Get a version of The New York Times on line that focuses on what I want to read today (which is different from yesterday)? Get my IT systems sharing data?
The technology exists without .NET to allow all of these, but programming is very hard for the vendor, and those that require client logic — say, having Outlook coordinate scheduling with the dentist — are harder yet.
.NET is designed to make this level of interaction easy, even among disparate systems. For IT, consider both internal and B2B line-of-business apps and systems; if they're all .NET enabled, you can mate up systems and give users access to the data-based information they need with tools rather than laborious programming, as in the simplified examples that follow. (I picked the dentist example to show some possibilities. The real IT examples will be in Part 3.)
In other words, .NET is the difference between pointing a browser at a single web site and reading or entering information and working in an environment where information from systems across the Internet can be gathered into a rich view supporting user involvement, creativity, annotation, and true interaction with the applications.
.NET supplements but does not supplant today's HTML approach. HTML works very well for the class of problems wherein one web site presents information or collects simple data from the user. However, if you want to program the web, if you want to treat each device — in server-server or server-client interactions — as having intelligence and being able to exchange data in a flexible, heterogeneous form that includes enough self-description to allow the applications to adapt to that data, then .NET, built on XML/SOAP, is the key.
.NET and "Experiences"
When I set up an appointment with my dentist's receptionist, she offers a time; I can accept, ask her to suggest some other time, or make a counteroffer of days that would work for me. We go back and forth looking at our respective electronic calendars, and eventually settle on a date and time. This negotiation constitutes an experience, a sequence of related small interactions in real time that collectively define a process.
In the IT space, think about, say, the supply chain. Today it's often a series of phone calls, a fax/letter/e-form, more calls to track progress, and then — perhaps — electronic submission of an invoice. .NET posits a world in which I can describe the supplies I need, their schedule, and perhaps the price I'm willing to pay; cast a wide net over the Web for potential suppliers; come to agreement on price, delivery, invoicing, and payment; and then follow progress until the physical goods arrive at my loading dock — with automated tools doing each of the steps I just described. The supply-chain manager can actually manage and supervise rather than perform repetitive manual processes.
.NET and "Systems"
At the dentist's office, the receptionist and I compare our calendars manually, even though those calendars are computer-based. In the .NET world, the calendars themselves could negotiate a series of times and offer them to me, or even in the case of a toothache simply take the first time available to both of us. Just as in the supply-chain example, the systems themselves take on much of the underlying work.
Already our computers "know" things required by systems on the other end, such as my schedule or a needed manufacturing supply. However, because we take for granted that our systems can't interrogate each other and exchange the right information, we don't much consider the time we spend telling one computer what another already "knows."
But this retelling is time wasted. We can't fix it today; not quite. .NET offers hope over the next few years.
Twenty years ago, secretaries routinely retyped letters from scratch, even though they had typed the first version on a machine (remember typewriters?). Until standalone and PC word processors became commonplace, no one thought this was odd. When was the last time you retyped an entire letter to add a line?
Someday, you'll have to think about the last time you reentered information already in your system. My bet is that this day will come sooner than we think. Of course, that's Microsoft's bet too. I can envision losing the bet because some other company does it better, though I believe we'll execute best. I cannot, however, envision losing the bet because that day never comes.
Why .NET Matters to IT
.NET matters for two reasons, one "selfish," one tied to the profit motive.
It matters, in some ways, for the same reason that word processing mattered 20 years ago. In 1982, it was done on standalone machines by trained specialists, themselves called "word processors." Meanwhile, managers were hiding IBM PCs and Apple IIs in their offices to crunch numbers with early spreadsheets. These same managers quickly discovered that they could get word processing programs for their machines, and suddenly their productivity, flexibility, and turnaround time improved. It took IT a decade to catch up to their users.
XML is here. .NET technologies are available. Users and departments will figure this out if IT doesn't. This time, let's keep up with our users.
There's a bigger reason. The corporate environment is changing. Companies are focusing on productivity and efficiency, some because they believe in it, others simply because their competitors are getting ahead of them. Look at general-merchandise retailing in the past decade, for example. One big chain (you know whom I'm talking about) relentlessly reduced both supplier and internal friction in their processes, slicing both their cost of goods and cost of sales; other retailers have had to follow suit. Or think about how the older brokerage houses have been responding to the innovations of their less traditional competitors. It's happened in dozens of sectors.
Do you think this march is going to stop?
I think most of our businesses are going to be engaged in these productivity processes, whether they lead or lag. And if a business is involved, IT is involved. IT needs to be committed to helping businesses not just survive but prosper.
.NET can help you help your company prosper in the coming years. It's not a panacea; it's not a solution in and of itself; it probably won't make much bottom-line difference in the next six or nine months. But looking out 12 to 36 months, the technological ideas behind .NET will be one of IT's biggest factors in driving efficiency.
Suggesting Some Very Unofficial Timelines
I write these without having studied Microsoft's marketing timelines. I'm basing them on actual product schedules, and my experience with IT.
Were I an enterprise IT manager today, I'd be spending time this winter and spring understanding .NET, probably doing a pilot project by the summer to climb the learning curve. Then, armed with that understanding and knowledge, I'd be on the lookout for a corporate initiative where IT could play a key role in winning for the business by using .NET. On this timeframe, I wouldn't be leading the curve, but I'd likely be on the rising side rather than in the middle.
Of course, that's my personality; were I more risk-averse than average (and I believe risk-aversion is generally a good thing in IT), I'd still jump quickly on the knowledge-gathering phase, get a small pilot up sometime this year, and then be ready to respond with larger efforts when you feel the time is right. In other words, whatever my comfort zone on the adoption bell curve, I'd be ready to step up when the business needs it.
Were I in non-enterprise IT, I'd still want to get knowledgeable about .NET before summer. In some businesses, customers may adopt .NET technologies and then expect their suppliers to be ready to join them. In other areas, you may find that a part of .NET affords you the opportunity to deliver a solution or service that belies your smaller size relative to your competitors.
I see .NET having impact in two critical areas of IT in the next 18 months. One area is the perennial IT thorn, integration of disparate systems; some companies are already making real progress here. The other is in providing new capabilities to our businesses.
The sidebar link in the previous paragraph briefly describes two actual IT examples. In Part 3 of this series, I'll dig further into a handful of real businesses and offer examples of where and how I might implement .NET as a productivity enhancer. (I used to be a Principal Consultant for Microsoft Consulting Services; this is what I used to do for businesses around the world.)
For starters, TechNet has an article about .NET and IT.
.NET and Day-to-Day IT
I don't think .NET is much of a risk, but I know most of you do. I know taking risks is especially tough in hard economic times. I also know that it's such times that afford scrappy, efficient companies an opportunity to get in front for the better times that will follow.
I know day-to-day problems are still IT's focus, and many of you are one or two or three versions back on various products. We at TechNet are not going to stop giving you straightforward technical information on these products and issues; we just released 50 new How-To articles on Office, for example.
But I've been reading reports on what companies are doing to cope with a stalled economy, and the TechNet team has been out talking to users. Some folks are ready to start taking advantage of what .NET offers, and with the release of Visual Studio.NET to complement the released .NET Servers there will be solutions flowing.
Which gets us back to the second so-you-work-for-Microsoft question: Can I solve your computer problem? The IT version of this question doesn't have just the help desk as the answer; the bigger computer problems are also business problems. .NET is about solving business problems. I'm trying to help.
Oh, my nephew-the-doctor who came to dinner? Sure enough, over coffee he asked us a question about his PC. And we helped him… I think.
I can't answer questions about your PC on line. However, if you have questions or comments about TechNet itself, here's the address. I can't promise to answer each one individually, but I do read them.更多精彩文章及讨论，请光临枫下论坛 rolia.net