04.11.02
Posted in .NET, Application Development at 7:42 pm by Tony Baer
Nothing lasts forever, something most of us have learned the hard way in the technology world. At Microsoft’s Tech Ed conference this week, we found the software giant switching gears a bit. As it demonstrated examples of web services, under its breath, it was reassuring the assembled audience of developers that, no, .NET is not only about web services. With .NET, you can still develop the familiar Windows and web applications — far more effectively.
As if the message wasn’t strong enough, Microsoft also announced that it would continue to support VB6 (the now “former” version) in various forms for the next 6 years.
Microsoft is taking real risks with .NET. Maybe not with C++ developers, who were already developing the type of object-oriented “managed code” that .NET requires, but with the mass of VB developers who, according to Microsoft’s own numbers, comprise 3.2 of the world’s 6 million developers. That’s a huge installed base to migrate. Although similar to the transition from 16- to 32-bit programming that occurred to VB4 over five years ago, on this go-round, the affected base is much larger.
While VB6 customers won’t be cut off Friday at midnight, the tea leaves are clear. Organizations that haven’t progressed beyond .NET pilots within the next 12 – 18 months risk being saddled with orphan technology. More importantly, when the labor market tightens up again, they will also face difficulties in attracting the best people.
While we’re on the subject of reading tea leaves, we’re wondering whether Microsoft has yet sorted out the game plan for Kodiak, the code name for the next release of Exchange. We see it as a game of numbers — there are far more developers for Visual Studio languages than there are for Exchange. At Tech Ed, Microsoft announced it was opening up Exchange to web services — but that’s just an interim move. Collaboration — the stuff that Exchange does — is complex, but not too complex to benefit from the .NET Framework. We think Kodiak/Exchange should become another .NET application that is developed with the same .NET languages. If Microsoft was willing to risk it all to change VB, why shouldn’t it do the same with Exchange?
Permalink
04.05.02
Posted in .NET, Application Development, Java, Middleware at 7:35 pm by Tony Baer
The Java market is in the third — but not the final — stage of consolidation. More importantly, we also see signs that the focus of Java competition itself is shifting. Phase I, appserver competition, ended about 18 months ago. In the following phase, appserver folks began morphing into (choose one) integration, messaging, portal, or commerce providers. The notion? Corporations didn’t necessarily need appservers, but they were hurting for integration or commerce solutions.
Phase II likely appears stillborn, however, because appserver vendors didn’t always have the best commerce or enterprise integration tools. Instead, we see a third phase dominated by frameworks.
The first shot turning this into a battle was IBM’s formation of the Eclipse open source initiative. Sure, it might have been more expedient just to join NetBeans, the original Java framework open source effort sponsored by Sun/Forte, but IBM decided that frameworks were becoming strategic. Remember, IBM’s WebSphere appserver rose to prominence, not because of its J2EE support (until recently, it trailed folks like BEA), but because it was a natural buy for existing IBM shops. It needed a bold move to win the hearts and minds of Java developers. So why not give them a killer development tool, using the open source community to make it even better and draw third party support in the process?
Since then, BEA and Oracle have ratcheted up their own frameworks initiatives. But what’s really focused minds is Microsoft’s recent Visual Studio .NET rollout. Thanks to a common IDE, a standard deployment framework, and standard APIs for third-party plug-ins, it provides the single target for developers and niche tool providers missing from the Java market.
While the Java server platform has been pretty effectively standardized, the development side has not. The Java community is resolving one part of the problem, standardizing deployment from IDEs to appservers. But now comes the harder part, figuring out how to simplify the way that third party vendors bolt onto existing frameworks. That’s incredibly difficult, for reasons that we don’t have the space to explain. But if Oracle has its way, framework APIs could become one of the next areas for Java to standardize. Given the competition posed by VS.NET, that discussion won’t come a moment too soon.
Permalink