How one bank set realistic expectations for SOA

How one bank set realistic expectations for SOA

Summary: SOA team at New Orleans-based bank builds SOA one measurable step at a time, through close collaboration with the business.

SHARE:

One of the most vexing -- and most criticized -- aspects of service oriented architecture has been trying to establish and measure its impact on business agility.

Whitney Bank, New Orleans. Credit: Wikipedia

Whitney Bank, New Orleans. Credit: Wikipedia

This is the vaunted second phase of SOA, in which results move from more localized benefits, particularly developer productivity stemming from spending less time rewriting code that already exists in available services, or not having to go in and tear apart hard-wired back-end applications because someone needs a new interface.

However, what exactly is business agility?  Faster time to market with new products or services?  Check.  Greater responsiveness to customers?  Check. Ability to rapidly absorb newly merged subsidiaries?  Check.  Ability to rapidly bring new partners or suppliers online? Check. Ability to get real-time or near-real-time information to decision makers? Check.

SOA can play a role in enhancing all of these areas, but it's exact return on investment from a business perspective is difficult to measure. By extension, it's even more difficult to ascertain the contribution of an SOA-enabled infrastructure to the increased revenues that may be flowing in as a result of this greater agility.

This is simply something that's going to take time to work through and figure out as SOA practices mature within organizations. In the meantime, building a business case for a SOA-based transformation requires working with facts close to the ground.

That's the way Stan Limerick, director of technology strategy and architecture for Whitney National Bank in New Orleans, built a winning SOA formula, helping the bank is attaining measurable results on a number of fronts. I recently had the opportunity to speak with Stan about the program, and he explained how the key to Whitney's SOA success is close collaboration with the business -- and setting realistic expectations from the start.

To track the progress of the implementation, Limerick meets every month with the bank's financial managers. "We go through all of the cost-savings aspects of the original business case. To see how were tracking to that. This wasn't a fire-and-forget business case. We're actually tracking month to month, to see if we are realizing the savings and benefits that we expected to see. And so far we slightly exceeded what we had in the business case."

These savings and benefits come from two areas -- cost savings within the technology group, and through operational efficiencies outside of the technology group. "It was based on process efficiencies and staff reductions across the bank, and we built the business case on a percent reduction base versus non-interest income."

While Limerick's team was able to build a strong business case on cost savings and efficiencies, they did not extend that to revenue-generation capabilities, at least not for now. "The business case stood on its own without that, so there was no reason to go there. Those numbers are always going to get pulled into question. We decided it wasn't even necessary, so let's not go there. We were able to give the on-the-line banker a lot more information about their customers, and things like that."

Whitney began its SOA journey in earnest about a year and a half ago, when Limerick sought to address the multiple interfaces and legacy systems, some supported on a mainframe, and representing a range of messaging styles and interfaces. "We had everything from screen-scraping or sockets, you name it. This was our chance to standardize on something, and do it in the same style and form across the bank both for internal applications, as well as ASPs and business process outsourcers."

The scope of the integration was driven by the business units. "It was a highly involved process," Limerick says. "We had a fairly good functional taxonomy of the entire bank. It gave us a good way of lining up requirements for doing product selection and evaluation. The business themselves did the functional scoring, not IT."

The SOA effort was not presented to the business as "SOA," Limerick explains. "We explained to the business that their way of integrating and providing data, as well as integrating applications, is actually hindering them in several ways. If they wanted to go in and change suppliers, it was a significant effort, because they had all point-to-point interfaces, and we had to figure out what all would be impacted by that change. If we could get that decoupled, then they would have a lot more leeway in moving to better suppliers to give them competitive edge in market changes."

The SOA-based infrastructure enables business users to more easily swap out suppliers as needs change. "It gave the business guys a lot more leeway than what they would before," Limerick says. "It helped us on introducing new products, because its a much simpler environment." Limerick says the bank currently has less than a third of the interfaces it once had -- numbering more than 850. "This means that I can actually make changes and improvements in the environment much faster than I could before."

The new SOA-aware core banking application was built on IBM's WebSphere Process Server, IBM WebSphere DataPower appliances, and WebSphere Service Registry and Repository.

Topics: Browser, Banking, Enterprise Software, Software, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

0 comments
Log in or register to start the discussion