July 28, 2003
(Computerworld)
The deputy CIO at a major aerospace company had worked hard to get her company into software reuse. She hired reuse librarians, trained developers in reuse and object-oriented methods, and overhauled the company's software development methodology. Her goal was to have 60% of the code in new systems come from a library of reusable components within 12 months. But at the end of that time, the figure stood at just 6%.
"They were doing all the right things technically," says Richard Soley, chairman and CEO of Object Management Group Inc., a standards consortium in Needham, Mass. "But when I asked her how she measured the productivity of her developers, she said the same way they always had -- by lines of code generated. And making code available for reuse just takes away from writing more lines."
Not changing programmer incentives and culture along with the technology is the No. 1 mistake companies make in software reuse, Soley says.
Diebold Inc. in North Canton, Ohio, is getting better results from its reuse program than the aerospace company did. Richard King, a senior software applications support engineer, says Diebold has seen a whopping fivefold improvement on the speed of development of new applications by using its "toolbox of reusable assets."
The toolbox holds components as simple as "read-me" text files and as complex as Java and .Net components. It uses Component Manager Enterprise Edition (CMEE), a repository manager from Flashline Inc. in Cleveland that creates searchable indexes of software-related assets and maintains metadata and use history about those assets.
CMEE spans multiple source-code repositories at Diebold, including Microsoft Visual SourceSafe and PVCS Version Manager from Merant Inc. in Hillsboro, Ore.
Although programmers at Diebold are expected to make software reusable whenever feasible, the company has a special development group dedicated to reuse. It looks for reuse needs, develops components accordingly and puts them into CMEE.
Getting developers to tap into the reuse library thereafter isn't difficult, King says. "Deadlines are so tight now that they would never be able to meet them without aggressively reusing," he explains.
Sharing Made Easier
Programmers have been swapping code for as long as software has existed. What's often lacking are procedures, disciplines and tools for tracking, managing, searching and distributing software assets.
"Developers like to share things informally, and managers might be surprised to find how much reuse they already have," says Dale Hite, chief technology officer for software architecture at Fidelity National Financial Inc. in Santa Barbara, Calif. "The leverage comes from being able to manage where it's at, locating it, updating it and maintaining it once vs. maintaining it in n number of iterations."
The functions Hite refers to are central to a family of tools that lie at the heart of software asset reuse: searchable repositories of software metadata and use history.
But those aren't the only products that support reuse. Others include development tools and environments, version-control software, tools for wrapping or transforming legacy code, and messaging tools that can access reusable code where it sits.
Software reuse received much attention in the 1980s but didn't catch on in a big way until the advent of object-oriented languages and tools. More recently, the rise of XML-based Web services and their Universal Description, Discovery and Integration (UDDI) directories have made reuse easier, as have two standard component models, J2EE and .Net.
Finally, the emergence of Unified Modeling Language (UML) for object-oriented software management and the Reusable Asset Specification, a UML-based standard for defining and managing reusable components, are making software tools more powerful and interoperable.
Fidelity's goal is to have half or more of any new system come from reusable components. It uses Flashline's CMEE and several source-code version-control tools. The company's reusable components include mostly low-level code -- just above the operating system level -- and "patterns," such as the Model-View-Controller pattern, a standard way to break a graphical user interface into its input, processing and output functions (see "Patterns Form Code-Reuse Fabric," QuickLink 39893).
At Fidelity, patterns are standards, or "prescribed methods," Hite says .
More Than Code
Indeed, although the practice is called "software reuse," much more than code can be carried in reuse libraries. Assets can include things such as business-process rules, best practices, interface specifications, test cases, images, documentation, models, patterns, XML schemas and code at all levels -- virtually anything that can be placed in a file.
Companies are increasingly seeing the benefits of reusing precode assets, says Grant Larsen, model-driven development strategist at the Rational Software Corp. division of IBM.
"Artifacts that come from the earlier part of the [software] life cycle -- design specs and requirements -- potentially have higher leverage than code," Larsen says.
CNA Financial Corp. reuses software assets at two levels. It catalogs and reuses patterns such as the J2EE Session Facade, which encapsulates business logic and presents a uniform service access layer to clients.
The patterns constitute best practices, says Dmitry Tyomkin, enterprise architect at the Chicago-based company. He says these kinds of components might be used six or seven times in a year out of some 10 to 12 projects for which they are candidates for reuse.
At a higher level, CNA also maintains reusable routines such as the code that determines claims eligibility in insurance applications. Both kinds of reusable assets are managed and tracked by the Logidex metadata catalog from LogicLibrary Inc. in Pittsburgh.
Logidex catalogs software assets and shows their relationships to one another and to a company's business processes and technical infrastructure.
Companies should move to a "service-oriented architecture where you essentially decompose your large specifications into smaller pieces, or 'services,'" Tyomkin advises. These services, such as claims eligibility, are "subroutines taken to a higher level," he says.
"They don't care if the client is written in Java or .Net or anything else, and they don't care which platform," adds Tyomkin. "They use XML to communicate, and that's all they care about."
The extra effort necessary to make code suitable for reuse ranges from 50% to 100%, says Andrew Zimmerman, senior application architect at Citigroup Real Estate Servicing and Technology, a St. Louis-based division of Citigroup Inc.
But the payoff can be significant. Zimmerman cites an application that took 6,000 hours to develop with reuse in mind but then required just 240 hours to roll out to a second business unit and 40 hours to roll out to a third. Had the system not been developed for reuse originally, it would have taken only 4,000 hours or so the first time, but thousands of hours for each subsequent rollout, he says.
Citigroup now puts metadata about all of its code into its repository, not just metadata for those components designated for reuse. Each component is tagged as "mandated," "recommended" or "educational."
"People would hold back submitting something because it, for example, hadn't been documented," Zimmerman says. "So we said we are going to treat all of our software as potentially useful in future development efforts."
Finding Ways to Reuse
Citigroup hasn't yet gone back to harvest reusable components from its mainframe systems, but it has found a way to make those components reusable. It uses the messaging capabilities in IBM's WebSphere MQ to allow its Web applications to invoke Cobol code on a mainframe. These Cobol components aren't registered in CMEE, but the WebSphere MQ components that access them are.
The reuse program at Home Buyers Warranty Corp. in Aurora, Colo., is built around the RequisitePro requirements management tool from Cupertino, Calif.-based Rational and the Component Manager repository from Select Business Solutions Inc. in Boulder, Colo. HomeBuyers Warranty uses RequisitePro to track "use cases" -- essentially business-process rules.
Component Manager holds and manages self-contained code routines, such as the program that pops up a calendar on a Web site, says James Tallant, director of IT at Home Buyers Warranty. A business application could have more than 2,000 such reusable components, he says.
Tallant says the company's CRM, ERP and accounting applications are all custom-built in the .Net architecture using C# and C++. Between 50% and 70% of each one comes from reusable components, he says.
"Doing it this way beats out packaged applications, which are so difficult to implement," he says. "People don't realize that the hard part about systems is building the interfaces. We don't have to do that anymore. It's all integrated. It's the new way to develop big enterprise software."