Many organizations out there don't really have to sell SOA. They understand that hype is the driver, and, in essence, leverage the thousands of articles and books on the topic to sell this architectural pattern.

However, in most cases SOA has to be sold in the enterprise. If you're doing SOA right, you'll find that the cost quickly goes well into the millions, so you'll need executive approval for that kind of spending. However, the benefits are there as well, including the core benefit of agility that could save the company many times the cost of building a SOA. Or, at least, that's the idea.

How do you sell SOA? Let's look at a few key concepts, including:

• Shining a light on existing limitations
• Creating the business case
• Creating the execution plan
• Delivering the goods

Shining a light on existing limitations refers to the process of admitting how bad things are. This is difficult to do for most architects, because it can expose you to criticism. You're in charge of keeping things working correctly, and now you have to explain why things aren't working as they should or could. If it's any comfort, the architecture in most Global 2000 companies needs fixing. You can't change the architectures; they're too complex and ill-planned. If your architecture has issues, and they all do, now is time to list them.

This is analogous to admitting that you're 20 pounds overweight before going on a diet, or admitting you have a substance abuse problem before taking the famed 12 steps. In essence, you're defining your issues and so have a clear understanding of the problems before you attempt to fix them.

Creating the business case refers to the process of actually putting some numbers down as to the value of SOA to the enterprise or business. This means looking at the existing issues (from the previous step), and putting dollar figures next to them. For instance, how much are these limitations costing the business, and how does that affect the bottom line? Then, how will the addition of SOA affect the business - positively or negatively?

Put numbers next to the core values of reuse and agility. You'll find that agility is the most difficult concept to define but has the most value for those building a SOA. Then, if the ROI for the SOA is worth the money and the effort, you move forward. This tactic communicates a clear set of objectives for the effort and links the technical notion of SOA with the business.

Creating the execution plan refers to the detailed plan that defines what will be done, when, by what resources, and how long it will take. This is basically a project plan, but most people will find that the systemic nature of SOA requires that a great many resources work together to drive toward the end state. Leveraging and managing those resources is somewhat complex, as is the project management aspect of SOA.

Delivering the goods just means doing what you said you would do. Execution is where most SOAs fall down. However, if you fail to deliver on time and on budget, chances are your SOA efforts won't have credibility in the enterprise, and future selling will be impossible. So, say what you'll do, and do what you say.

Selling SOA is more of an art than a well-defined process, as you've seen. It really requires a certain degree of understanding, including the technology, the business, and the culture of the enterprise. Most important to the project, selling needs to be followed up with delivery and the value. That's the tough part.