In-Depth

The culture of components

Nationsbank's Consumer Finance Group, Jacksonville, Fla., believes that development projects must get done fast. "As a banking business, we have to get 90-day delivery to stay competitive," said Tom Williamson, senior vice president. But his is not your garden-variety rapid application development shop. The Consumer Finance Group is pushing development of Java component-based applications covering mission-critical processes, such as loan processing, whose business logic and back-end functions can be reused and refined. As such, Williamson and his associates are getting components ready for prime time.

While development managers say that the tools and technologies for developing server-side components are beginning to mature, the real challenge to upsizing components from mere GUI widgets to enterprise-wide applications, according to Nationsbank and others on the front lines, is mostly cultural.

Until recently, the appeal of component-based applications was associated primarily with VBX and OCX controls, or Java widgets used for front-end GUI design. A cottage industry developed during the early '90s, selling items such as GUI controls or mortgage amortization calculators.

The GUI notion remains popular, however. At this year's JavaOne conference, held in March in San Jose, Calif., much of the booth attendance was for tools producing dancing alphabets, not middleware or back-end business logic. The Internet has also provided a new impetus for developing user interface components that simplify deployment of graphically complex applications.

Some organizations, such as the Sierra Club, a nonprofit organization that promotes conservation of the natural environment, have grown a bit more ambitious, relying increasingly on components for back-end, non-visual functions. The driver for the San Francisco-based group was the need to replace a PowerBuilder application that was formerly distributed through mailed diskettes to regional chapters and proved difficult to maintain. A PowerBuilder non-visual database access component was encapsulated as an ActiveX control and managed by a Sybase Jaguar transaction server, which acted as the focal point for a Web-based replacement.

Yet the more things change, the more they stay the same. "Component-based development is really nothing more than modular programming with defined interfaces," said Barry Zukose, a consultant with Tier Technologies headquartered in Walnut Creek, Calif. "I remember reading about modular programming in the 1970s and '80s. At that point, maintainability was the big issue. Today, that's matured to reusability and replaceability."

Components are not such a new thing to Barclays Merchant Services, a United Kingdom-based processor of retail credit cards. Five years ago, the firm began a long-term migration from a 15-year-old IMS system to a more distributed architecture involving a DB2 host, Informix mid-tier databases and terminal-based front ends.

Like other large organizations at the time, Barclays had been burned by Case technology. "We were producing process models with little value. We couldn't keep up with the volume of changes that we had to make. We never found a slick way to go from application modeling to code generation," said Ian Gausden, head of development. Components proved a common sense alternative. Barclays relied on a proprietary framework from Netron Inc., Toronto, that generates software modules with defined interfaces, a technology Netron calls "frames." Barclays currently has an application with six high-level "frames" -- which are akin to applications -- and roughly 200 subcomponents, 90% of which have been reused in some form.

Component technology is not new to San Francisco-based Charles Schwab & Co. either. More than two years ago, the company, using standard APIs developed internally, developed the Schwab Entry Gateway or Sentry, which provides basic business services furnishing securities market data, trade positions and balances. Schwab estimates that it has saved more than $1 million annually because the standard interfaces facilitated considerable reuse. However, because the API was not platform-independent, Schwab's first generation was partial. It still had to write different versions for each platform in its highly varied environment.

Maynard Vitalis employed some of the general lessons he learned as an alumnus of the Schwab team at CommerceOne, a Walnut Creek, Calif.-based electronic commerce software provider where he holds the post of director of product architecture. Components were the means of untangling a needlessly complex development process that was jump-started with Rational Rose object models from Rational Software Corp., Cupertino, Calif. Using Rose's reverse engineering capabilities, Vitalis hopes to build Use Cases to define the ways in which the system is used, extract business rules, diagram application process interactions and then generate Visual Basic, C++ and Java code in Component Object Model (COM) containers.

The evolution of modeling and component management tools from vendors such as Rational; Select Software Tools Ltd., Irvine, Calif.; Riverton Software Corp., Cambridge, Mass.; Sybase Inc., Emeryville, Calif.; Platinum Technology Inc., Oakbrook Terrace, Ill.; and others point to the fact that the technology pieces are slowly falling into place to make component generation a more civilized exercise than the "bad old days" of Case. Additionally, component standards have begun to evolve. For example, until recently, component specifications, such as COM and JavaBeans, only dealt with the client side. [Ed. Note: Upcoming issues of Application Development Trends will include an update on Unified Modeling Language tools' status and a story on meta data component management offerings.]

Sun Microsystems Inc., Mountain View, Calif., and Microsoft Corp., Redmond, Wash., have begun fleshing out their war of words with real specifications covering server-side components -- the stuff of which multitier business applications are made. Meanwhile, vendors such as IBM are beginning to deliver server component frameworks encapsulating essential functions, such as CICS transaction services or security, and generic business processes such as general ledger, warehouse management and order management.

Yet in spite of, or perhaps because of, the move toward components, it remains difficult to get two or more people to agree on the definition of a component. The most basic definition is that components are bits of modular code, wrapped inside standard interfaces, that identify the component and its behaviors and provide the mechanism for interactions with other like components. Beyond that, almost anything goes. A component could be as modest as a radio button for a user screen, or an order-entry process that in the conventional world might otherwise be called a full application. Using this over-simplified definition, could Microsoft Word be considered a component of Microsoft Office because it has interfaces that the Office suite understands and can interact with other Office applications?

The Barclays project demonstrates that server components come in all shapes and sizes, from a CICS transaction call to a customer service screen. For others, components approach full-size applications, such as the customer management component developed for Sterling Software Inc., Dallas, by Toronto-based systems integrator Castek.

On the other hand, components developed for an Australian government child support system by Tier Technologies range from a validation component that interacts with 13 DB2 tables to a workflow component hitting against only a single table. The story is similar at Emery Worldwide, Redwood City, Calif., where the firm's application contains a shipping component encompassing order entry and shipment specification, and smaller components such as charge amount, business associates, container type, unit of measure and infrastructure services such as event notification.

Getting everyone on board

"Moving to components is more a cultural shift than a technology shift," noted James Chong, vice president for architecture and planning at Schwab. The biggest hurdle is the notion of reuse. At Schwab, it meant convincing business users that their needs could be met by assembling standard components. "Consumers of business logic are always cynical initially because they think that all their processes are unique," said Chong.

Admittedly, reuse is not a new concept. "We've been trying to reuse Cobol and Pascal for a long time, and we have been using lots of application libraries," said Stu Weiss, development manager at Burlington Coat Factory, a Burlington, N.J.-based retailer.

"It helps if everyone places components with the same interfaces. It may help get everyone thinking along the same lines, but that is not the be all or end all," added Weiss. He noted that it is "horrendously complex" to fit multiple business processes together, components or not.

Nonetheless, it can be an uphill battle getting developers on board the notion of developing components and embracing reuse. Admittedly, this may be endemic to making any type of major change.

At Emery, there was initial resistance to the new organizational structure and processes introduced as part of component development. "There was a lot of distrust and skepticism initially among the developers and project leaders. The new procedures were viewed as overhead and threats to their ability to deliver. The benefits weren't immediately evident," said Maja Tibbling, application architect.

For example, at the outset, component-based development appeared to hinder rather than streamline development. The project team initially found itself making mistakes. "We defied the rules of COM, which say that you don't invalidate an interface," said Tibbling. Consequently, recoding was necessary in several related projects that used the modified components in question. Luckily, the error was spotted prior to entering production, she noted.

Gaining developer buy-in often comes from basic structural changes. At Nationsbank, although reuse was not the primary goal of the new component methodology, it was a critical means of achieving faster project cycle times.

Admittedly, technology was also part of the equation. With the idea that component-based development should not add complexity to the process, the bank developed its own development life-cycle workflow wizard in which users check off the type of application -- mainframe, client/ server or Web. The wizard then prompts users at each necessary checkpoint or milestone, starting with activating a project schematic that must be completed, filing documentation, generating artifacts such as object models or test scripts, and the source code itself. The result is the population of the bank's Enabler repository from Softlab Enabling Technologies, Atlanta. Select Software's Component Manager is used as the repository front end.

But more important than the technology was the new process that Nationsbank put into place for the Consumer Finance Group's 375-person I/S group. "We realized that we had to be proactive in promoting reuse," said Keith Barrett, vice president for reusable objects and components.

It is human nature to prefer writing new code; the bank therefore had to put incentives in place to encourage reuse. Each development team is rated on the percentage of projects for which it has satisfied customers after 90 days -- a goal that encourages teams not to waste time reinventing the wheel. The group has also gone as far as to assign several analysts as "reuse evangelists." Their mission is twofold: to sit with teams at the beginning of the development cycle in order to identify prospective components that might be reused, and to examine projects after the fact for components that might have an afterlife.

Obviously, teams must produce components that can stand the test of time. Yet they must also aim for quick, timely delivery. As any grizzled Case veteran will testify, these two goals are at odds with each other. Theoretically, it takes a lot of what-if analysis to determine if a component or chunk of source code will stand the tests of time.

Instead, Nationsbank pushes expediency over analysis paralysis. "I can't ask a developer to build the perfect loan calculator or other component in 90 days," said Barrett. The bank uses a "harvest, refine and publish" approach in which a component developed for a specific project is refined after the fact for future use. It is a solution that balances the need to deliver applications quickly with the realization that the world is not perfect.

At Barclays, this led to a different approach to component reuse, one in which the basic components are kept generic but allowed to be modified for use in applications. "Developers cannot anticipate all of the possible exceptions in advance," said Paul Bassett, senior vice president for research at Netron, which supplied the component framework to Barclays.

For Emery, requirements definition and initial analysis originate with particular project teams, but is then subject to review by the application and component architects. If a broader use can be identified or anticipated, a central group performs further analysis, design and component generation. That group then works closely with business application developers to ensure that the component fits the bill.

"If the components are not managed centrally, you'll end up with something that only works for a particular project and does not achieve maximum reusability, if any," said Emery's Tibbling. The differing approaches to reuse point to one of the few universal truths of component development: There is no silver bullet.

Most   Popular