For non technical people I would use the following concept. The whole professional world is service oriented.

• Instead of baking a cookie by youself, you go to the baker.
• Instead of trying to cure yourself, you go to the doctor.
• Instead of writing a program, you ask a programmer to do this for you.

This implies two major advantages:

• Each one does his job better than if we all were trying to solve all our tasks separately.
• There is a way, which allows non professionals to communicate with those, who will solve our task (in real world such way is money and business contracts)

In the world of software such architecture is implemented by defining specialized services (applications) which are dedicated to perform specific tasks and by defining protocols, which are solving problem of communications between such applications. When such architecture is deployed, you get some benefits, which can be also mapped to the real world:

• If doctor is unavailable, you cannot be cured but at least you can get a cookie from the bakery! In software this means one failed service does not break the whole system.

• Usually doctors and bakers do not share the same room and this allows them to operate better. Just like in software you can place each service on its own hardware.

For software world this means, better availability, maintainability, reuse, and reduced costs. Good luck!

"SOA is like hiring new employees when the job gets too large for the current team." Each part of the whole system is analogous an employee. Managers understand employees ;)

Maybe you have some applications in your company to use as a demonstration.

Try to show them the big picture with lots of loosely dependent services with some common needs/features created by various teams, and pulling out those embedded but commonly used features and use them as service providers.

The other thing that came into my mind is to show them the various connectors that the services can use to communicate (maybe there are some really old screenscraping legacy apps). Also, the message bus concept with normalizing and transaction handling needs to be clarified. In my opinion, non-technical people should see this whole SOA concept as loosely coupled services talking to each other with any kind of messages, where services are written/managed/governed by different teams (so formal service declarations and SLAs can come handy).

Try to avoid mentioning vendors, if possible. Or mention lots of vendors and technologies for each part in order to show them the various options.