Philip Brittan's Blog: September 2003 Archive

I recently spoke at a technology conference as a part of a panel, and one question from the audience was about which open standards were most important. My response was that there are many important open standards, but that one crucial capability that customers are looking for from open standards is the ability to make application decisions independently from infrastructure decisions.

The reason it�s valuable to be able to decouple those two decisions is that they are typically made by different groups within the enterprise and they are made for different reasons. Infrastructure decisions are made by the IT organization and are based ideally on price / performance. Application selection is typically made by line of business users, and functionality is the primary driver.

If a company cannot treat each of those layers independently then an application decision becomes simultaneously an infrastructure decision, which means that all the factors of functionality, price, and performance need to be considered together and the decision needs to be made by a combination of business people and IT folks, which complicates the process and potentially ends back up in �silo� structures that companies today are trying hard to escape.

Avalon: A new UI for Windows

Posted by pbrittan on September 29, 2003 at 01:35 PM | Permalink | Comments (13)

Avalon gives Microsoft an opportunity to demonstrate its leverage over the user experience and to shake up competitors.

There is a lot of buzz in the Microsoft community these days in advance of the first public educational events around 'Avalon', one of the many new pieces of the Longhorn version of Windows. Avalon is the new Windows API, and it apparently represents a major jump in UI capabilities. Part of its value proposition is in the ease of use to developers and part in the experience for end users.

In order to increase developer productivity, Avalon will rationalize and reduce the number of APIs in the Win32 stack from over 70,000 down to 8,000.

On the user experience side, Avalon will feature advanced support for 2D and 3D vector graphics as well as standard GUI widgets. Some descriptions of Avalon suggest that it is more comprehensive than just the graphics layer, and will incorporate support for paradigm-shifting "task-oriented" UIs.

Microsoft has already said that they will be releasing a version of Microsoft Office for Longhorn based on Avalon, which should help drive user demand for Avalon’s capabilities.

I see several immediate ramifications for this:

It is a shot across the bow of Macromedia Flash MX. Flash has traditionally been focused on adding real-time vector graphics to Web pages for decoration or on-line advertising. Microsoft played along with Macromedia, bundling Flash into IE, because it never really cared about those fluffy things. But in the last year or so, Macromedia has been actively re-positioning Flash (now called Flash MX) as an alternative for building the user interfaces for enterprise applications -- smack into Microsoft’s home turf. It has been inevitable that Microsoft would respond at some point (there were early rumors that Microsoft might even try to buy Macromedia), and now it seems to be doing that with Avalon. Even though Longhorn isn’t due out until 2005, the mere fact that Microsoft will be baking into Windows the same kind of real-time 2D and 3D vector graphics capabilities that Flash promises, nicely integrated into same API layers as standard GUI widgets, could create enough FUD to slow down companies considering Flash MX. The fact that Flash is a client-side UI execution engine, just like Microsoft technology, means that it doesn’t have a strong differentiation over a Microsoft offering. Strategically, Microsoft can potentially always turn off its bundling deals with Macromedia, leaving them high and dry.
Introducing a major change in the UI API means giving Java a good shake. It is likely that it will take client-side Java long time to support the new capabilities of Avalon. If Microsoft can get its users addicted to the new paradigm (by using it in Office, which they plan), then they make Java look even more out-dated on the client side.
As I have argued elsewhere, Microsoft doesn't really like the idea of browser-delivered apps because it weakens the Microsoft desktop. Just as with Java, if Avalon gives users an amazing experience which is just not available through the browser, then browser-based apps don't seem like such a good idea to users. Alternatively, the browser might support these capabilities, but only through IE when powered by IIS on a Windows server.
Longhorn requires hefty hardware support, so Microsoft will undoubtedly time release to coincide with a price/performance level for new PCs that will allow them to encourage a massive hardware churn. That means that the Longhorn release will likely be coordinated with hardware partners like Intel and Dell.
The depth dimension of the desktop is catching on. Sun’s Project Looking glass uses depth by letting users angle windows away from them, thus using less of the 2D space of the desktop while still giving users an oblique view of what’s in the window. Microsoft’s new desktop, Aero, which relies heavily on the capabilities of Avalon, also makes more use of the 3rd desktop dimension by supporting transparent windows (so you can see the whole stack underneath at once), and also supporting real-time window rotation.

Of course, a rich thin client technology could take advantage of all the advanced features of Avalon and still let the business logic be powered by Java.

Microsoft and Web Services

Posted by pbrittan on September 22, 2003 at 10:06 AM | Permalink | Comments (2)

Web Services are a way for Microsoft to leverage the existing base of J2EE without having to do anything to support Java explicitly.

In his article, "Why Microsoft needs IBM this time around", Mike Ricciuti argues that "Microsoft needs IBM to legitimize .Net and its entire development plan as a truly cross-platform strategy." While I think that both IBM and Microsoft sincerely want to make a case for the power of Web Services and to demonstrate that it is a cross-vendor effort, I think that neither does Microsoft needs IBM to help drive sales of .NET nor does IBM have any interest in legitimizing .NET.

Web Services and .NET are two very distinct things. Web Services is an open standard for programs to exchange data over a network. .NET is Microsoft's proprietary application development and deployment framework that happens to use Web Services as part of its approach. IBM can support the former without supporting the latter.

Web Services are in fact starting to take off. A number of customers that I work with have started to adopt Web Services as both an internal IT transport layer and even also as a way to make content available to business partners (in very contained ways so far). The fact that Web Services have not yet completely transformed the world by seamlessly interconnecting all supply chains and other business partner relationships is simply a result of:

the fact that it take a long time to adopt any new technology, and Web Services is still very young in the grand scheme of things.

there are still a lot of issues with Web Services that need to be worked out to make them practicable in the large. Specifically, Web Services need more management, orchestration, transactional efficiency, and security support. These are exactly the areas in which IBM and Microsoft made a commitment last week.

.NET is also being adopted, even without companies necessarily buying into the grand plan for Web Services. So far .NET’s success has primarily been a tools success -- Visual Studio developers are upgrading to Visual Studio .NET. However, I have come across several large Java-oriented enterprises that are now planning on building .NET Smart Clients to their J2EE back-ends because they feel that Java has not given them a viable alternative on the front end.

I suspect that Microsoft's peculiar interest in Web Services is a way to leverage the existing base of J2EE installations in the market without having to do anything specific to support J2EE (which would be anathema to MS). I have argued in an earlier entry that Microsoft plans to use its domination of the desktop to push the client side of .NET and then to use the domination of client-side .NET to push server-side .NET. The challenge that Microsoft faces is that many large corporations currently have big investments in J2EE -- if Microsoft forced them to turn their backs on those investments in order to adopt .NET, then client-side .NET would face a lot of extra friction in its adoption. Microsoft can erase that friction with Web Services and then tackle the server-side (i.e. head-to-head competition with J2EE) as Phase 2 of its strategy.

Building software that matters

Posted by pbrittan on September 17, 2003 at 01:42 PM | Permalink | Comments (6)

Industry gurus claiming that technology no longer matters to Corporate America may be drawing the wrong conclusion from the wrong evidence.

Just wanted to let everyone know that I wrote an article titled Building software that matters that was published on ZDNet today.

Pre-Integrated Airplanes

Posted by pbrittan on September 10, 2003 at 11:01 AM | Permalink | Comments (4)

If the IT industry wants to be more like other, mature manufacturing industries, then large vendors need to be willing and able to integrate and resell software components as easily as they do hardware parts.

We�re exhibiting at Oracle World in San Francisco this week. Yesterday, I watched Scott McNealy give a keynote address. It was as entertaining as always.

One of the points he made, which I have heard him make before, is that corporate America treats its data center is as if travel depended on our own personal airplanes that we each built from scratch. Scott argues that every data center is unique and custom built, despite the fact that the needs companies have from their data centers are fairly universal. For air travel, of course, no one builds their own airplanes from scratch. There are manufacturers, like Boeing and Airbus, who do that. And there are even airlines that own the airplanes and just rent us a seat when we need them.

This idea -- that the computing industry needs to become more like other, mature industries in which each customer is not expected to roll their own -- is very powerful. But for that to happen, the large vendors who set themselves up as the manufacturers and airlines need to have a more fluid relationship with component software vendors than now exists.

When Sun builds server hardware, they buy sheet metal, bolts, wires, electronic components, disk drives, power supplies, etc., from a host of suppliers, just as airplane manufacturers do. Sun assembles all these components into the boxes they sell. Sun is an OEM reseller of all those bolts and wires. This is a very well understood and practiced model on the hardware side. If Sun had to manufacture its own wires and bolts in order to build a server, our industry would be held back terribly.

But a server, especially one that is meant to be a complete solution for a customer (like a finished airplane) is far more than the hardware. It is at least as much about the software that is installed on the server.

At this point, many of the large IT vendors, like Sun, profess an explicit hesitation to bundle and resell third party software. So, a major vendor either has to supply all the software on the server, which is akin to manufacturing its own bolts and wires and power supplies, or it cannot offer a complete solution, i.e. the customer still has to bolt on some additional components in order to make the airplane flight-worthy.

If Scott�s vision for IT is to become reality, and it does seem right, then large vendors need to be willing and able to integrate and resell software components in their systems as easily as they do hardware parts.

.NET on Linux, part 2 - "It's the API, stupid"

Posted by pbrittan on September 04, 2003 at 07:56 AM | Permalink | Comments (6)

Speculation on a strategy for Microsoft to co-opt Linux

Pardon the title. I'm not actually calling anyone stupid. Just couldn't resist co-opting President Clinton's '92 campaign theme.

While writing my previous blog entry on .NET on Linux, I started thinking about what makes up an operating system. Certainly there is the kernel, there are system services, and there is the developer API. If one company is going to control the flow of money related to an OS, it may not need to control the whole OS. And if it set out to control just one part of the OS, the developer APIs would be that part. Controlling the developer API means controlling how software is built on that platform. It means being in the best position to provide tools for that API. It means being the one to arbitrate interoperability.

I believe that Microsoft has a shot, if they so choose, at making .NET a cross-platform developer API that would give them almost as much money-making ability and control over open-source OSes, such as Linux and FreeBSD, as they have over Windows itself.

A good description of the value of controlling the developer API is found in Jerry Kaplan’s book, Startup:

Creating an API is like trying to start a city on a tract of land that you own. First you try to persuade applications programmers to come and build their businesses on it. This attracts users, who want to live there because of all the wonderful services and shops the programmers have built. This in turn causes more programmers to want to rent space for their businesses, to be near the customers. When this process gathers momentum, it's impossible to stop.

Once your city is established, owning the API is like being the king of the city. The king gets to make the rules: collecting tolls for entering the city, setting the taxes that the programmers and users have to pay, and taking first dibs on any prime locations (by keeping some APIs confidential for personal use).

This is the great secret of the computer industry. While the newspapers chronicle the daily skirmishes of computer companies and their products, the real wars are over control of APIs, a subject too arcane to attract the attention of the press. But once an API is established, the owner has a natural monopoly of unprecedented proportions. API wars are brutal, winner-take-all conflicts in which the losers become mere shadows, eking out a marginal existence in specialty markets.

Sun and Microsoft realized this long ago. At a strategic level, Java was an attempt to by Sun to wrestle the developer API away from Microsoft by providing a cross-platform abstraction for developers to code to rather than coding to the native APIs. And it might have succeeded. Sun was able to drum up enough industry support -- and enough players were wary enough of Microsoft’s growing hegemony -- that many vendors jumped on the Java bandwagon. Several capable companies tried to create pure Java suites to compete with Microsoft Office, for instance. Sun also ingeniously targeted the green-field "platform" of the browser as a way to differentiate Java from the cross-platform GUI toolkits of the past. Microsoft was forced by the industry to support Java, at least for a while. If Sun’s plan had worked, all the software we use today might be written in Java and Microsoft might be scrambling to catch up.

But it didn't work. Every pure Java office project, for instance, failed. Developers on those projects have told me that it was Java’s lack of focus on usability and performance that killed them. Those types of apps have to be pixel-perfect and Java was not pixel perfect. So Microsoft retained app supremacy and also retained control of the developer APIs on Windows, which has become essentially the only business desktop platform that matters at this point. Microsoft also performed an "embrace, extend, extinguish" on Java, almost immediately adding proprietary features to their version of the JVM, the result of which has been lawsuits, C#, and banishment of the JVM from Windows XP.

However, Java did go on to find big success on the server, where cross-platform does still matter (because there are still several vendors selling servers; if Microsoft sews up the server market too, then cross-platform won’t seem important on the back-end either). Plus, on the server, Java’s usability issues are far less of a problem.

To reconnect with my original point, I fear that Microsoft is maneuvering into a position to turn the tables on Java and provide what Java set out to provide in the first place: an abstraction layer that will allow developers to write to build high usability apps for many platforms at once. And it has a much stronger starting foundation: firm control of the most prevalent desktop platform, a reputation for getting things "pixel-perfect", and the world’s most popular desktop software, Office.

If Microsoft chooses to go down this route, it can jump-start the process and start making money from Linux and other OSS platforms by making its vast catalog of applications available for purchase on those platforms. Those apps will pull the .NET framework onto desktops that don’t already have it.

A world in which every computer is running Windows is probably impossible, because users get to choose, and there are users who don’t want Windows, for one reason or another. But only developers choose the API and write software to it. Users don’t necessarily even know about the API. If Microsoft successfully attracts large numbers of non-Windows developers to .NET as a way to develop Windows-style apps across all platforms, then they don’t have to wait for users to adopt Windows. The essential parts will be baked into everything they could possibly buy.

Of course Microsoft has to want to do this, which is not a given right now (although they are already testing the waters with the Mac and FreeBSD), and the success of this strategy will depend on how strongly Microsoft can establish .NET as the client side technology standard.

"I wonder when the Java developers will be as happy as the Mickeys"

Posted by pbrittan on September 03, 2003 at 06:03 AM | Permalink | Comments (11)

What do you think about when you write Java?

I recently came across this blog entry, Java vs. .Net developers, in which the blogger, Steve Noel says:

"Mickeys [developers who use Microsoft technology] in general are very happy with the latest new tools thrown at them from Redmond, and very generalized also look slightly happier. Java developers on the other hand have a slightly more weary smile, and especially the open source-addicted ones like to make a lot of fuzz about Sun not doing justice to the great platform that Java is.

Technically, the differences in both software platforms are getting smaller every day. I wonder when the Java developers will be as happy as the Mickeys."

As someone who has used both Microsoft technology and Java extensively, this comment struck some kind of nerve with me. As you may have seen from my blog polemic, Java vs. .NET, I am these days rather overly preoccupied with the relative advantages of the platforms and with the plate tectonics our industry is facing because of the struggle between them.

I was talking about the quote above with a guru-class developer friend of mine whom I respect totally and who has extremely deep experience with Microsoft technologies and Java. His immediate reaction, and explanation, was that when he uses Java, he finds himself thinking mostly about the technology itself. And when he uses Microsoft tools, he finds himself thinking mostly about the problem he is trying to solve. Somehow, he believes, Java distracts the developer with a sense of itself and its character, whereas Microsoft technology seems to blend into the environment, almost disappearing, and thus allowing the developer to concentrate more fully on the task at hand.

If this is true, this is a very powerful statement for Microsoft tools. Microsoft hopes to drive developer adoption of .NET by offering a superlative set of tools to make it extremely easy to create Web Services and user applications. Microsoft also offers a rich set of tools to migrate existing Java code to the .NET framework, a perfect �out� for Java developers who become enchanted with .NET. If Java cannot match this, it has yet another hurdle in its fight with .NET.

I have to give Java its due credit. When I used to code in C++, I had to think about memory management all the time. Now, thanks to Java, I don�t think about it any more. What a relief! Java has taken care of that issue for me, so that I can concentrate on my task at hand. Java needs to do much more of this type of complexity-hiding. I presume that this is the goal of Sun�s Project Rave.

.NET on Linux

Posted by pbrittan on September 02, 2003 at 07:34 AM | Permalink | Comments (3)

Could Microsoft co-opt Linux?

I have read a number of articles and blog entries speculating about whether or not .NET will catch hold on Linux and on what it would mean if it did. Much of the speculation centers around whether Microsoft will put out its own version of .NET for Linux, but there is also a lot of discussion of Mono, Ximian�s version of .NET on Linux, which has been released without Microsoft�s participation and is gaining some traction.

Some of the commentators are concerned about the power that .NET on Linux will give to Microsoft, many others think that it would be a victory over Microsoft. To explore this, I�ve been considering the following �thought experiment�. Imagine this timeline:

Microsoft releases .NET framework for client and server.
Microsoft gets excellent traction with .NET on the client-side (which I firmly believe they will, unless they are more seriously challenged there, as I outline in my Java vs. .NET blog series)
Microsoft strongly encourages the adoption of Windows Servers by marketing the synergies between the client and server pieces of .NET, and makes some headway there
IBM, Sun, Oracle, and other Java vendors push hard to drive Linux adoption in the marketplace, at which they also make good headway. .NET starts to get some adoption on Linux thanks to Ximian Mono.
Then, suddenly, in the face of "customer demand", Microsoft "capitulates" and releases a version of the .NET server framework for Linux. It is not free but inexpensive, and perhaps nets them an amount of money approaching a basic OEM Windows Server license.
Microsoft then drives adoption the .NET server framework on Linux using the strong synergy with the large and growing base of .NET client applications, taking share away from Java app servers. Mono is crushed by Microsoft in the process.
Microsoft releases the .NET client framework for Linux and a version of Microsoft Office that runs on it.
Microsoft ends up owning the developer APIs for Linux, client and server, which is perhaps more important than owning the operating system itself.
Since no company owns the Linux kernel or the lower-level Linux APIs on which this .NET for Linux will be built, there is no one to thwart Microsoft�s efforts to control how software is developed on Linux. If Microsoft succeeds in taking control of the developer APIs for Linux, it makes money from Linux�s popularity, and once again there is no one to challenge Microsoft desktops.

Interestingly, Microsoft is already offering a portion of .NET for Mac OS X and FreeBSD. These might well be experiments to test the waters or perhaps simply ways to keep the DOJ calm. What if Microsoft helps BSD compete more effectively against Linux?

Powered by
Movable Type 3.01D

java.net RSS Feeds