FAQ: Microsoft's .NET or Sun's Java?
Y. Natis
What does Gartner think about Microsoft's .Net vs. Sun's Java? To what degree should we develop and balance our skill bases in these two technologies? Here we explain the Gartner position.
--------------------------------------------------------------------------------
Core Topic
Enterprise Application Servers and Component Models ~ Software Infrastructure
Key Issue
Which component models, application servers and vendors will emerge as the new standards for mainstream enterprise computing?
Strategic Planning Assumptions
Through 2005, both Microsoft and Java enterprise platforms will remain viable and widely used, and no one architecture alternative will establish a significant (greater than 5 percent of the market share) presence as a platform for new business applications (0.8 probability).
By 2002, more enterprises will build their differentiation on the ability to integrate purchased, partnered and legacy applications than on their ability to engineer custom in-house-built applications (0.8 probability).
The productivity gap between a typical Microsoft and a typical Java project will continue to favor Microsoft through 2003, while the enterprise maturity gap will remain in favor of Java through 2005 (0.8 probability).
--------------------------------------------------------------------------------
What does Gartner think about Microsoft's .Net vs. Sun Microsystem's Java? To what degree should we develop and balance our skill bases in these two technologies?
Gartner does not anticipate that one of the two platforms (enterprise Windows or enterprise Java) will eliminate the other in the five-year planning period. In fact, we project that both infrastructures will continue to grow and both will be important to most enterprises. We further project that no other platform will present a strong third alternative (in excess of 5 percent of the market) during the next five years (see Research Note SPA-11-9284). The preceding market-share-dominating application platforms (CICS, Tuxedo, CORBA) have fallen behind and will remain legacy platforms, subject to minimal new project starts and a steady, if slow, decline in the installed base. With regard to Windows and Java platforms, the Gartner-recommended best strategy had been (and remains) to anticipate that both will be viable and important to enterprises rather than to make an exclusive commitment to one. Moreover, we believe that the competitive differentiation, business viability and vitality of enterprises increasingly depends more on an enterprise's ability to integrate applications than on its ability to best exploit either of the two environments or make the "correct choice" between the two. In fact, in 1999 we projected that by 2002 more enterprises will build their differentiation on the ability to integrate purchased, partnered and legacy applications than on their ability to engineer custom in-house-built applications (0.8 probability; see Figure 1).
Figure 1
The Shifting Focus: From Development to Integration
Source: Gartner Research
Beyond the five-year planning period, a new architecture is likely to emerge. A major new technology trigger that may have a long-term architectural (and business) impact is associated with wireless networks and unique per-consumer, always-on wireless devices. Leaders in the cellular infrastructure have not yet emerged, and the market is full of anticipation and innovation. A new architecture, a new strong vendor and a new standard may indeed emerge here. While the cellular infrastructure will expand the boundaries of IT, it will not eliminate the now-traditional Internet infrastructure. Rather, the cellular and HTTP/SMTP networks will form a new infrastructure: the "Supranet" (see Research Note COM-11-4753). In the next three to five years the wireless field will see a great deal of innovation. These innovations will find their way into Java and Windows platforms, but they may also give birth to the next generation of infrastructure, the Supranet infrastructure. Just as enterprise Java and .NET (the Internet infrastructures) have now replaced CORBA and DCOM (the intranet infrastructures), the next generation of infrastructure will reflect the unique nature of the Supranet (see Figure 2).
Figure 2
The Architecture Train
Source: Gartner Research
The fact that both platforms will be important and used by enterprises does not mean that the platform for individual projects should be selected randomly. The platforms are not equal, and their different strengths do not make them equally appropriate for all projects. It is, of course, preferable to reduce the degree of heterogeneity in an enterprise. If either platform is acceptable for the given project, the project should select the one in which it has greater expertise or the one that had been selected by the enterprise as the primary platform of the two. In other words, it is useful to identify the primary application architecture for an enterprise. We recommend, however, that enterprises prepare for some cases in which an opposite choice will have to be made (when buying a packaged application, merging with other companies, or integrating with partners or other intermediaries). We examine the current state of the two platforms and their differentiation, keeping in mind that the conclusions are intended to be applied mostly within an individual project, not across the entire enterprise.
Microsoft is in the process of a major architectural transition (see Research Note COM-11-6016 and Research Note QA-12-1421). This is the transition from COM/COM+ to .NET. We believe that the .NET vision of Web services is in line with and, in some ways, ahead of industry and business trends. When delivered, it will move the Microsoft platform forward in flexibility and power. However, .NET is not only Web services. In fact, .NET is a catchall name for several, mostly independent new technologies from Microsoft's laboratories. Besides Web services, it includes the common language runtime (CLR), the new programming language (C#), the new object-oriented version of Visual Basic (VB.NET), several back-office products (.NET Enterprise Servers) and more. Bill Gates had compared the transition to .NET to the transition from MS-DOS to Windows. This will be a lengthy and expensive process. Meanwhile, the current Microsoft platform (COM/MTS/COM+/ASP) — to be replaced with a new architecture — has become a premature legacy environment. Thus, the Microsoft environment is in transition: the old infrastructure has reached maturity, has a large installed base and can be safely used (within its limitations), while the new architecture promises greater flexibility and power in the future. The most popular current architecture for Microsoft infrastructure is the combination of IIS/ASP and MTS/VB. Microsoft offers effective development tools and a dependable runtime environment for this architecture. The ASP/MTS applications tend to be small to moderate in terms of scale and lock developers into the mostly Microsoft tools and middleware world, but for mass-market users, the combination of Microsoft's easy-to-use tools, single-stop-shopping vendor, relatively low entry costs and good enough performance is often an unbeatable attraction. Yet, by 2003, the majority of Microsoft users are likely to be in the process of switching to a new architecture and the new .NET technology. This new technology is not yet finalized and not yet available.
Our recommendation to current Microsoft users is to continue to use the older and proven technologies of COM, MTS and MSMQ. We also recommend that new Microsoft systems be designed with the loosely coupled architecture in mind, building systems that have a reliable technology base (MTS) and yet follow a forward-looking, service-oriented architecture. Our recommendation for new enterprise prospects considering but not yet using Microsoft technology is to either begin with the current proven technology as stated previously (knowing that a substantial transition and retraining will be required in the next two to three years) or to consider delaying entry into Microsoft e-business infrastructure until at least the first elements of .NET are delivered (Visual Studio .NET by 2H01, 0.8 probability). Users engaged in smaller projects, building less-demanding applications (fewer than 100 to 150 concurrent transactions) with an expected useful lifetime of two to four years, can safely rely on ASP/COM+/MTS. The transition to .NET will not significantly affect them, and the ease of use of well-integrated Microsoft tools will be a clear and immediate benefit to the project.
J2EE does not yet reflect the vision of Web services (although users can build Web services using J2EE programs and some nonstandard vendor extensions or custom-developed middleware). The transition from the tightly coupled model of Java RMI to the loosely coupled, service-oriented architecture of Web services will require changes to J2EE somewhat similar to the changes that Microsoft is making in transition to .NET. However, for Sun and J2EE vendors, the change will be much less broad. IBM's own recently announced Web services strategy clearly positions Web services architecture as an external layer over J2EE (or over CICS, OS/400 and other existing architectures), not as a replacement for J2EE. Because some of the technology required for Web services support is already part of J2EE (JMS, Messaging Bean of EJB 2.0) and given that J2EE transition will likely not include a fundamental rework of the overall infrastructure (as the Microsoft transition from COM to CLR/.NET), we believe that, compared to the current COM+ applications, J2EE applications developed today will migrate to the next generation of the Java platform with greater ease, less cost and less disturbance to users.
Compared to Microsoft's Visual Basic environment, the object-oriented J2EE is relatively hard for a novice to learn. Despite the availability of 4GL and graphical productivity tools for Java, the lack of qualified developers is, in fact, one of the primary constraints to J2EE growth. The Java J2EE infrastructure is defined by Sun, but delivered by many vendors (i.e., BEA Systems, Oracle, IBM, iPlanet, Sybase, Iona Technologies, Brokat, Bluestone Software, Persistence Software, Borland, SilverStream Software). The implementations of different vendors differ in their technical focus, although all share the common architecture. Most J2EE platforms are newly written (typically in Java), and have not yet been proved as stable and safe platforms for enterprise computing. Most high-end enterprise systems still remain on IBM CICS/IMS or BEA Tuxedo platforms. J2EE enterprise momentum is at present aided more by the viability of the vendors than by the viability of the technology itself. The leading J2EE vendors (i.e., BEA, IBM) are also the long-standing leaders in the enterprise software market. When considering a choice of J2EE or Windows for their next large-scale enterprise projects, many users decide on J2EE because the vendors that offer it have greater credibility in enterprise computing than does Microsoft, despite the current immaturity of J2EE. This process will likely push J2EE servers up the scale and into the mainstream "safety zone" (the bigger projects push J2EE vendors to optimize their middleware to meet user requirements). For the same reason, J2EE servers are also likely to become more difficult to use, although they may be more system-tunable and more scalable. The productivity gap between typical Microsoft and Java projects will continue to favor Microsoft during the next three years, while the enterprise maturity gap will remain in favor of Java during the next five years (0.8 probability).
Typically, the Microsoft platform is selected for productivity-oriented, moderately demanding projects and the J2EE platform is selected for larger-scale systematic enterprise projects. This differentiation is likely to remain clearly pronounced through 2003. In fact, m ost enterprises end up with both architectures in different areas of their IT portfolios.
The wrong question? As illustrated in Figure 1, we believe that beyond 2001, enterprises' business differentiation will depend less on their ability to create unique custom applications (using .NET, J2EE or another architecture), and more so on the ability of the enterprise IT to integrate applications, transactions and information from various sources inside and outside the enterprise. Application integration technologies (integration suites, integration brokers, integration servers) will play as central (if not more central) a role in the evolution of enterprise computing as the choice of application server platforms. In a way, "Microsoft or Java" is not the right question. Considering that most enterprises will be exposed to both architectures during the next five years, the "right" question might be rather "how do we integrate the two platforms and, by the way, also all the other already-present enterprise platforms such as CICS and Tuxedo?" Neither Microsoft COM+ nor J2EE answer this question. There are almost no standards in the application integration field. Each vendor invents its own technology and programming models. Microsoft has begun to move in the right direction with DNA2000, introducing the concept of services and the BizTalk server. This technology (still not delivered) is now classified as part of .NET. When released, BizTalk will be v.1 of a platform that will require production deployment and several subsequent releases to mature. Microsoft also offers Host Integration Server — mostly a set of adapters to more-popular legacy platforms and packages. Microsoft's future XLANG can be considered a proposed standard for business process management — an integral part of most application integration projects. J2EE has just been extended with the new specification of Connectors APIs — an attempt to standardize legacy adapter interfaces — one of the central elements of integration projects. Sun had also said JAXM — Java APIs for XML Messaging — will be included in J2EE in the future, making a step toward support of Web services. Web services are instrumental in integration of applications across enterprises. There is, however, no agreement and no completeness in Microsoft, Java and other vendor products as far as application integration. Through the next two years, the choice of application integration architecture, programming model and vendor product will remain difficult and proprietary, yet the enterprise impact of this choice will continue to increase.
The choice of application integration architecture and technology will have a greater impact on the enterprise during the next five years than the choice between Microsoft and Java application architectures. This is because the choice of a platform tends to be more tactical (one project at a time), while the choice of integration technology tends to be more strategic (more likely to be repeated from project to project). In addition, the integration technology is less standardized and less mature, and thus the impact of a "wrong" choice is greater. While individual projects within an enterprise clearly need to select one architecture for their new development, the enterprise IT architects should focus their evaluation efforts on the bigger "city planning" issues and on the issues of application integration. In fact, the more developed the enterprise "city planning" architecture, the easier it is for any individual project to make its own platform choice and thus the less urgent becomes the original problem: the choice between Microsoft's .NET and Sun's Java/J2EE.
--------------------------------------------------------------------------------
Acronym Key
ASP Application service provider
CICS Customer Information Control System
COM Component Object Model
COM+ Next-generation MTS and COM
CORBA Common Object Request Broker Architecture
IIS Internet Information Server
MSMQ Microsoft Message Queue Server
MTS Microsoft Transaction Server
-------------------------------------------------------------------------------- |
