In-Depth

Schwab.com keeps tabs on Java code

• By Rich Seeley
• August 1, 2002

Routinely hosting as many as 70,000 simultaneous sessions as the stock market opens each weekday morning, Schwab.com is a front-line financial planning and investment Web site serving 7.9 million Charles Schwab customers. The site's developers, having embraced Java and object-oriented programming techniques, are experienced veterans of all the challenges that Web-oriented development has to offer. One of their conclusions, with some five years and more than 320 customer-facing applications to their credit, is that modeling can bring coherence to the sometimes chaotic task of Java programming. As well, they have found that modeling tools that support collaborative development further streamline the Web development process.

Three-and-a-half years ago, Schwab's IT department decided to move all applications into the Java domain. Ron Lichty, vice president, Java object services, was tasked with making that happen.

''They decided to create a group, which I [had] to create, that would be dedicated to ensure the success of Schwab's transition to Java,'' Lichty explained. ''We've since become responsible for Schwab's reuse efforts and for pulling together a community around stakeholders in Web services; [we've even] started looking into related technologies like XSLT transformations.''

To manage hundreds of Java developers collaborating on hundreds of applications where component reuse is a top priority would seem to be a Herculean task. Lichty traces much of his group's success to the employment of a Unified Modeling Language (UML) tool.

''A little over two-and-a-half years ago, senior management in one of our staff meetings had a conversation about object-oriented programming, the move to Java, and our goals of componentization and reuse; [they] determined that a UML modeling tool was critical to the success of those objectives,'' Lichty recalled.

At the time, the focus was on Rational Rose, but Lichty's group was put in charge of exploring tools. While they had copies of Rational Rose, some of the Java developers began working with a little-known tool with the unlikely name of Together J from a new vendor, TogetherSoft Corp., Raleigh, N.C.

The more Schwab developers worked with Together J (since renamed Together ControlCenter), the more they were able to exploit the features that supported collaboration and component reuse. Lichty said the upstart product had advantages over the more established Rational tool at that time.

''First, it had a user interface that was much more programmer-friendly,'' he explained. ''The second [advantage] was the ability to look at code and UML models and by changing either one, the other would update in real-time. That synchronized design modeling and code.''

The first Schwab developers to try the Together J tool requested it specifically for that synchronicity.

 ''Some of our technical leadership realized that our design documentation didn't match what we were actually putting into production. They bought Together J to basically reverse-engineer the Java code,'' noted Lichty.

Using the UML model that reflected the code eased the job of documenting the wide variety of projects developers were working on for Schwab.com.

The UML tool also had a feature that specifically supported the collaborative development among teams formed from the 400 developers at Schwab, noted Lichty.

''It allows a developer, at any point, to share their design model with another developer without having to go through another step,'' he explained. ''And the UML model always reflects the code regardless of what changes we've made in it. It's a real-time situation.''

This is important especially for the Schwab.com Web site, which requires new application development and revisions to reflect new customer demands and which the company takes pride in keeping customer-focused. Lichty values UML's ability to break applications into their component parts, which allows teams to focus on developing new components while reusing components another group may have already developed.

''Our business changes and our business focus changes,'' he said. ''And as those things happen, that leads us to develop new applications. For example, we have become more and more focused on delivering applications that help customers understand who they are as investors; to understand the kind of risk they are willing to take and the investment they are willing to make relative to who they are as people and as investors.''

What the developers at Schwab have to do is resist the old programmer temptation to listen to a business person describe a need and then just start coding something to meet it. In Lichty's view this is where UML work helps.

''Applications are much too complex to model in your head any more,'' he said. ''And modeling tools help you to think through the translation of business requirements into code without actually getting into that coding step immediately. Models help you think how you're going to break that application you're writing into pieces, components and into classes in the case of Java, and how they connect to each other and interdepend.''

The Schwab development teams have found that with object-oriented programming, they spend more time in the design phase than in the actual coding, especially if they are able to identify components for reuse. Lichty said this requires an adjustment for people coming from a procedural background.

With object-oriented development, noted Lichty, ''You spend much more time thinking through what the objects are and how they are going to interrelate with each other because once you've done that, the code just kind of falls into place. That's not to say it's easier or doe not require thorough thinking through of the code part, but the design part is such that you always know where the code goes and what its relationship is to all the other pieces of code.''

To speed the planning phase and facilitate greater component reuse, developers at Schwab have created two basic frameworks for applications. Within the framework for a Web application certain components are routinely reused, Lichty explained. Teams of developers work routinely with one or the other framework.

''Those frameworks are made up of lots of components that get a lot of reuse,'' he said.

For example, he said, the way in which a customer logs into the application is uniform, so the components for handling user IDs and passwords are usable by every new application. Other components handle the way the communications channel is opened between an end user's PC and the server, while another does the server connections to the customer databases. '

''All those sorts of things are handled by the framework,'' Lichty said. ''So they don't have to be written 20 times.''

At the end of the day, Lichty believes UML work, the creation of the frameworks and component reuse is the reason Schwab's developers have been able to keep up with the demand for new applications.