Mortgage Company Cashes in on Web Services: Page 6 of 16

The problem was that Freddie Mac's batch systems--like many other batch systems at other enterprises--weren't good enough. "These systems will tell you about what happened yesterday, rather than saying what was happening now and what will happen tomorrow," Potosky says. "It wasn't meeting our needs or our customers' needs." Freddie Mac was also spending a great deal of time training customers on proprietary systems.

Vital Statistics Click to enlarge in another window

The private extranet provided a proving ground for debugging its interactive applications, and also was important in modeling user behavior. In fact, Freddie Mac learned that the interactive world was an entirely new environment, and more important, learned what was different about servicing interactive users and how to build its systems around these needs. "We found that the behavior of the interactive users cannot be predicted," Potosky says. "As we gave the customers these new capabilities, they found a lot of different ways of using it than we had anticipated. That caused some interesting system behavior, including performance issues."

Freddie Mac had to develop new diagnostic routines to trace these problems, and also understand the various interactions of its apps as users logged in online. "Since then, we put in the ability to turn debugging and tracing capabilities on and off in all our applications," Potosky says. "The problem is that we ask for 400 different data elements for some of our more complex transactions. So one user session can kick off a hundred different interactions. This isn't like ordering a basketball from an online retailer."