Section: EXPERT opinion

A mid-size multiline insurer is exploring the benefits of pursuing a distributed object platform for software development. The insurer's IT architecture is a 50-50 blend of packaged and homegrown applications, combining a multitude of platforms, including Microsoft, Unix and IBM mainframes. After reading and researching the subject, a debate has formed about standardizing application component objects on one of several existing specifications from popular vendors/organizations. Management would like to develop a solution. It has asked the IT department to determine the validity of the current object standards options. Must they standardize? What factors should go into selecting a standard? Can they develop a strategy to blend the existing options? How can they do so?

KEVIN KELLY Worldwide Insurance Industry Manager Microsoft Corp. (Redmond, WA)

JON SIEGEL Director, Domain Technology Object Management Group (Framingham, MA)

The "need" to standardize is not as much a technology decision as a business one, although the "techno-zealot" warfare that commonly ensues can hide this fact.

The "need" is driven by the fact that all financial institutions desiring the ability to develop products and services more rapidly, expose them through a wider range of competitive distribution channels and ready themselves for e-commerce are mandated to migrate their development to an n-tiered, distributed component environment.

Factors that will affect this decision will be: maturity of the component spec, flexibility and availability of integration methods, ease of implementation (development tools), availability of competent programming talent, compatibility with potentially desirable packaged apps and the potential for purchasing business components developed by others for integration into the customer's apps.

In order to work in a "blended" environment, selecting a primary development model that will embrace and/or integrate with the others in the easiest fashion is the customer's best bet. Microsoft's COM (Component Object Model) is the most mature, widely used and flexible technology for delivering on the customer's requirements. It is a freely available specification that delivers implementability and compatibility with thousands of packaged applications and the only component model with a viable component-marketplace--allowing customers to purchase pre-built, ready to use/re-use components.

Developers have choices like Windows NT Services for Unix, Windows DNA support for Oracle and DB2, COM Transaction Integrator, MSMQ Gateway, COM on Unix, Internet Explorer on Unix, COM-CORBA bridges, and initiatives such as WinDNAfs, WinDNA for Manufacturing, ActiveStore, ActiveX for Healthcare, Value Chain, MS BizTalk initiative (industry-standards-based XML schemas) and more. ACORD currently shepherds a COM (and soon XML) specification for developing insurance systems. By selecting COM, the customer will achieve three fundamental "wins": They will be able to leverage existing legacy systems through the use of integration methods listed above, migrate off legacy platforms and develop new applications and functionality in a more accessible and programmer-friendly development environment.
KEVIN KELLY Microsoft Corp.

These questions make the decision sound like a trade-off: Should we use standards and give up something, or should we use whatever works well on one or a few platforms and give up interoperability? Fortunately, the company doesn't have to make this choice. The high quality of the CORBA architecture means they can take advantage of standards and make all their diverse platforms work together smoothly. At the same time, they can design and build in the best architecture in the industry, and choose from a suite of quality competing products.

Heterogeneity is good, not bad. Suppliers build, and companies buy, diverse hardware, operating systems and software, because these products are better for their target use, or more cost-effective, or both. But the end-user companies also have to integrate these disparate platforms smoothly, and this is where standards come in. OMG Interface Definition Language (IDL) standardizes the interfaces between the software modules--clients and objects--and the Object Request Broker (ORB) infrastructure to provide programming-language independence and code portability. The standard CORBA protocol, IIOP, lets all of these platforms interoperate over the network. On servers, CORBA's robust implementation architecture scales to Internet hit rates and enterprise numbers of objects.

On clients, the IDL interfaces make it easy to access (and therefore integrate) any number of different object types. A COM-CORBA bridge standard (available on the market from more than a half-dozen companies) lets clients on Microsoft operating systems function as citizens in the CORBA world so no one gives anything up.

CORBA is developed and maintained by the members of the Object Management Group, a non-profit consortium with membership open to all. Specification requirements and proposals are written by the members, and adoption decisions are made by the members in a one-company, one-vote process.
JON SIEGEL
OMG

~~~~~~~~

Edited by Michael Levine, mlevine@mfi.com