Schwab.com keeps tabs on Java code
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
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
''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
''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.
Rich Seeley is Web Editor for Campus Technology.