Wall Street Firms Turn to Best Practices Models to Speed Up Software Delivery
Waterfall vs. Agile
Mellon's shift to agile software development is part of an emerging trend. "Every investment bank and hedge fund I've spoken to is looking at agile," says Sungard's Chapman. A relatively new term, agile development is based on iterative development — developing software in small, manageable chunks that can be modified as requirements change, yet using a disciplined software delivery mechanism.
Historically, the software development approach used throughout Wall Street has been the "waterfall" method, which calls for strict, lengthy analysis and documentation of requirements. For a one-year project, for example, three to six months might be spent on needs analysis. "The business people are expected to define 100 percent of their requirements up front before the project even starts," Chapman says. "People get stuck in this analysis paralysis — they spend months and months trying to define what they want."
Another three to six months can be devoted to software design, then the actual program finally is written. "Inevitably what happens is requirements change, integration becomes very difficult and all the risky software development happens at the end of the development effort," Chapman explains. "The waterfall approach has a horrible track record of delivery."
Agile software development is designed to deliver software more quickly yet maintain high quality. In agile methods, every two or four weeks, businesspeople get a small amount of code to review and the opportunity to change the requirements. "Imagine a hedge fund where traditionally a new credit derivatives trading system would take a year to build using the waterfall approach, with businesspeople writing six months' worth of documentation versus using an agile approach, where some of the system is delivered in two weeks, and it's OK if you change your mind," Chapman says. "For the hedge funds particularly, agile is an extraordinarily good fit because the portfolio managers want to get things done quickly."
But not every project lends itself to short iterations, Chapman concedes. "On Wall Street it's not so easy because there are a lot of other systems you need to integrate with," he says. "But I think there are parts of agile you can use on every project to improve it."
Agile development has three levels: developer, project and enterprise. "Nobody on Wall Street is using agile at the enterprise level," Chapman says. "A lot of education needs to take place within the banks — it's going to take some time. But I think every project could gain some benefit from trying to break down the project into more-manageable chunks that can be delivered in a more iterative and agile way."
Agile methods even improve software quality, Chapman contends, because they emphasize testing. Agile methods encourage developers to do their own testing, often requiring them to write the tests before they write any code and to develop automated testing routines for the programs they deliver.
"Agile development approaches and CMMI are compliant with each other — you can use CMM and CMMI to make agile software development better," Chapman adds. On the other hand, he asserts, trying to use CMM and CMMI on top of waterfall development approaches will just weigh projects down with bureaucracy and paperwork.
HSBC Attracts Talent Through CMM
HSBC has more than 25,000 IT staffers and develops applications at 16 locations around the world. What used to be done locally now has to be done globally, and IT teams need to work together all over the world to build global systems. Its global technology group — 6,000 people in India, China and Brazil — is in the process of being certified at CMMI Level 5. The major GLT centre in India is already certified to CMMI level 5, China is at level 3, and the China and Brazil groups will progress to level 5 certification.
"When you create one center to do IT development in support of teams that are all over the world, you want to have consistency in process," notes John P. Carr, COO of IT at HSBC Global Group. "We wanted to bring in some level of continuity in the way we do systems development.
In addition to boosting the confidence of the internal IT customers in the offshore groups, Carr also had recruitment goals. "Professional certification adds to your attractiveness to bringing in quality staff," he explains.
So far, the CMMI project has cost $700,000, according to Ignacio Vera, global head of global technology, HSBC Software Development. "We trained about 3,000 staff because it's so important that everybody follow the same methodology in all their processes," Vera says. "You need to show consistency in process — that means that you guarantee almost every time you'll deliver the same quality of software."
The most important benefit has been the calming effect that Level 5 certification has on the stateside IT and business managers, according to Carr. "[CMMI certification] helps settle down the initial nervousness of local IT managers, who are the ones held accountable for final delivery, that they're engaging with an [offshore] IT organization that's more structured and certified than they are," he says.
Further, in the past local IT managers sometimes had to turn requested projects down because they couldn't make a business case for them, Carr continues. Today they can turn to the global tech centers to do that work more affordably. "Being able to say 'yes' to the business, being able to add an IT element to a business case justification that lets us do bigger things for a company that has an insatiable appetite for IT is really what this whole thing is about," Carr says.
The Dark Side of CMM
The Capability Maturity Model has its naysayers. Some feel it introduces a lot of time-consuming paperwork and can get in the way of fast development. "The idea was that CMM and CMMI process improvement would help people develop software better, in a more repeatable fashion. But that hasn't really happened," Sungard's Chapman charges. "What happens is people get bogged down in paperwork, artifacts and documentation, and the net result is the amount of software delivered doesn't increase; neither does the quality."
"That's absolutely what happens up front," admits Mellon's Keslar. "But once people are using these processes in the right way, I would argue with the idea that they're a hindrance or too much bureaucracy." He points out that firms need to be flexible in the way they use CMM; it's not always necessary to follow every process to the letter and fill out every piece of documentation. For example, when doing a recent research analysis project for Mellon's foreign exchange department, using internal data to perform predictive analysis for foreign exchange currency, stock and bond markets, the development group followed the CMM processes very lightly. Keslar asked for and received a waiver for certain CMM deliverables because it was only research.
HSBC's Carr concurs. "At the end of the day, IT teams get measured on one thing: Have they consistently provided a quality deliverable — do we deliver what we said we were going to do for the price and the level of quality that business has come to expect," he says. "While some may look at this as bureaucratic, it's worked for us. ... Business satisfaction has continued to be higher and higher as we mature in this process."
Page 1, Page 2
