![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
"There's an enormous demand for software components," said Charles Stack, CEO of Flashline.com, a Web-based company that offers software component products and services. "Financial institutions are rapidly moving as many services as they can to the Web, and they're using software components to do that," he said. Stack adds that many Flashline.com customers, which include large banks and Wall Street firms, are migrating to IBM's WebSphere or BEA's WebLogic application servers as the foundation for their Web strategies.
According to Mike Gilpin, vice president and research leader for the Boston, MA-based research firm Giga Information Group, "It seems like virtually every bank in the world has licensed either WebSphere or WebLogic, or is in the process of getting ready to do so."
While there are upwards of 40 vendors offering application servers to the financial services marketplace, WebSphere and WebLogic have managed to capture the lion's share of the market.
"The good thing about them both is that they're adhering to industry standards," said Colin Piper, CEO for Eontec, North America, based in Charlotte, NC. Eontec sells BankFrame, a component-based, Enterprise JavaBeans (EJB) solution that provides large financial institutions with core banking processes, such as back-office administration, loan processing, transaction routing, integrated bank accounting, corporate banking, call center support, and branch teller functions. Piper estimates the global banking industry will spend upwards of $7.7 billion on component-based software products between 2000 and 2004.
far, the adoption of component technology by the financial industry has varied by sector. Retail banks have been at the forefront, followed by Wall Street firms, and insurance companies.
Retail banks have been most aggressive in pursuing component technology, using it for core business processes, such as those supported by BankFrame. The rising popularity of online banking has also contributed significantly to the adoption of component technology.
Although the traditional brokerage model has not pushed Wall Street firms toward component technology, some brokerage houses are now testing the waters. "Wall Street firms have focused more on messaging technology as an integrator," Gilpin said. "They are just as technologically advanced as banks, just not in the area of components," he said. However, now that online stock trading is a major part of the market, component technology is beginning to take hold.
"Insurance companies don't have the business needs that push them toward component technology in the same way that a bank or a Wall Street firm would be motivated," Gilpin said. "Life insurance companies hope you don't call. They want to keep your money. There's not a lot of focus on customer interaction, which would typically drive Web usage and investment in component technology," he said. "Casualty insurance companies are focused on efficiently processing claims, not making customer interactions optimal from a sales perspective, which is a major driving force for component technology," he added.
Rob Mickley, president of Gazebo Software Solutions Inc. and Chair of the Finance Task Force for the Object Management Group (OMG), believes the financial services industry was somewhat unprepared for the move to component technology. "The Internet caught everyone by surprise," he said. "It came very fast, and the [financial industry] is not known for moving very fast." However, Mickley is quick to point out that component technology predates the Internet revolution, and gained significant momentum on its own prior to the industry's current emphasis on moving applications to the Web. The forces driving component technology to the Web, he maintains, represent only the most recent wave in the component revolution.
What's more, Mickley predicts that Application Service Provider (ASP) models for financial services will stimulate the trend toward commoditization of the financial services industry. "But they must have standards-based component interfaces for this to succeed," he said. "Banks [and other financial services providers] are listening to the need to open up their systems with industry-standard interfaces to support this new model. There are already industry examples for home banking, stock brokerage, and paying bills. These are quickly becoming standardized. There is also progress in newer areas like bidding systems and wireless access for financial services," he observed. "At the moment, the focus of these standards-based interfaces are customer-facing services. However, as the industry's use of the technology matures and new business-to-business (B2B) models are established, component interfaces for what was traditionally back-end processing will start to emerge and open up."
The appeal of reusable software components lies not only in their self-contained nature, but in their ability to allow companies to "open up" their systems, "even if the systems were really not designed to be that way," Mickley said.
Components provide autonomous, enterprise level, distributed functionality on the server, as well as help developers define and encapsulate system functionality at different levels of granularity. By adopting component technology, established firms with older systems can more easily compete with new companies that start out with systems designed around cutting-edge component architectures.
Piper adds that software components are easier than traditional programs to maintain, support, and modify for future requirements. "The advantage of taking a server-centric approach [in the financial industry] is that you can define a business process, write it as a set of software components once, and then deliver it across multiple channels."
In addition, the appeal of large-scale, financial services software suites, now prevalent throughout the industry, may begin to wane as companies discover the many advantages of component technology. "Once you get a financial system to where it's comprised of separate autonomous components [rather than a single monolithic program], flexibility goes up," Mickley said. "You not only have the component interfaces, you really have distributed components. Then you can start playing with system-level decisions, such as spreading them around or assigning functionality to a specific location."
Piper cites another reason why many banks are looking to components for delivering business processes, rather than single-vendor software suites. "They've tired of the buy versus build problem," he said. "If they pay for a complete package, it may require very heavy customization, sometimes up to three times the initial license cost," he observed. "There are also problems inherent in building systems from scratch; they become proprietary, and the company that creates them must provide its own support and maintenance over the life of the system." Piper maintains that the component model offers the best of both worlds; pre-built components only require customization on the back end for communication with existing systems and on the front end to accommodate a specific look and feel.
Industry watchers also emphasize that the emergence of interoperability architectures and software development frameworks should help ease the adoption of component technology for financial services applications. The Common Object Request Broker Architecture (CORBA) in particular has defined ways for objects to communicate, even if they were created in different programming languages. In addition, development frameworks such as Microsoft's Component Object Model (COM) and Distributed Component Model (DCOM), as well as Sun Microsystem's client-side JavaBeans and server-side EJB, have spurred interest in components. "This creates a bit of tension, because about 80 percent of the components on the market are COM components," Gilpin said.
While COM components may be more widespread, experts agree that EJB components are the most popular among software developers in the financial arena. "A lot of banks want to go to Java," Piper said. "If they want their applications to talk to each other, EJB is the way to do that," he said.
While large financial services companies with existing, heterogenous hardware and software architectures are more likely to gravitate toward EJB or Java 2 Platform, Enterprise Edition (J2EE) than Microsoft's COM and DCOM, "You can't make a commitment to one component model," Gilpin cautions. "It's clear that you're going to have a mix." However, he has noticed that some financial services companies have defined a preferred component model for certain kinds of development. For example, a bank may allow certain departments to buy either COM or EJB components, but stipulate that new components that reside on servers with multiple applications be EJB-based. "Many banks take an approach like that," Gilpin said.
Besides opening up systems and enhancing flexibility, components also allow financial institutions to take full advantage of legacy resources without having to revamp or replace existing code. Among financial services organizations, banks especially have large amounts of legacy code stored on mainframe computers. However, market forces increasingly dictate that they develop new, non-mainframe based applications to stay competitive. While it's possible to develop a Web service or wireless application using legacy code, it is much easier to simply wrap the legacy code in an EJB component that contains pre-built functionality. For example, a bank with a legacy mainframe application that provides a customer's account balance could wrap the application with an EJB component that provides the customer's account balance over a cell phone. "That's the type of distributed architecture that's so appealing to these companies. They don't have to disturb the back-end stuff," Stack said.
Mickley agrees that legacy systems are a good place for banks to start when moving to component technology. "They've got this big boat that's hard to turn around and expensive to replace," he said. "Using component interfaces to create a facade into legacy systems helps large financial organizations buy some time and leverage their investment in older systems," he said.
-
The Simple Object Access Protocol (SOAP)
-
Java 2 Platform, Enterprise Edition (J2EE)
-
CORBA
-
The Interactive Financial Exchange (IFX)
- Get the latest on what is happening with the Finance Domain Task Force of the Object Management Group.
- Find "success stories" in the banking and finance industry on the CORBA Web site.
- Walk through the Enterprise Java Series online banking demo, part of an IBM WebSphere tutorial series that includes architecture, design, and implementation.
Claude J. Bauer is a freelance technology journalist located in Middletown, MD. His work appears in numerous technology-oriented publications and on a variety of Web sites. Visit Mr. Bauer's home page or contact him at claudebauer@claudebauer.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
