The quest for component reuse carries on
- By Richard Adhikari
- February 1, 2002
Componentized application development is based on the premise that it will cut costs in the long run because the components can be reused. But reusing components is easier said than done. Most components developed during the past few years have not been reused, for reasons ranging from poor planning to inadequate infrastructure.
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.
|Legal issues in reuse
|While the ability to componentize legacy systems for reuse offers tremendous potential to save money and leverage existing investments and skill sets, it also opens up the possibility of getting bogged down in lawsuits, with all the expenditure of time, money and effort that entails.
Why? Three words: Intellectual property rights. You could be breaching the intellectual property rights of the vendor whose legacy software your company is using.
"More and more, when people implement component reuse, intellectual property rights come into question," said Nagaraja Srivatsan, senior vice president, Client Solutions Group at international IT consultants Silverline Technologies Inc., Piscataway, N.J. "With the older components, you roll your dice and you take your chances." That means users of older components will see "lots of disclosures and legal statements" telling them they can reuse the components at their own risk, Srivatsan said. Corporations that offer components for reuse have to write in the correct legal clauses and legal notices to protect themselves, he added.
The situation is worse when components are reused outside a corporation's firewall or a corporation reuses components from outside its firewall, which Web services will make possible. "Once you expose components to your business partners, legal issues will come in," Srivatsan said. It is better for corporations to reuse business components developed within their firewalls, where they can monitor the legality of those components and ensure they do not breach any intellectual property rights.
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.
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."
|Case study: Building reusable components
|Quick thinking and luck let Srini Bhagavan, lead software architect at Sprint PCS.com, Kansas City, Mo., turn an otherwise mundane project on provisioning handsets through browsers into one that leveraged the idea of component reusability.
While working on the project design, Bhagavan's team found that the system they were building would handle critical aspects of billing, provisioning, customer management and account management. Another project was planned to follow immediately after this one and Bhagavan, who was leading development in the first project, saw the similarities between the two and realized that both would use the same critical aspects of billing and so on. He suggested the development team decouple these functions from the application tier, build interfaces around them and reuse them in the next project. The team decoupled the functions and created Enterprise JavaBeans with them because it was developing in a J2EE framework.
It turned out these features could be used by every application that came in to create a customer or get a customer profile or subscription profile, functions that "are very repetitive and appear in a lot of projects," Bhagavan said. He found that Sprint PCS.com had "a lot of adapters that did transformation services to enterprise application integration services or other vendors the company interacted with" and began stacking up the adapters and the services.
Bhagavan's team deployed the components it built on an application server. "From the application perspective, we only had a single interface that we exposed—it was like a domain model—so the applications' only concern was requesting the domain objects for data. They looked at the domain interface to get the information, [so] they were completely isolated from all the gymnastics that happened in the back end," Bhagavan said.
Bhagavan's team had multiple instances of each component, each interfacing to a particular legacy system, because the legacy systems cannot handle multithreaded frameworks.
The domain model Bhagavan's team used also solved the problem of making the components widely available. "In this day and age, it's hard to find the right skill sets for things like writing quality EJB components or writing messaging type frameworks," Bhagavan said. "By making these components pluggable into our business layer, the application tier had no idea where it was getting the data from or how it was getting the data, so we didn't have to wait until we found people with the right skill sets to write the system calls."
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."
|Developing for reuse
|When you are developing a component, how can you ensure it will be reused?
Developers must organize the packaging, documentation and complexity of the component to the right level so it is easy to use, customize and apply to the context, said Grant Larsen, director of reuse strategies at Rational Software Corp., Lexington, Mass. "If someone can't pick up a component and figure out in a few minutes the mechanics of the thing, they'll toss it no matter how good it is," Larsen said. Components should also possess the characteristics of sound engineering: tight cohesion, loose coupling and sufficient capabilities.
Providing correct documentation is crucial, added Gary Baney, chief technology officer at Flashline.com, Cleveland. That means making sure context documentation is added to the business logic and requirements documentation. Context documentation "explains clearly the functionality and application of the component as opposed to explaining what its technical details are," Baney said.
Flashline.com offers Component Manager, Enterprise Edition (CMEE), a repository for software components and development assets that provides the meta data to give context documentation to developers so that "as soon as they see the component, instead of focusing on what the algorithm is doing, it explains to them what business problems the algorithms solves," Baney said. Creating new components from old ones using CMEE is easy: "You go into the repository and pull out the component you want and see you only need 10% of the code, so you chop out the other 90% and now you have a new component," Baney said. This is a new component, not a version change, so the developer has to re-submit the component into the repository and re-document and re-explain the context of the new component. The repository is a series of location linkages so it can be located anywhere. "We're kind of the Napster of component retesting," Baney said.
Brent Carlson, vice president of technology at LogicLibrary Inc. Pittsburgh, said corporations that find that the components and interfaces they want to deploy do not exactly match their existing components are solving this problem by building a component shell or wrapper that can be used to access existing applications. Once enterprises use component-based development and Web services to define the right set of interfaces to support their business processes, they can define a component, perhaps a Java Session Bean, that defines the correct interface, makes it callable, builds the right linkages to the back-end data and makes sure the user has consistent views on all back-end systems, Carlson said. New development can then be based on these new interfaces.
LogicLibrary provides an environment that helps IT organizations and line of business organizations capture, leverage and manage software assets. It defines the various elements that make up a well-documented, well-built asset and provides mapping facilities that let developers tie an asset against business or technical models their corporation has defined for future strategic business.