Here are some notes from a "brown bag" talk that I am preparing for our IT staff, many of whom are died-in-the-wool mainframe COBOL programmers. This talk will be far more evangelical then technical, and I hope that it will de-mystify SOA for some. I'm sure many of you will say "Duh!" when you read some of the points, but you'd be surprised how many folks just don't get it (yet).

I like the following definition of SOA from a paper by Bernhard Borges, Kerrie Holley and Ali Arsanjani, but it's a bit over-the-top as an introduction:

SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.

I think it works better if I break down the definition as follows:

SOA is an architectural style that encourages the creation of loosely coupled business services

Loosely coupled services that are interoperable and technology-agnostic enable business flexibility

An SOA solution consists of a composite set of business services that realize an end-to-end business process

Each service provides an interface-based service description to support flexible and dynamically re-configurable processes

I’d like to get across the following points about SOA:

1. SOA isn’t really new, but there are now some standard technologies (such as Web Services) that make it much easier to implement
2. The “Services” in SOA are business services… updating a loan application is a business service, updating a record in a database isn’t
3. Services are linked together to implement business processes... Business Process Engines make it easier to combine services into business processes, and BPEL is an emerging standard language for this purpose
4. Business partners can use your company's services within their own business processes and your company can use services provided by business partners within your own business processes.
5. SOA solutions favor flexibility over efficiency... machine cycles and network traffic are less important then being able to quickly implement and change business processes

On the implementation front, we need to clear up the following common misconceptions:

1. Services aren’t tied to user interfaces. User interfaces invoke services. Many user interfaces can use the same service. A partner may build a user interface on top of a your service, and you may build a user interface on top of a partner’s service.
2. Services can be implemented in any language, COBOL, Java, etc., but all services must support the same invocation/communication protocols (for example XML/SOAP).

Perhaps that's a bit more information then you can get across in one elevator ride, but it's close.

If you could add one more point, what would it be?