By far the best introduction for the layperson I've seen on services and SOA is the article What Is Service Oriented Architecture by Hao He at xml.com. It's slightly dated and get's mildly technical at the end, but it gets the idea across in a single page. I particularly like the quote (and indeed personal architecture principle): "Things should be made as simple as possible, but no simpler", by Albert Einstein. Another excellent resource is the ABC's of SOA by CIO Magazine which is a bit longer, but broader in scope and more up to date.
I don't believe that everyone needs to know how the architecture process works within an organization. Indeed, if you're running your architecture as a service, then most don't need to know much at all except what goes in (business desires) and what comes out (wonderful excellent plans and implementations that move the business efficiently forward).
I do believe that the business needs to understand the ideas of architecture, including services and SOA. One of the most effective ways to do that is to define your terms in the context of your enterprise. Services, web services, business services, product, offer, even client can cause all kinds of consternation and risk. Particularly if the groups your communicating with not only don't understand the terms, but where each group and individual applies their own meaning to the terms. Business terms must be understood uniformly across the business.
My humble advice would be: as early as possible, take the time to sit down with your architecture business stakeholders and define these terms. Come to a consensus... even make up common terms if you must, but you must all be on the same page with the same nomenclature in the end. Then, use the terms, and correct mis-usage. The few minutes spent in the exercise will be worth a complete library of books and papers explaining these terms and concepts, and will be invaluable when you meet next time to discuss ideas.