Building Blocks of Success
Once avant garde, component-based development may now be going from mainstream to mandatory.
In the movie "2001: A Space Odyssey," a great process of awakening involves the discovery of a huge, imposing monolith. If insurers were to make their own movie, it might be called "2001: A Systems Development Odyssey." But perhaps the symbol for the great advance of the time would not be a huge, monolithic entity but rather a cleverly arranged agglomeration of...Legos!
That, at any rate, might be the symbol chosen by the evangelists of component-based development (CBD), who say the approach has proven itself to become not merely a mainstream development approach, but to be the future of development, period...
CBD, they say, provides carriers with an alternative to a costly and time-consuming "all-or-nothing" development solution, and can provide the tactical business results needed today, while providing a flexible strategic platform for the future. But perhaps the greatest promise of CBD lies in the potential for reuse. By isolating bits of code into components, CBD makes business processes detachable from the applications they serve. Within a company's development organization, these components can be archived into an ever-growing library, enabling developers to repeatedly draw on development assets—resulting in potential efficiencies that would make a project manager's mouth water.
CBD sprang from both the success and the failure of object-oriented technologies, says Andy Labrot, chief technology officer of MTW Corp. (Lenexa, KS) a component-based e-business solutions provider. Languages such as Java and C++ were presented as a silver bullet to the industry, but presented serious shortcomings for business, Labrot says. "It's not that these technologies don't work—they do," he says. "But it was how they were implemented to solve business problems, which was very complex for the average developer to understand," that was a problem.
Mastering the Learning Curve
The promise of these technologies made organizations feel their programmers had to learn them, according to Labrot. "You basically took your best and brightest programmers out of their wheelhouse and, in effect, turned them into promising novices." Those novices were then directed—at considerable cost in time and money—to develop the new technologies. In the case of the emergence of client/server, for example, according to Labrot, "Everybody fell in love with the zap and sizzle of the screens. But what happened is that those systems were built on platforms that did not interoperate with existing platforms, so you ended up not only with application silos, but technology silos," he says.
The problem was, in part, one of emphasis. "Technologies aren't the issue, because the technologies themselves work. The issue is the people: People make systems work and it's people that provide the business value, implementing the business requirements required for companies to succeed," Labrot argues. "And what component-based technology does is allow you to leverage your existing people skills and legacy assets, while positioning companies to leverage emerging technologies as they make sense to the companies themselves, rather than to the industry at large."
An appreciation of these possibilities encouraged Chicago-based Accenture—then Andersen Consulting—to place a major bet on CBD, in the mid-1990s, according to partner Mike Jackowski, who says some of the firm's P&C clients were seeking a solution to help them out of development gridlock. "That gridlock was that their 1970s- and '80s-built mainframe-type technology was so old and brittle, and the business problem became so overwhelmingly large," he says. "We estimated the overall re-platforming of an entire claims suite of applications across an organization to be as high as 120,000 work days. When you try to re-platform that entire thing, you end up taking on too much risk and spending way too much money up front."
Accenture responded to the challenge by developing what it called a component blueprint to identify strategic means of solving business problems gradually, rather than resort to wholesale replacement of claims systems. "In going down the road of developing components, we wanted an approach that would minimize the risk," Jackowski says. "We wanted to be very thoughtful in terms of producing some front-end components that could have a very large near-term business impact, while allowing the slow replacement of these large, complex systems on the back end."
The fundamental challenge in developing a component strategy is to identify "what components we're going to build and why we're going to build them," says Jackowski. Having done the business case analysis for a client, it was suggested that work be done on the process of negotiation for a claim. "They didn't feel they needed to enhance their negotiation ability—they wanted to go after things that had a little more sizzle," Jackowski relates. But analysis of closed-file reviews and adjusters' use of time showed that adjusters were not negotiating effectively. "By focusing on areas where the adjusters could clearly have been more successful in having a dialogue with a claimant, they could really have reduced their cost. Based on that analysis, all of a sudden negotiation became one of the top components in our suite," he says.
Blinded by Science
Such business-driven analysis is the essence of success in CBD, according to Jackowski. While CBD culture may still retain some of the scientific focus of its object-oriented technology roots, "component development is an art," he says. That art, he adds, involves breaking down the business problem in manageable parts, and understanding the granularity of those parts. "It's knowing what components can stand alone and what needs to serve as building blocks for other components, and then in what order to follow in building those components out."
As MTW's Labrot puts it, "To be effective in implementing components you have to ask the right questions of the users." What must be clear up-front, he says, is, "Is the business in control?" Once that is established, companies must then ask, "Is there a clear way the components have been implemented? And is there a clear strategy of how I can do this across technologies and platforms?" The ultimate question, Labrot says, is, "Can I meet my business requirements today while evolving to the future?"
With so many questions to answer, is CBD a questionable developmental approach choice? "I don't think there's much of a choice anymore," says Kevin Murray, CIO, Claim Services, AIG (New York, $268 billion in assets). "I think we used to unknowingly slap things together and include the integration code within tightly coupled components, creating maintenance nightmares for later." The only question, he adds, is how to assess the "de-coupled value of the component and choosing where to draw the boundaries around it"—what might be called the granularity challenge. The danger, according to Murray, is (as Accenture's Jackowski might put it) in being blinded by the science. "Over-analyzing can result in 'analysis paralysis,' perhaps making too many components and making your integration world so complex that it becomes a maintenance issue," Murray says.
A different kind of maintenance issue is collecting and archiving the components built within an organization. AIG recently implemented content and code management software provider Starbase's (Santa Ana, CA) StarTeam product, which Murray describes as "a Web-based, version control, content-management control, object-component library." Before AIG programmers go forward with component development they will be required to log on to the system, Murray says. "You will go to this library and you will prove to us that you've done an appropriate search and verify that there's a reason they can't re-use a component that's there."
One of the greatest benefits of CBD is squandered if components cannot be found for future use, and at a vast organization such as AIG, controls must be put in place to promote reuse, according to Murray. "If you don't have a methodology in place for everyone across the organization to know where to go to see what components have been built, or the documentation concerning them, then those components are worthless," he says.
Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio
Tweet This