Utter the words, “modeling” and “reuse” among some developers, and you’ll probably get a response not suited for tender ears. These are code words for trying to manage the often-chaotic process of developing software.
Most efforts to reuse software code over the past 20 years languish in obscurity. Remember CASE, the idea of developing software with models? It’s gone in and out of style more often than bell-bottoms.
Modeling tools make it possible to design software projects visually, defining how different chunks of code fit together and what resources they draw on to function. These tools can identify what pieces of needed code are already available, and which still need to be written. Most modern modeling tools even generate “skeleton” software code, creating a frame within which programmers work. But models by themselves don’t do much to help programmers programbecause programmers can’t always color inside the lines drawn by models.
“Two and a half years ago, we were barely using modeling tools,” says Ron Lichty, Charles Schwab’s vice president of Java object services. “We would do models of programs, and then our software architects would notice the gap between our models and code. The code would take off in its own direction.”
That was then. Over the past two years, Lichty’s team has embraced modeling as not just an architect’s tool, but a way to accelerate development of Java applications.
Schwab uses Java to build its Schwab.com Web site, its Active Trader desktop software, wireless trading systems and internal business applications. Over 300 people are involved in Java development at Schwaband their window on all that software is Together Control Center. This came when Lichty and his team looked at ways to make the gap between its models and code go away. They had a few licenses for Rational Software’s Rose, a general purpose software modeling tool, and for TogetherSoft’s Together J, a modeling tool built for team Java software development.
A key feature of TogetherSoft’s software was its ability to “reverse-engineer” modelsscanning source code written by developers, and updating the model for the project to reflect any changes in the structure made in the code. That meant that models could be kept in sync with the codeand models could be created for code that had already been written.
From a developer’s standpoint, says Lichty, “you not only could reverse-engineer the model, but could see changes reflected in real time.” A common modeling tool makes it easier for a developer to move from one project team to another. Documentation is clearer. And developers can confidently reuse other developers’ code. “Good modeling and component reuse are indelibly connected,” says Lichty.
Two reuse projects set up “frameworks” for creating applications for Schwab.com and Schwab’s investment management business, respectively, based on a common set of software code.
A third reuse project, launched July 1, is much larger. It’s creating a “community center” of tools and applications that can be reused. The resources will be tied into the company’s existing systems for managing original source code of Schwab applications, developing new applications and managing the development process. When a component changes, everyone who’s built software that depends on it will be automatically notified by e-mail.
The time required to start new software projects has dropped dramatically, and Lichty’s team handles more projects simultaneously. “We just started work on our 320th project in Java,” says Lichty. “Three years ago, we had 10 projects deployed, and 20 others under way. Today, we have 175 deployed, and another 125 under way, and some of the original projects have been replaced.”
With the markets down (and Schwab’s revenue down with them), that kind of efficiency is even more important. But will that be enough to make modeling second nature to Schwab’s developers? If so, the idea of managing software development may no longer seem quite so contradictory.