Return to VSI Home

Business as Usual

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."

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

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."

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.

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.

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.

Less Painful Testing

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

"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.

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."