Business objects, RPC and separation of concerns

I mentioned the importance of separation of concerns before. From my point of view this is the first thing someone should learn when is doing development. I mention this again because i have inherited a codebase with a shockingly design error (this is a project which was described to me by its PM as a "bleeding edge project"). Basically these guys haven't learned about separation of concerns but they started using the "bleeding edge" WCF to expose their business functionality to their partners. But with a horror inspiring twist....their business objects are their WCF ServiceContracts !!! No separation, no intermediate layer, no orchestration....nothing.
The really hideous part is that this public RPC API requires you to pass "internal" (now of course made public) state objects to work properly. And this is a "bleeding edge" project baby :D.