Selling the dream

SOA isn't the first all-purpose cure all for IT woes. To get past the cynicism, focus on deliverables and bypass the technical details

Do businesspeople really want to hear IT promote yet another wonderful technology that will solve all their problems? SOA pitches tend to have a familiar ring. The past is littered with three-letter acronyms that never worked as advertised.

The key to getting a buy-in is to explain SOA not as a technology, but as a way of operating the business more effectively by being process-oriented, says Anne Thomas Manes, a Burton Group analyst. “SOA is a business activity,” she notes.

Understanding and speaking the business language is the key to getting executive buy-in, especially when the IT group has a track record for past success, notes Santosh Mohanty, SOA practice director at Tata Consultancy Services. He’s seen that understanding begin to take root and, consequently, the proportion of IT-driven SOA efforts shift from 90 percent a few years ago to perhaps 75 percent today. In a few years, he expects that to drop to 50 percent.

Another key way to gain buy-in is to make careful promises and put in place the metrics to gauge whether you’re satisfying them, suggests Prashanth Ajjampur, chief architect at The Hartford insurance company. Such discipline and self-confidence go a long way toward gaining executive endorsement, he notes.

Depending on the technical acumen of the business side, you may not even care to bring up the SOA acronym. Focus on the payoffs of business agility, not on architecture or technology. Along the way, give examples of what that means: faster time to market for applications the business knows it needs and wants.

It also helps to note that easier collaboration between business and IT will be one likely result of SOA. Instead of creating huge requirements documents, business can actually help design composite applications, in some instances using graphical tools.

And of course, there's the kicker: long-term cost reduction. Shared use of services lowers development and licensing costs, and (depending on the industry and the architecture) you may also be able to respond to shifting compliance regulations by making minor adjustments to services rather than bolting on new, expensive, unwieldy solutions.

Back to intro | Next: Hammering out the architecture