Return to VSI Home

Business as Usual

By Sandra A. Taylor

Three years ago, Neil Cartwright saw that the future of application development and life at the office had changed, to say the least. Back then, Cartwright heard about building business software with functional building blocks called components, and he intuitively understood how they could improve application quality, flexibility and time to market. The U.K.-based director of development for software vendor Walker Interactive Systems Inc., however, thought that most of the technology firms he surveyed had immature plans for exploiting this new paradigm for application development. On top of that, Walker’s own stable of talent wasn’t exactly filled with component gurus. Yet, he made a leap of faith and led his team of 40 on the path toward component-based development (CBD). "We knew there would be changes with CBD. We didn’t anticipate how extensive—how cultural—these changes would be," Cartwright says.

IT teams, such as Walker’s, that have embraced the component-based approach to building business applications have witnessed a profound shift in the life cycle of mission-critical applications. Most significantly, they were forced to resist the developer’s impulse to "code and go."

Business as Usual

Business Profile:
Walker Interactive Systems

Thorough analysis and design at the start of a project proved to be a necessity. "With CBD, you have to think about how the whole system will hang together and how the different components will interface with each other, and you need to do it before you start coding," explains Marshall Pimenta, senior research and development manager at Walker.

Just as surprising as the amount of upfront planning required to work with components, however, was the speed with which the teams sailed through the rest of the project life cycle.

Early adopters of CBD had believed trade press reports that they would not see a payoff from CBD until later development projects when they could save time by re-using components. Instead they discovered immediate benefits during their initial development projects.

Design by Necessity

Components for Mortals
A continent away from Cartwright, another software development chief, Sally Allen, also saw the promise of componentization. But she, too, wrestled with the specifics of how to turn the promise into reality. "My big questions were how do we define how big (or small) to make our components, what functions should go into the components, and so on," recalls Allen, president and chief technology officer of VSI, a software vendor in South Bend, Ind.

To answer those questions, Allen arranged for a week-long training course on CBD to be taught on site for VSI’s entire staff. Allen requested that the course be tailored to include one of VSI’s own packaged applications in the classroom example. "That training was one very intense week, but the result was fantastic," she says.

During the course, Allen became convinced VSI should first formally model the critical business processes in VSI’s existing suite of applications. VSI’s goal was to rewrite that application portfolio rather than start from scratch and create new applications. "Fairly simple, right?" Allen says. "Wrong! We did far more upfront work than originally planned."

Business Profile:

Like the other early adopters of CBD who used Compuware’s UNIFACE development environment, Allen credits an investment in training and professional services early in the project for her team’s success during what turned out to be a rigorous analysis and design phase.

VSI’s team spent a half-hour in the modeling process for every hour that later was spent coding, Allen says.

Already the models have helped VSI clarify customer requirements—often the source of errors or omissions in development projects. "In one instance, we were able to show a firm that their very detailed set of specifications was missing segments of the business process," Allen says. 4

Barbara Wilson, senior director of development for Kelly Services Inc., the temporary staffing firm, says initial planning is a necessity because componentization is "an art, not a science." That’s because developers must determine on a case-by-case basis how to package functionality into a component, how it will be used and what other components will invoke that functionality. "You can’t make these decisions quickly, without forethought," she says.

Speeding Development

Early adopters of CBD say they’re rewarded with a faster development cycle and higher-quality code than they had experienced with traditional programming methods. "Once you have the component definitions in place, code development becomes the smallest piece of the project," says Wilson of Kelly Services. Case in point: Kelly built a worldwide call center application in eight months; less than eight weeks of that time was spent actually constructing the 140 complex components that comprised the application.

David Marquez, data and automation engineer at Allied Signal Engines & Systems Phoenix Test Lab, found contract developers helping with the test lab’s initial component project became productive quickly. "Outside resources don’t need to know the A-to-Z of the entire application, just the definition of the component they’re working on," he says.

Business Profile:
Kelly Services Inc.

The productivity gains that were experienced by Walker, VSI, Kelly and AlliedSignal occurred even without their purchase of prebuilt components from third-party suppliers. These companies chose to build the major components that comprised their initial CBD applications. They do not rule out buying components in the future, however. "For our second CBD project, we’re buying some components, and we plan to do more of that in the future," says Wilson.

CBD Culture Shock

Of course the development teams felt the greatest cultural change from the transition to CBD. Other than a few developers with classroom exposure or some hands-on experience with C++, most of the IT teams had skills in traditional programming languages including COBOL-C and Visual Basic. Still, with training and guidance, they successfully made the transition.

Kelly reorganized its development team into what Wilson calls "software factory floors." She explains: "The first stop is a design group focusing on business requirements and functional business process design. The next stop is what I call ‘design and development.’ This group prototypes the physical design and confirms that the users’ business requirements have been met. This group also defines the components and finalizes the data models. The next stop is the ‘build floor’ where the components are built. From there the work flows to the ‘implementation floor,’ which includes assembly, integration and quality assurance."

Wilson saw some resistance from developers when they were first introduced to the new organizational structure. Some team members felt they would be pigeonholed into roles. Others worried that they would no longer have the opportunity to develop code. "We address those concerns by trying to cycle people through the process," Wilson says. "The other aspect of this ‘factory’ approach is that it lets us bring in junior people and give them a structured opportunity to learn the trade." At Walker and AlliedSignal’s Phoenix test lab, the development teams became real partners with their colleagues and managers on the business side. The test lab used an iterative modeling and iterative development process. "The users get to see and validate the system as it evolves," says Marquez. "They have the opportunity to redirect us if we’re going down the wrong path in terms of functionality."

The iterative development process also allows the test lab to continually reinforce buy-in from top management, Marquez adds.

Business Profile:
AlliedSignal Engines and Systems

Similarly, Walker went beyond the common practice of involving business analysts in the requirements definition during the build phase. "We give these analysts a CD of the latest software build for them to test and verify," says Cartwright. "They really have become development partners and formally take ownership to ensure their tests reflect their business thinking and practices."

Less Painful Testing

For Walker, a component approach not only sped development, it simplified the drudgery of finding and fixing bugs in software.

"We found that the time needed to test our application went down by about 20 percent," Cartwright says.

"First we test a component in isolation. Then we do an integration test. At that point, we know the component will work, wherever that component is used. Also—and we didn’t anticipate this at all—bug fixing has become more efficient. Since everything is compartmentalized, it’s easier to track down the source of the bug. And once you’ve fixed the problem, it’s fixed everywhere."

A Clear-Cut To-Do List

Kelly Services found the component approach also aided project management efforts. "A component is a bounded, well-defined entity. And as simple as it may sound, you know when you’re done coding," says Wilson.

Kelly also is accumulating historical data that will serve as the basis for estimating the length and cost of future component projects.

All that planning at the start of the project also has made ongoing enhancements to applications easier, says VSI’s Allen. The modeling work upfront created an extra level of documentation VSI now uses to help define and estimate the scope of extensions requested by clients or desired by VSI staff. "Our policy is to model all our own and our client-specific enhancements," Allen says.

Shifting Life-Cycle Dynamics

To be sure, a component approach to building applications changes the development life cycle. At a time when the IT community has never been under more intense pressure to deliver applications to meet the needs of the business, the inclination to "code and go" is hard to resist. Yet that is exactly what CBD demands.

The good news is that a greater emphasis on application design leads to faster development, more robust code and streamlined code maintenance.

As early adopters of CBD have attested, it’s easier to invest in training and thorough analysis and to design with the support of management. "Our decision to go with component-based development was a long-term strategic decision. We weren’t looking for a quick gain," says Walker’s Cartwright. "We believed there were benefits in deployment and delivery flexibility. But we needed time to prove our beliefs. Top management gave us that time."



VSI | Partnered With

Compuware Uniface







The Pilot Group



VSI | Industry Links







VSI | Online Support

Copyright 2000 - 2006 VSI, Inc. All Rights Reserved.