Something I’ve witnessed many times in many different places, is a confusion between service oriented architecture and the use of services (usually web services).
Separating an amorphous block of code with an interface and JAX-RPC or WCF makes you no more service oriented than you were before. If you can’t administer and evolve the services independently and have a requirement to do so, then it’s not service oriented architecture. You’ve just wasted your time and made your existing situation worse by introducing more complexity, more code that will contain bugs, and made monitoring and diagnosis of problems in live more difficult.
And no, making it RESTful and using JSON doesn’t help either.
Service oriented architecture is difficult and it’s more of an enterprise architecture discipline (when it’s done properly, which is even rarer than proper service oriented architecture) than a developer discipline. Remember, you’re trying to divide, or partition, your business in to autonomous, independent chunks, then realise some of those chunks using IT. All the time remembering that the most important thing you have to remember is complexity kills.
Keep it autonomous. Keep in aligned to the business. Keep it simple; and remember: simple is hard and simple is expensive in the short term, but the benefits you reap in the ability to quickly and cheaply evolve and react to business changes will far exceed the initial investment.
Complicated and large are cheap and easy.