OppenheimerFunds Gets Return on Investment from Agile and SOA

OppenheimerFunds used to have a data entry efficiency problem. Address changes that customers made on its website had to be manually re-entered into a variety of back-end systems before they went into effect.

“Our business was growing — that was the good news,” said Geoff Youell, the firm’s assistant vice president of architecture. But due to the integration issues, the record keeping side wasn’t scaling very well. “There was a lot of retyping the same information multiple times into legacy systems,” he said.

The company had a choice: to solve this one immediate problem, or to invest a little more time and money in order to plan a little bit further ahead. To decide what to do, the firm sat down with a consultant and thought about where it wanted to be in five years. The main items, Youell said, were taking down the silos, and eliminating redundant processes.

The cornerstone of this strategy was an enterprise service bus (ESB) that would pull together the various parts of the business into a service-oriented architecture (SOA). The project was internally code named “Capstone.”

A single portal would have served the immediate needs of the company, to integrate that one customer-facing application with the databases it needed to connect to, but it wouldn’t have scaled as well.

According to Progress Software CTO Hub Vandervoort, the Sonic ESB allows developers to model the integration, instead of writing pieces of code for each connection. “It’s actually more understandable by business analysts, and more changeable without the same level of complexity of writing and testing Java code,” Vandervoort said.

OppenheimerFunds was already using a WebLogic portal server for its web portal, he said, which works for “hub and spoke” integration. “For small-integration, that may be adequate,” he said. “But with geographically dispersed information, siloed organization, federated in terms of political organization — you’ve got to ask yourself, who’s going to own the center of the universe? You need a highly distributed environment because the topology calls for that, but also the business calls for that.”

ESBs are, by nature, distributed platforms, he said, able to plug into both different legacy systems and different front end systems. On top of that, the compliance, management and security features are built right into the ESB.

“For us, it was about back-end integration and exposing legacy systems,” said OppenheimerFunds’ Youell.

Preliminary research involved looking at the Forrester and Gartner research reports for background information. Youell, who had recently joined the firm, also hired a couple of architects. The team soon had a short list of vendors, and finally picked Bedford, MA-based Progress Software Corp., maker of the Sonic ESB.

The Sonic ESB is built around high-availability containers, Youell said. “Their deployment model — and the pricing strategy — scales very well,” he said. “We have a number of departments and geographic locations, and the way their containers scaled without additional cost was a big thing for us. And the tool set was quite mature — this was about a year and a half ago, and some of the vendors weren’t as mature in this space.”

It’s turned out to be a good decision, Youell said. “They’ve been a good strategic partner for us.”

The first project was that customer-facing address change Web application. “While we had acquired some skills, we were fairly immature with respect to SOA,” Youell said. “We decided that our Web development team — which builds websites for shareholders and advisors — was the best place to start.”

Before, when a customer updated their address using the website, it would take an OppenheimerFunds employee five to seven minutes to process the change. As a result, the company didn’t particularly promote the Web-based functionality. Once the back-end process was automated, the company started to heavily promote the self-service functions available on the website — and soon, 70% of all address changes were coming in over the Web.

“It was a huge marketing win,” he said, and helped build momentum for the SOA project. “One of the reasons for our success, was that right out of the gate we had some legitimate return on the investment.”

Since the address change function was written as a service, it can now be reused in multiple channels. For example, over the next coming months, the company will hook up the telephone customer service center applications to the new address change function.

There was a little additional work involved in making the address change function an SOA service rather than writing it as straight code, Youell said. “But one of the advantages is re-usability,” he said. “All of a sudden, you have that service to re-use through internal channels.”

After the address change, the next service was one to update bank information.

After piloting with the Web development group on these two services to get their toes wet, the Capstone team now went after a bigger target: paper. “The majority of our work comes in electronically, though feeds, but 40% of work comes in as paper,” Youell said. “People mail in an application or transaction, and we image it, and people see that on their screens and type it into their applications.”

The project was to deploy a new imaging application that moved the work around the firm in a more efficient, automated way. Say, for example, a customer sends in a purchase form. Previously, someone would look at it to figure out how to route it. If it needed a Tax ID number, someone would go look it up and type it in.

“The ESB actually spiders out to eight different legacy applications, and if you already had information about [the customer], it would pull that information in to enrich the work items as they move around the organization,” Youell said.

This required integrating the ESB with those applications. There were gateway products available for the legacy systems on the AS/400 and mainframe. The Oracle databases were accessed through JDBC (Java DataBase Connectivity) service calls.

As part of the Capstone project, OppenheimerFunds built a data warehouse. But even without the warehouse in place, the ESB knows where to go to find info and pulls everything out into a common result, Youell said.

The imaging project went live in July, he added, and is now used internally by about 1,000 people in the call center, processing and management groups.

“We looked at that first phase of the Capstone project as foundational,” Youell said. “We installed the ESB and the imaging product, both enterprise-wide installations, both fairly substantial. From there, we decided we wanted to move into fully transformational mode.”

What that meant, in practice, was putting together a wishlist of SOA project, then prioritizing them based on business value. On the top of the list? A project to streamline user interfaces for internal applications. Today, there are 22 legacy applications used, in various combinations, by servicing agents helping customers. Any given employee might need to know their way around a dozen of these.

The new integrated interface will be built using Adobe Flex, using the ReST procotol for the Web services. ReST (representational state transfer) is a Web 2.0-friendly alternative to SOAP, and is heavily used for rich Web applications.

Work on this project started in August, said Youell. The initial rollout will be at the end of this year, and work is expected to be completed by the end of 2009.

Another top priority is a new workflow system. “We have a lot of legacy applications with a lot of manual processes,” said Youell. “So there are a lot of different ways you can service a customer. As part of our goal, we want to standardize the processes.”

The workflow project was launched in September, and will take a couple of years to complete. All together, there are 25 people working on these projects — 10 on the user interface and 15 on the workflow.

The Capstone project has done more than change the way that applications are integrated at OppenheimerFunds — its also affected the company’s approach to the programming process itself. Before Capstone began, OppenheimerFunds used the traditional, “waterfall” model of software development. “SOA has driven us to Agile development,” Youell said. “When you think of the granularity of services, agile takes the same approach. The business needs help you decompose the larger function into the smaller granularity of stories. SOA and Agile played off of each other for us, and helped make our SOA strategy much easier.”

As a result of the switch to Agile development, the Capstone project plan changed as well. “We laid out a business strategy at the beginning which was a multi-year strategy, fitting with the waterfall plan,” he said. “Now, with the Agile process, we’re going to continue to burn with these teams until we don’t get a return on value from them. We’ll keep the development teams on these stories, and we can stop at any point where we don’t think we’re getting value from them.”

Given the current backlog of these “stories,” that will take at least a couple of years, he added.

The technology has led the development teams to think more about business value, Youell said, which was a significant philosophical shift.

The shift to developing discrete services rather than large software projects has brought in some excitement to the firm, he said. “This program has allowed to bring in these new technologies, created a new vibe.” As a result, the technology team had to update its skill set, he said. And it’s not about just learning new programming languages or development appoaches.

“I’m as guilty as anyone else of leading projects with technology, then finding business problems to solve with them,” he said. “Because we led with the business strategy and we know our value proposition, I think it’s help up very well with the senior executives.”

The next step for the company is to look at policy enforcement, create a more robust security model and registry depositories, Youell said. “I think we’re more informed about being able to make those decisions now,” he added.

It’s important to ensure that there’s enough maturity in the model, he said, in documentation, and in being able to trace problems. “Or you could end up with a Wild West situation,” he said. Decisions about governance will be made at the end of 2008 and during 2009, he said.

If the company were to do it all again, it would only do one thing differently: move to Agile development right away, Youell said. “We switched over to the Agile approach in the last three months,” he said. “The first few projects were very waterfall, and could have been broken up into smaller components that would have been less difficult to execute.”