Application Platform Selection

Integration & Development Strategies
Application Delivery Strategies

The delivery of Microsoft's Visual Studio .Net IDE (integrated development environment) marked the beginning of the next battle phase for platform supremacy. Organizations must determine a directed approach toward platform selection and not get caught in a mire of ad hoc use.

META Trend: Global 2000 organizations will have heterogeneous application environments indefinitely, but .Net share will increase to 30% of enterprise development projects as J2EE use stabilizes at 40% by 2004.

Broad support for Web services and early efforts to ensure interoperability across Web service implementations (i.e., http://www.ws-i.org) enables organizations to use a mixed development platform of both Java 2 Enterprise Edition (J2EE) and Microsoft .Net. However, it is important to use these technologies in an organized fashion to maximize reuse, developer efficiency, and performance. Our research finds that most organizations will have fairly even spending between these two platforms by 2004. This represents a shift from previous strategies, which have focused on moving exclusively to J2EE (see SIS Delta 876). We believe this is being driven by the productivity of Microsoft's development environments, quality of the overall frameworks, and the continuing need to integrate efficiently with client devices. As this growth occurs for Microsoft, Java vendors will battle to create compelling offerings and those that lead with strong Web service and integration support (e.g., IBM, BEA, Sun) will survive.

During 2002, most organizations with existing Visual Basic 6 (VB 6) and Active Server Page (ASP) applications will begin pilots to assess the advantages and costs of moving to .Net. Although several early adopters have begun deploying applications, we do not expect widespread deployment until 4Q02. In addition, many organizations (challenged by the move to J2EE from VB 6 and other client/server tools) will face developer pressure to move back to the Microsoft platform. Continuing corporate focus on productivity and ROI will strengthen Microsoft's case of low-cost and high-productivity through 2003, and result in a growing number of .Net deployments (see ADS Delta 1116). Each of the large platform vendors, working from current areas of market strength (e.g., BEA, Microsoft, IBM, SAP, Oracle, Sun), will seek to tell the most compelling story by building the most complete and integrated offering (see ADS Delta 1064). The battle for n-tier platform share will drive continued integration of services (e.g., integration, portals, transactions) with application server/operating system supported by integrated development suites (e.g., Sun's SunONE and IBM's WebSphere suites) during 2003-05.

As enterprises evaluate these competing platforms they should first closely evaluate each platform's strengths and weaknesses in an organizational context (see ADS Deltas 913 and 927). This means realistically measuring the need for specific feature/functionality, existing skills and culture, and the role of custom applications. The larger an organization is, the more likely it will require support for both technologies. In addition, we see most application projects now focusing on integration and repurposing of existing systems, and not creating massive amounts of new business logic components. This approach will continue as enterprises continue to increase dependence on packaged software solutions; therefore, integration should be a key element of any product evaluation (see ADS Delta 1030).

The Case for Java. The J2EE platform has achieved broad acceptance as a core platform in most large enterprises. The ability to use J2EE across various hardware and operating systems is a key advantage of the platform. However, it has been challenged in productivity and cost. Productivity has been affected by the increased complexity of n-tier applications, immaturity of frameworks, and a greater need to understand more complex object-oriented (OO) concepts. A number of vendors are currently working to provide frameworks and tools to boost the productivity of Java (see ADS Delta 1119) and several viable options are appearing to reduce the cost of tools and the runtime platform (e.g., the free Eclipse and NetBeans IDEs, free application servers from JBoss and Hewlett-Packard). Yet the cost of tools and application servers is minimal compared to the cost of developers - and it is developer productivity that is a key platform criterion.

A key Java factor has also been vendor choice, with several application server implementations, tools, and components. Still, although there are many J2EE implementations to choose from, the market has rapidly contracted around BEA WebLogic and IBM WebSphere. Other technically viable alternatives exist (e.g., Sun, Borland, Oracle, HP), but none has yet mounted a serious challenge to the incumbent leaders. This choice is also driven by the Java Community Process, which creates an open forum to explore and define new platform capabilities. However, while the community effort enables a forum for new ideas, it also presents a challenge to the pace at which platform standards can evolve.

We expect Java's greatest appeal will be the creation of Enterprise JavaBean (EJB) components, with a growing number of deployments during 2002-04. The combination of Java's cross-platform support (i.e., the ability to run on various hardware and operating system combinations, not portability across application servers) and the fact that these components will be created by skilled developers with strong OO experience is key to this position. In addition, broad third-party support from application packages and strong offerings for integration and portals will act as drivers to use EJB components for enterprise business logic.

The Case for .Net. Because Microsoft is the soul owner of the .Net technology stack, it gains the advantage of cohesive design. This aids developer productivity and speeds the learning of the class libraries. But, Microsoft, like its Java competitors, has not fully integrated the extended service stack with its developer tools. In addition, while its core client technologies for both thick and thin clients are stronger than current Java libraries, Microsoft's portal efforts lag behind the J2EE-based portals (see WCS Delta 1055).

Microsoft's .Net includes greatly improved technology for creating thin- client applications. Its new WebForms components provide the ability to support multiple client types and ASP .Net provides enhanced scalability and performance by separating the underlying "model" code from the presentation HTML (typically called a Model-View-Controller architecture). This also makes it easier for Web designers to work with the pages without fear of breaking the application. The Java community is currently working to address this type of functionality with several working groups (i.e., JavaServer Faces, Java Standard Tag Libraries, and XMLC support).

The critical battleground for Microsoft is that of maintaining its Visual Basic developer base (see ADS Delta 1025). The standard Java rhetoric has been to announce that the change between VB 6 and VB .Net is so great, developers should move to Java. Although there are many dramatic changes, we do not believe they are unmanageable. And vendors such as BEA (with its WebLogic Workshop project) are trying to create new types of Java development environments that can deliver a more compelling experience to the VB developer.

Living Together. Web services provide a strong candidate that enables both .Net and J2EE to be used in organizations. The platforms are more common than different, and this similarity will only grow. For many, the initial split in technology use may be for application tiers, with EJBs being the back-end business logic and .Net maintaining Microsoft's traditional hold on the client interfaces with integration based on XML (e.g., SOAP, WSDL, UDDI). Other organizations may split technology use across business units according to existing skills. The key is that the use of each technology should be driven by a set of clearly defined criteria (see Figure 1) to maximize technology value in the situation and leverage the development team's skills.

Business Impact: Organizations' technology choices must reflect availability of skills, or they will risk enormous cost overruns.

Bottom Line: Most organizations will use a mixture of J2EE and .Net in their platform selection. Their decisions should be made based on business-driven criteria, with Web services used to integrate between platforms.

Figure 1 -- Evaluation Criteria in Applying Java and .NET Technologies
Organizations should consider the following factors in deciding how to apply Java and .NET Technologies:
 • Developer Skills: The key factor in cost of development is the productivity of developers.
 • Integration needs: Web services are becoming a key element, but they do not currently replace existing technology for EAI (enterprise application integration) and IEI (inter-enterprise integration). Each tier of integration must be considered: data, business logic and process, content, and partners.
 • Existing hardware infrastructure: This may cause a forcing function toward Java (e.g. existing infrastructure is Unix-based).
 • Package applications: Many enterprise packages are moving towards Java interfaces and are using Java as a customable language (e.g. SAP, PeopleSoft).
 • Presentation tier: Although most organizations are moving toward thin-client topologies, the ability to support a mix of thick and thin clients and provide integration to other desktop productivity applications continues to be important. The immaturity of presentation technologies for thin clients (e.g. portals, caching) will leave this are unsettled until 2004, as new challenges appear (e.g. CURL, Macromedia Flash MX).
 • Security: The continued move towards collaborative computing will keep security as a fundamental issue. Consideration in this area must include not only the development platform itself but also the runtime environment.
 • Availability: The ability to choose between application vendors, tool vendors, and component vendors should be evaluated

Source: Meta Group