This column kicked off three weeks ago with an attempt to answer the question, "What's wrong with SOA?" That led to an exploration of a plain-English conceptual model that business leaders can lean to on to keep SOA efforts on track.

To recap:

• SOA is about business processes, not services.

• SOA maps business processes to a software implementation that facilitates stakeholder outcomes and value.

• SOA should be designed to exist in the context of the total built environment (that is, the business environment).

What's wrong with SOA? Nothing that a name change wouldn't fix. We should ditch the SOA acronym, and replace it with a new one: BPOA, for Business Process Oriented Architecture. Only then does what we're trying to accomplish sound like something that makes sense to everyone in the business.

I know; dream on. It's too late to rename SOA. But hey, it was done for PCMCIA, because People Can't Memorize Computer Industry Acronyms. So PCMCIA became the PC Card. Ahh. Now that makes sense. So let's rename SOA to BPOA, and end the confusion around this shiny new thing by pointing out that it is, in truth, the old new thing: alignment of IT to the business.

Last week I promised to move from dissertation to illumination by shining a light on some sterling examples of real-world SOAs. In each case, the IT professionals leading these initiatives understood from the get-go that SOA is more about business processes than services.

They understood and enumerated the business processes their SOA had to map. The result was a collection of business puzzle pieces that, when snapped together, fit perfectly into the total business application puzzle—and which can be easily snapped out and replaced as requirements change.

In some cases these apps stand alone. In others they connect various systems old and new, behind the firewall. In still others the business application puzzle spans the requirements of customers, partners, suppliers, and others on both sides of the firewall, and over the public Internet.

While their implementations differ, they do share a common bond. Each system exists in the context of the total environment. And implementation details are rooted in customer value, which organically drives technology decisions into their appropriate realms.

Up first is Michael Richardson, CTO of Sterling Infosystems in New York, which provides background checks and other employment screening services to HR professionals. Sterling aggregates public and private personal records, and mines them for clients for background checks, employment screenings, drug screening, criminal records checks, and so on.

Their business depends on the integration of myriad networks and data sources—customers, partners, public and private information sources—into a central information system that clients can access on demand. To get there, Richardson's team built, and continues to evolve, an supple application that, in my estimation, is a sterling SOA example.

Listen now to my unedited interview with Richardson, or download it to your iPod or any MP3 player, and listen at your leisure. I'd also love to hear from other organizations which have deployed or are developing SOAs. Write to me.