Close Close
Popular Financial Topics Discover relevant content from across the suite of ALM legal publications From the Industry More content from ThinkAdvisor and select sponsors Investment Advisor Issue Gallery Read digital editions of Investment Advisor Magazine Tax Facts Get clear, current, and reliable answers to pressing tax questions
Luminaries Awards

Technology > Marketing Technology

.NET vs. J2EE: The New Infrastructure Battle Is On

Your article was successfully shared with the contacts you provided.

.NET vs. J2EE: The New Infrastructure Battle Is On


As insurance companies continue business as usual with their tried-and-true revenue generators (or legacy systems as new technology vendors like to refer to them), the insurers also know that in the not too distant future, these aging systems that have served them well will reach their end of life.

Every possible means and method has been used to squeeze a bit more life from these systems–from extensions to Web front-ends. But despite the valiant efforts of the IT group, these old warhorses have just about reached their limits.

Todays business requirements for straight through processing, speed-to-market and the ability to fully leverage the Internet for anywhere, anytime computing have presented a hurdle that these trusty revenue generators just cant overcome.

Many insurers have prolonged the inevitable need to adopt a new infrastructure due to the associated pain and cost. However, the time has come to make a choice–not a choice of new or old technology, but a choice of which new technology: .NET or J2EE.

Not long ago J2EE and .NET were given the moniker of emerging technologies, but they have quickly been adopted into the mainstream with a battle under way to determine whether IBM or Microsoft will claim market dominance. But while the battle for leadership ensues, an insurance company cant afford to stand on the sidelines and wait to see who wins.

The fact is that technical folks at every insurance company have either already picked their J2EE or .NET dance partner or are aggressively evaluating which is the best path for their organizations. Software and systems infrastructure vendors have, for the most part, already committed themselves to J2EE or .NET, with vendors like BEA, Oracle and IBM seemingly opting for the J2EE camp.

While these and other vendors will continue fierce competition for a piece of the J2EE pie, the real industry battle between .NET and J2EE has become synonymous with Microsoft and IBM.

While the tech folks continue to evaluate the technical merits and drawbacks of each approach, it might also be beneficial to take a practical view of the business implications of one alternative over the other.

Just as the proliferation of the Internet introduced an abundance of technology terms (typically with ambiguous and plentiful definitions) so have the .NET and J2EE models brought to the forefront a whole new language, only serving to further confuse the business layman.

J2EE is the acronym for Sun Microsystems Java 2 Platform-Enterprise Edition. With J2EE, Sun has established the standards for large, multi-tier server applications written in the Java programming language. In business terms, it is a roadmap or a “how to” to build distributed software applications using Java.

.NET is a set of Microsofts software technologies for connecting software applications via the Internet. In simplistic terms, .NET is a suite of software products and models to build software programs on a common platform.

What J2EE and .NET both provide, which is not found with the older technology infrastructure, is “inter-operability.” This is the ability for applications from multiple vendors distributed across multiple systems and locations to easily communicate and share data.

The interoperability characteristic is required in order to effectively:

utilize the Web as an information exchange and access medium externally between customers, agents, brokers (and internally with field offices and remote employees);

implement straight through processing in support of streamlined core insurance processes;

provide 24/7 (anywhere, anytime) customer and distribution channel services; and

enable self-service capabilities.

Despite efforts to do so, legacy systems cannot be retrofitted or reconfigured well enough or quickly enough, if at all, to meet the interoperability need.

Lets get past all the vendor pontification and take a look at the basic differences between a .NET application and a J2EE application. From the perspective of functionality, access and other business attributes, the applications could very well be identical. The primary differences are found in the flexibility of the underlying platform and development languages.

A J2EE application must be written in Java, a platform independent development language. For example, a Workers Comp file auditor could have the exact same rating engine running on his or her laptop as the one running on the home offices mainframe, even though the underlying technologies and operating systems are different.

On the other hand, with .NET, a variety of languages could be used to develop the application, but the platform is a choice of Microsoft or Microsoft.

Quite simply, J2EE offers platform independence with Java being the only development language, while .NET offers development language independence with Microsoft being the only platform.

Java has become a mainstream language with a plentiful and readily available pool of qualified resources. Over the life of an applications growth, technical innovations and costs, J2EE offers the maximum flexibility to choose the most appropriate platform.

But with .NET, an insurer can develop or maintain programs in a variety of languages that can accommodate preferences or in-house expertise.

The scalability and enterprise-class capabilities of .NET and J2EE will continue to be argued until real-world application decides if one is better than the other. So, for the sake of this article, well let the experts and opposing vendors continue that particular debate.

The nature of the insurance industry, with it predisposition to “siloed” and disparate systems, presents another interesting complexity. The quest for one system of record will continue to be elusive for both J2EE and .NET. Although they are being developed, a greater number of insurance applications–addressing all functional insurance areas using the J2EE standard–will need to be available in the market.

While Microsoft applications are plentiful, adoption of the .NET standard will also take time and an effort to implement a sole database, eliminating redundant data in the various .NET applications.

In reality, whether carriers choose .NET or J2EE, very few insurance companies will achieve the nirvana of a “sole system” anytime soon.

Everyone wants to be with a winner and rightfully so. Being in the mainstream technologically provides greater software choices for the insurer and greater access to labor and resources. Neither .NET or J2EE will likely become the BetaMax of Web Services. However, early returns from the real world seem to be showing a trend. Those companies who intend to replace an entire “big iron” legacy environment are choosing J2EE, and those that have legacy environments consisting of many Microsoft applications are choosing .NET.

Each organization will have to determine which discipline will provide it with the broadest technology stance for whatever the future may bring. If an insurance company is waiting for a winner in the J2EE vs. .NET race to be determined, it may fall behind in the race for sustained competitive advantage and market share.

is director, Insurance Solutions, with WorldGroup Consulting Inc., based in the San Fransisco Bay area. He can be reached at [email protected].

Reproduced from National Underwriter Life & Health/Financial Services Edition, November 25, 2002. Copyright 2002 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.


© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.