About a year ago I was working with a project that was massively entrenched in OOP design, specifically using the Domain Model pattern to represent business entities as business objects. They had huge class hierarchy (6 foot) diagrams to go with it with more interconnecting lines than a NY subway map.
Yet throughout my work on that project, one thing that occurred to me is that when we were talking to the business experts we never once discussed these objects. Perhaps in our minds we were thinking of specific objects, but we couldn't talk on those terms to the business experts because it was just so foreign to them.
Right now I'm working on a project based on a service-oriented architecture, or more precisely a service-oriented design. In this project all the data is separate to the objects, and we use schema to define the data entities and then have mostly autonomous services working on or returning that data independently.
And the big difference is that now I can talk to the business experts about the very same data entities that are in my schema. At one point I actually showed them the schema and they understood it instantly. They would even understand the services (by their name and what they act on), and could even make some suggestions.
Perhaps the new model is a simpler system, or perhaps the business expert is more tech savvy. I'm not sure. But I do feel that service oriented architecture lends a lot to opening up communications between developers and business experts - simply because the design isn't centered on polymorphism, inheritance and searching for your business logic deep inside your class hierarchy - it's centered on data and services.
Business experts tend to think in terms of data and service separation. They have a pile of invoices, and they have a good idea of the workflow that those invoices need to pass through. This is how the business is modelled in their heads.
Most SOA designs are very upfront, deliberately simplified in order to keep everything agile and easily understandable to all levels of the corporate structure. They focus on separating the data from the business logic, which is not only great for re-use and scalability, it also seems to be great for getting the business experts interacting more with the development process. And I think that's a very valuable thing.