In-Depth

The quest for component reuse carries on

• By Richard Adhikari
• February 1, 2002

Not all components can be reused; developers must select the right components. That includes deciding which category a component falls into. And because reusability is more of a functional than a technical issue, developers must understand the functional issues. They also need to consider components from both the business and technical points of view before they reuse them.

Looking to the future, when developers are working on new components, they must consider several factors, including design, refactoring, testing and documentation.

Thousands of person-hours put into developing software components over the years have been wasted. "More than 70% of all components built prior to 2001 will need to be rebuilt in the next five years," said analyst Mike Blechar at Gartner Inc., Stamford, Conn. He gave two reasons for this. One is that most corporations have no formal reuse program in place, so they fail to follow the steps needed to build reusable components, even if they are using reuse methodologies. The other is that corporations may not have the culture or the political climate to build reusable components.

Ian Archbell, vice president of product management at Micro Focus International, Rockville, Md., said much object-oriented development "is not much more reusable than development was 10 years ago" because the groundwork was not laid properly during development.

"Many developers can't reuse objects because things like object repositories, which tell you what's available [and include] descriptions of object interfaces, don't exist," Archbell said. While small groups of programmers can get some measure of reuse because "the teams are small enough that everyone is aware of the objects and interfaces and communicate easily," that falls apart once development is scaled out to a larger organization with 1,000 or so programmers, Archbell said.

Brent Carlson, vice president of technology at LogicLibrary Inc., Pittsburgh, said the that reason many components cannot be reused is that they were built for specific needs: developers did not spend enough time working out the real requirements, they defined them too narrowly to allow reuse or development was rushed to meet specific deadlines. LogicLibrary offers a solution that ties assets to business processes through the use of reference models.

Making a choice
Because not all of a corporation's existing software components can be reused, developers need to sort out the reusable ones and discard the rest. The first thing to do before selecting components for reuse is to decide what reuse means, said Grant Larsen, director of reuse strategies at Rational Software Corp., Lexington, Mass.

"Does it count as reuse if I reuse a couple of classes from another developer in the same team, or if I take a set of fields and documents from another team on the same project?," Larsen said. "You need to come up with policies saying what you count as reuse and what you don't."

There are four things to consider when evaluating a component for reuse, Larsen said. One is the business angle: Does it make financial sense to reuse the component? Can the corporation afford to maintain the component? Are there legal or licensing issues involved with reuse? The second is issues related to the corporate culture. "Is there the 'not-invented-here' mentality? Will people feel threatened that they have to reuse this component?," noted Larsen. Third is process: Is the organization mature enough and does it have sufficient roles, activities and process maturity to take on the component as part of its development effort? The final requirement is engineering: Does the component being picked for reuse solve the problem at hand?

LogicLibrary's Carlson recommends evaluating components from both the technical and functional points of view. For the technical side, developers must make sure the component is well designed, well implemented and conforms to the best practices for the environment in which it is implemented. For the functional side of things, ask whether the requirements for the components were rich, consistent and complete enough to allow component reuse or whether they were very narrowly focused. However, even if the requirements were narrowly focused, developers should rework the component for reuse if it is a core piece of the business, building new versions and adding new capabilities over time, explained Carlson.

Gary Baney, chief technology officer at Flashline.com Inc., Cleveland, which offers tools to assist in software reuse, considers functionality more important than the technical side in terms of reuse. "What determines a component's ability to be reused is 90% functional and 10% technical," Baney said. "The technical barriers are being torn down, so the emphasis is increasingly being put on context, documentation, scalability and availability." Baney picks components for reuse that most closely match his client's specifications or business needs.

Gartner's Blechar divides components into three categories when figuring out what can be reused: technology or technical components, business components and application templates.

Technology components are things such as date validation routines, which relate to the technology regardless of the business problem, Blechar said. Organizations reusing technology components "talk about getting a 40% or greater productivity benefit for their programmers in design and construction than those that do not" because technology components generally do not change and can be reused rapidly, Blechar said.

Business components focus on satisfying a business need. To build reusable business components, corporations need to make some changes in their approach, Blechar said. One change is to integrate data and process into components that are more reusable across the enterprise instead of delivering the data and process and other modules separately, he noted. Another change is to adopt a newer methodology, such as the Unified Modeling Language (UML) or business process modeling, and base components on use cases and classes, or workflows based on business processes.

Application templates are commoditized collections of business and technology components such as payroll and human resources applications offered as mini-packages, Blechar said. Usually, corporations pay third parties to customize such packages, he said.

Nagaraja Srivatsan, senior vice president, Client Solutions Group at international IT consultants Silverline Technologies Inc., Piscataway, N.J., said connectivity components are one type of component well suited to reuse. If, for example, a development team has built a component to be used for Oracle and SQL connectivity, it can develop a mega-component such as accounts receivable that draws on that connectivity component, Srivatsan said.

Future development
Developers building components now have to take several steps to ensure they can be reused in the future.

First off, they have to spend a lot of time on design. At outsourced payroll handlers Ceridian Corp., Minneapolis, Bob Hughes headed an enterprise-wide project to consolidate 26 mainframe databases nationwide into a single Microsoft SQL Server 2000 database. This tied into an Oracle front end and Ceridian's call centers. The aim was to create objects that could be reused repeatedly. Achieving that goal "requires a lot more thought to be put into design," said Hughes, Ceridian's manager of sales and service technology. In fact, the amount of time put into planning and design was "unnerving, and we had to deal with the 'Why aren't you programming?' question a lot. But in the end, we could generate a vast amount of code," Hughes said.

Hughes' team received help from consulting firm Extreme Logic, Atlanta, in creating the architecture. Extreme Logic also delivered some shared COM components for the project. In addition, Ceridian developed business objects in Visual Basic and C++ using Rational Rose and other tools from Rational Corp.

Srini Bhagavan, lead software architect at Sprint PCS.com in Kansas City, Mo., said spending time on design "helps you identify prime candidates for reuse or impose your reuse infrastructure on your application and see how much of it can be harvested." This shortens the development life cycle "quite a bit," added Bhagavan. He has a team of component architects who work with application development teams to identify components for reuse, harvest components and refactor them.

Refactoring is a long and involved process. "It may sound like an overnight event, but it takes two to three [days] to refactor components because the refactoring involves a very strict engineering process," Bhagavan said.

Testing is critical when building reusable components, and the earlier it is done the better. "One of the key lessons we learned is that if you want to deal with objects, you have to have your hands around your quality assurance [QA] and source-code processes," Ceridian's Hughes said. "QA can't be an afterthought; it has to be built in from the beginning."

Quality assurance becomes even more important when components are reused, because any change in a component will have a ripple effect everywhere it is reused. "Every time you change your object you need to be able to regression test your application," said Hughes. "The only way to do that is to make sure tests are written at the same time as developers write the code."

Documentation is critical. "Component reuse will only succeed if components are sufficiently well-documented to support reuse," said Flashline's Baney.

"When you post Web services for consumption, you should indicate things like how many transactions those services will support at peak times, and indicate [that peak times] are, say, 2 p.m. to 3 p.m.," Baney added. "[This way,] if they won't support enough traffic that my application can use them during that time, I can decide not to use those services."