Telirati Newsletter #6
In this sixth newsletter, I can claim a reasonably prescient view of COM as being insufficient for competing against Internet standards. Surprisingly, .NET is not really pulling people into a Microsoft/Internet world, either. .NET really does deliver a suite of technologies for making the Internet an active network of connected software, rather than a very large hypertext web.
But .NET has not set the world afire. Perhaps it took too long. Perhaps it has too few widely used applications with high value. Whatever the case, nobody is saying "Wow, .NET changed the Internet."
Perhaps there really is nothing Microsoft can do to retain a position as utterly vital in the software ecology.
Newsletter #6: Diversity vs. compatibility
Some people think I'm a Young Turk. But compared with the engineers I hired at my last start-up, I'm a geezer. A running gag we had was that "When I was young I walked three miles through the snow to toggle in the boot load code on the front panel of a PDP-8." Back then, we had diversity -- lots of different hardware and software. Back then, end users often enough wrote their own operating systems. Back then, a VAX with 16MB was a honkin' machine. Back then, it was not unusual for a new computer company to create a CPU, a bus architecture, an OS, a language, and applications -- all on the R&D budget of a start-up.
Gradually, all that came to an end. The first beta release of Windows 95 signaled to me the end of history: We would all write COM objects, for Windows OSs, in C++, and hundreds of millions of x86-based computers all over the world would run this software. In a way, this was exciting. Adding tens of millions of customers each year to a uniform, standardized market for software is exciting by any measure. But while this looked like an ever-expanding opportunity, it also represented the end of a certain class of opportunity. In almost all the major categories of software used on business desktops, Microsoft stood astride the market. Sure, PeopleSoft, Baan, and SAP have the enterprise fiscal management software realm to fight over, but the world plainly is not waiting for the next great word processor, spreadsheet, business graphics program, page layout program, or other mass-market desktop software.
Then came the Internet. Now, before you say you've heard that one before, recall the suddenness with which things were changed. I would have told you, back when Microsoft first announced MSN, that AOL was doomed because the AOL technology was clunky and sure to be overwhelmed by the elegant, well-integrated MSN software. And I would have dismissed the Internet entirely. Who, after all, would take the trouble to learn all that Unix-oriented arcana? Who would tolerate managing IP addresses, telnet, ftp, and all that nonsense? And I stood in good company.
Now things are damn weird. Take COM. COM and DCOM have clearly trounced CORBA as a distributed object technology for Windows software. Writing COM software is not simple, but it is nothing like all the hoops you have to jump through for CORBA, and COM has the distinct advantage that Microsoft creates highly productive application frameworks for COM, and Microsoft's software development tools are ideal for writing this kind of software. And this situation continues to improve. COM+ is better, more powerful, and in many ways simpler. But do you need COM?
If you are writing Windows applications, yes you should use COM. And if you don't use it, you'll suffer. Your applications won't share information and capabilities with other Windows applications. You'll be an outsider wearing a loud tie and a bad suit in a very conformist club. But do you need COM to make distributed applications? That depends on who you are. Who endorsed COM+ immediately? PeopleSoft, Baan, and SAP. These are exactly the companies out there replacing the mainframe-based enterprise fisc with modern distributed systems running on NT. Good for them, and good for their customers. Good for all of us now liberated from ever having to consider buying a mainframe no matter how big our business grows. But what does it mean to the company writing an Internet-based personal financial management package? What does it mean to the company writing multi-player simulation games? What does it mean to anyone with fewer than 100 software engineers not writing a product which their customers will spend millions of dollars buying and installing -- that's millions each, not in aggregate?
Let's say you were designing a unified messaging system today. How are things different from the time of the Windows 95 announcement? How are things different After the Internet?
Before Internet: The customer would install your product from a CD disk, first at the server, then at the clients. A more-advanced system might make use of software management features of SMS.
After Internet: The customer installs the product on the server. Client installations are made by accessing Web pages on the server that contain a client software download, interactive instructions for installation, and a tutorial on using the product.
Before Internet: The best way to make a distributed system ready for big companies is to make it operate across multiple protocols -- IPX/SPX, NetBEUI, and TCP/IP. This can be accomplished by using RPCs or distributed COM objects. Both these technologies make it possible to write multi-protocol distributed software while containing the nasty details of networking in one place.
After Internet: Use TCP/IP only. Even if you are using DCOM or RPCs, you can assume the network is an IP network. Remember, we're talking about a new-generation unified messaging system here, which means the network will be chock full of H.323 clients and Internet telephony gateways, which means IP. Yes, you really can assume IP on everything, especially in telephony applications.
Before Internet: Document-level compatibility meant Microsoft Word. Or, if you wanted to play in the multi-application document integration world, you had to implement OLE linking and embedding. Compound document architectures like OLE assume that there will never be a single document format, so they must enable disparately formatted document objects, and the code that edits those objects, to be embedded in foreign documents.
After Internet: Just like there is one protocol, IP, there is one document format: HTML. HTML together with XML mean your documents and data can be read and modified anywhere. The result will crack the hegemony of Word in document editing and viewing.
Before Internet: Your messaging system should be a MAPI service, either directly connected to your messaging server, or integrated with Exchange Server.
After Internet: Your messaging system should still be a MAPI service, either directly connected to your messaging server, or integrated with Exchange Server. This is because Exchange Server will be Microsoft's Internet messaging solution, and will be very successful. But you should also include IMAP support in your server so Internet mail clients without MAPI support can access your server and present a unified messaging environment to users. And you should have a Web access option as well, where clients can access messages using only a browser. Did your job just get three times bigger implementing this part of unified messaging? Yes.
Before Internet: You had your choice of proprietary management systems -- SMS, Solstice, etc. -- with their own integration interfaces, plus some open systems that use SNMP.
After Internet: SNMP. None to their credit, Sun seems to be trying to foist Solstice's interface on Java, instead of providing the best possible open, SNMP-oriented management tools.
What can Microsoft do to continue to dominate the scene? One answer is "Nothing." Not everyone needs a distributed object and compound document architecture, and less so with Internet standards widely adopted. The other answer is that Microsoft could do a better job of marketing their distributed object technology: First it was OLE, then ActiveX (which gave us the ActiveBuzzword nomenclature), and now DNA, which sounds like a throwback to some DEC announcementware related to networks of VAXes.
One thing Microsoft can do -- and is doing -- is a good job adopting Internet standards. Microsoft is doing is a good job making Exchange Server a good Internet mail server, and Microsoft's Outlook Express is a good Internet mail client (though they did screw up their upgrade path by omitting MAPI support in Outlook Express). And not least, networks of Windows PC and NT servers support TCP/IP very well. To say that Microsoft is doing well adopting Internet standards may sound odd in the face of the tiff over Java, but Microsoft's general advantage in the industry is that they execute better than their would-be competitors.
Execute better than your competitors. Microsoft, which has often enough been wrong about the first release of a product, doggedly pursues top-notch execution. And they do it even if it did not work out right the first time, instead, as is often the case in the industry, a weak start dooms a product to insufficient follow-on investment. What the Internet has done is open the door to new opportunities, new companies. But Microsoft's formula for success still holds true: execute well, and then, when you are done with the first release do not -- do not even consider -- allowing the product to become stale before you aggressively upgrade it in anticipation of, not in reaction to, feedback about improvement.
Copyright 1997 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.
.
But .NET has not set the world afire. Perhaps it took too long. Perhaps it has too few widely used applications with high value. Whatever the case, nobody is saying "Wow, .NET changed the Internet."
Perhaps there really is nothing Microsoft can do to retain a position as utterly vital in the software ecology.
Newsletter #6: Diversity vs. compatibility
Some people think I'm a Young Turk. But compared with the engineers I hired at my last start-up, I'm a geezer. A running gag we had was that "When I was young I walked three miles through the snow to toggle in the boot load code on the front panel of a PDP-8." Back then, we had diversity -- lots of different hardware and software. Back then, end users often enough wrote their own operating systems. Back then, a VAX with 16MB was a honkin' machine. Back then, it was not unusual for a new computer company to create a CPU, a bus architecture, an OS, a language, and applications -- all on the R&D budget of a start-up.
Gradually, all that came to an end. The first beta release of Windows 95 signaled to me the end of history: We would all write COM objects, for Windows OSs, in C++, and hundreds of millions of x86-based computers all over the world would run this software. In a way, this was exciting. Adding tens of millions of customers each year to a uniform, standardized market for software is exciting by any measure. But while this looked like an ever-expanding opportunity, it also represented the end of a certain class of opportunity. In almost all the major categories of software used on business desktops, Microsoft stood astride the market. Sure, PeopleSoft, Baan, and SAP have the enterprise fiscal management software realm to fight over, but the world plainly is not waiting for the next great word processor, spreadsheet, business graphics program, page layout program, or other mass-market desktop software.
Then came the Internet. Now, before you say you've heard that one before, recall the suddenness with which things were changed. I would have told you, back when Microsoft first announced MSN, that AOL was doomed because the AOL technology was clunky and sure to be overwhelmed by the elegant, well-integrated MSN software. And I would have dismissed the Internet entirely. Who, after all, would take the trouble to learn all that Unix-oriented arcana? Who would tolerate managing IP addresses, telnet, ftp, and all that nonsense? And I stood in good company.
Now things are damn weird. Take COM. COM and DCOM have clearly trounced CORBA as a distributed object technology for Windows software. Writing COM software is not simple, but it is nothing like all the hoops you have to jump through for CORBA, and COM has the distinct advantage that Microsoft creates highly productive application frameworks for COM, and Microsoft's software development tools are ideal for writing this kind of software. And this situation continues to improve. COM+ is better, more powerful, and in many ways simpler. But do you need COM?
If you are writing Windows applications, yes you should use COM. And if you don't use it, you'll suffer. Your applications won't share information and capabilities with other Windows applications. You'll be an outsider wearing a loud tie and a bad suit in a very conformist club. But do you need COM to make distributed applications? That depends on who you are. Who endorsed COM+ immediately? PeopleSoft, Baan, and SAP. These are exactly the companies out there replacing the mainframe-based enterprise fisc with modern distributed systems running on NT. Good for them, and good for their customers. Good for all of us now liberated from ever having to consider buying a mainframe no matter how big our business grows. But what does it mean to the company writing an Internet-based personal financial management package? What does it mean to the company writing multi-player simulation games? What does it mean to anyone with fewer than 100 software engineers not writing a product which their customers will spend millions of dollars buying and installing -- that's millions each, not in aggregate?
Let's say you were designing a unified messaging system today. How are things different from the time of the Windows 95 announcement? How are things different After the Internet?
Before Internet: The customer would install your product from a CD disk, first at the server, then at the clients. A more-advanced system might make use of software management features of SMS.
After Internet: The customer installs the product on the server. Client installations are made by accessing Web pages on the server that contain a client software download, interactive instructions for installation, and a tutorial on using the product.
Before Internet: The best way to make a distributed system ready for big companies is to make it operate across multiple protocols -- IPX/SPX, NetBEUI, and TCP/IP. This can be accomplished by using RPCs or distributed COM objects. Both these technologies make it possible to write multi-protocol distributed software while containing the nasty details of networking in one place.
After Internet: Use TCP/IP only. Even if you are using DCOM or RPCs, you can assume the network is an IP network. Remember, we're talking about a new-generation unified messaging system here, which means the network will be chock full of H.323 clients and Internet telephony gateways, which means IP. Yes, you really can assume IP on everything, especially in telephony applications.
Before Internet: Document-level compatibility meant Microsoft Word. Or, if you wanted to play in the multi-application document integration world, you had to implement OLE linking and embedding. Compound document architectures like OLE assume that there will never be a single document format, so they must enable disparately formatted document objects, and the code that edits those objects, to be embedded in foreign documents.
After Internet: Just like there is one protocol, IP, there is one document format: HTML. HTML together with XML mean your documents and data can be read and modified anywhere. The result will crack the hegemony of Word in document editing and viewing.
Before Internet: Your messaging system should be a MAPI service, either directly connected to your messaging server, or integrated with Exchange Server.
After Internet: Your messaging system should still be a MAPI service, either directly connected to your messaging server, or integrated with Exchange Server. This is because Exchange Server will be Microsoft's Internet messaging solution, and will be very successful. But you should also include IMAP support in your server so Internet mail clients without MAPI support can access your server and present a unified messaging environment to users. And you should have a Web access option as well, where clients can access messages using only a browser. Did your job just get three times bigger implementing this part of unified messaging? Yes.
Before Internet: You had your choice of proprietary management systems -- SMS, Solstice, etc. -- with their own integration interfaces, plus some open systems that use SNMP.
After Internet: SNMP. None to their credit, Sun seems to be trying to foist Solstice's interface on Java, instead of providing the best possible open, SNMP-oriented management tools.
What can Microsoft do to continue to dominate the scene? One answer is "Nothing." Not everyone needs a distributed object and compound document architecture, and less so with Internet standards widely adopted. The other answer is that Microsoft could do a better job of marketing their distributed object technology: First it was OLE, then ActiveX (which gave us the ActiveBuzzword nomenclature), and now DNA, which sounds like a throwback to some DEC announcementware related to networks of VAXes.
One thing Microsoft can do -- and is doing -- is a good job adopting Internet standards. Microsoft is doing is a good job making Exchange Server a good Internet mail server, and Microsoft's Outlook Express is a good Internet mail client (though they did screw up their upgrade path by omitting MAPI support in Outlook Express). And not least, networks of Windows PC and NT servers support TCP/IP very well. To say that Microsoft is doing well adopting Internet standards may sound odd in the face of the tiff over Java, but Microsoft's general advantage in the industry is that they execute better than their would-be competitors.
Execute better than your competitors. Microsoft, which has often enough been wrong about the first release of a product, doggedly pursues top-notch execution. And they do it even if it did not work out right the first time, instead, as is often the case in the industry, a weak start dooms a product to insufficient follow-on investment. What the Internet has done is open the door to new opportunities, new companies. But Microsoft's formula for success still holds true: execute well, and then, when you are done with the first release do not -- do not even consider -- allowing the product to become stale before you aggressively upgrade it in anticipation of, not in reaction to, feedback about improvement.
Copyright 1997 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.
.
Comments
Post a Comment