Building Blocks of Success
Avoidance Tactics
Without some type of incentive—and/or disincentive—both project managers and developers can find reasons to avoid working toward re-use, says George Dart, application architect, Aetna (Hartford, $47.4 billion in assets). As for the considerations that influence developers, Dart says, ""If it takes me 10 hours to build a piece of functionality for my application, as a rule of thumb it's going to take me 1.5 to two times as long to build that same piece of functionality in a reusable way."" Then there's the ""not-invented-here syndrome"" affecting most engineering types. ""Developers are cowboys, they want to do it themselves so that it's done 'right.'""
Aetna is in the process of formalizing a reuse strategy to motivate development of reusable components while providing a kind of ""supermarket"" archiving and tracking tool where developers can ""shop"" for what they need. Though Aetna is itself still in the process of shopping for such a tool, Dart envisions it ""like Amazon.com—I can browse a list, read reviews, provide my own reviews, and purchase items directly. We're looking for a platform to be able to do that,"" he says.
Incentives for Aetna developers will likely include some of the trigger features that Kevin Murray hopes will keep developers honest at AIG. In addition, Dart says, developers who succeed in building the original reuse components will receive recognition. Beyond that, managers are likely to become more supportive when they realize the economies that reuse can afford. A piece of functionality that normally takes 10 hours to develop may take 15 to 20 when built for reuse, by Dart's calculation. ""But if that thing gets used once, it saves 10 extra hours. Then if it gets used again, it saves 10 more hours. Now you're able to see that graph of savings begin to climb,"" he says.
Nor is that the only benefit, according to Dart. ""It can also contribute to a higher integrity in the application itself, because if I don't have to build a piece of functionality, I don't have to test it. And by definition, something doesn't make it into the repository until it's completely tested.""
Built-in capability to track and measure reuse will make all the difference in demonstrating the value of the ongoing effort. When Aetna management asks, ""What good is this strategy doing me?"" Dart says he'll be able to answer, ""Well, it saved us 4,000 hours this quarter.""
One-Stop Shopping
Sharing reusable components within an organization is one thing, but the long-term vision held by many is leading to something like one-stop component shopping. ""The overall hype is 'every component is reusable,' so that with a shelf full of components, you would never have to build software again,"" says Mike Sparling, CTO at advanced business software firm Castek (Toronto). The reality, at least for the time being, is that an organization may not be able to find a precise fit to its needs. What this demands of the industry, Sparling adds, is a shift in thinking. ""If I can get a component off the shelf that does, say, functions A to F, and all I'm going to use is A to C, but there is no component that does A to C or is cheaper, then I have to reconcile myself to the idea that the commodity is the right way to do it."" Firms marketing commodity components already exist, Sparling notes, including Objecttools.com (Mt. Laurel, NJ), ComponentSource (Kennesaw, GA) and Flashline (Cleveland).
The use of differing proprietary technologies constitutes a barrier against freer access of component assets, but a rosier future may well lie with the concept of Web services, Sparling suggests. ""Taking the open interoperability of a generic set of technologies and applying them to a shared, encapsulated reusable asset is really what Web services strategies are all about.""
The issue is no longer whether to build component solutions, but whether to embrace XML Web services as part of the enterprise architecture, says Josh Lee, global technical evangelist, insurance, Microsoft (Redmond, WA). ""The advantage to choosing XML Web services will be an easier integration with trading partners and industry-standard applications and schema. Insurance claims applications will soon be able to take advantage of a network of applications that are readily available and competitive, and that will drive down costs and reduce claims processing times,"" he predicts.
---------------------------------------------
WHAT IS A COMPONENT?
The building block of component-based development (CBD)—the component itself—can be conceived of as a ""black box"" encapsulating a specific business process, says Lydia Patterson, vice president, Starbase (Santa Ana, CA), a provider of software for the management of integrated content and code for e-business applications.
""We don't need to know about the internal code of the component, which could be extremely complex; we only need to know the functions it can perform,"" she says. ""Traditionally developed applications are monolithic in nature, fulfilling several business functions, with each function tightly coupled to the rest of the application. The potential of a component architecture lies in the fact that it provides 'stand-alone' functionality, reducing the dependency factor—enabling reuse of the 'component' in other applications.""
The language in which a component is written is irrelevant, since its key feature is the interface functions that it surfaces. ""One of the great advantages of components is the ability to leverage legacy applications together with new technology. Legacy COBOL code can be modularized, and plugged into modern object-oriented client/server applications by defining the business interface logic and providing this in a 'component wrap' technology, such as C+.""
The complexity of a component is expressed in terms of a description of being either fine- or coarse-grained. The appropriate level of ""granularity"" within any given application context may be the source of much contention, but one may generalize to say, according to Patterson, that ""the bigger a component, the greater the maintenance challenge.""
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