A product management approach to SOA

Deploying an enterprise-wide SOA is not just about developing and deploying components and services -- it’s about changing the DNA and culture of IT to become more product-management oriented.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld Return to "SOA gets real"

While most IT shops talk about meeting the needs of the business, Wachovia’s Corporate and Investment Banking (CIB) CIO Susan Certoma and Tony Bishop, her head of technology product management, talk about SOA as an ongoing process of product development and evangelism -- a methodology for productizing responsiveness to changing customer needs.

“We’ve taken a software vendor product management model -- the product management discipline with its associated life cycle -- and instilled that discipline so I can create that horizontal utility infrastructure,” Bishop explains.

“The developers reporting to the divisional information officers are to some extent our customers,” Bishop continues. “We’ve created this product management team … to prioritize road maps and requirements, to get people to use the components.”

The customer set also includes major clients of the CIB division plus operations, as well as the managing directors who run line of business technology groups, Certoma adds. “They’re all consumers of these core components.” When she was staffing up to kick-start the SOA deployment, she specifically sought technologists with product management experience servicing a diverse set of customers.

Yet Certoma advises against adopting a 100-percent pure product management model for large enterprise SOA deployments. “You have to be very careful about how you implement that product management model,” she says. “It’s a great concept, but we’re not a software company -- we build technology to drive our business.”

In other words, all that work must be mapped to business objectives, she continues. “In other firms, when they forget there’s a business partner and it becomes all about the technology, it’s a slippery slope. We could build some very sharp components, but we have to always ask: Are these the things that are going to drive our business?”

Sometimes tough decisions must be made that break the product management mold entirely, because they’re the right thing to do for the business, rather than for the SOA platform, Certoma acknowledges.

Early on, for example, some groups came to IT and said they needed certain functionality right away and wanted to buy from a vendor who could deliver it immediately, albeit disconnected from the SOA road map. In some of these cases, Certoma says, she gave the go-ahead on an interim basis, but requested double-funding so the functionality could be built on the SOA platform to get the users “back on the road map.”

“That’s why you have to be careful,” Certoma explains. “A pure product management approach would have said, ‘No, we’re not going to let you go off the road map,’” potentially alienating political allies inside the company.

“But because we’re driven by our business and the market,” Certoma adds, “we must make sure not just to get the perfect product out the door that everyone has to wait for, but also to meet the requirements every day. ... It’s got to be a mix.”