Not only does technology need to cross silos, governance does, too, points out Unisys' Ott. He advises banks to create a cross-function steering committee around the governance of SOA. While enterprise architects manage SOA procedures, the steering committee should enforce the policies, Ott says.
One best practice is to maintain a center of excellence (COE) group, according to Tibco's Greene. The COE should comprise a cross section of the bank, including IT, business, operations and other areas that may be touched by the SOA project, he says.
Santa Clara, Calif.-based Sun Microsystems offers a solution specifically tailored for COE governance of SOA initiatives, according to Larry Scott, VP of financial services for the vendor. The COE becomes the reference point within the organization for the delivery of specific SOA components, and it also owns the governance going forward, he explains. Sun provides workshops and mentors to ensure a bank's COE is headed in the right direction, Scott notes. Other vendors that offer products and services to support SOA governance include Oracle (Redwood Shores, Calif.), Microsoft, Tibco, webMethods (Fairfax, Va.), IBM and SAP (Walldorf, Germany).
Banking on CIO Leadership
Bank of America delegated governance for SOA to the four CIOs within the organization, the bank's Conroy says. An architecture council, which Conroy chairs, made up of the CIOs controls new technology and new products. "We're very controlled on the products we let in -- we let in on a very specific business case," he relates, adding that new technology has to pass a litmus test: It has to drive a significant amount of revenue, reduce a significant amount of risk or clean up the environment. No new technology can be purchased throughout the bank if the council has not approved it, Conroy stresses.
While Conroy says he has a pretty tight grip on technology and product governance, he's still trying to "work out the kinks" when it comes to governance over services. Service-level agreements across CIO units are the next hurdle, Conroy says, especially figuring out how to price services and allocate costs. "The two things that make SOA hard to do in a big group are governance -- who can generate the requirements and decide what your billing is -- and who pays for it," he contends.
"The ugly little thing about SOA is that there's not very good metering," Conroy adds. In a big organization, figuring out who's really using what services at what service level is a challenge. "That's the fundamental driver of costs," he says, adding that this is something vendors don't discuss because it's "not their problem after the sell."